Thanks a lot for the reference, Jeff. Now I don't feel too bad not supporting it :).
I saw this email in Exchange's streaming store (.STM). Unfortunately it doesn't have any indication of what MUA or some WebMail interface was used.
This is the first time I saw "message/rfc822" mixed with "attachment" disposition and a filename. I am wondering if that was the reason that the MUA chose base64 because it might assume that the mime part here would be treated as a regular attachment, which is how Outlook Express renders this message.
I will keep an eye on it and see if there are more than just a couple of these odd cases.
Thanks again.
- Junping
-----Original Message-----
From: Jeffrey Stedfast [mailto:fejj novell com]
Sent: Thu 2/25/2010 8:06 PM
To: Junping Zhang
Cc: gmime-devel-list gnome org
Subject: Re: [gmime-devel] 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