Re: [dmarc-ietf] Ruminating the tree walk

An alternative here is a pointer to one or two open-source implementations
that readers can refer to if they want to.  That keeps the document tight
while providing access to implementation examples.

Barry

On Sun, Apr 3, 2022 at 7:27 AM Alessandro Vesely <vesely@tana.it> wrote:

> 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
> --
>
>
>
> _______________________________________________
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc
>