It helps to know the assumptions that have led John to such incorrect conclusions.
When moving from a PSL to the DNS, the primary obstacle has always been missing information. Therefore, one goal of this project is exactly to induce people to update their DMARC records, to supply information that is currently missing. We are attempting to do what DBOUND tried and failed to do - insert boundary information into DNS using information published by registrars and the registered organizations. Ale has correctly assessed that in the new design, a DMARC record can play one of four roles. Evaluators must code for all four of these possibilities, regardless of how many token values we define. With four roles, we have five information states: explicit indicators for Registrar, Org, Both, None, and the fallback result of NULL. Anyone who has ever tried to interpret incomplete data knows that a null result is different from a default value, and that explicit data is always preferable to guessing a default value to use when confronted with null. Evaluators will be required to cope with a NULL result by assigning those policy records to one of the four roles. The assigned role will be context-sensitive, which is one of the reasons that NULL and NONE are not equivalent. Fortunately, we expect that the correct default can be applied most of the time. However, the proposal to project five states into three, using "psd=(y,n,null)", is an unforced error that cannot be justified. There is also a huge communication error introduced by assuming that "psd=n" will be reliably configured to mean "org=y". There are a relatively small number of registrars who will be publishing DMARC information, against millions of organizations that are publishing, or will publish, DMARC policies. We need the language optimized to ensure that organizations publish their flag data correctly. We also have a nomenclature problem connected to the choice of "psd=value" as a token. We have recognized that there are public registrars and private registrars, and that DMARC must cope with both types. Private registrars are not PSOs and we should not bless them with a title that they do not deserve. Our document needs to be updated to reflect this reality. Throughout the text, we should have "Registrars", and "Registration Domains", not PSOs and PSDs, except for introductory material where we explain the difference between the two and its implications for tree walk. The registrar role should be indicated with "REG", not with "PSD". Doug Foster On Sat, Feb 26, 2022 at 12:14 PM John R Levine <[email protected]> wrote: > >> No. This just adds more useless complexity that is unlikely to get > implemented. > > > > While composing a DMARC record, setting role=org seems more likely than > psd=n. > > For the umpteenth time, the goal here is to be as compatible as possible > with the way that DMARC works now. An important part of that is not to > ask people to change their existing DMARC records because we know that > most of them won't. > > The normal case, like 99.99% of the time, is that the PSD does not publish > a DMARC record at all. The org domain has a DMARC record if it sends mail > or its subdomains use relaxed alignment. The way Scott and I propose to > do a tree walk, that will get the same alignment as now with no changes to > the DMARC record. That includes millions, maybe tens of millions of > domains. > > A few PSDs publish DMARC records, either because they have a policy about > their registrants' mail, or because the PSD itself has an MX. We want > them to add psd=y. That includes 52 domains. (I counted them.) > > As an extreme corner case, if you are registered under a PSD that > publishes a DMARC record but erroneously doesn't include psd=y, you can > use psd=n as a kludge to prevent evil sibling alignment. That currently > includes about 45 of those 52 domains, but I think we can get it close to > zero because we have contacts at many of them. > > I'm finding it hard to understand the advantage of a scheme that requires > millions of DMARC records to change rather than one that changes 52. > > 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
