W3C home > Mailing lists > Public > www-international@w3.org > April to June 2013

Re: Testing UTF-8 email addresses

From: Leif Halvard Silli <xn--mlform-iua@xn--mlform-iua.no>
Date: Wed, 29 May 2013 20:53:56 +0200
To: John C Klensin <john+w3c@jck.com>
Cc: Paul Deuter <pdeuter@zendesk.com>, www-international@w3.org
Message-ID: <20130529205356286804.2647041d@xn--mlform-iua.no>
Thanks for replies to e-mail dumb me.

John C Klensin, Wed, 29 May 2013 11:23:03 -0400:
> 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.

The e-mail client with which I send this message, allows me to set up 
e-mail accounts without entering IDNs as punycode. As such, it is one 
of the best clients I have tried …

When I spoke about online services, I meant Web forms where one has to 
enter one’s e-mail address. But I now remember that I spoke too 
positive about my experience: It has actually happened more than once 
that I could not register, not even when I used the punicoded shape of 
the address - the Web form would tell me that my address is not a valid 
e-mail address. I had to pick another address before it would work. 
This has little to do with RFCs, I believe, but more with dumb Web 
forms. Nevertheless, it is probably a thing that e-mail providers will 
be bothered with from their customers.
-- 
leif halvard silli
Received on Wednesday, 29 May 2013 18:54:30 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:41:02 UTC