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
