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
