I think you are making far too much of this. I've been implementing this as we go and it's pretty trivial.
Scott K On Tuesday, March 22, 2022 10:27:37 PM EDT Douglas Foster wrote: > The response below went out prematurely and incomplete, but I hope you can > see where we I was going. We have an ever-changing algorithm as we try to > do a desk analysis of the problem. > > One of my purposes for the outline was to see how many indicators we will > need, by identifying what actions we would like to trigger based on those > indicators, as well as clearly defining how we cope with the expected > absence of indicators within each situation. > > Trying to implement a specification is the best way to learn whether a > specification provides a developer with sufficient guidance to produce the > intended result. In our case, we need a specification which provides > sufficient information to many developers. That is a tall order. > > Doug > > On Tue, Mar 22, 2022 at 9:40 PM Douglas Foster < > > [email protected]> wrote: > > No, I think the RFC 7489 algorithm is much simpler than this one. > > John was adamant that we only needed one indicator. Then he conceded that > > we need two. Now he thinks we need three. Ale and I said early on that > > we > > thought we needed four. > > > > On Tue, Mar 22, 2022 at 7:47 AM Scott Kitterman <[email protected]> > > > > wrote: > >> I gather then that your claim is that RFC 7489 isn't implementable. Is > >> that right? > >> > >> Scott K > >> > >> On March 22, 2022 11:11:40 AM UTC, Douglas Foster < > >> > >> [email protected]> wrote: > >> >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 _______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
