Subject: [dmarc-ietf] Ticket #64 - Contained Data PII Concerns

From: "Brotman, Alex" <[email-masked]>
Date: Fri, 12 Feb 2021 20:30:38 +0000

Hello folks,

In ticket #64 (https://trac.ietf.org/trac/dmarc/ticket/64), 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.

--
Alex Brotman
Sr. Engineer, Anti-Abuse & Messaging Policy
Comcast

---

From: "John Levine" <[email-masked]>
Date: 12 Feb 2021 15:46:23 -0500

In article <[email-masked]> you write:
>Hello folks,
>
>In ticket #64 (https://trac.ietf.org/trac/dmarc/ticket/64), 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.
>

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.

---

From: "Brotman, Alex" <[email-masked]>
Date: Fri, 12 Feb 2021 20:49:55 +0000

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.

> -----Original Message-----
> From: John Levine <[email-masked]>
> Sent: Friday, February 12, 2021 3:46 PM
> To: [email-masked]
> Cc: Brotman, Alex <[email-masked]>
> Subject: [EXTERNAL] Re: [dmarc-ietf] Ticket #64 - Contained Data PII Concerns
>
> In article
> <[email-masked]
> 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.
> >
> >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.
> >
> 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.
>

---

From: Seth Blank <[email-masked]>
Date: Fri, 12 Feb 2021 13:16:51 -0800

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=
[email-masked]> 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
> _______________________________________________
> dmarc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dmarc
>

-- 

*Seth Blank* | VP, Standards and New Technologies
*e:* [email-masked]
*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.

---

From: "John R Levine" <[email-masked]>
Date: 12 Feb 2021 16:23:31 -0500

> rewriting by an intermediary. ...

All true, but more to the point, the reports include IP addresses and 
domain names of mail servers and DKIM signers, not IP or e-mail addresses 
of individual users.  There's no PII other than in the extreme case that 
the domain has only a single user so all of the mail can be attributed to 
that user.

R's,
John

PS: updated the ticket title to say aggregate reports

PPS: that extreme case lets me tell things like how many NANOG subscribers 
get their mail at gmail.

---

From: Seth Blank <[email-masked]>
Date: Fri, 12 Feb 2021 13:27:03 -0800

Yes, very true. Again as an individual, I think it's worth calling out
explicitly in the draft, simply because it does seem to cause friction with
implementations.

-- 

`

---

From: Alessandro Vesely <[email-masked]>
Date: Mon, 15 Feb 2021 14:30:57 +0100

On Fri 12/Feb/2021 21:30:38 +0100 Brotman, Alex wrote:
> 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

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
--

---

From: "Brotman, Alex" <[email-masked]>
Date: Wed, 17 Feb 2021 18:40:13 +0000

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.
-------------------

> From: dmarc <[email-masked]> On Behalf Of Alessandro Vesely
> Sent: Monday, February 15, 2021 8:31 AM
> To: [email-masked]
> Subject: Re: [dmarc-ietf] Ticket #64 - Contained Data PII Concerns
>
> (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
> 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.
> >
> > pertaining to the 5322.From Domain.
>
>
> > The data should not contain any identifying characteristics about
> > individual senders or receivers.
>
>
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/dmarc
> __;!!CQl3mcHX2A!W97hZ0-
> iwRDi8wBssmRFF6OycVE12vM3xhGd9BmLhEzi6Vycp3bgzwji21xLQQgnnMTF6
> fzPKA$

---

From: Ken O'Driscoll <[email-masked]>
Date: Wed, 17 Feb 2021 21:27:00 +0000

I PM deployments for organisations and the concept of aggregate reports have caused problem more than once. Similar to the PII concerns of providers which originated this ticket, these organisations operate in heavily a regulated industry and have extensive DPO functions. To give a flavour of what those concerns translate to - I have been asked is it possible to implement DMARC without using reports! I have also had con-calls about training a new hire to read and classify the reports! That's just two examples. It's mostly driven by overzealous DPOs but I understand their concerns on some level. When they realise that we can distil the report data and it doesn't need to be on-site, they hand wave away any custodian concerns and the project moves forward.

So, assuming that my DMARC clients aren't unique, I'm wondering if this section could be split into two parts, one for Mail Receivers and one for Domain Owners?

If so, for Domain Owners, I'd propose something like this:

Aggregate feedback reports are essential for the proper implementation and operation of DMARC. Domain Owners can choose to exclusively direct reports to a processor external to their organization. In such cases, the content of the reports are never sent directly to the Domain Owner.

Thoughts?

Ken.

> From: dmarc <[email-masked]> On Behalf Of Brotman, Alex
> Sent: Wednesday 17 February 2021 18:40
> To: Alessandro Vesely <[email-masked]>; [email-masked]
> pertaining to the DMARC Identifier.  The data should not contain any
> 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
> 
> > 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.
> > >
> > > 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 aggregated data refers to names and IP addresses of SMTP servers.
> > It cannot be used to identify individual users.
> >
> >
> > >  An entity
> > > 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
> > --
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >

---

From: Douglas Foster <[email-masked]>
Date: Wed, 17 Feb 2021 21:21:11 -0500

It would help me if you could elaborate on the concerns that you have
encountered.

Which data is sensitive and therefore needing classification?

Which roles creates the objection?   Server owner sending reports,
recipient domain allowing the server owner to send reports from recipient
data, or only report recipient?

When the report recipient domain delegates reception to an authorized
agent, how does the organization making the delegation escape liability for
how the information is handled and used?

On Wed, Feb 17, 2021 at 4:27 PM Ken O'Driscoll <ken=
[email-masked]> wrote:

>
> I PM deployments for organisations and the concept of aggregate reports
> have caused problem more than once. Similar to the PII concerns of
> providers which originated this ticket, these organisations operate in
> heavily a regulated industry and have extensive DPO functions. To give a
> flavour of what those concerns translate to - I have been asked is it
> possible to implement DMARC without using reports! I have also had
> con-calls about training a new hire to read and classify the reports!
> That's just two examples. It's mostly driven by overzealous DPOs but I
> understand their concerns on some level. When they realise that we can
> distil the report data and it doesn't need to be on-site, they hand wave
> away any custodian concerns and the project moves forward.
>
> So, assuming that my DMARC clients aren't unique, I'm wondering if this
> section could be split into two parts, one for Mail Receivers and one for
> Domain Owners?
>
> Aggregate feedback reports are essential for the proper implementation and
> operation of DMARC. Domain Owners can choose to exclusively direct reports
> to a processor external to their organization. In such cases, the content
> of the reports are never sent directly to the Domain Owner.
>
> Thoughts?
>
> Ken.
>

---

From: "John Levine" <[email-masked]>
Date: 17 Feb 2021 21:46:05 -0500

In article <[email-masked]> you write:
>Aggregate feedback reports are essential for the proper implementation and operation of DMARC. Domain Owners can choose to
>exclusively direct reports to a processor external to their organization. In such cases, the content of the reports are never
>sent directly to the Domain Owner.

That is OK but I would also want to point out that the data are
aggregated and contain no individual e-mail addresses of senders or
recipients, nor IP addresses of individuals nor any contents of
messages, so it is unlikely that they contain any PII.

I have to say it seems weird to me that it's OK to send whatever to external places but not to 
your own staff.

R's,
John

---

From: Ken O'Driscoll <[email-masked]>
Date: Thu, 18 Feb 2021 15:09:18 +0000

In hindsight, it looks a bit strange to have the first paragraph say "don't worry about PII" and the next paragraph say "if you're worried about PII, here's how to mitigate".

But it's a genuine concern (misguided or not) and I've been in enough meetings to at least understand where it comes from, even if I don't agree. So I'd propose something like the below, which I think gets across what we all want to say.

=======
Aggregate feedback reports contain anonymized data relating to messages purportedly originating from the Domain Owner. The data does not contain any identifying characteristics about individual senders or receivers. No personal information such as individual email addresses, IP addresses of individuals, or the content of any messages, is included in reports.

Mail Receivers should have no concerns in sending reports as they do not contain personal information. In all cases, the data within the reports relates to the authentication information provided by mail servers sending messages on behalf of the Domain Owner. This information is necessary to assist Domain Owners in implementing and maintaining DMARC.

Domain Owners should have no concerns in receiving reports as they do not contain personal information. The reports only contain aggregated anonymized data related to the authentication details of messages claiming to originate from their domain. This information is essential for the proper implementation and operation of DMARC. Domain Owners who are unable to receive reports for organizational reasons, can choose to exclusively direct the reports to an external processor.
=======

And, I agree - it's a bit weird to be okay with having a policy to not see your own reports. But the "see no evil, hear no evil" risk mitigation strategy is tried and tested. The whole IG/DPO space is really crazy in some places too.

Ken.

> Sent: Thursday 18 February 2021 02:46
> To: [email-masked]
> Cc: Ken O'Driscoll <[email-masked]>
> <[email-masked]
> angelabs.com> you write:
> >Aggregate feedback reports are essential for the proper implementation
> >and operation of DMARC. Domain Owners can choose to exclusively direct
> >reports to a processor external to their organization. In such cases,
> the content of the reports are never sent directly to the Domain Owner.
> 
> I have to say it seems weird to me that it's OK to send whatever to
> external places but not to your own staff.
> 
> R's,
> John

---

From: Ken O'Driscoll <[email-masked]>
Date: Thu, 18 Feb 2021 15:30:58 +0000

The concern is that PII is contained in the aggregate reports.

The machinations of the individual Information Governance functions that draw such conclusions or the decision making processes of individual organisations around those conclusions, is not relevant, and won’t help close this ticket.

Ken.

From: dmarc <[email-masked]> On Behalf Of Douglas Foster
Sent: Thursday 18 February 2021 02:21
To: IETF DMARC WG <[email-masked]>
Subject: Re: [dmarc-ietf] Ticket #64 - Contained Data PII Concerns

It would help me if you could elaborate on the concerns that you have encountered.

Which roles creates the objection?   Server owner sending reports, recipient domain allowing the server owner to send reports from recipient data, or only report recipient?

When the report recipient domain delegates reception to an authorized agent, how does the organization making the delegation escape liability for how the information is handled and used?

On Wed, Feb 17, 2021 at 4:27 PM Ken O'Driscoll <ken=[email-masked]<mailto:[email-masked]>> wrote:

Thoughts?

Ken.

> From: dmarc <[email-masked]<mailto:[email-masked]>> On Behalf Of Brotman, Alex
> To: Alessandro Vesely <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
> > From: dmarc <[email-masked]<mailto:[email-masked]>> On Behalf Of Alessandro Vesely
> > To: [email-masked]<mailto:[email-masked]>
> (https://urldefense.com/v3/__https://trac.ietf.org/trac/dmarc/ticket/64_<https://urldefense.com/v3/__https:/trac.ietf.org/trac/dmarc/ticket/64_>
> _;!
> > !CQl3mcHX2A!W97hZ0-
> > [email-masked]<mailto:[email-masked]>
> > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/dmar<https://urldefense.com/v3/__https:/www.ietf.org/mailman/listinfo/dmar>
> > c
> > __;!!CQl3mcHX2A!W97hZ0-
> [email-masked]<mailto:[email-masked]>

_______________________________________________
dmarc mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/dmarc

---

From: "Kurt Andersen (b)" <[email-masked]>
Date: Thu, 18 Feb 2021 08:52:55 -0800

On Thu, Feb 18, 2021 at 7:09 AM Ken O'Driscoll <ken=
[email-masked]> wrote:

>
> . . . I'd propose something like the below, which I think gets across what
> we all want to say.
>
> =======
> Aggregate feedback reports contain anonymized data relating to messages
> purportedly originating from the Domain Owner. The data does not contain
> any identifying characteristics about individual senders or receivers. No
> personal information such as individual email addresses, IP addresses of
> individuals, or the content of any messages, is included in reports.
>
> Mail Receivers should have no concerns in sending reports as they do not
> contain personal information. In all cases, the data within the reports
> relates to the authentication information provided by mail servers sending
> messages on behalf of the Domain Owner. This information is necessary to
> assist Domain Owners in implementing and maintaining DMARC.
>
> Domain Owners should have no concerns in receiving reports as they do not
> contain personal information. The reports only contain aggregated
> anonymized data related to the authentication details of messages claiming
> to originate from their domain. This information is essential for the
> proper implementation and operation of DMARC. Domain Owners who are unable
> to receive reports for organizational reasons, can choose to exclusively
> direct the reports to an external processor.
> =======
>

With a s/anonymized/aggregated/g change, this seems like reasonable
language. In technical terms, there is no anonymization involved. The only
other issue might be some ambiguity in the intepretation of the term
"individual senders or receivers" because the IP addresses of the MTAs
involved in the email interchange are definitely in the report. As someone
has pointed out earlier in the thread, a compromised home computer which is
able to send out on port 25 would indeed be exposed in such a scenario,
though it is a rare case.

--Kurt

---

From: Alessandro Vesely <[email-masked]>
Date: Thu, 18 Feb 2021 18:09:06 +0100

> though it is a rare case.

I'd s/individual senders or receivers/individual users/.

Also s/authentication/domain-level authentication/.

Best
Ale
--

---

From: "Brotman, Alex" <[email-masked]>
Date: Thu, 18 Feb 2021 20:39:19 +0000

Aggregated comments:

--------------------------
Aggregate feedback reports contain aggregated data relating to messages purportedly originating from the Domain Owner. The data does not contain any identifying characteristics about individual users. No personal information such as individual email addresses, IP addresses of individuals, or the content of any messages, is included in reports.

Mail Receivers should have no concerns in sending reports as they do not contain personal information. In all cases, the data within the reports relates to the domain-level authentication information provided by mail servers sending messages on behalf of the Domain Owner. This information is necessary to assist Domain Owners in implementing and maintaining DMARC.

Domain Owners should have no concerns in receiving reports as they do not contain personal information. The reports only contain aggregated data related to the domain-level authentication details of messages claiming to originate from their domain. This information is essential for the proper implementation and operation of DMARC. Domain Owners who are unable to receive reports for organizational reasons, can choose to exclusively direct the reports to an external processor.
--------------------------

Agreeable?

> Sent: Thursday, February 18, 2021 12:09 PM
> To: Kurt Andersen (b) <[email-masked]>; Ken O'Driscoll
> <ken=[email-masked]>
> Cc: [email-masked]; John Levine <[email-masked]>
> >> . . . I'd propose something like the below, which I think gets across
> >> what we all want to say.
> >>
> >> =======
> >> Aggregate feedback reports contain anonymized data relating to
> >> messages purportedly originating from the Domain Owner. The data does
> >> not contain any identifying characteristics about individual senders
> >> or receivers. No personal information such as individual email
> >> addresses, IP addresses of individuals, or the content of any messages, is
> included in reports.
> >>
> >> Mail Receivers should have no concerns in sending reports as they do
> >> not contain personal information. In all cases, the data within the
> >> reports relates to the authentication information provided by mail
> >> servers sending messages on behalf of the Domain Owner. This
> >> information is necessary to assist Domain Owners in implementing and
> maintaining DMARC.
> >>
> >> Domain Owners should have no concerns in receiving reports as they do
> >> not contain personal information. The reports only contain aggregated
> >> anonymized data related to the authentication details of messages
> >> claiming to originate from their domain. This information is
> >> essential for the proper implementation and operation of DMARC.
> >> Domain Owners who are unable to receive reports for organizational
> >> reasons, can choose to exclusively direct the reports to an external
> processor.
> >> =======
> >>
> >
> > language. In technical terms, there is no anonymization involved. The
> > only other issue might be some ambiguity in the intepretation of the
> > term "individual senders or receivers" because the IP addresses of the
> > MTAs involved in the email interchange are definitely in the report.
> > As someone has pointed out earlier in the thread, a compromised home
> > computer which is able to send out on port 25 would indeed be exposed
> > in such a scenario, though it is a rare case.
>
>
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/dmarc__;!
> !CQl3mcHX2A!QnQcMsS_KTWtqiiZuaapRUWc3xT1P55tS453rXWzE_lJElYm2DKE3
> yW2lwFWuJZIJs-sye0H4w$

---

From: Dotzero <[email-masked]>
Date: Thu, 18 Feb 2021 16:06:53 -0500

I'm comfortable with the language.

Michael Hammer

On Thu, Feb 18, 2021 at 3:40 PM Brotman, Alex <Alex_Brotman=
[email-masked]> wrote:

> Aggregate feedback reports contain aggregated data relating to messages
> any identifying characteristics about individual users. No personal
> information such as individual email addresses, IP addresses of
> relates to the domain-level authentication information provided by mail
> servers sending messages on behalf of the Domain Owner. This information is
> necessary to assist Domain Owners in implementing and maintaining DMARC.
>
> contain personal information. The reports only contain aggregated data
> related to the domain-level authentication details of messages claiming to
> originate from their domain. This information is essential for the proper
> implementation and operation of DMARC. Domain Owners who are unable to
> receive reports for organizational reasons, can choose to exclusively