Re: [dmarc-ietf] Nonexistent Domain Policy was: Re: Working Group Last Call: draft-ietf-dmarc-psd

[Scott Kitterman <[e-mail]>]

On Wednesday, July 17, 2019 1:18:50 AM EDT Seth Blank wrote:
> As an individual-
> 
> On Tue, Jul 16, 2019 at 10:05 PM Scott Kitterman <[e-mail]>
> 
> wrote:
> > Although a few people have suggested this, I think it would be a mistake
> > because it would cause a gratuitous incompatibility with RFC 7468.
> 
> The people suggesting this are the people asking for np= in the first place.
> > I think it is a desirable characteristic that the addition of np not
> > disturb
> > existing expectations.  If a recipient that is a participant in the
> > experiment
> > attempts to determine policy for a sub-domain without 'np', then the
> > result
> > should match what a non-participant gets.
> 
> I'm not certain this is desirable for PSD in the context of an experiment
> around np=.
> 
> Specifically, the point of np= is for strict enforcement for non-existent
> domains while the remainder of the zone gets its act together moving
> registered domains to policies more strict than none. Since, a) nearly all
> sp= policies in the world are set to "none", and b) sp= is meaningless at
> the PSD level anyway, I concur that np= should default to p=.
> 
> Or put a different way, the tags serve very different use cases, and in the
> wild, sp= will generally be none, whereas np= will generally be
> reject/quarantine. p= is the the meaningful tie-breaker here at the PSD
> level if no np= is set.
> 
> This (np='s default) should also be called out as part of the experiment
> around np if the group doesn't reach consensus before WGLC ends tomorrow.

Let's be clear:  If the experiment around 'np' is successful and it is 
included in a future non-experimental update, then it will have enough 
deployment that changing its behavior will almost certainly fall into the too 
hard bucket without an amazingly good reason.  While the experiment may 
conclude 'np' isn't worth doing, I think we should assume that if it is 
carried forward, then it will be the way we define it in this document.  So, 
"It's an experiment" is not, in my view, a useful reason to accept 
interoperability issues we can avoid.

I think you are reading the request backwards.

Yes, the point of 'np' is to allow for a stricter sub-domain policy, but 
that's to support early deployment of strict PSD level policies without 
breaking org domains that are still deploying/have not deployed DMARC.

Case:

PSO mandates all orgs deploy DMARC, but that's not done yet.  PSO wants to 
deploy PSD DMARC for reject at the PSD level and for non-existent domains, but 
leave non-DMARC deployed existing domains at none.  PSO publishes these 
policieis for the PSD:

p=reject, sp=none, np=reject

Results (for org domains)

Org domain with DMARC: Use org policy
Org domain with no DMARC:
         Regular DMARC: No DMARC policy, no feedback
         PSD DMARC receiver: policy is none, feedback to PSO if requested
Non-existent domain:
         Regular DMARC: No DMARC policy, no feedback
         PSD DMARC receiver: policy is reject, feedback to PSO if requested

Having 'np' fall back to 'p' doesn't actually solve the problem you claim to 
be solving since it only affects non-implementers.

I believe that's the exact requested case and the changeset I've provided 
supports that without creating a situation where every implementer of the 
experiment suddenly starts processing existing DMARC records differently (which 
I think would be very bad).

Scott K