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

Seth Blank <> Fri, 12 February 2021 21:17 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 380B63A0E9E for <>; Fri, 12 Feb 2021 13:17:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.088
X-Spam-Status: No, score=-2.088 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 763OoQKoQTJp for <>; Fri, 12 Feb 2021 13:17:04 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::e30]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 9797A3A0E88 for <>; Fri, 12 Feb 2021 13:17:04 -0800 (PST)
Received: by with SMTP id x201so349495vsc.0 for <>; Fri, 12 Feb 2021 13:17:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google2048; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ZaqGNM3DGU6oJ+P7CBP/HNkR9K9LUDEHsXaGBP/4X4Y=; b=KuGf7OLzg6UWiKbKbTryjfElXvTmF/mvINYQWcngxWwku7MmXEzXSNZXFKAnhL0ekF PO04pBLF4uH+g/x6fhXCIa/MYvh+sTBm9+cWYvTcBYEGKIexbIlxptZXC7eWxSjqSyb1 B4xD7/BEXTLGcF8cMHAgLiuooAHtGjA14J90I2qR8Melw2VXRipe3C2LXMj84+zjeeqZ vaUVSNsK2flqT9G97Qlc8B3Opp0wC4yjFZ3DgjGAoxs80wYZmGmxAwPnpeSL1vXR5ac1 hA+vej3POsqvKQoMGzPcFLIeAt92cM0OnIRlA4DjK8YTfU9ZvoWl9omypXhbHLP0+M4J ToKg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ZaqGNM3DGU6oJ+P7CBP/HNkR9K9LUDEHsXaGBP/4X4Y=; b=hn5d0davfW2AkDrlp7icm7+6WMN0D5n/eysYXCakUnD0inysJJ82AErct1irS+LTob jSVL/3HIOo6dFzH/ex/p7F8GWAXhB4ivw0tVVRrVYKPo1/r5gFeK2ZBpe66Xn4YWwhPa YIgbcrsiwStjvWjRPtZAG4acm1sWcN99mJt1Uf2TeMq/vew5+QjLwjqDWd1tOpnZkuwp KNXupx/48f/JN6iUOdlDxcU9ya7FH5mVURUP8wbRYMX3h8XPNSo6b4TLPnVNUOoqJd+6 o4D/lf4pxpfxZxDEk6FvIdYLUGnN/uidOaFKWPugj1YcxWVQ0kdDVcJaarMfH8foX12D iwzA==
X-Gm-Message-State: AOAM530Rl4RsTAX3h87pKr++zEjHeHrpCS5aDWPlfb3+SudhBC//P//v JED108gASgYHxzU1rGsmO2CW2ugTkt5zXZLRpFTvQlJKVJ8=
X-Google-Smtp-Source: ABdhPJwtb0/ZYaU6VTAc64N1JqhUmFUT/B10ZvVtGtH7xSPBSNoqrHBTQMXcnC6pae+csILlrwAHKTmt/ew1DdDKwMg=
X-Received: by 2002:a67:ed84:: with SMTP id d4mr3278489vsp.52.1613164622055; Fri, 12 Feb 2021 13:17:02 -0800 (PST)
MIME-Version: 1.0
References: <> <20210212204624.BD53A6DDB3F5@ary.qy> <>
In-Reply-To: <>
From: Seth Blank <>
Date: Fri, 12 Feb 2021 13:16:51 -0800
Message-ID: <>
To: "Brotman, Alex" <>
Cc: John Levine <>, "" <>
Content-Type: multipart/alternative; boundary="000000000000431b2605bb2a28ae"
Archived-At: <>
Subject: Re: [dmarc-ietf] [EXTERNAL] Re: Ticket #64 - Contained Data PII Concerns
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 12 Feb 2021 21:17:07 -0000

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.


On Fri, Feb 12, 2021 at 12:50 PM Brotman, Alex <Alex_Brotman=> 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 <>
> > Sent: Friday, February 12, 2021 3:46 PM
> > To:
> > Cc: Brotman, Alex <>
> > Subject: [EXTERNAL] Re: [dmarc-ietf] Ticket #64 - Contained Data PII
> Concerns
> >
> > In article
> > <MN2PR11MB435185A171029EF4282A2BF4F78B9@MN2PR11MB4351.namprd
> >> you write:
> > >Hello folks,
> > >
> > >In 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


*Seth Blank* | VP, Standards and New Technologies
*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.