Re: [dmarc-ietf] Ruminating the tree walk

[Alessandro Vesely <[e-mail]>]

On Sun 03/Apr/2022 01:35:16 +0200 Scott Kitterman wrote:
> On Wednesday, March 23, 2022 6:59:08 AM EDT Alessandro Vesely wrote:
>> Hm...
>> 
>> On Wed 23/Mar/2022 03:08:35 +0100 Douglas Foster wrote:
>>> During my ruminations last night, I gained some clarity around that
>>> question and wanted to highlight those conclusions.  They simplify the
>>> alignment search significantly:
>>> 
>>> - If the common substring is shorter than the Organizational Domain, then
>>> the names are not aligned and the candidate domain can be ignored.
>>> 
>>> - Otherwise, if any candidate domain is a parent of (or equal to) the FROM
>>> domain, then and we have alignment and DMARC PASS.  The secondary tree
>>> walk is not needed and no further evaluation is required.
>>> 
>>> - If several candidate names are child domains of the FROM address, then
>>> only the shortest string needs to be evaluated with a secondary tree
>>> walk.  If it is aligned, further evaluation is not required.  If it is
>>> not aligned because of an organizational boundary, all other child
>>> domains are also excluded.
>>
>> That and the deeper-than-5 optimization Doug posted on a separate message.
>> 
>> I know the document is already longish.  However, collecting these
>> observations in an appendix may be helpful for developers, and maybe also
>> for general understanding of the intricacies involved in the tree walk,
>> including proper usage of the psd= flag.
> 
> I think we do need to add some additional clarity, which I plan to draft, but
> let's not go overboard.  We are trying to describe a protocol, not a
> implementation specification.  So far, in my experience, the extra code
> required to address short cuts like this is not justified by the improved
> 'efficiency'.  I don't think these need to be in the document.


I agree that the efficiency is determined more by having a dedicated caching 
resolver than by the algorithm.  And the importance of setting up DNS will 
never be stressed enough.

I was thinking rather to a walk through the tree walk (no pun intended), to be 
read by domain owners and programmers alike, to help understanding what's good, 
what's bad, what's normal and what's exceptional.

Having such an appendix permits the actual algorithm to be stated in a concise, 
formal expression.  The last description, for example, uses two steps, 2 and 7, 
to advise to discard non-DMARC records.  Step 8 repeats the directive already 
given in step 3.  That language is neither formal nor friendly.


Best
Ale
--