- From: John C Klensin <john+w3c@jck.com>
- Date: Wed, 29 May 2013 11:23:03 -0400
- To: Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>, Paul Deuter <pdeuter@zendesk.com>
- cc: www-international@w3.org
--On Wednesday, May 29, 2013 16:40 +0200 Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no> wrote: > Just a question - to you or whoever: Is "UTF-8 email > address" something other than e-mail addresses where the > domain name is an IDN? Or does it related to the part before > the @-character? The latter (called the "local part" in email-speak. See RFCs 6530-6533 and 6855-6858. Note that there turns out to be a lot more to this than just handling UTF-8 in addresses. In particular, the addresses affect header fields as well as the envelope (and address-specific header fields), message encapsulation issues, and the need to have transition strategies for sites and clients that can't handle the extended addresses. > Btw: As a person who has personal experience over some years > with using the former - an e-mail address with an IDN domain > name, I find that the only trouble I have is when some online > service asks me to enter my email address: It ought to be > possible to type foo@målform.example.com - in decoded form. > But I constantly have to use the IDN coded form - > foo@xn--mlform-iua.example.com. Because the syntax rules in RFC 5321 (and 821 and 2821) very explicitly prohibit non-ASCII characters in an email address ("mailbox name") you will find that many mail clients reject such things. Of course, if the client sees non-ASCII characters in the domain part of the address and converts the appropriate labels to A-Labels as specified for IDNA before transmitting the message, the inter-host email system (and the recipient) don't need to know what you entered. But non-ASCII local parts or transmission of messages with non-ASCII UTF-8 addresses or headers requires the extensions specified in the RFCs identified above. john
Received on Wednesday, 29 May 2013 15:23:41 UTC