On Wednesday, January 19, 2022 1:38:15 PM EST John Levine wrote: > I took a look at sections 4.5 and 4.6 of the draft, the part that describes > the tree walk and PSD, and unfortunately what it currently says is > seriously wrong. Apologies for not catching this sooner. > > It currently says you do a tree walk to find a PSD record, and the org > domain is the one under the PSD. That's fine if there's a PSD record, but > in the vast majority of cases there will not. There is no chance that .COM > or .ORG or .NET or any of the other public gTLDs will ever publish a DMARC > record because they are not in the business of managing their customers' > mail. (There are also acronym-studded ICANN reasons they couldn't even if > they wanted to, ask me if you want the details.) > > 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. > > This means that if there's no PSD and no higher level DMARC records, there's > no org domain, but I believe that we discussed this before and in practice > it doesn't matter.
Apologies for jumping back to the top of the thread, but I've lost track of where we are on this. I took some time to try and code this up (it's not pretty, no judgment please), so the git version of authheaders has grown a new script called dmarc-policy-find[1]. If you know how to install python modules from source, you can try it yourself. I tried to allow one to query via this script using any of the RFC 7489 (DMARC), RFC 9091 (PSD), or DMARCbis methods for policy and organizational domain discovery. In attempting to implement the dmarcbis-04 methods I did run into the problem that John describes and it's not clear what to do for cases where the PSD record is not present. What I implemented is roughly: For policy determination, first check the From domain, if that has a DMARC record, then that's the policy domain. Otherwise, tree walk up to the apex looking for DMARC records. First domain you find with a record is policy domain, use the policy (p=, sp=, np=) from that domain's DMARC record. This matches my interpretation of dmarcbis-04. For org domain determination (for alignment), if any of the records retrieved during the policy search have psd=y, then add one more label and that's the org domain (as written). From there it's anyone's guess. Unlike John, I continued down the tree and made the first match the org domain. I agree it doesn't matter much if you go down the tree or up the tree (for the number of steps specified in the tree walk). There may be a corner case where down the tree is slightly more compatible with RFC 7489 results, but I haven't found a real life example of it. Scott K [1] https://github.com/ValiMail/authentication-headers _______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
