--On Thursday, May 12, 2016 15:15 +0100 Arnt Gulbrandsen
<arnt(_at_)gulbrandsen(_dot_)priv(_dot_)no> wrote:
John C Klensin writes:
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.
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.
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 <Joe(_dot_)Evil(_at_)example(_dot_)net>
Arnt Gulbrandsen <Fred(_dot_)Evil(_at_)example(_dot_)net>
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 <joe(_dot_)evil(_at_)example(_dot_)net>
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
"Joe(_dot_)User(_at_)example(_dot_)org" in the "From:" field, the user says
"reply", and the MUA or MSA generates an outgoing message with
"joe(_dot_)user(_at_)example(_dot_)org" 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
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp