Subject: Re: [ietf-smtp] New Mailing List to discuss email canonicalization?

From: "Peter J. Holzer" <[email-masked]>
Date: Sun, 1 May 2016 09:04:18 +0200

On 2016-04-15 21:16:42 +0100, Arnt Gulbrandsen wrote:
> Steve Atkins writes:
> >"except on the final delivery server" is an important part of what John
> >said.
> >
> >While the message is in the realm of SMTP, it mustn't be modified, meaning
> >that two local parts are equivalent only if they're identical (I guess).
> 
> The address isn't on the final delivery server when Fred Flintstone types
> "fred.flintstone@..." or perhaps "Fred.Flinstone@..." into a web UI and
> expects to see his complete order history.

I wouldn't show Fred's complete order history to anyone able to type
"fred.flintstone@..." (with or without correct capitalization). He has
to login first, and after that I can show him his history without asking
for an email address.

(At the login prompt, the email address really isn't an email address:
It's a login name, and I can chooses the rules for login names myself:
For example I can make them case insensitive)

        hp

-- 
   _  | Peter J. Holzer    | I want to forget all about both belts and
|_|_) |                    | suspenders; instead, I want to buy pants 
| |   | [email-masked]         | that actually fit.
__/   | http://www.hjp.at/ |   -- http://noncombatant.org/

---

From: John C Klensin <[email-masked]>
Date: Sun, 01 May 2016 09:53:20 -0400

--On Sunday, May 01, 2016 09:04 +0200 "Peter J. Holzer"
<[email-masked]> wrote:

> (At the login prompt, the email address really isn't an email
> address: It's a login name, and I can chooses the rules for
> login names myself: For example I can make them case
> insensitive)

Exactly.

I don't know how many times this needs to be said and in how
many different ways.  If someone decides to use a string that
"looks like" an email address as a login ID, they are free to
use whatever synonyms, mappings, or other "canonicalization"
they like on it.   As a more extreme example than "make them
case insensistive", if someone wants to accept
"ибан.иетф@example" as canonically equivalent to
"john-ietf@example" in such a login identifier, more power to
them.   Similarly, while I assume we would not recommend
accepting [email-masked] as canonically equivalent to
[email-masked], it is Not Our Problem.  Neither of those
examples has anything to do with email addresses or their
"canonicalization".  

Now, as Peter points out, if I decide to use something that
looks like an email address as a login identifier _and_ I
actually want to have and use an address for email purposes, I'd
better be sure I have an email address stored that works.   As a
best practice issue, that probably implies storing an email
address somewhere.   If I don't, and the login ID I store as my
local preferred/canonical form (regardless of what I allow to
match it on login), then I'm sometimes going to get errors or
incorrect deliveries when I send the email out.  Too bad for me.
Not an IETF problem or an email problem.

    best, 
     john

p.s. One consequence of this, for those who are designing UIs
for login IDs, is that, if you don't like the syntax of my
local-parts for some reason (e.g., if I were to use
[email-masked]), a message of "invalid email address" is
simply false -- there is nothing wrong with the email address.
However, "string unacceptable as login ID on this system" is
perfectly valid.  Whether it is reasonable or not depends a bit
on whether you store an actual email address separately.  But,
as stupid as it might be to turn away customers or other users
because you refuse to accept their email addresses, decision
stated the second way are not the IETF's problem.

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Thu, 12 May 2016 15:15:06 +0100

John C Klensin writes:
> they like on it.

Then this four-step sequence is okay, right?

1. Site makes signup form that says "enter your email address here".
2. Site does backend processing as it pleases.
3. Site displays the result to other users.
4. Users assume that what's displayed is an email address, and send email.

Arnt

---

From: John C Klensin <[email-masked]>
Date: Thu, 12 May 2016 11:00:47 -0400

> 4. Users assume that what's displayed is an email address, and

I think it (particularly item 3) would not be very smart on the
part of the site, but that sequence is Not Our Problem, at least
from an email standpoint.

Let me suggest another example that might make my position more
clear.  Suppose someone puts up a site that claims to show email
addresses for people who participate in IETF work, presumably
with some sort of name to address translation function.  Or, to
make things more exciting, spoofs or hijacks the name or address
of a legitimate site that provides such a function.   The
database contains
    John Klensin <[email-masked]>
    Arnt Gulbrandsen  <[email-masked]>
along with many other entries.

Now that is a trust problem.  It is a reputation problem for the
site and a trap for users.   But it is not an email address or
address processing problem.   Similarly, if someone sends out a
message whose "From:" field shows
   John Klensin <[email-masked]>

and the MUA simply shows "from John Klensin" so that, if the
user replies, the bogus address is never exhibited, that would
be similar to a popular tactic among those who find phishing
popular.  It is a trust problem, a problem about confidence in
what information is received, and, IMO at least, really stupid
UI design in today's world.  But it isn't an email address or
address processing problem.

Now, if we were making recommendations about good advice for
users or practices in UI design, the above examples might
suggest several things, including avoiding directory services
whose authenticity cannot be verified, exposing addresses (not
just names) in MUAs, and perhaps keeping a database of frequent
or important correspondents with name phrase to address
correspondences and generating warnings when they appear to be
inconsistent.  With the exception of displaying addresses, those
sorts of practices are, to put it mildly, rare, even outside the
email area.   For a non-email example, I'm appalled that web
browsers allow constructions like

  <a href="http://www.evil.example/">www.bigbank.com</a>

without alerting the user to the probably discrepancy.

Similarly, if an MUA receives a message with
"[email-masked]" in the "From:" field, the user says
"reply", and the MUA or MSA generates an outgoing message with
"[email-masked]" in the "To:" header and RCTP command in
the outgoing envelope, that would be a practice so stupid that
we'd probably consider the MUA broken.  But there is nothing
about it that actually violates 5321 or 5322, it just shows
ignorance and/or violates good sense.

For better or worse, the IETF rarely makes recommendations about
those types of issues, but perhaps thinking about doing so would
be more useful than discussing how to "canonicalize" an email
address.    Either way, the problem just isn't with the email
addresses or their handling in email transport.

  best,
    john