org-mime - issues and remarks

org-mime - issues and remarks

[David Maus]

[-- Attachment #1.1: Type: text/plain, Size: 2056 bytes --]

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.

  - when creating an attachment for a image org-mime uses the path to
    the image for the value of the content-id header.  This violates
    RFC2045, section 7.

    The value of the content-iD header field is syntactically
    identical to the message-id header.

    addr-spec   =  local-part "@" domain

    For SEMI the function for creating a message-id string is
    `wl-draft-make-message-id-string' that is called without any
    argument and returns a shiny new message-id header field value
    /with/ the angle brackets.

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

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

  - org-mime /should/ add information to the user-agent mail header
    field indicating that the message was created with the help of
    org-mime.

HTH
 -- David
--
OpenPGP... 0x99ADB83B5A4478E6
Jabber.... dmjena@jabber.org
Email..... dmaus@ictsoc.de

[-- Attachment #1.2: Type: application/pgp-signature, Size: 230 bytes --]

[-- Attachment #2: Type: text/plain, Size: 201 bytes --]

_______________________________________________
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

Re: org-mime - issues and remarks

[Sebastian Rose]

Hi David,


David Maus <dmaus@ictsoc.de> writes:
>   - 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.


reporter.el is part of emacs. Imagine an Emacs without reporter :)

Org-mime _will_ depend on something, won't it?



  Sebastian

Re: org-mime - issues and remarks

[Eric Schulte]

Hi David,

If I find some time, I'll certainly take a look at these.  More comments
below.

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.

>
>   - when creating an attachment for a image org-mime uses the path to
>     the image for the value of the content-id header.  This violates
>     RFC2045, section 7.
>
>     The value of the content-iD header field is syntactically
>     identical to the message-id header.
>
>     addr-spec   =  local-part "@" domain
>
>     For SEMI the function for creating a message-id string is
>     `wl-draft-make-message-id-string' that is called without any
>     argument and returns a shiny new message-id header field value
>     /with/ the angle brackets.
>

I agree it would be good to use existing and spec conforming functions
for the id construction.  Again I will need to find the analogous
mml/gnus function to the function you mention above.  One issue here is
the need to ensure that the first three letters of the ID are CID to
resolve HTML links from within the article.

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

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

>
>   - org-mime /should/ add information to the user-agent mail header
>     field indicating that the message was created with the help of
>     org-mime.
>

Agreed, this would be a good thing to add.

Patches welcome :)

Thanks for the thoughts -- Eric

>
> HTH
>  -- David
> --
> OpenPGP... 0x99ADB83B5A4478E6
> Jabber.... dmjena@jabber.org
> Email..... dmaus@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

Re: org-mime - issues and remarks

[David Maus]

[-- Attachment #1.1: Type: text/plain, Size: 3936 bytes --]

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

[-- Attachment #1.2: Type: application/pgp-signature, Size: 230 bytes --]

[-- Attachment #2: Type: text/plain, Size: 201 bytes --]

_______________________________________________
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

Re: org-mime - issues and remarks

[Eric Schulte]

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