On Tue, 02 Mar 2010 18:45:01 -0000, John Levine <johnl(_at_)iecc(_dot_)com>
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 ascii(_at_)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: chl(_at_)clerew(_dot_)man(_dot_)ac(_dot_)uk 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