On Wednesday, October 27, 2021 3:28:53 PM EDT John Levine wrote: > It appears that Scott Kitterman <[email protected]> said: > >On Tuesday, October 26, 2021 10:09:13 PM EDT John Levine wrote: > >> The question remains what to do about the fake mail with 12 label > >> domains. > >> My perhaps radical suggestion is to say that if the author domain does > >> not > >> exist, i.e., you look it up and get NXDOMAIN, then DMARC does not apply > >> and > >> you do whatever you do to mail with fake addresses. Or perhaps you only > >> say that if it's NXDOMAIN and has more than four labels. That way if you > >> really want to use 12 label addresses, you have to add a _dmarc record > >> every four levels. Nobody will do that, but nobody sends mail like that > >> other than to be perverse, so it doesn't matter. > > > >Thanks. From the bottom up, I think that seems reasonable, but my concern > >(not surprisingly) is on the other end of the question. Should a policy > >found at _dmarc.com be treated differently than _dmarc.example.com? If > >so, then what about _dmarc.gov.uk versus _example.gov.uk and how do we > >distinguish between the first set and the second? > > Since we are writing a technical spec, the only answer is that we don't. > The PSL, or anything like the PSL, is only someone's guess about > relationships between various DNS subtrees. > > Let us not rehash the theological argument about who controls the DNS tree, > the technical faction saying that each zone controls all of its descendants, > and the political faction saying we have rules about that not visible in > the DNS. One the one hand, zones like .BANK have real contracts that they > want to enforce, but on the other hand, we have overclever hosting > providers who imagine that the PSL is a get out of jail card for dealing > with sleazy customers, and the PSL maintainers are not happy: > > https://github.com/publicsuffix/list/wiki/Third-Party-Diffusion > > I would say that if you have an issue with a DMARC record in the > tree above your domain, that's a business issue with whoever > controls that record, not a technical one.
I didn't like this when I first read it. Contrary to my usual practice, I didn't react immediately and sat on it to think about it instead. It's growing on me. If I understand correctly, there really isn't a technical difference between _dmarc.example.com and _dmarc.gov.uk and so from the point of view of an RFC that defines DMARC and DMARC interoperability we can't and shouldn't distinguish between them. There are, however privacy and security concern differences between processing a record for _dmarc.example.com and _dmarc.com. We can, and should explain those differences in the security and privacy considerations sections of the eventual DMARC RFC, but if com should publish a DMARC policy is really between the operator of com and ICANN and if ICANN were to allow it, it would be up to com domain registrants to decide how to deal with it (to be clear, I think it would be horrible if that happened, but that's not a technical, interoperability horror, it's about privacy and security). Technically, the change is: Lookup policy and if not found, lookup up the next level (up to 4) instead of lookup policy and if not found, consult PSL and lookup the org domain. For the common case like eml.example.com where there is no DMARC record the trade is one extra DNS lookup in exchange for getting the PSL out of the equation. Assuming I have that right, I think that is a reasonable path forward that would solve a number of problems. The key is to get the security and privacy considerations documented so that ICANN and ccTLD operators are informed and can set their own rules appropriate. Scott K _______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
