Subject: [ietf-smtp] EAI valid local part characters

From: Steve Atkins <[email-masked]>
Date: Thu, 29 Sep 2016 08:20:57 -0700

I'm trying to understand what's allowed in the local part of an (unquoted) internationalized email address.

RFC 6532 extends atext so that in addition to the existing ascii characters - a-zA-Z0-9!#$%&'*+-/=?^_`{|}~ - it can also contain any UTF8-2, UTF8-3 or UTF8-4 character. That addition includes all non-ASCII utf8 characters, I think.

Does that mean that, for example, whitespace (other than ascii space, 0x20) is valid in an unquoted email address?

Am I looking at the right RFCs to understand this?

(This seems a reasonable place to ask, given the EAI group has wound down, but if there's a better place please point me in that direction).

Cheers,
  Steve

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Thu, 29 Sep 2016 18:22:43 +0200

The EAI list remains open and you can ask the. The answer, however, is 
yes, as far as i know.

Arnt

---

From: Steve Atkins <[email-masked]>
Date: Thu, 29 Sep 2016 09:25:20 -0700

> On Sep 29, 2016, at 9:22 AM, Arnt Gulbrandsen <[email-masked]> wrote:
> 
> The EAI list remains open and you can ask the. The answer, however, is yes, as far as i know.

Thanks!

Cheers,
  Steve

---

From: John C Klensin <[email-masked]>
Date: Thu, 29 Sep 2016 12:44:50 -0400

Steve,

I'd recommend trying the still-active EAI list ([email-masked])
for questions like this and any follow-up, if only because I'm
not sure the authors of RFC 6531 are following this list.

However...

--On Thursday, September 29, 2016 08:20 -0700 Steve Atkins
<[email-masked]> wrote:

> I'm trying to understand what's allowed in the local part of
> an (unquoted) internationalized email address.
> 
> RFC 6532 extends atext so that in addition to the existing
> ascii characters - a-zA-Z0-9!#$%&'*+-/=?^_`{|}~ - it can also
> contain any UTF8-2, UTF8-3 or UTF8-4 character. That addition
> includes all non-ASCII utf8 characters, I think.

Following the lead of RFC 821, the WG was reluctant, and
ultimately unwilling, to go down the rabbit hole of trying to
pick which Unicode code points and/or in what combinations,
present and future, should be allowed or disallowed.  As you
know and given the experience of IDNA, PRECIS, etc., that hole
is inhabited by creatures much less pleasant than rabbits and is
not a attractive place to explore.

> Does that mean that, for example, whitespace (other than ascii
> space, 0x20) is valid in an unquoted email address?

I have not gone back and looked at the specs, but would not be
at all surprised if this were somewhat underspecified and hence,
"yes".  In practice, there are probably at least three separable
cases:

(i) What should an SMTP server that actually supports mailboxes
(or the local mail store) allow as a mailbox name?

(ii) How should a sending server or MSA handle such
names/strings?

(iii) How should MUAs behave in dealing with them?

My answer would be that, for the first case and entirely
consistent with experience with all-ASCII quoted names with
embedded spaces, embedded whitespace should simply not be
allowed (quoted or not, ASCII or not), unless there is a
specific goal of making the mailboxes hard to access by anyone
but an expert.  For the second, I'd quote them, whether it is
required or not: doing so should be harmless; not doing so could
lead to a lot of problems.  I think that applies to sending MUAs
too, unless they provide some rules that forces the quoting onto
the users.  I think receiving/reading MUAs should attempt to
handle the mailboxes without quotes as well as with them, but,
if I were implementing such a thing, I'd probably not want to
spend a lot of time on it or making sure it works.

Most of the above is, IMO, common sense and the robustness
principle, regardless of what 6531 and 6532 say or appear to say.

If you think those documents need to be upgraded to contain
clearer rules, that is definitely a matter for the EAI list.
However, if I were to propose such a thing, I'd be sure I had a
reference or mechanism readily available to identify what is or
is not white space.  And I'd be sure that reference or mechanism
would be stable across all present, past, and future versions of
Unicode.

> Am I looking at the right RFCs to understand this?

Probably

best,
    john
    (writing as the very happily retired former co-chair of EAI)