> "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
