Your idea is brilliant - search for a policy that applies to both the FROM domain and the other domain name. If it is not a PSD policy, then the two names are aligned. It eliminates the PSL while also creating no need for PSD policies.
But your organization assumption does not work. In the RFC 7489 algorithm, we skip over intermediate policies, but they can still exist. We cannot assume them away. Redefining the organization to mean "the first policy record over the current subdomain" is a significant redesign and unnecessary. There are also performance considerations. Before testing for alignment, we need to test for DMARC participation. It would be inefficient to test the SMTP address and three DKIM signatures for alignment, only to find that they all fail because the organization does not have any DMARC policy records published. Consequently, we start with the tree walk on the FROM domain, and the lowest-level policy found applies. That walk serves to prune the tree, providing a lower limit on any possible policy record that could apply to both the FROM address and the aligned name. Now we are ready to test candidate names against the domain name that returned a policy record. If the match is strict, alignment is now determined with a simple string compare. If the match is relaxed, we start from the domain name that returned a policy record and keep walking up the tree. Since we are looking for a policy that applies to both names, we need to start at the point where the two names merge - the longest common substring. For DKIM signatures, signatures that do not align are ignored for alignment testing. An implementation might choose to build a list of domain names and compute the common-substring matches first. Matches that produce no match or a match on TLD-only can be discarded. With this approach, only the longest match needs to be tested for alignment, although the draft asks the evaluator to fully evaluate and report about each name. DF On Fri, Jan 21, 2022 at 7:55 AM Alessandro Vesely <ves...@tana.it> wrote: > On Fri 21/Jan/2022 05:29:05 +0100 John Levine wrote: > > It appears that Alessandro Vesely <ves...@tana.it> said: > >>On Wed 19/Jan/2022 19:38:15 +0100 John Levine wrote: > >>> What I always intended with the tree walk is that you walk up the tree > and if you find > >>> a DMARC record that isn't a PSD, that's your org domain. To see if > two names are in relaxed > >>> alignment, do a tree walk for both and if they end at the same place, > they're aligned. As > >>> a special case albeit a very common one, if one name is a descendant > of the other, and there > >>> are no DMARC records in between, they're aligned. > >> > >>Why would a DMARC record in between invalidate the alignment? > > > > For the same reason the PSL has a lot of two- and three-label domains. > > > Except that the PSL is somehow vetted; that is, there are no > self-appointed > PSDs. Anyway, b.example.com below exhibits no psd=y tag... > > > >>DKIM-Signature: d=a.b.example.com [...] > >>From: j...@c.example.com > >> > >>_dmarc.example.com IN TXT "v=DMARC1; p=reject;" > >>_dmarc.b.example.com. IN TXT "v=DMARC1; p=none; inbetween=y" > > > >>Is that aligned? > > > > No, the org domain for c.example.com is example.com, while > > the org domain for a.b.example.com is b.example.com. > > > If we specify it that way, we need to warn users about the effects that > publishing a DMARC record involves. Users of b.example.com need to know > that > they cannot override the DMARC policy of their org domain unless they want > to > become the org domain of the whole subtree. That is, doing their own DKIM. > > > > I suppose we could try and invent rules that say only records with > > the PSD flag prevent alignment, but then the description of the tree > > walk becomes much more complicated and the tree walk gets longer and > > slower and I don't see what actual problem that would solve. > > > Or we could use a multi-valued tag instead of psd=. For example role=X, > where > X can be any of psd, org or sub. > > > > In your model, when doing a tree walk from a.b.example.com, how do you > > know not to stop at b.example.com? Do you always do five levels and use > > the one highest up the tree or what? > > > Personally, I'd consult the PSL if I find no role= tag. Or I could do one > more > query for _dmarc.com to understand the role of the last record found. > > Let's consider that we have a number of settled DMARC filters based on > PSL, > along with an installed base of DMARC records, which we shouldn't throw > away. > The specification of the tree walk has to strive for compatibility. > > > 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
