Re: [dmarc-ietf] What is a policy domain? an org domain? How do we not break existing DMARC?

[Scott Kitterman <[e-mail]>]

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 <[e-mail]> 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 <[e-mail]> 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, [e-mail], Taughannock Networks, Trumansburg NY
> > > > Please consider the environment before reading this e-mail.
> > 
> > https://jl.ly
> > 
> > > > _______________________________________________
> > > > dmarc mailing list
> > > > [e-mail]
> > > > https://www.ietf.org/mailman/listinfo/dmarc
> > 
> > _______________________________________________
> > dmarc mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/dmarc