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