On Thu, 11 Jun 2015, John Levine wrote:
This is a strong statement, I have a problem with your word "preventing" .
My reading of the draft is that mail sender can perform the Hash() operation
on any name she/he has/guesses for the receiver, and looks each one up in until
a
match is found or the sender gives up.
Right now we do not really know if this will scale, ...
But we do know that it is absolutely forbidden by any normal reading
of the mail RFCs.
Just like not supporting !UUCP email addresses is violating the mail RFCs?
The [email protected] and [email protected] being allowed to be different
mailbox targets is an 25+ year old artifact of VAX/VMS/Windows and my
university's cost savings of their ADM3a egg terminal lowercase ROM
purchase. And not a single actual deployment of it was demonstrated to
me in the three years we worked on this document.
I am baffled that a design that is supposed to be
about security would include guessing addresses that might or might
not be the party to which you want to send your highly secure mail,
and that the WG has repeatedly rejected small changes that could solve
that problem.
I have answered this a few times already, but let me try again.
1) If you reply to a message, there is no lookup guessing as the address
is known exactly.
2) If I give you my email address on a business card, there is no lookup
guessing but there gould be typoes or brainfarts. Like accidentally
sending to [email protected] which is not under my control.
3) If you make up an email address in your brain from memory, there is
a chance of error. (and an even greater one if you MUST remember case)
What we are talkng about here is 3) and that's an unsolvable problem to
begin with, seeing how many people tried and failed to add me to their
XMPP list as [email protected] instead of [email protected].
So while getting the domain completely wrong is a complete security
disaster, so is getting the local part. If you make up characters,
eg [email protected] when I have given you [email protected],
then if your software does not warn you, I can still accomodate you
by putting in multiple hashes with the dot(s). But that is NO DIFFERENT
from putting in several base32 entries to accomodate these.
The base32 split up actually gains you nothing.
Upon review by the WG, we did determine that any translations other than
case are too dangerous because they are not universal, and there is no
way you can query a domain for those policies. So any rewriting with +
or . or - substituation should not be done and the draft does not tell
you to.
Let me write of saying my dad and his girlfriend have an email address
of [email protected], and that is NOT the same mailbox as
[email protected].
You submitted a proposed draft for a "email address confirmation lookup
service". Once that is standardised we could look at adding support for
that. But as noted, it being outside of DNSSEC/DANE, and requiring an
SMTP (or otherwise direct link) to the target mail domain, I do not
think that is a very realistic extension that many people will be able
to actually use, with todays SMTP filters in place on behalve of the
anti-spam people.
Paul
R's,
John
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
