ietf-smtp
[Top] [All Lists]

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

2016-09-29 11:45:05
Steve,

I'd recommend trying the still-active EAI list (ima(_at_)ietf(_dot_)org)
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
<steve(_at_)wordtothewise(_dot_)com> 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)

_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp

<Prev in Thread] Current Thread [Next in Thread>