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

[Seth Blank <[e-mail]>]

On Tue, Jul 16, 2019 at 10:40 PM Scott Kitterman <[e-mail]>
wrote:

> 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.
>

I absolutely agree with this.


> 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
>

Ah, I see what you're saying here. I honestly couldn't understand why you
were talking about sp=none at all within a PSD context. I thought the
solution to this scenario was to do as the PSO p=none; np=reject. I
actually like p=reject; sp=none; better here, because that lets the PSD
lock itself down as a sending domain. But to me, this also makes it clear
that np= should use the p= not the sp= as its default.

That said, I feel less strongly about this now, and can see merit in
inheritance from either side (or from a hard default of none, for that
matter, although I'd strongly argue against that personally...).


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

This I don't understand. The results you outlined are exactly what I think
should happen.


> 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).
>

I don't think I properly understand what you're saying. Can you clarify
this point?

Thanks!

S