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