PSL entries are imputed with four important characteristics: - name not valid for MAILFROM - name not valid for FROM - name not valid for DKIM - name not valid as an alignment point for mismatched names.
For non-PSL names, the reverse is assumed by default - any name is valid for any of these purposes. It is important to note that the PSL covers all possible names -- if a name prefix is not in the PSL, we assume it is a fake name. Experience also indicates that it is trusted as accurate. We have not spent any time talking about a need for PSL override rules. Finding the first available DMARC policy, as John suggests, does not come close to replacing the PSL. - First, DMARC policies do not cover all possible names, which is a rather critical problem. - Secondly, even when they are present, the first-match DMARC policy does not define all valid alignment points. Consider unit2.example.com and unit1.example.com. Each unit may have its own DMARC policy, but the parent domain may still be a valid alignment point. I can test alignment without a DMARC policy, but I cannot test alignment without a PSL or a comparable replacement. We could define DNS flags to cover the four PSL characteristics listed above, and those flags have potential use cases outside of the PSL But we have already concluded that we cannot reliably expect every PSL to configure DNS entries to meet our needs, so the DNS-based PSL would lack the necessary trust that we have in the current PSL. Doug On Wed, Oct 27, 2021 at 3:29 PM John Levine <jo...@taugh.com> wrote: > It appears that Scott Kitterman <skl...@kitterman.com> 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. > > R's, > John > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc >
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
