On 17/09/15 07:27, Paul Wouters wrote: > 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. I think the above is repetitive of points already made in the LC. Now, as it happens I (still) don't get John's position on this but I plan to follow up on that off list and would suggest that we can all do that for now, given that there will be another LC before this draft proceeds. S. > >>> 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 > >