On Thu, Oct 20, 2011 at 11:55:43AM -0400, Wietse Venema wrote:
> John R. Levine:
> > > 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
falls away...
--
Viktor.
