Post by Wietse Venema Post by John R. Levine Post by Wietse Venema
in draft-ietf-eai-rfc5335bis-12.txt. While Victor is too specific
about message/rfc822, the draft explicitly allows transfer-encoding
of message/global, which is just as problematic as allowing
message/rfc822 non-identity encoding.
Yes, it does, although that's the best of a bad lot. People are going to
send EAI messages as attachments, some of the mail they're attaching it
to will be 5322. What else could they do? Tell people to hide them
inside base64 encoded zip files?
Once you allow non-ascii headers, you break compatibility with
existing infrastructure, so you break other things to work around
it (with "you" not specifically aimed at John R. Levine, btw). For
security's sake I'd prefer if they had broken the 8bit header rule
instead of MIME.
Indeed, I consider radically changing the design of MIME (composite
MIME entities are never subject to transfer encoding) a much more
substantial change than any change in the details of SMTP or
character restrictions on RFC822 headers.
There are a lot more MIME readers than MTAs, and fundamentally
changing MIME is going to cause breakage near and far from the MTA.
Having written a number of MIME parsers, a few of them security-oriented
normalizers, I can assure you that these took the MIME design
promise (of single-pass parsing of composites without nested
decoding) seriously, and messages that violate such promises are
and will be treated with prejudice.
I'll try to take a look at the final RFCs when I get the chance. If
the "<address1 <address2>>" syntax is gone, perhaps that objection