On Tuesday, July 16, 2019 12:14:54 PM EDT Chudow, Eric B CIV NSA DSAW (USA) wrote: > I recently joined this working group from the United States Department of > Defense (DoD), which runs the .mil TLD. We appreciate all the work that has > been done so far on DMARC and are currently investing significant efforts > to implement DMARC broadly across DoD domains. We value and support this > PSD DMARC draft and experiment and see how it will complement the existing > DMARC effort for us and many others by being able to broadly apply DMARC at > TLDs and PSDs when subdomains are missing their own DMARC records and for > non-existent subdomains, which are significant gaps today. > > > > I agree with the suggestion below that the default policy for non-existent > sub-domains should be the domain's policy if the "np" tag is absent, rather > than defaulting to the "sp" tag's policy.
Although a few people have suggested this, I think it would be a mistake because it would cause a gratuitous incompatibility with RFC 7468. Current behavior (where np is not defined) is for sp to apply to all domains, existing or not. No distinction is made. Consider the effect of the two different approaches: Example: p=reject sp=none np=quarantine A receiver that is not a participant in the experiment will process the policy for a non-existent subdomain as none (since they don't recognize np). This is equivalent to: p=reject sp=none 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. If no 'np' falls back to 'p', then the policy is reject, which will have a negative interaction with non-participants. If the policy falls back to 'sp', then the result is the same whether the recipient is a participant or not. Also, keep in mind, that if 'sp' is not present, it falls back to 'p', so falling back to 'sp' first is not a dead end. > > A few minor suggestions: > > > > In section 4, "requiremetns" should be "requirements". Fixed. Thanks. > In section 4.1, there is an extra "be", so "This leakage could be > potentially be utilized ..." should be "This leakage could potentially be > utilized ....". Fixed. Thanks. > In appendix B, "faciliate" should be "facilitate". Fixed. Thanks, .... Scott K _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
