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.

> >
> > 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.

>
> >
> >   - 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'.

HTH
 -- David


[1] mid:87hbndq0ym.wl%ucecesf@ucl.ac.uk
--
OpenPGP... 0x99ADB83B5A4478E6
Jabber.... dmjena@jabber.org
Email..... dmaus@ictsoc.de