On 10/20/23 12:35 PM, Murray S. Kucherawy wrote:
(1) As written, the text says (to me) that the handling of a message
might change depending on this mapping of a broken value to "none",
but only if "rua" is present; absent "rua", the record is treated as
junk and DMARC doesn't apply.
It's not so much changing the handling as changing the reporting.
* The policy to apply is "none," because the p/sp/np value was faulty. Done.
* Next step, if there's no "rua" target you can't report - which is now
equivalent to bailing out of DMARC processing for this message.
Olivier's language comes close to this. But then Matt and Ale have
continued with reporting...
Matt Wander wrote:
In the above case, the already existing (but not prominently known)
optional <error> field in the <report_metadata> section can be used to
include an error message, e.g., "syntax error in sp tag".
Text suggestion:
The Mail Receiver MAY utilize the optional "error" field in aggregate
reports to announce syntax errors identified in the DMARC policy record.
+1
So then, maybe we wind up with something like this:
PROPOSED versus draft 28 section 4.7:
========
If a retrieved policy record does not contain a valid "p" tag, or
contains an "sp" or "np" tag that is not valid, then:
* The Mail Receiver MUST act as if a record containing "p=none" was
retrieved and continue processing;
* The Mail Receiver MAY note the invalid "p", "sp", or "np" tag
in the optional "error" field of the informative section of the
DMARC aggregate report [I-D.ietf-dmarc-aggregate-reporting];
* If there is no "rua" tag, or if it does not contain at least one
syntactically valid reporting URI, the Mail Receiver effectively
applies no DMARC processing to this message.
========
And if somebody wants to argue against including the third point, I
would offer that it may be better to be explicit that to repeat this
exercise in a future WG.
--S.
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
