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
