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
