Re: Best practice of using regex on identify none-ASCII email address

Philippe Verdy <verdy_p_at_wanadoo.fr> wrote:
 |2013/11/2 Philippe Verdy <verdy_p_at_wanadoo.fr>
 |> Note also that the SMTP server configured in ISO-8859-1 will not accept
 |> To: <caf%C2%89_at_glacé.example.net>
 |> but may accept
 |> To: <caf%C9_at_glacé.example.net>
 |> or only the raw form
 |> To: <café@glacé.example.net <http://xn--glac-epa.example.net>>
 |> or could accept the last two as *distinct* addresses (ech one needing its
 |> own way to escape them in envelope formats.
 |
 |it should always accept the domain part "@xn--glac-epa.example.net"
 |everywhere "@glacé.example.net <http://xn--glac-epa.example.net/>" is not
 |supported (when the SMTP server does not know IDN)

btw. i never liked IDNA, also because it is terrible to look at
for users unless you're using some software which actually knows
that it is looking at IDNA and is capable to decode it.
So yes, user-readability would be the thing i'd worry about.

(Once i've implemented our caching resolver back in 2004 (latest
RFC read was RFC 3845) i wondered why the unused bit wasn't used
to switch to an extended protocol with longer labels and names.
If that would have been done once the widespread use of UTF-8 was
clear (rather than forseeable), there would have been more
options. It's messy, but M$ had an ugly solution for the short
forms when they've added long filenames, and that wouldn't have
been impossible for DNS either. But that ship has sailed, too.)

In the end software will have to hide even more complexity,
whatever this will end up with (thus most likely percent
encoding).

--steffen

attached mail follows:

2013/11/2 Philippe Verdy <verdy_p_at_wanadoo.fr>

> Note also that the SMTP server configured in ISO-8859-1 will not accept
> To: <caf%C2%89_at_glacé.example.net>
> but may accept
> To: <caf%C9_at_glacé.example.net>
> or only the raw form
> To: <café@glacé.example.net <http://xn--glac-epa.example.net>>
> or could accept the last two as *distinct* addresses (ech one needing its
> own way to escape them in envelope formats.
>

it should always accept the domain part "@xn--glac-epa.example.net"
everywhere "@glacé.example.net <http://xn--glac-epa.example.net/>" is not
supported (when the SMTP server does not know IDN)
Received on Sat Nov 02 2013 - 11:34:23 CDT