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. Doug Foster On Tue, Mar 12, 2024 at 3:49 PM Murray S. Kucherawy <superu...@gmail.com> wrote: > On Tue, Mar 12, 2024 at 6:23 AM Tobias Herkula <tobias.herkula= > 401und1...@dmarc.ietf.org> wrote: > >> The DMARC Record on the DKIM signing domain is not relevant for DMARC >> evaluation, so if the 5322.From header domain is “example.com” the >> “adkim:r” is relevant for evaluation regarding your example setup and would >> consider a DKIM signature domain of “sub1.example.com” as aligned. It’s >> the same behavior as vice versa. As if the 5322.From header domain is “ >> sub1.example.com” the “adkim:s” would apply and a DKIM signature Domain >> of “example.com” should not be considered aligned. >> > > Well, Section 4.8 in -30 reads: > > == BEGIN == > For Organizational Domain discovery, it may be necessary to perform > multiple DNS Tree Walks to determine if any two domains are in alignment. > This means that a DNS Tree Walk to discover an Organizational Domain might > start at any of the following locations: > > - > * The domain found in the RFC5322.From header of the message being > evaluated. > - * The domain found in the RFC5321.MailFrom header if there is an SPF > pass result for the message being evaluated. > - * Any DKIM d= domain if there is a DKIM pass result for that domain > for the message being evaluated. > > === END === > > So it's not clear that the "d=" domain isn't relevant. Perhaps this list > should be ordered? > > -MSK > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc >
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
