Dave asked the question - does DKIM work with IDNs. The simple answer is
"no" because IDNs themselves don't really work today, as a practical matter,
in the context of email. What is clear is that folks from DKIM need to track
and perhaps influence EAI.
Sounds to me like we have a confusion of TLAs. IDNs, that is, Unicode
domain names, work just fine. There is a standard, well defined, and
widely implemented way to translate between Unicode and punycode. If you
want to use an IDN as the d= domain or a selector, or even as the domain
part of i=, it is quite clear what should happen, and existing signing and
verifying code will handle it correctly since it's no different from the
handling of any other domain. I could imagine ways that provisioning
systems might be broken, but I'd be surprised if there were any that
didn't do the right thing if you typed in the xn--blah punycode version of
your IDN.
EAI, on the other hand, general non-ASCII e-mail addresses, don't work at
all, and I think we agree that they don't work in DKIM just like they
don't work anywhere else.
In 7-bit, we have two forms of encoding available: punycode for domain names
in the from line and MIME for the rest. To date, we have confused
implementations, Apple Mail being one clear case.
Right. There's no standard, so it's not surprising that different MUAs do
different random things. We can hope that the EAI WG will eventually
disgorge a usable spec and that MUAs will implement it.
Again, in answer to Dave's question, this situation is ripe for a mess,
and closer collaboration with EAI might help.
Agreed, but it's not just a DKIM mess, it's a general mess.
Regards,
John Levine, johnl(_at_)iecc(_dot_)com, Primary Perpetrator of "The Internet
for Dummies",
Information Superhighwayman wanna-be, http://www.johnlevine.com, ex-Mayor
"More Wiener schnitzel, please", said Tom, revealingly.
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html