On Tue, 02 Mar 2010 18:45:01 -0000, John Levine <[email protected]> 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. Indeed, although it is rapidly becoming into use in China and such places. But DKIM cuurently applies only to messages complying with RFC 5322. A future (possibly Experimental) extension would be needed to DKIM for it to apply to RFC 5355 messages. AIUI, punycoding is only essential for DNS queries (i.e. when you need to get an MX record in order to send email to it). And even that may change, as Doug has said. Before that, one might use either UTF-8 or punycode forms. All agree that in visible form in email clients it will be in UTF-8. Currently, for transmission using RFC 5321, it has to be in punycode. In the "experimental" universe within which people implement RFC 5335/6, transmission also uses UTF-8 (so punycode is only seen during DNS lookups, if there). So long as messages remain within that experimental universe (as 95% of them will), DKIM as it stands should work quite happily, leaving everything in UTF-8, with no punycode anywhere. BUT at a boundary where a message leaves that experimental universe (i.e. where the sending server advertises the UTF8SMTP Capability and the receiving server does not), then a Downgrade has to take place. Downgrading can change so many things that any DKIM signature is almost certain to be broken, and I think we have to accept that (as we already do with mailing list expanders). And changes to the format of email addresses would not be the only cause of such failures. A sufficiently smart verifier MIGHT just about manage to salvage a verifiable signature from the remains, but I doubt it. Hence that boundary seems like a good place for the Downgrading Agent to do a resigning (hopefully adding an A-R header and including it in the new signature). Coming in the opposite direction, a message addressed to as...@i18ndomain would already have the i18ndomain in punycode. Under EAI it would remain in that form (although user agents might well display it in utf-8). Likewise with any From and Reply-To headers and suchlike. So any incoming DKIM signature should remain verifiable anywhere in the experimental universe. But I agree that what we need now is for some dialogue with the EAI WG. -- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131 Web: http://www.cs.man.ac.uk/~chl Email: [email protected] snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9 Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
