On 3/2/10 7:45 PM, John Levine wrote: >> "The domain part of email addresses is already internationalized >> [RFC3490], while the local part is not." > Right. There is a standard way to encode Unicode domain names, but > there is no standard way to represent email addresses with non-ASCII > local parts. EAI is working on it, slowly, and I think it would a > poor idea to attempt to guess what they might eventually send down the > standards track. EAI docs so far are experimental or informational.
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. > This means that in DKIM, the d= value is a domain, it's punycoded, no > question about that. The i= value has the syntax of an email address, > so its domain part is also punycoded. But if the mailbox part is not > ASCII, you're out of standards territory. For the copied headers, > they should all be in ASCII already unless you're doing 8bit, but 8->7 > downcoding will break a lot more than the copied headers, so > fugeddaboudit. 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. Again, in answer to Dave's question, this situation is ripe for a mess, and closer collaboration with EAI might help. Eliot _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html