On Tue, Jul 16, 2019 at 10:40 PM Scott Kitterman <[email protected]> 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
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
