Your latter questions were similar to Ale's - If the SPF/DKIM domain is a parent of the From domain, then we check its relationship to the organizational domain. If it is a parent of the organizational domain, the result is unaligned. If it is anywhere between the organizational domain and the From domain, then it is aligned. In either case, the Tree Walk is no needed.
- Exact match domains do not need the Tree Walk. That is obvious and was handled in one of my first bullets. Otherwise, the SPF/DKIM domain must be a child of the organizational domain. Determining whether a candidate domain meets these criteria do not require a Tree Walk. All of this is based on my slightly confrontational comment that "Tree Walk is inefficient and unreliable", which maybe needs elaboration. My approach to the problem changed dramatically when I discovered, by accident, that a subset of DNS servers will refuse to answer queries that produce NXDOMAIN, and a non-response does not come with a TTL value. Additionally, the increase in DNS traffic of at least 100% will be mostly NXDomain queries, while the raw volume will also increase the frequency of random DNS timeouts. All of this means that a successful implementation needs to have optimizations which ensure known answers are cached, especially if that result was obtained after experiencing timeout errors. I don't think the oblique reference to DNS timeouts comes close to documenting the severity of the problem. I have always felt that the Tree Walk should be referenced in the main body as a concept, to focus on the decision process, and then described in detail in an appendix, where the differences between first and second tree walks can be presented succinctly, and some discussion of optimizations can be included without losing train of thought. You write really good prose when you have room to do so. In this case, the Tree Walk description was done early, because it was needed, but then it became frozen in place. Doug On Wed, Mar 13, 2024 at 10:04 AM Todd Herr <todd.h...@valimail.com> wrote: > On Wed, Mar 13, 2024 at 6:24 AM Douglas Foster < > dougfoster.emailstanda...@gmail.com> wrote: > >> My unsuccessful attempt to implement to the specification has reminded me >> of my past concerns. >> >> Our document gives primacy to the Tree Walk, as if it will be used on >> every From domain, SPF domain, and DKIM domain. The Tree Walk algorithm >> is explained in detail before any discussion of how it is used, and the >> differences between the From walk and the SPF/DKIM walks have been >> ignored. I find that this makes the document harder to follow and less >> usable. >> >> The reality is that the Tree Walk is an inefficient and unreliable way of >> obtaining an answer, particularly because of the risk of DNS timeouts. As >> a result, the Tree Walk should be avoided whenever possible. In fact, the >> secondary tree walks for SPF and DKIM can frequently be avoided: >> >> - When strict alignment is required. >> - When the SPF/DKIM domain is not verified. >> - When the SPF/DKIM domain matches the From domain. >> - When the SPF/DKIM domain is a parent of the From domain. >> - When a string comparison shows that the SPF/DKIM domain is not a >> child of the organizational domain >> >> For many messages, these optimizations will mean that no secondary tree >> walk will be needed at all. In the event that multiple secondary tree >> walks are required, additional efficiencies can be gained by prioritizing >> which signature domain is walked first. >> >> The Tree Walk is an important tool for deprecating the PSL. But the >> oversimplification of its discussion has prevented any substantive >> consideration of either the differences between the two types of Tree Walk >> or the available optimizations to avoid performance problems. >> > > Section 4.8 in DMARCbis includes this text: > > > ============================================================================== > > Note: There is no need to perform Tree Walk searches for Organizational > Domains under any of the following conditions:¶ > <#m_5516805231390163404_section-4.8-3> > > > - The RFC5322.From domain and the RFC5321.MailFrom domain (if SPF > authenticated), and/or the DKIM d= domain (if present and authenticated) > are all the same, and that domain has a DMARC record. In this case, this > common domain is treated as the Organizational Domain. > - No applicable DMARC policy is discovered for the RFC5322.From > domain during the Tree Walk for that domain. In this case, the DMARC > mechanism does not apply to the message in question. > - The record for the RFC5322.From domain indicates strict > alignment. In this case, a simple string comparison of the RFC5322.From > domain and the RFC5321.MailFrom domain (if SPF authenticated), and/or > the > DKIM d= domain (if present and authenticated) is all that is required. > > > ============================================================================== > > > Does that text not at least address the first three bullets you've > included here? > > As for your other bullets.. > > - "When the SPF/DKIM domain is a parent of the From domain." - I'm not > sure this is a valid exception in all cases. Consider the domain > dept.school.college.edu, which publishes a DMARC policy and has an > organizational domain of school.college.edu. The domain college.edu is > a parent of that domain, but school.college.edu (an organizational > domain) and college.edu do not have the same organizational domain. On > the other hand, if college.edu is the organizational domain, then the > SPF/DKIM domain will align with the From domain. > - "When a string comparison shows that the SPF/DKIM domain is not a > child of the organizational domain" - An SPF/DKIM domain does not have to > be the child of an organizational domain in order to have the same > organizational domain as the From domain; it can be the organizational > domain, as I mentioned above. Perhaps this could be written as "When a > string comparison shows that the rightmost labels of the SPF/DKIM domain > are not identical to the organizational domain, in which case alignment > between the two domains is not possible."? > > > -- > > Todd Herr | Technical Director, Standards & Ecosystem > Email: todd.h...@valimail.com > Phone: 703-220-4153 > > > This email and all data transmitted with it contains confidential and/or > proprietary information intended solely for the use of individual(s) > authorized to receive it. If you are not an intended and authorized > recipient you are hereby notified of any use, disclosure, copying or > distribution of the information included in this transmission is prohibited > and may be unlawful. Please immediately notify the sender by replying to > this email and then delete it from your system. >
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
