Well, that's simply and completely false.
The message format specification(s) have no dependency on the email transport
mechanism.
Huh. When I look at RFC 822, section 3.1 says:
The body is simply a sequence of lines containing ASCII charac-
ters. It is separated from the headers by a null line (i.e., a
line with nothing preceding the CRLF).
If a message uses 8BITMIME, there are characters in the body that are
not ASCII. It does not conform to RFC 822, it's a different format.
If you feed an 8BITMIME message to an RFC 822 mail system, random bad
things can happen, particularly back on PDP-10s where we stored five
7-bit characters in 36 bit words.
By the time we get to RFC 5322, there is a paragraph of waffle in
section 2.1 that says that non-ASCII stuff is described somewhere else
and "Discussion of those mechanisms is not within the scope of this
specification." I suppose we can have a metaphysical argument about
what you call something that exists but we pretend for now that it
doesn't.
EAI adds another level of version, by redefining the address syntax so
domains can be U-labels, local parts can be any UTF-8, and most places
in mail headers that can contain text can be UTF-8. Again, if you
feed one of these to a 5322 mail parser, even an 8BITMIME parser, it
won't work. It's a new version of the message format.
In both cases the new versions are backward compatible with the old
versions, but so what? They're not forward compatible, you need some
sort of version flag to avoid feeding new messages to old parsers.
Regards,
John Levine, johnl(_at_)taugh(_dot_)com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html