On Monday, August 29, 2022 1:48:57 PM EDT Alessandro Vesely wrote: > 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?
RFC 9091 Privacy Considerations spend the bulk of its text discussing Aggregate reporting. Failure reporting is a simple "don't". I'm not proposing inventing anything new beyond what's needed to deal with the document split. I hadn't anticipated anything that would cause records to become invalid. Scott K _______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
