"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.
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.
Basically, for non-ASCII domains, the solution is obvious, for general
non-ASCII mail addresses, we do what everyone else is doing and wait
for EAI.
R's,
John
PS: Dueling experts: I ran this past Paul Hoffman and he generally
agreed.
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html