On Thu, 17 Sep 2015, John Levine wrote:
J. Levine, [3] 20150909
- LHS only to be interpreted by recipient MTA, claims that this draft
breaks that
SF: This draft explicitly repeats exactly the MUST NOT required. A
claim that the choice to hash the LHS as it is breaks this SMTP
protocol requirement seems wrong.
This draft mandates that the DNS publishes only a small handful of the
addreses that an SMTP server would accept.
I don't see that. The -05 draft does not do lowercasing. So all
addresses are accepted unless you find a sha256 hash collision. Can you
give an example of an address that would not be accepted by this
document but would be accepted by an SMTP server?
RFC 5321 describes how
local-parts are interpreted, and this draft doesn't do what 5321 says.
We do not interpret/modify the local-part - we only hash it.
J. Levine, [3] 20150909
- Says because of LHS issue, every variation "has to be" put into
DNS.
SF: I do not buy that argument. (I do not claim to know more about
email, but the idea that email operators would have to populate
the DNS with every possible option seems wrong.)
Same thing.
Same thing.
J. Levine, [3] 20150909
- Say that most addresses that could work with SMTP will not be in
the DNS, leading to possible or actual failures.
*SF: That is worth including as a consequence of this design.
Presumably though, if all this is working, all the addresses that
will end up used for PGP will also work in SMTP.
Yes, but not the other way around. Note my example of john+bank@example
which works in SMTP but not in this design.
It works fine in this design if you publish the record at sha256(john+bank)
or add CNAMEs for your john+FOO email addresses. Adding the CNAME's
should be easier than adding them as valid ID's on your OpenPGP key.
J. Levine, [3] 20150909
- "this draft pretty much demands name guessing."
SF: I don't accept that and the draft says to not do that. It might
be worth noting as part of the experiment that recording if
implementations do/don't guess would be good.
Note comments by draft author and others saying they're going to do name
guessing regardless.
Correct. It is the obvious choice in real world auto-casing scenarios
versus imaginary world support for case sensitive email addresses. Some
offline discussion seems to suggest that we can re-introduce lowercasing
provided we state clearly that it does not support case sensitive
mailboxes.
J. Levine, [4] 20150910 (in follow up to authors)
- Suggestion to publish re-write rules as a domain specific thing
in the DNS (maybe with a registry of standard rules)
SF: Seems like it could be done. If this experiment was a success
in getting deployment that should help too. But that could be
done later.
Note that decades of attempts to do this have all failed, and nobody I
know who is familiar with commercial mail systems believes it is
feasible. It is not an accident that RFC 5321 and predecessors do not
attempt to describe rewrite or canonicalization rules.
So it seems we all agree to punt this for now and not include anything
like this in the document.
Paul