Re: [I18ndir] HTML, email addresses, etc

[Nico Williams <[e-mail]>]

On Sun, Jun 07, 2020 at 11:46:31PM -0400, John C Klensin wrote:
> Hi.
> 
> The following comments by John Levine and myself might be
> relevant to people on this list.  
> 
> https://github.com/whatwg/html/issues/4562#issuecomment-640070477

I'm not sure that we need a new input type for EAI addresses.  If the
user types in non-ASCII, then presumably *they* know that the domain can
handle EAI.

Another way to put it is that if we did add a new input type, should
developers build websites where the user must pick whether to enter an
EAI or not?  Or should developers just always use the new input type?

(Answer to the second question: No! First the page must detect whether
the browser supports the new input type!)

If we add a new input type, then after a while that will be all that is
used.  Ergo it's not needed.

The mere fact that the user typed in an internationalized mailbox name
is all the evidence we need that it is likely that the domain supports
EAI.

You could say that because *your* system doesn't support EAI for
outbound email, you won't accept it as input.  _This_ could be a new
option on the input.

> (1) We could try to clarify the SMTPUTF8 specs by noting the
> difficulties associated with trying to determine whether a
> purported email address is valid or not, especially in the light
> of fairly clear language in RFC 5821 that only the system (or
> set of systems) actually hosting that address can know and the
> greater diversity of troubles people can get themselves into
> with a nearly-unlimited range of Unicode code points rather than
> just ASCII.

Ulitmately, the true right way to validate a mailbox name is to ask its
MTA to validate it.

> (2) We could actually modify those specs to prohibit, or
> strongly recommend against, allocating email addresses whose
> local-parts contain anything but Unicode code points associated
> with graphics, or even letters, digits, and a small selection of
> symbols (possibly bringing the local-part recommendations close
> to a PRECIS profile).   Or perhaps a different set of
> restrictions. Might prevent a certain amount of mischief
> associated with excess cleverness or strange (to me) ideas about
> freedom of expression although I not sure it would have any
> significant value against deliberate attacks.

I feel like saying no to (2).  Requiring that mailbox names be printable
is OK, but I wouldn't forbid, say, emoji.

Nico
--