--On Friday, April 15, 2016 08:44 -0700 Ned Freed
<ned(_dot_)freed(_at_)mrochek(_dot_)com> wrote:
...
-- The domain parts are equal under DNS rules
(case-independent for ASCII strings and U-label:A-label
equivalence for IDNA strings)
-- The local parts are equal if they are octet-by-octet
identical.
As a purely technical matter, the second of these is
incorrect. Just as one example, both RFC 5321 (section 4.1.2)
and RFC 5322 (section 3.2.1) are quite clear that \-quotes
have no semantic meaning, and have to be ignored when
comparing addresses.
As such, there is a cannicalization step involved in proper
address comparison. I discussed this in some detail in an
earlier message to the IETF list:
http://mailarchive.ietf.org/arch/msg/ietf/XXWuPVa82lmNDrduVlPg
HbjMPQs
Sorry. You are correct of course. I've just gotten a bit too
frustrated with the discussion.
...
Now, if someone claims that the language in 5321 is
insufficiently clear on that point, discussion of a proposed
update to clarify it might be useful. However, I doubt that
is what proponents of "canonicalization" have in mind. What I
think I'm seeing is claims that 5321 is either ambiguous or
says something else by people who don't consider reading and
understanding it to be a necessary requirement for developing
standards about email.
I concur. What people here want are two things:
(1) A universally applicable definition of what "these
addresses are the same" means
(2) A means of determining that similarity
The common perception is that (1) is trivial so why can't we
have (2)? But this perception is incorrect - it's actually (1)
that's hard.
For example, even the question "do these addresses point at
the same mailbox" is difficult. My email system supports
subaddresses, so
ned+1(_at_)mrochek(_dot_)com
and
ned+2(_at_)mrochek(_dot_)com
so in some sense they both point at my mailbox. But not only
do I have the ability to file based on subaddress, I can
forward. Or file into someone else's mailbox. And if I elect
to do that, does the answer to the "same mailbox" question
change? Or is the question badly posed, and should be "are
these addresses under the control of the same user?". And if
that's the only question we can answer, is the answer to that
question useful?
Indeed.
My view is that the entire question of address equivalence is
a red herring. What's needed is a means of retrieving
properties associated with a given address. (And if a
particular property of an address happens to be the same as
another address, then those addresses are "the same" in terms
of that particular property.)
This entire issue has come to the fore as a result of the
general limitations associated with using the DNS for email
address lookup as well as the specific limitations when a hash
function is employed, as it is in the dane-openpgp draft.
As as I pointed out in the message I cited above, I think this
is also a red herring. The way to think of the mechanism
defined in dane-openpgp is that its use implicitly defines the
policy for a particular sort of address similarity. And if
your site has addresses that don't conform to that policy,
then you can't use the dane-openpgp mechanism effectively.
Anyway, what's really needed here isn't a mailing list to
fully explore the rathole of how to define the various axes of
address similarity. What's needed instead is a working group
tasked with specifying a general mechanism for secure lookup
of properties associated with a given email address.
I agree... if that WG is explicitly tasked with looking at
operational race and coordination issues as well as making up
mechanisms. Especially if specialized DNS entries are
considered part of the solution, in addition to the issues Ned
cites, questions about what we are assuming about coordination
between email administrators and DNS ones, TTLs and other
caching-related issues, edge cases associated with race
conditions, etc., have to be (at least IMO) clearly understood
as part of any approach.
I'll try to write more about that subject when I have a bit more
time.
john
p.s. I agree with John Levine. If people want to discussion
the "canonicalization" issue despite Ned's analysis above and my
earlier comments, it needs to be done here. If it is not, we
are likely to see another chapter of what we've seen before --
discussions among people who are not closely in touch with the
SMTP standard and the wide range of email operational realities
reaching some conclusion than then insisting the the IETF
community (and specifically the email community) needs to accept
it because they discussed it at length on their mailing list or
in their WG.
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp