As someone who has worked with companies, educational institutions, and governments to set DMARC policy it makes no sense to me that we’d argue the top-most-non-PSD policy is the one that should apply. Given how DNS works technically and how policies are set in practice, I support stopping at the bottom-most policy.
laura > On 28 Feb 2023, at 11:52, Douglas Foster > <dougfoster.emailstanda...@gmail.com> wrote: > > 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 > <mailto:superu...@gmail.com>> wrote: >> On Mon, Feb 27, 2023 at 4:29 AM Douglas Foster >> <dougfoster.emailstanda...@gmail.com >> <mailto: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 -- The Delivery Experts Laura Atkins Word to the Wise la...@wordtothewise.com Email Delivery Blog: http://wordtothewise.com/blog
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
