I can not agree more than 100 percent on this. The PSL has issues. We need to stop depending on it.
If anything, the PSD work has shown the W3C folks that there is a path forward for folks who need to do PSL-like things without boiling the ocean. tim (who has spent a bit too much time recently attempting to work out a success path for DBOUND2) On Mon, Feb 27, 2023 at 10:08 AM Scott Kitterman <skl...@kitterman.com> wrote: > > > On February 27, 2023 3:04:11 PM UTC, "Murray S. Kucherawy" < > superu...@gmail.com> wrote: > >On Mon, Feb 27, 2023 at 4:29 AM Douglas Foster < > >dougfoster.emailstanda...@gmail.com> wrote: > > > >> The current text has an incentive problem. For an evaluator, the PSL > >> works fine. Unless an evaluator is Google-class, receiving mail from > >> everywhere in the world, most of the PSL entries will never be examined > and > >> most of the PSL errors will never be exposed. When an error is > detected > >> by an evaluator, it is a trivial effort to add or remove a record from > the > >> local copy of PSL. For evaluators, the PSL works fine. > >> > > > >The notion that different operators are using slightly different versions > >of the PSL is one of the reasons we want to stop depending on the PSL. I > >don't think we should offer this as an option. > > > > > >> Domain owners / message senders are the ones who should be powerfully > >> motivated to replace the PSL. If so, they should be willing to add a > tag > >> that invokes MUST USE TREE WALK because it eliminates ambiguity and > >> protects them from the PSL. With that elimination of ambiguity > >> and corresponding MUSRT, evaluators have a reason to change. Without > >> that, evaluators have every reason to ignore this new, unproven, and > >> imperfect algorithm; > >> > > > >I'm worried about leaving operators with a choice here, for a number of > >reasons: > > > >1) "pct" also presented a choice, and the consensus appears to be that > this > >didn't work out at all, for the reasons previously given (mostly related > to > >variance in implementations). > > > >2) "Stop using the PSL" as a goal is delayed or even thwarted if we add > >such a tag. It creates an undefined, possibly infinite, period of > >migration during which operators can opt out. If we're going to do this, > >we should discuss including some kind of firm sunset period for the PSL. > >But now we're walking in the direction of having a flag day, and everybody > >hates those. > > > >3) Since the goal is to wind down dependence on the PSL, I suggest that an > >implementation might choose to make the algorithm selectable, but I don't > >think the specification should. > > > >-MSK > > 100 percent agree. The only way to stop doing something is to stop doing > it. The specification is all we control. Implementers will adjust and > transition to the IETF design based on their own business timelines. > > Scott K > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc >
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
