David Maus <dm...@ictsoc.de> writes: > At Mon, 26 Apr 2010 10:04:12 -0600, > Eric Schulte wrote: >> David Maus <dm...@ictsoc.de> writes: >> >> > While skimming the source code of org-mime I noticed two severe issues >> > with regards to the MIME specifications: >> > >> > - when creating an attachment for a image org-mime (still) uses the >> > file extension as MIME media subtype for Gnus messages. This not >> > in compliance with RFC 2046. As mentioned before org-mime >> > should/could use the function to determine MIME media type of >> > message-mode and mime-edit-mode respectively. >> > >> > For SEMI the function is `mime-find-file-type', called with the >> > file name as argument and returns a list whose first element is a >> > string with MIME media type and second element is MIME media >> > subtype. >> > >> >> Alright, >> >> once I find the appropriate similar function in mml/gnus I will make >> this change. > > Well, I tried to change it for SEMI but this would require a complete > rewrite of `org-mime-replace-images' because `mime-find-file-type' > modifies the match-data and the `replace-regexp-in-string' get's > confused (i.e.: throws an error). I'll see if I can come up with > something w/o rewriting to much. >
The `save-match-data' macro should fix this. > >> > >> > Furthermore there are some minor glitches: >> > >> > - the "filename" parameter is only defined for the >> > content-disposition header field; because images are attachments >> > they can/should be easily send with >> > >> > content-disposition: attachment; filename="<filename>" >> > >> > For SEMI (replace _ by -): >> > >> > __[[type/subtype >> > content-disposition: attachment; filename="<filename>"][base64]] >> > >> >> could you expand upon this point, what's the problem? > > Hm. I noticed that in the test mail of Eric Fraga[1] images where attached > as: > > ,---- > | Content-Type: application/octet-stream; type=image/png > | Content-ID: _home_ucecesf_s_test_mip.png; > filename="/home/ucecesf/s/test/mip.png" > | Content-Transfer-Encoding: base64 > `---- > > I.e. with the 'filename=' parameter in the Content-ID MIME header > field. That wouldn't be correct or, say, not entirely correct because > the filename option is only defined in a Content-Disposition MIME > header field. So, the old story: It's out of the scope of MIME so you > don't know what receiving clients will do. > > Anyway, org-mime currently does not put a filename parameter at all so > what's only left is to send attached images with SEMI is Disposition: > attachment like Gnus does. > > The difference: The Content-Disposition MIME header field contains an > optional hint for the receiving MUA what to do with attached files. > > - 'inline' :: Show attachment without user interaction. > > - 'attachment' :: Show attachment only with explicit user > interaction. > > For the attached images we don't want them to be shown without user > interaction but rendered in the html markup. Sending them with > Disposition: inline could result in a MUA showing the images inside > the html markup and again maybe at the bottom of the message. > Alright, it shouldn't be hard to add the "attachment" content disposition to the attachment strings. And if I'm reading you correctly we should also place a filename parameter in the "Content disposition" header? > >> >> > >> > - org-mime uses `reporter-compose-outgoing' to open a new message >> > draft. This is not a could solution because (a) org-mine does not >> > want to send a bug report and (b) would depend on reporter.el >> > without necessity. >> > >> >> I don't think this is a problem, I think reporter.el is the best >> approach here. > > Yes, I admit this is somewhat pedantic and hypothetical: If you depend > on reporter that you should say so (require 'reporter) and you will > depend on this particular implementation of > `reporter-compose-outgoing'. As soon as this function does something > else or something more, strange things might happen. It's like taking > a detour: When we prepare the message draft we already know which > functions are required depending on `org-mime-library'. > The (require 'reporter) string is present in org-mime.el, so I think we're all set here. Thanks -- Eric > > HTH > -- David > > > [1] mid:87hbndq0ym.wl%ucec...@ucl.ac.uk > -- > OpenPGP... 0x99ADB83B5A4478E6 > Jabber.... dmj...@jabber.org > Email..... dm...@ictsoc.de _______________________________________________ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
