On Wed 29/Oct/2025 02:23:26 +0100 Murray S. Kucherawy wrote:
I've volunteered to shepherd this document.
Thank you.
The points I quote below below seem to depend on an interpretation of fo=,
which took me quite quite a while to understand. Dmarcbis says:
d: Generate a DKIM failure report if the message had a signature that
failed evaluation, regardless of its alignment. DKIM-specific reporting
is described in [RFC6651].
s: Generate an SPF failure report if the message failed SPF evaluation,
regardless of its alignment. SPF-specific reporting is described in
[RFC6652].
Now the arguable points:
5. In Section 2, replace Paragraph 4 with:
When a Domain Owner requests failure reports for the purpose of
forensic analysis, and the Mail Receiver is willing to provide such
reports, the Mail Receiver generates and sends a message using the
format described in [RFC6591] but as modified in Section 4 of this
document.
The Mail Receiver may want to generate a DKIM report, possibly after reading
fo=d. In this case, the modifications in Section 4 should be ignored.
Instead, they should use the ARF extension defined in RFC 6591 only.
If this interpretation is correct, citing RFCs 6651/2 is incorrect. These
documents specify how to /request/ DKIM or SPF failure reports, not their
format. If the reports are requested in the _dmarc record, it is redundant to
request them by other means as well.
8. Also in Section 3, some explanation of why that RECOMMENDED is there
would be good to include (or remove it if we can't justify it in terms of
interoperability).
The main reason is that the methods defined in RFCs 6651/2 are almost never
used. Their use is considered an error by most DKIM/ SPF syntax checkers.
Now, I'm not aware of any report generator that modifies the report format
depending on the failure type and/or the fo= tag. However, I would never want
to prevent that. In case, life for a report generator would be much easier if
it can simply check the _dmarc record, leaving _report._domainkey and r=y alone.
Would someone suggest a plausible wording?
Almost all the other points look fine. I saved changes on GitHub; see
https://github.com/ietf-wg-dmarc/draft-ietf-dmarc-failure-reporting/compare/2ac4ec04f49bf08c3948e8a0bafa40e65e4f4bdf...main
Best
Ale
--
_______________________________________________
dmarc mailing list -- [email protected]
To unsubscribe send an email to [email protected]
