As an individual, part of the reason for this ticket is that some receivers do not send aggregate reports, as they're unclear on whose data is being provided to whom (which then spirals into issues of legalities). While the IETF cannot weigh in on legalities, it can make clear the intention of whose data is being transmitted in the report. I believe clarifying this will enable more reports to flow. My thoughts, quickly, with less precision than I'd like, but as a starting point:
For aggregate reports, the data is intended for the domain owner to understand what is being sent in its name, as seen by the receiver. The intention is that this data is aggregated on behalf of the domain owner by the receiver, and sent if the domain owner publishes a reporting record. In the data itself, there are summaries of IP addresses and authentication statuses of mail that fall into three categories: 1) mail that is authenticated by the domain, 2) mail that fails to authenticate as the domain, and 3) mail that is wholly unauthenticated. From a domain owner perspective, this means they get reports of mail that is 1) authorized by them, 2) not authorized by them, or 3) broken by forwarding or other rewriting by an intermediary. In all cases, this is valuable information for a domain owner to have, and any PII (IP addresses specifically) either belong to the domain owner getting the report, are threat attempting to act as the domain owner, or are intermediaries being used by the domain owner. In all cases, there is nothing here that leaks or exposes someone else's PII to a domain owner, just things explicitly that are theirs or attempting to be seen as them. Seth On Fri, Feb 12, 2021 at 12:50 PM Brotman, Alex <Alex_Brotman= 40comcast....@dmarc.ietf.org> wrote: > Apologies, this is for aggregate reports. I'm would imagine the Failure > reports draft would have its own section as the questions there may be > different. > > -- > Alex Brotman > Sr. Engineer, Anti-Abuse & Messaging Policy > Comcast > > > -----Original Message----- > > From: John Levine <jo...@taugh.com> > > Sent: Friday, February 12, 2021 3:46 PM > > To: dmarc@ietf.org > > Cc: Brotman, Alex <alex_brot...@comcast.com> > > Subject: [EXTERNAL] Re: [dmarc-ietf] Ticket #64 - Contained Data PII > Concerns > > > > In article > > <MN2PR11MB435185A171029EF4282A2BF4F78B9@MN2PR11MB4351.namprd > > 11.prod.outlook.com> you write: > > >Hello folks, > > > > > >In ticket #64 > > >(https://urldefense.com/v3/__https://trac.ietf.org/trac/dmarc/ticket/64 > > >__;!!CQl3mcHX2A!TwDVjWOh08AOGCxPZ0IKR8IxgdUb6u3LDW1Po0KbrzIgXW > > wlVm53NUB > > >Q6gqZ8IbIjUjG$ ), it was suggested that a Privacy Considerations > section may > > alleviate some concerns about the ownership of the data. I created an > initial > > attempt, and thought to get some feedback. I didn't think we should go > too far > > in depth, or raise corner cases. Felt like doing so could lead down a > rabbit hole > > of trying to cover all cases. This would go within a "Privacy > Considerations" > > section. > > > > > >* Data Contained Within Reports (#64) > > > > > >Within the reports is contained an aggregated body of anonymized data > > >pertaining to the sending domain. The data is meant to aid the report > > >processors and domain holders in verifying sources of messages > > >pertaining to the 5322.From Domain. The data should not contain any > > >identifying characteristics about individual senders or receivers. An > > >entity sending reports should not be concerned with the data contained > > >as it should not contain PII (NIST reference for PII definition), such > > >as email addresses or usernames. > > > > > >Does this seem a reasonable start? Thanks for your time. > > > > It's not clear which kind of report this is talking about. > > > > If it's aggregate reports, they contain IP addresses of mail servers and > domain > > names of SPF and DKIM identifiers, but nothing about the e-mail address > or IP of > > the original senders. > > > > If it's failure reports, they contain as much or as little as the > reporter includes, > > possibly an entire message sent by someome who may or may not be > connected > > to the domain that receives the report. > > > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://www.ietf.org/mailman/listinfo/dmarc > -- *Seth Blank* | VP, Standards and New Technologies *e:* s...@valimail.com *p:* 415.273.8818 ` This email and all data transmitted with it contains confidential and/or proprietary information intended solely for the use of individual(s) authorized to receive it. If you are not an intended and authorized recipient you are hereby notified of any use, disclosure, copying or distribution of the information included in this transmission is prohibited and may be unlawful. Please immediately notify the sender by replying to this email and then delete it from your system.
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
