Specify MUST, but clarify that this is just for now and may be revisited
at a later time -- for example, if the SMTP protcol design community ever
backs down and accepts DJB's approach to the 8-bit message problem
(<http://cr.yp.to/smtp/8bitmime.html>, essentially that it is OK to break
any remaining 7-bit enforcing servers). They probably won't ever, but
just in case...
If you were following the EAI work, you'd know that they probably will do
that within the next couple of months, albeit with an SMTP flag so servers
and clients can tell whether a hop is 8-bit UTF or legacy. They
specifically do NOT provide any downgrade mechanism -- if a path isn't EAI
from end to end, the message can't be delivered. (Please read the many
years of archives of the EAI list, in which they tried every imaginable
approach via many experimental RFCs and a lot of running code, before
commenting on the wisdom of this approach.)
I beseech this group to refrain from hypothetiecal guesses about what some
of us might think would be a good idea to address some anticipated
problem, even though nobody has tried it. It was a mistake in the mailing
list so-called BCP, and it would be a mistake here.
There will be DKIM signatures on EAI messages. It is pretty obvious how
to do it, and in the few corners where it's not obvious, we won't know the
right answer any better than anyone else until we've tried it and seen
what happens.
Regards,
John Levine, johnl(_at_)iecc(_dot_)com, Primary Perpetrator of "The Internet
for Dummies",
Please consider the environment before reading this e-mail. http://jl.ly
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html