On what basis do you assert I haven't read things? It's interesting that you know better than I what I'm going to do. It's particularly amazing since I haven't had the time to do it yet.
Scott K On Sunday, February 27, 2022 4:17:04 PM EST Douglas Foster wrote: > If you are determined to submit your own text, perhaps you could read and > acknowledge the draft that has already been posted. > > On Sat, Feb 26, 2022, 7:41 PM Scott Kitterman <[email protected]> wrote: > > Which has nothing to do with what is a policy domain, an org domain, or > > how > > not to break existing DMARC. As I suggested earlier, we can decide what > > to > > call the tags independent of the policy lookup and org domain > > determination. > > I think we have those things resolved, modulo me having time to write it > > up in > > detail. Perhaps you could start a new thread on this topic. > > > > Scott K > > > > On Saturday, February 26, 2022 6:19:25 PM EST Douglas Foster wrote: > > > 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 _______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
