--On Friday, April 15, 2016 21:00 +0000 John Levine
<johnl(_at_)taugh(_dot_)com> wrote:
...
My system (a heavily hacked version of qmail, which is still a
surprisingly good base for a reliable mail system) maps
addresses into delivery rules in a variety of ways, but those
delivery rules look nothing like e-mail addresses. Some are
files, some are directories, some are scripts.
With some effort I could probably tell you whether two
addresses went to the same delivery rule, but there's no way I
could say whether one was "canonical", or if there were some
other address more canonical than either.
My objection to discussions of ways to canonicalize e-mail
addresses are pretty much the same as my objections to
discussions of ways to divide by zero.
And that is why, if one wants to go down that path at all, an
"are their equivalent" function is superior to a "what is the
canonical form of this address" one. Even then, it needs to be
understood that, at least unless a specific purpose is given,
"equivalent" will be strictly in the mind of the final delivery
server _and_ will have some temporal properties, i.e., caching
the answer for a non-trivial period would be a bad idea.
--On Friday, April 15, 2016 21:16 +0100 Arnt Gulbrandsen
<arnt(_at_)gulbrandsen(_dot_)priv(_dot_)no> wrote:
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.
And so? Either it will work or it won't. If it doesn't, it
will either be rejected as unknown (or not matching a password
of other authenticator or it will reach the wrong party's
history.
The user can expect whatever he or she chooses, including that
"Pebbles(_dot_)Flintstone(_at_)example(_dot_)com" will reach the same order
history as "Fred(_dot_)Flintstone(_at_)example(_dot_)com" and even the same
order
history as "Fred(_dot_)Flintstone(_at_)example(_dot_)us". Under different,
perfectly rational, circumstances, each of those will work,
reinforcing that users' view that all cases they think are
similar will match and "work". Sometimes that won't be true for
at lest some of the cases and users will get the other message.
I think that example actually "proves" only the following:
(1) Email addresses are not particularly good user identifiers.
Most of us, especially those who use multiple addresses,
subaddress logic, or who have used ISP-provided addresses and
then switched ISPs, have known that for a really long time.
Nonetheless, we seem to have lost that battle, at least until
things get a lot worse.
(2) If one is going to use email addresses or things that look a
lot like them as user identifiers, it would be wise to educate
users about variations ("that field is case-sensitive" is
ultimately user education) and/or to be very flexible about how
equivalence of the identifier is interpreted. The latter could
make "fred.flintstone@..." and "Fred.Flinstone@..." equivalent
for order history purposes even if they aren't equivalent
mailboxes (and even with the probable typographical error in the
second one).
(3) If the designers of that order system ask for an email
address when the account is set up and actually intend to use it
as an email address (as well as an identifier), they would be
well-advised to record the address in the form in which it was
provided, and then use it when sending email, independent of
what users get to type when logging in again.
If it is really necessary to explain the above in a more
permanent way, it might be the core of a reasonable
Informational or BCP document (or a suggestion to W3C for one),
stressing that variations on email addresses used as identifiers
may not a valid email addresses and that there is a nasty
security hole with "you user ID is your email address, if you
have forgotten your password, type in your email address and we
will mail it to you" systems unless one is _really_ careful.
But, really, none of it has anything to do with canonicalization
of email address as email addresses.
john
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp