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