3.5. Report Delivery
このページは RFC 9990 の該当節を要約し, XML schema, report fields, IANA values を保持します.
Report delivery, Report-ID ABNF, filename ABNF, email transport requirements, and duplicate handling from Section 3.5 are preserved below.
3.5. Report Delivery
The Mail Receiver, after preparing a report, MUST evaluate the
provided reporting URIs (see [RFC9989]) in the order given. If any
of the URIs are malformed, they SHOULD be ignored. An attempt MUST
be made to deliver an aggregate report to every remaining URI, up to
the Receiver's limits on supported URIs.
If delivery is not possible because the services advertised by the
published URIs are not able to accept reports (e.g., the URI refers
to a service that is unreachable), the Mail Receiver MAY cache that
data and try again later or MAY discard data that could not be sent.
Where the URI specified in a "rua" tag does not specify otherwise, a
Mail Receiver generating a feedback report SHOULD employ a secure
transport mechanism, meaning the report should be delivered over a
channel employing TLS (SMTP+STARTTLS).
3.5.1. Definition of Report-ID
This identifier MUST be unique among reports to the same domain to
aid receivers in identifying duplicate reports should they happen.
The Report-ID value should be constructed using the following ABNF:
ridfmt = (dot-atom-text ["@" dot-atom-text]) ; from RFC 5322
ridtxt = ("<" ridfmt ">") / ridfmt
The format specified here is not very strict, as the key goal is
uniqueness. In order to create this uniqueness, the Mail Receiver
may wish to use elements such as the receiving domain, the sending
domain, and a timestamp in combination. An example string might be
"[email protected]". An alternate could use a date
string such as "[email protected]".
3.5.2. Email
The message generated by the Mail Receiver MUST be as described in
[RFC5322] and formatted per [RFC2045]. The aggregate report itself
MUST be included in one of the parts of the message, as an attachment
with a corresponding media type from below. A human-readable
annotation MAY be included as a body part (with a human-friendly
content-type, such as "text/plain" or "text/html").
The aggregate data MUST be an XML file that SHOULD be subjected to
GZIP [RFC1952] compression. Declining to apply compression can cause
the report to be too large for a receiver to process (the total
message size could exceed the receiver SMTP size limit); doing the
compression increases the chances of acceptance of the report at some
compute cost. The aggregate data MUST be present using the media
type "application/gzip" if compressed (see [RFC6713]) and "text/xml"
otherwise. The attachment filename MUST be constructed using the
following ABNF:
filename = receiver "!" policy-domain "!" begin-timestamp
"!" end-timestamp [ "!" unique-id ] "." extension
receiver = domain-name
; imported from RFC 6376
policy-domain = domain-name
begin-timestamp = 1*DIGIT
; seconds since 00:00:00 UTC January 1, 1970
; indicating start of the time range contained
; in the report
end-timestamp = 1*DIGIT
; seconds since 00:00:00 UTC January 1, 1970
; indicating end of the time range contained
; in the report
unique-id = 1*(ALPHA / DIGIT)
extension = "xml" / "xml.gz"
The following primitive tokens that are used but otherwise
unspecified are taken from "Core Rules" (Appendix B.1 of [RFC5234]):
DIGIT, ALPHA.
The extension MUST be "xml" for a plain XML file or "xml.gz" for an
XML file compressed using GZIP.
"unique-id" allows an optional unique ID generated by the Mail
Receiver to distinguish among multiple reports generated
simultaneously by different sources within the same Domain Owner. A
viable option may be to explore Universally Unique Identifiers
(UUIDs) [RFC9562].
If a report generator needs to re-send a report, the system MUST use
the same filename as the original report. This would allow the
receiver to overwrite the data from the original or discard the
second instance of the report.
For example, this is a sample filename for the gzip file of a report
to the Domain Owner "example.com" from the Mail Receiver
"mail.receiver.example":
mail.receiver.example!example.com!1013662812!1013749130.xml.gz
No specific MIME message structure is required for the message body.
It is presumed that the aggregate reporting address will be equipped
to extract body parts with the prescribed media type and filename and
ignore the rest.
Mail streams carrying DMARC feedback data MUST conform to the DMARC
mechanism, thereby resulting in an aligned "pass" (see Section 4.4 of
[RFC9989]). This practice minimizes the risk of Report Consumers
processing fraudulent reports.
The RFC5322.Subject field for individual report submissions MUST
conform to the following ABNF:
; FWS is imported from RFC 5322
dmarc-subject = %s"Report" 1*FWS %s"Domain:"
1*FWS domain-name 1*FWS ; policy domain
%s"Submitter:" 1*FWS
domain-name 1*FWS ; report generator
[ %s"Report-ID:" 1*FWS ridtxt ] ; defined above
The first domain-name indicates the DNS domain name about which the
report was generated. The second domain-name indicates the DNS
domain name representing the Mail Receiver generating the report.
The purpose of the Report-ID: portion of the field is to enable the
Domain Owner to identify and ignore duplicate reports that might be
sent by a Mail Receiver.
For instance, this is a possible Subject field for a report to the
Domain Owner "example.com" from the Mail Receiver
"mail.receiver.example". It is folded as allowed by [RFC5322]:
Subject: Report Domain: example.com
Submitter: mail.receiver.example
Report-ID: <[email protected]>
This transport mechanism potentially encounters a problem when
feedback data size exceeds maximum allowable attachment sizes for
either the generator or the consumer.
Optionally, the report sender MAY choose to use the same "ridtxt" as
a part or whole of the RFC5322.Message-Id header included with the
report. Doing so may help receivers distinguish when a message is a
re-transmission or duplicate report.
3.5.3. Other Methods
The specification as written allows for the addition of other
registered URI schemes to be supported in later versions.
3.5.4. Handling of Duplicates
There may be a situation where the report generator attempts to
deliver duplicate information to the receiver. This may manifest as
an exact duplicate of the report or as duplicate information between
two reports. In these situations, the decision of how to handle the
duplicate data lies with the receiver. As noted above, the sender
MUST use the same unique identifiers when sending the report. This
allows the receiver to better understand when duplicates happen.
Here are a few options on how to handle that duplicate information:
* Reject back to sender, ideally with a permfail error noting the
duplicate receipt
* Discard upon receipt
* Inspect the contents to evaluate the timestamps and reported data,
act as appropriate
* Accept the duplicate data
When accepting the data, it's likely that the duplicate data has not
yet been noticed and is a one-off experience. Long-term duplicate
data is not ideal. In the situation of a partial time frame overlap,
there is no clear way to distinguish the impact of the overlap. The
receiver would need to accept or reject the duplicate data in whole.