>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. RFC 5321 describes how local-parts are interpreted, and this draft doesn't do what 5321 says. >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. >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. >J. Levine, [3] 20150909 >- "Hashed names require that all of the keys for a domain be served in > one flat zone. Large mail systems typically partition the users > based on the local part, but since the hashes aren't reversible, > there's no way to tell what partition would handle what hashed name." > In a later [5] mail V. Dukhovni noted: "What does change is that the > partitions responsible for user addresses would need to publish > hashes to the corresponding server for the hash in question." > *SF: I think that is correct and ought be stated as a consequence > of this design. I suppose -- the partitioning for the DNS would be unrelated to the one used for mail, so you'd need some sort of crossbar to get stuff from the existing mail system into the DNS. Since the mail system can't use its existing partitions, it in effect has to publish names into one big flat zone even if the implementation of that zone partitions it somehow. >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. >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. R's, John