This optimization is only relevant when a very inefficient algorithm is being used. There is no reason to ever compute all of the organizational domains for all of the candidates for relaxed authentication.
A highly simplified summary of the new DMARC process looks like this: 1) Check for and use the same-domain policy. If complete, exit with PASS or FAIL (5 use cases) 2) Determine the organizational domain name and default policy. If complete, exit with PASS, FAIL, or NO POLICY (8 uses cases) 3) One at a time, check the remaining identifiers for alignment with the selected Organizational Domain. On first alignment, exit with PASS. If the list is exhausted, exit with FAIL. (2 use cases) By the time we get to step 3: - Unverified identifiers are discarded at or before step 1. - Verified exact-match identifiers would have caused early exit during step 2 or step 3. - If a method requires strict alignment, inexact match identifiers for that method are discarded in step 2. - If an inexact-match identifier is not equal to or a child of the Organizational Domain, it is discarded in step 2. - During step 3, the remaining identifiers do a tree walk up to the Organizational Domain, one at a time. If no PSD tokens are found during the walk, alignment is confirmed and the result is PASS. If a domain name is rejected as unaligned, proceed to the next one until all candidates are checked. If none produce PASS, the result is FAIL. Possible Optimizations for step 3 If a domain is rejected as unaligned, then any duplicates and subdomains are also rejected. This might be a reason to sort alphabetically. One could find the common substrings between the verified identifiers and the From address, so that each identifier is segmented into a common part and an uncommon suffix. If a name is found with no suffix, then we have PASS. Otherwise, the identifiers with uncommon suffixes could be sorted by length of suffix, starting with the shortest suffix, because the shortest suffix has the shortest tree walk and therefore the least likelihood of finding a PSD token. But again, the first identifier will almost always PASS, because there will be no private registry underneath the Organizational Domain. So optimization is probably not worth the effort. Doug On Mon, Jul 18, 2022 at 5:32 PM John Levine <[email protected]> wrote: > It appears that Scott Kitterman <[email protected]> said: > >Change: > > > >"Select the Organizational Domain from the domains for which valid DMARC > >records were retrieved from the longest to the shortest:" > > > >to > > > >"For each Tree Walk for which valid DMARC records were retrieved, select > the > >Organizational Domain from the domains with DMARC records, evaluating > from the > >longest to the shortest:" > > Seems reasonable. Added that to the current pull request > > R's, > John > -- > Regards, > John Levine, [email protected], Primary Perpetrator of "The Internet for > Dummies", > Please consider the environment before reading this e-mail. https://jl.ly > > _______________________________________________ > dmarc mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dmarc >
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
