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

Alessandro Vesely <> Thu, 18 February 2021 17:09 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D03ED3A1471 for <>; Thu, 18 Feb 2021 09:09:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.399
X-Spam-Status: No, score=-4.399 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, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1152-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Y72EI9jpM0pt for <>; Thu, 18 Feb 2021 09:09:10 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3577B3A1460 for <>; Thu, 18 Feb 2021 09:09:09 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=delta; t=1613668146; bh=Vfyt9bu3WxrloMDTbbI71+YnGl2AVOjYDMl6zgPQ/RE=; l=2268; h=To:Cc:References:From:Date:In-Reply-To; b=AEqA9zChWZ+hsqY3R5sTh5w6fofueyWvg/4m1E81HZx9AFos1+uZNCyLR+Zkg+Fy1 GgnpaFbiug7dARqi8K29+0q3S0ts5MAC+7bbb+wOjShwaA2gpvD/aDWoYDN3mS+D/d QdrGkdjAx0RajGQOitgtIlFC92Q0KYD1D2J5i2uIcqvcl8yT1AYaQedPf/Qj8
Authentication-Results:; auth=pass (details omitted)
Original-From: Alessandro Vesely <>
Original-Cc: "" <>, John Levine <>
Received: from [] (pcale.tana []) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLS1.3, 128bits, ECDHE_RSA_AES_128_GCM_SHA256) by with ESMTPSA id 00000000005DC042.00000000602E9F32.00003CD7; Thu, 18 Feb 2021 18:09:06 +0100
To: "Kurt Andersen (b)" <>, Ken O'Driscoll <>
Cc: "" <>, John Levine <>
References: <> <20210218024606.4727B6E23874@ary.qy> <> <>
From: Alessandro Vesely <>
Message-ID: <>
Date: Thu, 18 Feb 2021 18:09:06 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <>
Subject: Re: [dmarc-ietf] 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: Thu, 18 Feb 2021 17:09:12 -0000

On Thu 18/Feb/2021 17:52:55 +0100 Kurt Andersen (b) wrote:
> On Thu, Feb 18, 2021 at 7:09 AM Ken O'Driscoll <ken=
>> 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.

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

Also s/authentication/domain-level authentication/.