Re: org-mime - issues and remarks

["Eric Schulte" <schulte.eric@gmail.com>]

David Maus <dmaus@ictsoc.de> writes:

> At Mon, 26 Apr 2010 10:04:12 -0600,
> Eric Schulte wrote:
>> David Maus <dmaus@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%ucecesf@ucl.ac.uk
> --
> OpenPGP... 0x99ADB83B5A4478E6
> Jabber.... dmjena@jabber.org
> Email..... dmaus@ictsoc.de