[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Orgmode] org-mime - issues and remarks

From: David Maus
Subject: Re: [Orgmode] org-mime - issues and remarks
Date: Tue, 27 Apr 2010 20:14:12 +0200
User-agent: Wanderlust/2.15.9 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (Goj┼Ź) APEL/10.7 Emacs/23.1 (i486-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO)

At Mon, 26 Apr 2010 10:04:12 -0600,
Eric Schulte wrote:
> David Maus <address@hidden> 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; 
| 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

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

 -- David

[1] mid:address@hidden
OpenPGP... 0x99ADB83B5A4478E6
Jabber.... address@hidden
Email..... address@hidden

Attachment: pgp2ekA2MyVBB.pgp
Description: PGP signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]