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
