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