I have been proceeding on the assumption that we can and should implement support for independent subdomains. This is a difference with RFC 7489 which recognizes the additional complexities in the deployed ecosystem.
The tree walk must find an organizational domain to act as an upper bound on relaxed alignment. I do not think we can assume that DMARC-participating subdomains will always have an organization-level DMARC policy, so the problem is more complex than finding the top-most policy. Organization-level policies are probably the norm, but there is nothing in RFC 7489 that makes it necessary, and nothing in DMARCbis which makes it certain. If we allow for this exception, we have no choice other than to consult a list sometimes. Ale's comment helped me to simplify my understanding of the tree walks: 1) Walk up from the From domain to the policy domain, then continue upward until the organization domain is determined. Consult a list if necessary. 2) If the Authorizing domain is between the From domain and the Organization domain, the names are aligned. 3) If the MatchPoint domain is above the Organization Domain or empty, the names are not aligned. 4) Otherwise, the Authorizing domain should be checked for an independent subdomain boundary by walking up from it until any point is reached between the From domain and the Organization domain. If no boundary is found, the names are aligned. (If independent subdomain boundaries are intentionally ignored, this second tree walk can be skipped.) Doug On Sun, Feb 13, 2022 at 6:00 AM Alessandro Vesely <ves...@tana.it> wrote: > On Fri 11/Feb/2022 19:25:15 +0100 John Levine wrote: > > It appears that Alessandro Vesely <ves...@tana.it> said: > >> I think it is already clear to the WG that the tree walk is screwed up. > > > > Yes, we know we have to rewrite sections 4.5 and 4.6. > > > > I think there are 2 1/2 situations we need to look at. > > > > The first is finding the policy record for a domain that does not have > its own DMARC > > record. That seems easy, walk up five levels and stop at the first > DMARC record, > > which is your policy record. For this purpose it doesn't matter whether > the domain > > says psd=y. I suppose that it if doesn't have psd=y, you can call the > domain with the > > record the org domain. > > > More or less agreed. > > > > The second is deciding whether two different domains are in relaxed > alignment. This has > > an easier case and a harder one. > > > > The easier case is when one domain is a subdomain of the other. You > look at the domains > > between the two and they are in relaxed alignment if one of these is > true but I'm not > > sure which one: > > > > a. there are no DMARC records at all > > b. there are no DMARC records with psd=y > > > > I don't think there is a lot of practical difference between the two. > If you don't find > > a record, there is no policy and no org domain. > > > Yes, I think we can relay on PSD domains not publishing DKIM or SPF stuff. > > > > The harder case when the domains are siblings, or maybe a great aunt. > Possibilities: > > > > a. they are never aligned. This would be the easiest, but would in > principle be a significant > > change from the current spec. Does anyone know in practice how often > mail uses sibling alignment? > > > > b. walk up from both, stop at the first DMARC record. If they're at > > the same name and it's not a PSD, they are aligned and that's the org > domain > > > > b+. walk up from both, if the DMARC records are at the same name, it > has psd=y, and they have the > > same name below the PSD, they are aligned and the name below the PSD is > the org domain > > > > c and c+. like b or b+ but allow other non-PSD DMARC records below the > org domain. > > > I'd avoid walking up from both, because there are likely multiple > identifiers, > typically SPF and DKIM. Walking up from each becomes burdensome. This > leaves > pretty much only a. However, why not continue the walk upward? The > topmost > domain having a DMARC record is the Organizational Domain. > > In a few cases, the domain thus found can happen to be a PSD. If there is > psd=y, the plan in Section 4.6. works fine. Until that flag is not > reliable, > we need to apply specific knowledge. To this end, note that the list of > domains at psddmarc.org is much much shorter and more easily maintainable > than > the PSL. > > If flags are not reliable, a tree walk without extra knowledge or > heuristics is > not going to work in any case. OTOH, if one day flags become reliable, we > will > have put a mark where DBOUND failed. > > > > I lean toward "a" if we believe that sibling alignment is rarely used, > otherwise b. I don't like b+ or c+ because > > I think it is reasonable to expect mailers who depend on an org domain > to publish a record there, although I do not > > think an org=y flag would be useful, since it would break existing org > domain records that don't have the flag. > > > Finding org=y saves one or more extra lookups. The org domain is > determined > even without that flag, albeit at an extra cost. Perhaps more > importantly, > org= allows a subdomain to claim independence from its parent domain. > > To put it more analytically, psd= and org= correspond to different ways to > apply DMARC, with respect to both determining the alignment and feedback > reporting. Mail filters must ascertain which role a domain plays, whether > declared or not. Then, it is false to assume that psd=n ==> org=y, as > org's > subdomains may exist. It could even make sense to define sub=y. > > > Best > Ale > -- > > > > > > > _______________________________________________ > 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
