John overstates his case when he objects to creating a scheme which requires everyone to update their policy records. No such requirement has been proposed. Most participants MAY leave their policy records unmodified, but there are good reasons for them to CHOOSE to add the role indicator to their record.
The assumption that virtually no one will implement a role indicator seems to assume that no one will read, understand, and act on our document according to their understanding of their best interests. If we actually believe this is the case, we should stop wasting our time right now. Let's look at who does not require an org-top role indicator: - an organization which is registered with a PSD that does not have a PSD-level DMARC policy. - an organization which is registered with a PSD that has a DMARC policy that is properly tagged. When is a PSD flag necessary or useful? 1. For all registrars, a registrar-level policy prevents impersonation of unregistered domains. 2. For registered organizations, an org-top policy prevents relaxed alignment errors caused by a. a next-level parent domain DMARC policy that incorrectly lacks a Registrar tag, and (b) a Registrar-tagged DMARC policy which is more than one level above the organization top, leaving one or more levels with no DMARC policy and therefore assumed to be part of the organization. b. For private registrars, a registrar-level policy prevents client domains from impersonating each other. 3. For private registration client organizations, an org-top policy prevents impersonation by siblings within the private registration domain, by the private registrar organization, and by PSD-level siblings of the private registrar. 4. When an org-top policy is not detected, the evaluator must query DNS until a PSD-level policy is detected or a TLD is queried. Therefore, domain owners who publish an org-top policy benefit evaluators and DNS operators by improving efficiency. I tend to believe that when participants read that a mis-labeled PSD policy can cause false positives, that they will choose to publish org-type policies as a risk management measure. I expect regulators and insurance companies to drive this action as well. I also believe that a non-trivial number of domain owners will implement the org-top tag for the efficiency of evaluators. I have no opinion about whether private registration clients will embrace DMARC using relaxed alignment or SP pollicies, but if they do, they will be the one group where role tagging is mandatory for correct results. Regardless of the volume of participation, we need a role tagging specification that allows participation and minimizes confusion. Doug On Mon, Feb 28, 2022 at 3:04 PM John R Levine <[email protected]> wrote: > >> I think it would be a cruel joke on our users to give it a name that > looks > >> like something that has to be in every org domain's record. > > > > You're welcome to suggest better names. > > Like I said, psd=y / psd=n > > > Hm... However small, it's the only quality gain we can expect by > switching > > to tree walk. > > Sorry, that's just wrong. The PSL is only an approximation to the > boundaries for http cookies, and it's a worse approximation to DMARC > boundaries. The tree walk lets domains say what their actual policy is. > > > Roughly, I think it could grow to the size of the PSL private domains > section, no? > > Yes, that might be the number of DMARC records with psd=y, although if > the PSD doesn't do mail and doesn't have a PSD above it, which is the > typical case, it doesn't need a DMARC record at all. > > Regards, > John Levine, [email protected], Taughannock Networks, Trumansburg NY > Please consider the environment before reading this e-mail. https://jl.ly > > _______________________________________________ > dmarc mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dmarc >
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
