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="" For SEMI (replace _ by -): __[[type/subtype content-disposition: attachment; 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