On Mon 29/Aug/2022 18:27:11 +0200 Scott Kitterman wrote:
On Monday, August 29, 2022 11:09:50 AM EDT Scott Kitterman wrote:
Also, I am reminded that since this document will obsolete RFC 9091 if
approved, we need to incorporate the Privacy Considerations from that
document instead of referencing them. I'll prepare a recommend change for
that.
I looked into this a bit and it turns out to be more complicated than I
expected.
Currently DMARCbis has no Privacy Considerations section at all. Generally, I
think this is correct since the DMARC relevant privacy issues are tied to
reporting, which is in separate drafts. I do think though that since we are
covering all aspects of DMARC record publishing in DMARCbis, there are a few
specifics that should go in the main draft with pointers to the reporting
drafts for relevant details.
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 have no opinion on the worthiness of a Privacy Considerations section.
However, I'd mandate that a report generator MUST NOT send failure reports
related to subdomains of a PSD (which is approximately expressed in the
failure reporting draft.)
Prohibition to publish a ruf= sounds strange. Would the record become
invalid in that case? And then there's the case of PSDs sending mail,
which may be entitled to receive failure reports as well.
The bulk of the RFC 9091 Privacy Considerations text would then go in I-
D.ietf-dmarc-aggregate-reporting. All that would be needed in I-D.ietf-dmarc-
aggregate-reporting Privacy Considerations is a relatively simple admonition
to not send failure reports for PSDs.
Aggregate reporting seems to be extraneous to those considerations, no?
Best
Ale
--
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
