> On 28 Feb 2023, at 17:51, Alessandro Vesely <ves...@tana.it> wrote: > > > What are subdomains being used for?
If it’s DMARC policy, then it’s email. > Is that more often done for email reasons (MX) or for something else? DMARC is an email authentication protocol so everything about DMARC is for email reasons. > What changes when there is a zone cut (delegation) rather than having > sub-subdomains all in the same zone? Controlling inheritance obviously has > different tastes depending on the case. Which case is more common? If it’s a zone cut, then that supports the “bottom-most” policy even more than if it’s in the same zone, IMO. laura > > > Best > Ale > > On Tue 28/Feb/2023 14:46:54 +0100 Mark Alley 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> 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 list >>> dmarc@ietf.org >>> https://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 -- 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
