On 1 February 2001, Wietse Venema <wietseporcupine.org> wrote:
> Liviu Daia:
> > > > The only simple case is when mail is not MIME formatted.
>
> > > Actually for MIME formated input, MIME formated output is
> > > acceptable therefore it's quite "simple" to encapsulate the
> > > input message into a MIME message/rfc822 section of a new output
> > > message, with another text/plain section (before or after, as you
> > > like).
>
> > Actually, as I explained in a previous incarnation of this
> > fascinating thread, it _isn't_ that simple, because of the
> > requirement that the top level body shouldn't have embedded
> > multiparts with non-trivial encodings. I can lookup and quote the
> > verse of the relevant RFC if you want me to.
>
> That could help. This topic needs to be addressed in the FAQ and you
> could save me some time.

    Ok, here it is. Basically, it should work in an ideal world, but
not in the real one. As usual, the devil is in the details. RFC 2045:

: 6.4. Interpretation and Use
:
: If a Content-Transfer-Encoding header field appears as part of a
: message header, it applies to the entire body of that message. If
: a Content-Transfer-Encoding header field appears as part of an
: entity's headers, it applies only to the body of that entity. If
: an entity is of type "multipart" the Content-Transfer-Encoding
: is not permitted to have any value other than "7bit", "8bit" or
: "binary". Even more severe restrictions apply to some subtypes of
: the "message" type.
[...]
: 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.

RFC 2046:

: 5.2.1. RFC822 Subtype
[...]
: No encoding other than "7bit", "8bit", or "binary" is permitted for
: the body of a "message/rfc822" entity. The message header fields
: are always US-ASCII in any case, and data within the body can still
: be encoded, in which case the Content-Transfer-Encoding header
: field in the encapsulated message will reflect this. Non-US-ASCII
: text in the headers of an encapsulated message can be specified
: using the mechanisms described in RFC 2047.

    What all this means is that enclosing a message as an
"message/rfc822" attachment is possible, provided that the enclosed
message itself is legally encoded, and subject to some 8-bit fun with
headers. However, some broken mailers (f.i. Sun's Mailtool and at least
two Windows MUAs) send multipart messages with the top body encoded as
Base64. Most MIME-aware MUAs can handle this situation, but _won't_
decode those messages when attached as "message/rfc822". So adding the
signature attachments would break things even further.

    Enclosing non-MIME messages can be another source of fun. RFC 2045
again:

: 4. MIME-Version Header Field
[...]
: Note that the MIME-Version header field is required at the top
: level of a message. It is not required for each body part of a
: multipart entity. It is required for the embedded headers of a
: body of type "message/rfc822" or "message/partial" if and only if
: the embedded message is itself claimed to be MIME-conformant.

This situation is more common than it looks, since most CGI scripts that
send mail reports etc. don't bother to add a MIME-Version header.

    Finally, mixing 7-bit with 8-bit attachments might impose unexpected
restrictions on the enclosing message itself:

: 6.2. Content-Transfer-Encodings Semantics
[...]
: The proper Content-Transfer-Encoding label must always be used.
: Labelling unencoded data containing 8bit characters as "7bit" is
: not allowed, nor is labelling unencoded non-line-oriented data as
: anything other than "binary" allowed.

Any "8bit" attachment, if not re-encoded, would thus force the enclosing
message to "binary".

> By the way, does this also mean that a Message/Rfc822 that is sent
> in a bounce message ought to be reformatted if it has a non-trivial
> encoding?

    No if it was legally encoded, yes if it wasn't. Also yes if it
contains 8-bit junk in headers.

> That would be gross, but nothing surprises me anymore.

    Agreed.

    Regards,

    Liviu Daia

-- 
Dr. Liviu Daia               e-mail:   Liviu.Daiaimar.ro
Institute of Mathematics     web page: http://www.imar.ro/~daia
of the Romanian Academy      PGP key:  http://www.imar.ro/~daia/daia.asc

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]