> 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, [email protected], 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
