On Thu, Feb 25, 1999 at 13:00:34 -0500, Vikas Agnihotri wrote:
> > MIME-Version: 1.0
> > Content-Type: multipart/mixed;
> > boundary="PART-BOUNDARY=.1990225092640.ZM8086.BelWue.DE"
> > Content-Transfer-Encoding: quoted-printable
>
> If this header line is not present, everything works fine. Mutt indeed
> displays the parts of the multipart attachment properly.
>
> Is this a problem? Should multipart/ messages have a c-t-e header in
> the top-level? Each part already has its own c-t-e, right? Anyway,
> Mutt should deal with it more gracefully.
Multipart messages may have a c-t-e header, but only the identity
encoding (i.e. the values 7bit, 8bit, binary) is allowed. All other
encodings are clearly and explicitly disallowed. But nevertheless
some broken MUAs encode multipart messages, and therefore mutt will
try to decode them. However in this case the c-t-e header was not
even illegal, it was also lying: the multipart message wasn't
QP-encoded. Therefore it will be malformed after mutt's attempt to
decode it. Especially are the boundary lines which in this case
contain an equal-sign not any longer recognizable, so Mutt doesn't
find any parts after decoding, and cannot display anything!
I'm not able to see how Mutt should deal more gracefully with such
a message.
> Could this also be a problem? Shouldnt multipart mails start with the
> 'boundary' string and nothing but?
No, that's not a problem. RFC 2046 says about this:
There appears to be room for additional information prior to the
first boundary delimiter line and following the final boundary
delimiter line. These areas should generally be left blank, and
implementations must ignore anything that appears before the first
boundary delimiter line or after the last one.
NOTE: These "preamble" and "epilogue" areas are generally not used
because of the lack of proper typing of these parts and the lack of
clear semantics for handling these areas at gateways, particularly
X.400 gateways. However, rather than leaving the preamble area
blank, many MIME implementations have found this to be a convenient
place to insert an explanatory note for recipients who read the
message with pre-MIME software, since such notes will be ignored by
MIME-compliant software.
Regards,
- Byrial
