IETF Last Call Review of draft-ietf-dmarc-failure-reporting-20
review-ietf-dmarc-failure-reporting-20-secdir-lc-huitema-2025-11-23-00

I have reviewed  draft-ietf-dmarc-failure-reporting-20 as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG. These comments were written primarily for the benefit of the
security area directors. Document editors and WG chairs should treat
these comments just like any other last call comments.

    The summary of the review is Ready with 2 nits

The new version of DMARC (draft-ietf-dmarc-dmarcbis) specifies that
Mail Receiver can provide feedback on domain policies by sending
daily aggregate reports (draft-ietf-dmarc-aggregate-reporting) and
optionally immediate failure reports. The reviewed
draft (draft-ietf-dmarc-failure-reporting) specified how
to send these failure reports. 

By their very nature, the failure reports present a privacy risk.
They have to contain enough information to diagnose the reason
why the mail processing failed, but the more information they
provide the higher the privacy risk. This compounded by the
possible practice of outsourcing DMARC management to third
parties that can receive reports from multiple organizations,
and thus collect large amount of data.

The privacy considerations in the "failure report" draft expand on
these considerations. They are well written and, I think, fairly complete.

The security consideration section directs the reader towards the
privacy considerations in section 7, to the privacy and security
considerations in section 10 and 11 of the DMARc bis draft, and
to the privacy and security considerations in the DMARC
aggregate reporting draft. This is fair: these two drafts have well
developed privacy and security considerations, and make for good reading.

One first nit: the last paragraph of section 2, starting
with "failure reports represent a possible denial-of-service attack"
points out that adversary could send malformed messages and
trigger a flood of failure reports, and suggest resorting
to aggregation and rate limiting to mitigate these attacks. This
material arguably belongs in the security consideration. I would
suggest either moving it here, or promoting it to a subsection
2.1 that could be referenced in the security section.

Second nit: the privacy consideration rightly point out the
privacy risk of reporting failures. The DMARC bis draft clearly states
that sending the failure reports is optional. To quote, "Experience
has shown, however, that Mail Receivers rightly concerned about
protecting user privacy have either chosen to heavily redact the
information in such reports (which can hinder their usefulness) or
not send them at all." It would be very nice if some form of
this advice was repeated in the introduction.