On Tue 30/Aug/2022 23:34:18 +0200 Scott Kitterman wrote:
On Monday, August 29, 2022 12:27:11 PM EDT Scott Kitterman wrote:
RFC 9091 Privacy Considerations (which are currently incorporated by
reference in DMARCbis) say that for PSDs, feedback MUST be limited to
Aggregate Reports.
I think it would be appropriate that DMARCbis have a short Privacy
Considerations section which points out that putting an rua or ruf tag in
your DMARC record may have privacy implications for organizations with
pointers to the reporting drafts for details. I would include something
like if psd=y, MUST NOT also have an ruf= value in DMARCbis.
I oppose that point, as explained below.
I've prepared an update in git (that I will shortly submit as a PR). The
bulk of it is to add a new Privacy Considerations section. That's provided
below. > [...]
## Failure Report Considerations {#failure-report-considerations}
Failure reports do provide insight into email sending patterns, including
specific users. If requesting failure reports, data management controls
are needed to support appropriate management of this information. The
additional detail available through failure reports (relative to aggregate
reports) can drive a need for additional controls. As an example, a
company may be legally restricted from receiving data related to a specific
subsidiary. Before requesting failure reports, any such data spillage risks
have to be addressed through data management controls or publishing DMARC
records for relevant sub-domains to prevent reporting on data related to
their emails.
Out of band agreements between failure report senders and receivers may be
required to address privacy concerns.
DMARC records for multi-organizational PSDs MUST NOT include the ruf= tag.
Dmarcbis allows PSDs to send messages. Indeed the tree walk sections provide
for cases where the first domain searched has psd=y. PSDs should be able to
get failure reports for the messages they send. Publishing a ruf= tag is key
to having a chance to get them.
The privacy consideration should prevent report generators from /sending/
failure reports for messages that were sent from a child domain of a PSD. That
is, an authentication failure in a message where the org domain is determined
to be PSD+1 and the policy record is the PSD (because the org domain publishes
no DMARC record) MUST NOT be reported.
Best
Ale
--
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
