Mark and Laura's perspective solves my objections. We propose a deliberate change to use the bottom-most policy because we believe it better meets the needs of large organizations, of which regional governments are a good example.
A supporting benefit is that we eliminate the possibility of false NO POLICY or false PASS that can occur when the PSL (or any other jumping algorithm) jumps to the wrong organizational domain. We can partially test for negative impacts of this change by looking for messages where: - The organizational domain is different from the policy domain, and - Alignment is only possible using a parent of the policy domain. Do you think we can get that assessment from one of the big players? A sub-issue to consider: Should we do a Tree Walk on the authenticating domain? For example, assume that "virgina.gov" and "dmas.virginia.gov" both have DMARC policies with relaxed alignment. Should "dmas.virginia.gov" be prohibited from authenticating "virginia.gov"? My gut says yes, but it adds some overhead to enforce that rule. Doug On Tue, Feb 28, 2023 at 8:47 AM Mark Alley <mark.alley= 40tekmarc....@dmarc.ietf.org> wrote: > I agree with Laura's stance. Many organizations (that are not PSDs, and > not on a PSL) will publish explicit subdomain-specific DMARC policies to > prevent inheritance from a higher level, or the organizational domain > (which may not be ready for a stricter policy), during implementation. This > is a very common configuration. > On 2/28/2023 6:07 AM, Laura Atkins wrote: > > 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> > <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> > 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 > > > -- > The Delivery Experts > > Laura Atkins > Word to the Wise > la...@wordtothewise.com > > Email Delivery Blog: http://wordtothewise.com/blog > > > > > > > > _______________________________________________ > dmarc mailing listdmarc@ietf.orghttps://www.ietf.org/mailman/listinfo/dmarc > > _______________________________________________ > 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
