Murray, I think we need to acknowledge that we are already in a long tail. A small percentage of domain owners publish DMARC policies, a still smaller percentage publish "reject", and evaluators have a hard time deciding whether to use DMARC because the results are unreliable. The PSD discussion merely highlights the fact that DMARC results can be unreliable in both directions - PASS and FAIL.
We were much closer to a plausible algorithm when the Tree Walk stopped at the top-most non-PSD policy. We know that most PSOs and private registries do not publish DMARC policies, and we hope that those who do will add the PSD=Y flag. Given both of these conditions, if a DNS path contains multiple DMARC policies, the top-most policy will be the organizational policy because we don't expect any non-PSD policies above the organizational domain. To get a Tree Walk algorithm that stops at the bottom-most policy, John added the assumption that domains will never publish sub-domain policies, so that a higher-level policy will either not exist at all, or will only exist as a registry policy, either of which can be ignored. This assumption was made without data and is simply implausible. If have trouble assuming that registries, especially private registries, will only publish PSD=Y policies, now and forever. My goal in replacing the PSL is to give domain owners the responsibility and the control to define their own organizational domain boundary. The current Tree Walk does not do that, so it cannot succeed. The org=-n term places responsibility where it belongs. Doug Foster On Mon, Feb 27, 2023 at 10:04 AM 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 >
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
