Incorporating some feedback: ------------------- ## Data Contained Within Reports (Tkt64)
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 DMARC Identifier. 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 does not contain personal information, such as email addresses or usernames. There are typically three situations where data is reported to the aggregate receivers: messages properly authenticated, messages that fail to authenticate as the domain, or messages utilizing the DMARC Identifier that have no authentication at all. In each of these cases, there exists no identifying information for individuals, and all content within the reports should be related to SMTP servers sending messages posing as that domain. ------------------- -- Alex Brotman Sr. Engineer, Anti-Abuse & Messaging Policy Comcast > -----Original Message----- > From: dmarc <dmarc-boun...@ietf.org> On Behalf Of Alessandro Vesely > Sent: Monday, February 15, 2021 8:31 AM > To: dmarc@ietf.org > Subject: Re: [dmarc-ietf] Ticket #64 - Contained Data PII Concerns > > On Fri 12/Feb/2021 21:30:38 +0100 Brotman, Alex wrote: > > Hello folks, > > > > In ticket #64 > (https://urldefense.com/v3/__https://trac.ietf.org/trac/dmarc/ticket/64__;! > !CQl3mcHX2A!W97hZ0- > iwRDi8wBssmRFF6OycVE12vM3xhGd9BmLhEzi6Vycp3bgzwji21xLQQgnnMRa > BuxGQg$ ), 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. > > > I'd replace all those 5322.From Domain with main DMARC identifier. > > > > The data should not contain any identifying characteristics about > > individual senders or receivers. > > > The aggregated data refers to names and IP addresses of SMTP servers. It > cannot be used to identify individual users. > > > > 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. > > > I'd substitute /should not/does not/. Even if a server has a unique user, the > domain name and the IP address are those of a public entity, not those of a > private citizen. > > The term Personally Identifiable Information (PII) is US-national. I think > just personal information is of broader use. Personal data is also a valid > alternative. > > > jm2c > Ale > -- > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > dmarc mailing list > dmarc@ietf.org > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/dmarc > __;!!CQl3mcHX2A!W97hZ0- > iwRDi8wBssmRFF6OycVE12vM3xhGd9BmLhEzi6Vycp3bgzwji21xLQQgnnMTF6 > fzPKA$ _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc