Re: [gmime-devel] help on "message/rfc822" with base64 encoding

[Jeffrey Stedfast <fejj novell com>]

Title: help on "message/rfc822" with base64 encoding

On 02/25/2010 04:44 PM, Junping Zhang wrote:

Jeff,

  I am using gmime-2.4.11, and it doesn't seem to handle message attachment case like this:


    Content-Type: message/rfc822
    Content-Transfer-Encoding: base64
    Content-Disposition: attachment; filename="whatever.eml"

    MIME-Version: 1.0

    <base64-encoded-plain-text-message-here>


  In this case, after constructing the message with the GMimeParser from an .EML file, after
     GMimeMessage *gm_msg = g_mime_message_part_get_message(gm_msg_part);
I can't retrieve the regular properties from the message object.

  This case itself is rather rare, and I don't know if the "attachment" disposition should
overwrite "message/rfc822" and make it a regular attachment. But I think in this case the
problem is with the non-7-bit encoding that usually goes with "message/rfc822" type, which
is not too rare.

This is unsupported by GMime as it is expressly forbidden in rfc2045 and since I have never ever come across any messages that do this in the wild, it was assumed that this sort of message did not occur in the wild either.

from rfc2045:

   Certain Content-Transfer-Encoding values may only be used on certain
   media types.  In particular, it is EXPRESSLY FORBIDDEN to use any
   encodings other than "7bit", "8bit", or "binary" with any composite
   media type, i.e. one that recursively includes other Content-Type
   fields.  Currently the only composite media types are "multipart" and
   "message".  All encodings that are desired for bodies of type
   multipart or message must be done at the innermost level, by encoding
   the actual body that needs to be encoded.


What mail client(s) are actually exhibiting this behavior?

Jeff