Re: org-mime - issues and remarks

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

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