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 <skl...@kitterman.com>
>
> 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
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
