7. Privacy Considerations

Diese Seite fasst den entsprechenden Abschnitt von RFC 9991 zusammen und bewahrt ARF-Felder, ABNF, MIME-Beispiel sowie Datenschutz- und Sicherheitsdetails.

The privacy considerations from Section 7 are preserved below.

7.  Privacy Considerations

   The generation and transmission of DMARC failure reports raise
   significant privacy concerns that must be carefully considered before
   deployment.

   Given these factors, many large-scale providers limit or entirely
   disable the generation of failure reports, preferring to rely on
   aggregate reports, which provide statistical visibility without
   exposing sensitive content.  Operators that choose to enable failure
   reporting are strongly encouraged to:

   *  Limit the scope and duration of use to targeted diagnostic
      activities;

   *  Ensure that reporting URIs are carefully controlled and validated;

   *  Apply minimization techniques, such as redaction of message bodies
      and header fields, to reduce sensitive data exposure;

   *  Always transmit reports over secure channels.

   In summary, while DMARC failure reports can offer diagnostic value,
   the associated privacy concerns have led many operators to restrict
   their use.  Aggregate reports remain the recommended mechanism for
   gaining visibility into authentication results while preserving the
   confidentiality of end-user communications.

   Particular privacy-specific issues are explored below.

7.1.  Data Exposure Considerations

   Failure reports may include PII and non-public information (NPI) from
   messages that fail to authenticate, since these reports may contain
   message content as well as trace header fields.  These reports may
   expose sender and recipient identifiers (e.g., RFC5322.From
   addresses), and although the [RFC5965] format used for failed-message
   reporting supports redaction [RFC6590], failed-message reporting is
   capable of exposing the entire message to the Report Consumer.  They
   may also expose PII, sensitive business data, or other confidential
   communications to unintended recipients.  Such exposure can create
   regulatory, legal, and operational risks for both senders and
   receivers.  Examples include product launches, termination notices
   for employees, or calendar data.  Even innocuous-seeming failures
   (such as malformed or "broken" calendar invitations) can result in
   the leakage of private communications.

   Domain Owners requesting reports will receive information about mail
   using their domain, but which they did not actually cause to be sent.
   This might provide valuable insight into content used in abusive
   messages, but it might also expose PII or NPI from legitimate
   messages mistakenly or accidentally failing authentication.

   Information about the final destination of mail, where it might
   otherwise be obscured by intermediate systems, may be exposed through
   a failure report.  A commonly cited example is exposure of members of
   mailing lists when one list member sends messages to the list, and
   failure reports are generated when that message is delivered to other
   list members.  Those failure reports would be sent to the Domain
   Owner of the list member posting the message or their delegated
   Report Consumer(s).

   Similarly, when message forwarding arrangements exist, Domain Owners
   requesting reports may receive information about mail forwarded to
   domains that were not originally part of their messages' recipient
   list.  This means that destinations previously unknown to the Domain
   Owner may now become visible.

7.2.  Report Recipients

   A DMARC Policy Record can specify that reports should be sent to a
   Report Consumer operating on behalf of the Domain Owner.  This might
   be done when the Domain Owner sends reports to an entity to monitor
   mail streams for deliverability, performance issues, or abuse.
   Receipt of such data by third parties may or may not be permitted by
   the Mail Receiver's privacy policy, terms of use, etc.  Domain Owners
   and Mail Receivers should both review and understand whether their
   own internal policies constrain the use and transmission of DMARC
   reporting.

   Some potential exists for Report Consumers to perform traffic
   analysis, making it possible to obtain metadata about the Mail
   Receiver's traffic.  In addition to verifying compliance with
   policies, Mail Receivers need to consider that before sending reports
   to a third party.  On the other hand, a Domain Owner may publish a
   destination address that appears to be an Internal Report Consumer
   but is actually a forwarding address; in this case, the final
   destination of a report is not guaranteed.

7.3.  Additional Damage

   The risks associated with failure reports are compounded by volume
   and content distribution concerns.  Partially or unredacted reports
   may propagate large amounts of spam, phishing, or malware content,
   all of which may require special handling by Report Consumers or
   other recipients to avoid incidents.  This underscores the need to
   avoid misconfiguration of the destinations in the "ruf" reporting
   URIs and the suggestions for redaction in this document, for example,
   using the method described in [RFC6590].  All of these concerns are
   heightened for high-volume domains.  To mitigate such concerns, the
   following steps should be considered:

   By report generators:

   *  Help prevent accidental access to potentially malicious URIs by
      substituting hxxp for http;

   *  Remove attachments that could embed malicious payload.

   By report consumers:

   *  Isolate report streams from other mail streams;

   *  Use sandboxes in evaluating failure reports;

   *  Use network segmentation;

   *  Limit access to failure reports to authorized individuals with
      appropriate security training.