--On Sunday, May 01, 2016 09:04 +0200 "Peter J. Holzer"
(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
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 joebloggs(_at_)example(_dot_)biz as canonically equivalent to
joebloggs(_at_)example(_dot_)com, it is Not Our Problem. Neither of those
examples has anything to do with email addresses or their
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.
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
john+ietf(_at_)example(_dot_)com), 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.
ietf-smtp mailing list