--On Friday, April 15, 2016 14:26 +0100 Alexey Melnikov
<alexey(_dot_)melnikov(_at_)isode(_dot_)com> wrote:
Hi,
I've been asked to create a new mailing list for discussing
solutions to "are these 2 email addresses the same" problem
which originated in the DANE WG. Should I just go ahead and do
that or would people prefer to just discuss this topic on this
mailing list?
Alexey,
Unless people propose to update RFC 5321 to eliminate a
requirement that has been in place from 821 and through 1123 and
2821, I don't see that there is anything to discuss. It seems
to me that the rules are very clear, i.e., that, except on the
final delivery SMTP server, two mailboxes are equal iff:
-- 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/XXWuPVa82lmNDrduVlPgHbjMPQs
But this is really a technical detail; it's not a major issue in
practice.
"Canonicalization" that produces any other results violates a
MUST constraint in 5321 with all of the interoperability
implications of that constraint.
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?
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.
Ned
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp