We need to remember the two uses of NP. Non-existent organizations are inherently untrusted. A knowledgeable administrator should block them whenever they are detected, with or without a DMARC policy, with or without an NP term in a PSD policy. There seem to be political problems with saying as much in this document, but it is the right action. Feedback reporting will only occur if there is a PSD policy, and every PSD policy SHOULD include an NP=reject term. If the PSD policy lacks an NP term, and NXDomain is the reason a message is blocked, then the disposition reason is local policy. Perhaps we need a local policy code for "blocked because of NXDomain without an NP clause", but this situation should be rare.
A non-existent subdomain is not a problem unless the domain owner says that it is a problem in the organization's DMARC policy. Non-existent subdomains are used on a daily basis for legitimate mail. Normal DMARC rules allow non-existent subdomains to be authenticated by parent or sibling domains. We should not be changing this. If an administrator chooses to block for non-existent subdomain without domain owner direction, this would also be a local policy disposition. I am intrigued by the idea of using inbound A-R data to provide a permanent record that could be used to validate outbound reporting data. But are changes really needed to do so, and would they be changes to our document or changes to A-R? Doug Foster On Fri, Dec 30, 2022 at 9:03 AM Alessandro Vesely <[email protected]> wrote: > On Wed 28/Dec/2022 17:39:34 +0100 Scott Kitterman wrote: > > On Wednesday, December 28, 2022 11:19:46 AM EST Alessandro Vesely wrote: > >> Appendix A5 in the I-D describes "Issues with ADSP in Operation". This > >> appendix existed in RFC 7489 (March 2015), when ADSP was already set to > >> Historic (November 2013). > >> > >> Bullet #2 in that appendix says "Nonexistent subdomains are explicitly > out > >> of scope in ADSP." DNARC, instead has an apposite np= policy. > >> > >> However, in Authentication-Results one can write dkim-adsp=nxdomain. I > >> found no equivalent result for dmarc=. Shouldn't there be one? > > > > nxdomain isn't a DMARC result, so from that perspective, no. > > > Why not add it? We'd write dmarc=temperror on a DNS hiccup, correct? The > result of DNS lookup strongly affects DMARC results. > > It is important to know whether the From: domain exists. The only > standard way > to report it is to write dkim-adsp=nxdomain, which is a nuisance. > > > > I think a better question is should the A-R header field indicate which > tag was > > used for policy determination (p=, sp=, np=). I think the answer is, > again, > > no. > > > The draft has a polrec.p= tag to report the policy found. It is tricky to > tweak that into, say, polrec.np=. Would it mean that the polrec.domain > had an > np= tag, or that the receiver got nxdomain and hence determined to use an > np= > policy, irrespective of what was actually written in the policy record? > > > > Is that currently captured in aggregate reporting? If we're going to > indicate > > it anywhere, I think that's the right place. > > > I think having a strict match between A-R lines and aggregate reports > would be > a good thing. To wit, one could debug emitted reports by looking at A-Rs. > > > > Best > Ale > -- > > > > > > > _______________________________________________ > dmarc mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dmarc >
_______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
