We need an algorithm with enough detail to ensure that it can be implemented consistently, something closer to the RFC for SPF rather than RFC 7489.
For example, it is only when you get into the weeds do you discover that error handling for the primary walk needs to be different than error handling for the secondary walk, and that this has security implications. A policy error on the secondary walk MUST be ignored, rather than triggering PERMERROR. Otherwise an attacker could create a domain with an invalid DMARC policy, then sign an impersonating message with that domain, causing the evaluator to conclude PERMERROR instead of REJECT, defeating the domain owner policy. We need to have though through the implementation issues with as much care as will be needed by developers. This is no small feat. I have already thought of a few refinements since last night. We probably cannot succeed without a reference configuration. I don't have any problem with the tree walks as a replacement for the PSL. But I don't think we are close to a usable document because it is simply too vague. Doug On Tue, Mar 22, 2022 at 12:16 AM Scott Kitterman <[email protected]> wrote: > Doug, > > I think you are mistaken. The Organizational Domain is what is used to > test alignment. If you have suggested changes from what's in DMARCbis06, I > think it would be easier if you made specific recommended changes. > > Also, the level of detail in the current draft is very similar to what is > in RFC 7489. If you think we need a more detailed exposition than there is > in the existing DMARC spec, please explain what current issues you are > seeing that you are trying to solve. > > I find it very difficult to relate what is in your email to the text in > the draft. > > Scott K > > On March 22, 2022 3:03:59 AM UTC, Douglas Foster < > [email protected]> wrote: > >We have significant functional differences between the two tree walks, > >which are lost or ignored in the current prose. This lack of precision > >has also allowed us to overlook error handling, which is different between > >the two types of tree walk. > > > > > >I have provided a rough cut of the primary tree walk, using an outline > >approach rather than prose. For the secondary tree walk, I only have > >summary comments about how it differs from the primary tree walk. I could > >beef up both sections after feedback > > > >Doug > > > >There are potentially two types of tree walks, both of which can be > avoided > >under specific circumstances. > > > >- The primary tree walk is used to find the RFC5322.From address > >organizational domain and associated default policy, and is performed > >once. > > > >- The secondary tree walk is used to test each verified domain for > >alignment with the RFC5322.From domain. > > > > > > > >1) RFC5322.From tree walk to Organizational Domain > > > > > > > >Exact-match check > > > >------------------------- > > > >- (optionally) verify that the lowest segment is a valid label (doesn't > >start with an underscore, 64 or fewer characters long. If format rules > are > >violated, return an error. > > > >- check for TXT records at _dmarc.<domain name> > > > >- if no DMARCv1 records are found, report no-data-found and exit. > Proceed > >to the organization domain and default policy search. > > > >- if two records are found, or if a single record does not parse > correctly, > >return an error. > > > >- if one usable record is found, check for a <role> indicator, and proceed > >as follows: > > > > If a <not-for-mail> indicator is detected, return a DMARC Fail > result. > > > > If both alignment policies are strict, the organization domain and > >policy are not needed, so the primary tree walk is omitted. Otherwise, > the > >tree walk is invoked to determine the organizational domain and default > >policy > > > > > > > >If the tree walk is to be used, check to see if the From domain is more > >than <Max=5> segments. If so, shorten the domain to <Max=5> segments. > >Otherwise, remove one segment and check the resulting domain name for a > >DMARC policy. Then evaluate the shortened domain name: > > > > > > > >- (optionally) verify that the first segment of the domain name is a > >valid label (doesn't start with an underscore, 64 or fewer characters > >long. If format rules are violated, return an error. > > > >- check for TXT records at _dmarc.<domain name> > > > >- if no DMARCv1 records are found, report no-data-found and exit the step > >so the search can continue. > > > >- if two records are found, or if a single record does not parse > correctly, > >return an error. > > > >- if one usable record is found, check for a <role> indicator, and proceed > >as follows: > > > > If a <non-boundary role> indicator is present, return no-data-found > >and exit the step so the search can continue. > > > > If a <psd role> indicator is present, return the cached domain and > >policy, ending the search. > > > > If a <top-of-organization role> indicator is present, return the > >current domain and policy, ending the search. > > > > If no indicator is found, cache the domain name and policy as a > >possible organizational domain. Exit the step so the search can continue. > > > > > > > >If a step exits with a confirmed organizational domain and default policy, > >the search is complete. > > > >If a step exits with no-data-found, and the domain name has at least 2 > >segments, then remove the first segment and repeat the domain evaluation. > > > >If a step exits with no-data-found, and the domain name is only 1 segment, > >then the search terminates. > > > > If a cached organization domain and default policy are available, > these > >are the organizational domain and default policy. > > > > If the cache is empty, no organizational domain is found. > > > > If an exact-match policy was previously detected, so that the > >tree walk was only needed for relaxed alignment, then the match rule > >reverts to strict. > > > > If an exact-match policy was not detected, the domain does not > >participate in DMARC. > > > > > > > > > > > >2) Secondary Tree walk to test for alignment > > > > > > > >This has some notable differences from the Primary Tree Walk. > > > >- The search only returns an “Aligned” or “Unaligned”. The > >values of the organization domain name and default policy will be known if > >the names are aligned, and unimportant if the names are not aligned. > > > >- Only one alignment result is needed, so domain evaluation > ceases > >as soon as an aligned result is obtained. > > > >- If a DMARC policy error is detected during evaluation, the > >domain being evaluated is discarded as not aligned, but the evaluation > >proceeds. > > > >- The common substring should be determined. If the common > >substring is shorter than the organizational domain, the domains are not > >aligned, and the tree walk is not necessary. Otherwise, the tree walk is > >performed, but it terminates when the common substring is reached, rather > >than when the domain string is exhausted. > > > >- If an organization boundary is detected during the tree walk, > >the domain being evaluated is discarded as not aligned. > > > >- If no organization boundaries are identified during the tree > >walk, the names are aligned. > > > >If the domain is discarded as not aligned, the alignment search proceeds > to > >the next DKIM-verified or SPF-verified domain name. > > > >If the set of verified domain names contains any duplicates, only one > >evaluation needs to be performed and the duplicates can be ignored. > > > >There are significant benefits expected from prioritizing the order in > >which verified domain names are tested. Recommended sequence: > > > >- Exact-match domains > > > >- Parent domains. Only the longest match needs to be evaluated. > > > >- Child domains. Only the shortest match needs to be evaluated. > > > >- Sibling domains. Process in order from longest common > >substring to shortest common substring. > > _______________________________________________ > dmarc mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dmarc >
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
