[Top] [All Lists]

Re: [ietf-smtp] another attempt to canonicalize local parts

2016-03-10 03:39:04
On Wed, Mar 9, 2016 at 3:08 PM, John R Levine <johnl(_at_)taugh(_dot_)com> 

Do you see any problems to introducing a new PKIX email address type to
support Unicode in email local part for Email-Address-Internationaliza

No new problems, although it makes the variant local part issue even more
obvious.  I don't claim to be a Unicode expert but it seems clear to me
that for the mapping rules to be useful to non-technical users they have to
match offline conventions, which means that they depend on the user's
language.  So for a large system like gmail, there's likely to be dozens of
different character mapping rules for different user languages, just as
there are dozens of different language options for the gmail web interface.

The alternative is that for each mapping i.e. email address variant the
sender will need a different set of signing keys and certificates,
which they will have to distribute.  Because these email addresss local
variations have become so ingrained, adopting PKIX for email address
authentication becomes burdensome to point of killing off its feasibility.

S/MIME has been widely available for close to 20 years, implemented in
nearly all desktop MUAs, and the number of people who use it (other than
the ones whose employers demand it) still rounds to zero.  PGP is no
better, despite the wide availablity of public PGP key servers.  I think
the poor match between the addresses in certs and the ones in real mail is
one of the reasons.

Very much agree.

If you want to move ahead with this, it would be more productive to think
harder about how to improve PKIX to match mail practice than try to force a
billion mail users into the underdesigned PKIX address model since there
are a whole lot more mail users than S/MIME and PKIX certificate users.
It's not out of the question that SMTP servers could help, e.g., the oracle
to ask if two addresses are the same recipient.

Agree that the SMTP servers could be a reasonable approach.  Others might
be to declare some sort of canonicalization rule or matching regex in the

It'd also be a big help to clarify what the problem is to be solved. Is it
to assert that mail with the address fred(_dot_)smith(_at_)example(_dot_)com 
is from an
actual person named Fred Smith, that encrypted mail will only be read by
that person, that today's mail with that address is from the same person it
was from yesterday, or something else?

I would argue in the basic guarantee users are looking for is an email
conversation between senders and receivers stays private, and that
participants don't get spoofed.  Using email addresses for naming would
suffice in this usage.  Its certainly true a validated personal name is
more meaningful to most users than a email address and really could help
with abuse prevention (anti phishing).  It does bring in a number of issues
though and certainly expands the scope quite a bit.  Validating Fred Smith
actually uses fred(_dot_)smith(_at_)example(_dot_)com is going to be fairly 
difficult at
scale.  Doing this consistently across CAs is another issue though could
follow the model of EV server certificates i.e. create a policy ala CA/B
Forum for standardizing methods for proving ownership.  Another issue is
that personal names are often not unique and need some additional
identifier.  This too would need standardization most likely by some sort
of policy.  I'm sure there are other things to think about too.



ietf-smtp mailing list
<Prev in Thread] Current Thread [Next in Thread>