Scott, good point about the interoperability issue for the ‘np’ tag. I hadn’t really thought about that. Since what we do here for PSD DMARC will hopefully be included in regular DMARC for the future as well, I agree that it makes that we should not have the default behavior be different than current implementations, so we should keep your original intent to have ‘np’ default to ‘sp’ first if ‘np’ is absent.
From a purist perspective, I agree with Ian that non-existent sub-domains are really the responsibility of that domain and so that domain’s policy should apply by default. But the interoperability issue is more important. Even without having ‘p’ as the default, it’s easy for a domain to achieve this by adding the ‘np’ tag explicitly. For the current wording, I think the “if not” is unclear in the “If absent, the policy specified by the "sp" (if present) and then the "p" tag, if not, MUST be applied for non-existent subdomains.” Does the “if not” mean if the sp tag is not present? If so, then I think it should be in parentheses to match the “(if present)” and probably could be a little clearer by saying “(if the “sp” tag is not present)”. Thanks, -Eric _________________________ Eric Chudow DoD Cybersecurity Mitigations _______________________________________________________ From: Tim Wicinski <tjw.i...@gmail.com> Sent: Wednesday, July 17, 2019 8:29 AM To: Scott Kitterman <skl...@kitterman.com> Cc: IETF DMARC WG <dmarc@ietf.org> Subject: Re: [dmarc-ietf] Nonexistent Domain Policy was: Re: Working Group Last Call: draft-ietf-dmarc-psd Thanks for the update Scott, and your wording on the 'np' tag in the Appendix works. I just want to call out your statement: I think changing existing defined behavior for non-participants in an experiment is not appropriate. It's even more unacceptable in a case like this where we absolutely don't need it to achieve the desired behavior within the experiment. I agree very strongly on this, and this is the right way to view this. While we all are confident that the 'np' tag will be a wild success, there is the case this is not true, and we need to not upset current working behavior. Tim (probably chair'ing a little here) On Wed, Jul 17, 2019 at 2:27 AM Scott Kitterman <mailto:skl...@kitterman.com> wrote: On July 17, 2019 5:54:41 AM UTC, Seth Blank <mailto:s...@sethblank.com> wrote: >On Tue, Jul 16, 2019 at 10:40 PM Scott Kitterman <mailto:skl...@kitterman.com> >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. See if you still feel that way after considering backward compatibility ... >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 think we agree on the goal, the difference is only about implementation details and impact on non-particpants in the experiment. > >> 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? Keep in mind that senders do send from what we call non-existent domains for reasons that seem good and sufficient to them. Let's take that as a fact, whether it makes sense to us or not. Sender (who knows nothing of our experiment) has published a DMARC record that includes: p=reject, sp=none When a DMARC compliant receiver receives mail from a subdomain of that organization domain, the policy to apply is none. If our experiment has 'np' fall back to 'sp', then the non-particpant gets the same result. An experiment participating receiver would use 'sp' directly (none) for an existing sub-domain and also use 'sp' (none - 'np' fallback) for a non-existing sub-domain. If our experiment has 'np' fall back to 'p', then the non-particpant gets a different result. An experiment participating receiver would use 'sp' directly (none) for an existing sub-domain and also use 'p' (reject - 'p' fallback) for a non-existing sub-domain. Keep in mind, this isn't just about receiver processing. The policy applied is also in the aggregate reports. I think changing existing defined behavior for non-participants in an experiment is not appropriate. It's even more unacceptable in a case like this where we absolutely don't need it to achieve the desired behavior within the experiment. Scott K _______________________________________________ dmarc mailing list mailto:dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
