Re: [dmarc-ietf] Ruminating the tree walk

[Scott Kitterman <[e-mail]>]

It doesn't matter what order you do the queries in.  You still have to do them 
all.

Scott K

On Sunday, April 3, 2022 10:03:18 PM EDT Douglas Foster wrote:
> The problem remains that the tree walk only provides a reliable result if
> it has complete information about private registries, and we have no way of
> knowing if the tree walk provides that information.  Because these
> processes are voluntary opt-in mechanisms, we cannot assume that all
> private registries will publish the appropriate indicators.
> 
> To solve the problem, we need an indicator from the organization. that it
> either (a) contains no private registries, (b) contains private registries
> and the registration point is tagged with an indicator, or (c) contains
> private registries but tagging is incomplete or not usable.   For (c), the
> organization boundary cannot be determined reliably so only strict
> alignment can be used  (or the PSL could be consulted.)  This
> private-registry status indicator would need to be on the PSD-registered
> organization domain policy.   The most efficient way to find a
> PSD-registered organization policy is top down, as Scott originally
> proposed.
> 
> Doug
> 
> On Sun, Apr 3, 2022 at 9:11 AM Barry Leiba <[e-mail]> wrote:
> > 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 <[e-mail]> 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
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/dmarc
> > 
> > _______________________________________________
> > dmarc mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/dmarc