On Monday, January 24, 2022 5:23:27 PM EST Scott Kitterman wrote: > 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
I forgot to mention: Since no one publishes psd=y yet, I cheated and internally pretend that any domains on the psddmarc registry have psd=y, so I could test it. Scott K _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
