rfc9991v1.txt   rfc9991.txt 
skipping to change at line 94 skipping to change at line 94
Failure reports provide detailed information about the failure of a Failure reports provide detailed information about the failure of a
single message or a group of similar messages failing for the same single message or a group of similar messages failing for the same
reason. Their purpose is twofold. On the one hand, they are meant reason. Their purpose is twofold. On the one hand, they are meant
to aid in cases where a Domain Owner wishes to determine the cause of to aid in cases where a Domain Owner wishes to determine the cause of
failures that were part of aggregate reports (see [RFC9990]). On the failures that were part of aggregate reports (see [RFC9990]). On the
other hand, they can allow the Domain Owner to quickly identify and other hand, they can allow the Domain Owner to quickly identify and
address harmful messages involving direct domain abuse. It is address harmful messages involving direct domain abuse. It is
important to note that these reports can contain the header fields or important to note that these reports can contain the header fields or
sometimes the entire content of a failed message, which may contain sometimes the entire content of a failed message, which may contain
personally identifiable information (PII). The potential disclosure Personally Identifiable Information (PII). The potential disclosure
of PII should be considered when deciding whether to request failure of PII should be considered when deciding whether to request failure
reports as a Domain Owner, or what information to include or redact reports as a Domain Owner, or what information to include or redact
in failure reports when creating them as a Mail Receiver, or whether in failure reports when creating them as a Mail Receiver, or whether
to create failure reports at all. Refer to Section 7 for more to create failure reports at all. Refer to Section 7 for more
discussion on privacy considerations. discussion on privacy considerations.
1.1. Terminology 1.1. Terminology
There are a number of terms defined in Section 3.2 of [RFC9989] that There are a number of terms defined in Section 3.2 of [RFC9989] that
are used within this document. Understanding those definitions will are used within this document. Understanding those definitions will
skipping to change at line 154 skipping to change at line 154
When a Domain Owner requests failure reports for the purpose of When a Domain Owner requests failure reports for the purpose of
forensic analysis, and the Mail Receiver is willing to provide such forensic analysis, and the Mail Receiver is willing to provide such
reports, the Mail Receiver generates and sends a message using the reports, the Mail Receiver generates and sends a message using the
format described in [RFC6591]; this document updates that reporting format described in [RFC6591]; this document updates that reporting
format, as described in Section 4. format, as described in Section 4.
The destination(s) to which failure reports are sent, and options for The destination(s) to which failure reports are sent, and options for
when they will be sent, are defined by the "ruf" and "fo" tags as when they will be sent, are defined by the "ruf" and "fo" tags as
provided in Section 4.7 of [RFC9989]. provided in Section 4.7 of [RFC9989].
When multiple URIs are provided to receive failure reports, the When multiple Uniform Resource Identifiers (URIs) are provided to
report generator MUST make an attempt to deliver to each of them. receive failure reports, the report generator MUST make an attempt to
External destinations MUST be verified (see Section 5). Report deliver to each of them. External destinations MUST be verified (see
generators MUST NOT consider "ruf" tags in DMARC Policy Records that Section 5). Report generators MUST NOT consider "ruf" tags in DMARC
have a "psd=y" tag, unless there are specific agreements between the Policy Records that have a "psd=y" tag, unless there are specific
interested parties. agreements between the interested parties.
Report generators MUST implement a rate-limit on outgoing reports so Report generators MUST implement a rate-limit on outgoing reports so
as not to flood Report Consumers with excessive reports, which would as not to flood Report Consumers with excessive reports, which would
allow denial of service (see Section 8.1). allow denial of service (see Section 8.1).
3. Other Failure Reports 3. Other Failure Reports
This document only describes DMARC failure reports. DomainKeys This document only describes DMARC failure reports. DomainKeys
Identified Mail (DKIM) failure reports and Sender Policy Framework Identified Mail (DKIM) failure reports and Sender Policy Framework
(SPF) failure reports are described in [RFC6591]. A Mail Receiver (SPF) failure reports are described in [RFC6591]. A Mail Receiver
generating DMARC failure reports MAY issue failure reports specific that generates DMARC failure reports MAY choose to issue failure
to the failed authentication mechanism instead of, or in addition to, reports of the type specific to the authentication mechanism that
DMARC failure reports, based on its own policy, the failure in failed instead of, or in addition to, the DMARC failure report type
described here. The Receiver SHALL determine which failure report
types, if any, to transmit based on its own policy, the failure in
question, and the content of the "fo" tag in the retrieved DMARC question, and the content of the "fo" tag in the retrieved DMARC
Policy Record. Policy Record.
Note that DKIM failure reports and SPF failure reports can also be Note that DKIM failure reports and SPF failure reports can also be
requested using the methods described in [RFC6651] and [RFC6652], requested using the methods described in [RFC6651] and [RFC6652],
respectively. Report generators are free to follow any of the respectively. Report generators are free to follow any of the
specifications. specifications.
4. Reporting Format Update 4. Reporting Format Update
skipping to change at line 211 skipping to change at line 213
2. The Identity-Alignment field is defined to contain a comma- 2. The Identity-Alignment field is defined to contain a comma-
separated list of authentication mechanism names that failed to separated list of authentication mechanism names that failed to
authenticate an aligned identity or the keyword "none" if all of authenticate an aligned identity or the keyword "none" if all of
the attempted methods were successful at authenticating an the attempted methods were successful at authenticating an
aligned identity. Here is the ABNF [RFC5234] (importing comments aligned identity. Here is the ABNF [RFC5234] (importing comments
and/or folding white space (CFWS) from [RFC5322]): and/or folding white space (CFWS) from [RFC5322]):
id-align = "Identity-Alignment:" [CFWS] id-align = "Identity-Alignment:" [CFWS]
( "none" / ( "none" /
dmarc-method *( [CFWS] "," [CFWS] dmarc-method ) ) dmarc-method
*( [CFWS] "," [CFWS] dmarc-method ) )
[CFWS] [CFWS]
dmarc-method = ( "dkim" / "spf" ) dmarc-method = ( "dkim" / "spf" )
; each may appear at most once in an id-align ; each may appear at most once in an id-align
3. Authentication Failure Type "dmarc" is defined for the Auth- 3. Authentication Failure Type "dmarc" is defined for the Auth-
Failure field, which is to be used when a failure report is Failure field, which is to be used when a failure report is
generated because some or all of the authentication mechanisms generated because some or all of the authentication mechanisms
failed to produce aligned identifiers. Note that a failure failed to produce aligned identifiers. Note that a failure
report generator MAY also independently produce an ARF message report generator MAY also independently produce an ARF message
 End of changes. 4 change blocks. 
11 lines changed or deleted 14 lines changed or added

This html diff was produced by rfcdiff 1.48.