7. Privacy Considerations
Diese Seite fasst den entsprechenden Abschnitt von RFC 9990 zusammen und bewahrt XML-Schema, Report-Felder und IANA-Werte.
Privacy considerations, security considerations, and operational considerations from Sections 7-9 are preserved below.
7. Privacy Considerations
This section discusses exposure related to DMARC aggregate reporting.
7.1. Report Recipients
A DMARC Policy Record can specify that reports should be sent to an
intermediary operating on behalf of the Domain Owner. This is done
when the Domain Owner contracts with an entity to monitor mail
streams for abuse and performance issues. Receipt by third parties
of such data may or may not be permitted by the Mail Receiver's
privacy policy, terms of use, or other similar governing document.
Domain Owners and Mail Receivers should both review and understand if
their own internal policies constrain the use and transmission of
DMARC reporting.
Some potential exists for report recipients to perform traffic
analysis, making it possible to obtain metadata about the Receiver's
traffic. In addition to verifying compliance with policies,
Receivers need to consider that before sending reports to a third
party.
7.2. Data Contained Within Reports
Aggregate feedback reports contain aggregated data relating to
messages purportedly originating from the Domain Owner. The data
does not contain any identifying characteristics about individual
users. No personal information such as individual mail addresses, IP
addresses of individuals, or the content of any messages is included
in reports.
Mail Receivers should have no concerns in sending reports, as they do
not contain personal information. In all cases, the data within the
reports relates to the domain-level authentication information
provided by mail servers sending messages on behalf of the Domain
Owner. This information is necessary to assist Domain Owners in
implementing and maintaining DMARC.
Domain Owners should have no concerns in receiving reports, as they
do not contain personal information. The reports only contain
aggregated data related to the domain-level authentication details of
messages claiming to originate from their domain. This information
is essential for the proper implementation and operation of DMARC.
Domain Owners who are unable to receive reports for organizational
reasons can choose to exclusively direct the reports to an external
processor.
7.3. Feedback Leakage
Providing feedback reporting to Public Suffix Operators (PSOs) for a
Public Suffix Domain (PSD) [RFC9989] can, in some cases, cause
information to leak out of an organization to the PSO. This leakage
could potentially be utilized as part of a program of pervasive
surveillance (see [RFC7624]). There are roughly three cases to
consider:
Single Organization PSDs (e.g., ".mil"):
Aggregate reports based on PSD DMARC have the potential to contain
information about mail related to entities managed by the
organization. Since both the PSO and the Organizational Domain
Owners are common, there is no additional privacy risk for either
normal or non-existent domain reporting due to PSD DMARC.
Multi-organization PSDs requiring DMARC usage (e.g., ".bank"):
Aggregate reports based on PSD DMARC will only be generated for
domains that do not publish a DMARC Policy Record at the
Organizational Domain or host level. For domains that do publish
the required DMARC Policy Records, the feedback reporting
addresses of the Organizational Domain (or hosts) will be used.
The only direct risk of feedback leakage for these PSDs are for
Organizational Domains that are out of compliance with PSD policy.
Data on non-existent domains would be sent to the PSO.
Multi-organization PSDs not requiring DMARC usage (e.g., ".com"):
Privacy risks for Organizational Domains that have not deployed
DMARC within such PSDs can be significant. For non-DMARC
Organizational Domains, all DMARC feedback will be directed to the
PSO if that PSO itself has a DMARC Policy Record that specifies a
"rua" tag. Any non-DMARC Organizational Domain would have its
feedback reports redirected to the PSO. The content of such
reports, particularly for existing domains, is privacy sensitive.
PSOs will receive feedback on non-existent domains, which may be
similar to existing Organizational Domains. Feedback related to such
domains have a small risk of carrying information related to an
actual Organizational Domain. To minimize this potential concern,
PSD DMARC feedback MUST be limited to aggregate reports. Failure
reports carry more detailed information and present a greater risk.
8. Security Considerations
While reviewing this document and its security considerations, it is
ideal that the reader also review the Privacy Considerations section
above, as well as the privacy considerations and security
considerations in Sections 10 and 11 of [RFC9989].
8.1. Report Content as an Attack
Aggregate reports are supposed to be processed automatically. An
attacker might attempt to compromise the integrity or availability of
the report processor by sending malformed reports. In particular,
the archive decompressor and XML parser are at risk to resource
exhaustion attacks (zip bomb or XML bomb).
8.2. False Information
The data contained within aggregate reports may be forged. An
attacker might attempt to interfere with or influence policy
decisions by submitting false reports in large volume. The attacker
could also be attempting to influence platform architecture
decisions. A volume-based attack may also impact the ability for a
Report Receiver to accept reports from other entities.
8.3. Disclosure of Filtering Information
While not specified in this document itself, the availability of
extensions could enable the report generator to disclose information
about message placement (Inbox/Spam/etc.). This is very much
discouraged as it could relay this information to a malicious party,
allowing them to understand more about filtering methodologies at a
receiving entity.
9. Operational Considerations
9.1. Report Generation
* The error fields should be reasonably terse and usable.
* If reports cannot be generated, the system should ideally log a
useful error that helps troubleshoot the issue.
9.2. Report Evaluation
As noted above, if a report does not match the specified format, the
evaluator will likely find the contents to be in question.
Alternately, the evaluator may decide to sideline those reports so
they can more easily collaborate with the report generator to
identify where the issues are happening.
It's quite likely that the data contained within the reports will be
extracted and stored in a system that allows for easy reporting,
dashboarding, and/or monitoring. The XML reports themselves are not
human readable in bulk, and a system such as the above may aid the
Domain Owner with identifying issues.
9.3. Report Storage
Once a report is accepted and properly parsed by the report
evaluator, it is entirely up to that evaluator as to what they wish
to do with the XML documents. For some domains, the quantity of
reports could be fairly high, or the size of the reports themselves
could be large. Once the data from the reports has been extracted
and indexed, the reports seemingly have little value in most
situations.