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

"Kurt Andersen (b)" <kboth@drkurt.com> Thu, 18 February 2021 16:53 UTC

Return-Path: <kurta@drkurt.com>
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F19143A144B for <dmarc@ietfa.amsl.com>; Thu, 18 Feb 2021 08:53:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=drkurt.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id klgyfGgng6WF for <dmarc@ietfa.amsl.com>; Thu, 18 Feb 2021 08:53:22 -0800 (PST)
Received: from mail-io1-xd2d.google.com (mail-io1-xd2d.google.com [IPv6:2607:f8b0:4864:20::d2d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3090F3A144A for <dmarc@ietf.org>; Thu, 18 Feb 2021 08:53:22 -0800 (PST)
Received: by mail-io1-xd2d.google.com with SMTP id y202so2709551iof.1 for <dmarc@ietf.org>; Thu, 18 Feb 2021 08:53:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=drkurt.com; s=20130612; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=pGKg70k+mjY0sco96COcIMoje0G065EcTjtCGbEPOtk=; b=G7hS0ooltYjW03fDqYSe+ozyvaTlrW6jax5sqd4fVt2OAtlwh8guaOAN/f8qokBtfF rxWr/KL/z871CQYnNCeD+WdZW2zaCKj8wyJSamM7qsE05WFO6XjZ3ihQJawi5MlqCxrC uLktl1c9s2dZb2uNhe+Bu4MApR9MFJbUiegO0=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=pGKg70k+mjY0sco96COcIMoje0G065EcTjtCGbEPOtk=; b=F/SFENg53MTEE3BRiDa9/FiZreqv8zDtkxlQNkTm7ACX3NeVya+p840RRtqoU2f0pg JKdDYcXY3Z/E8F06cvYDqIrGThRyZVG4iY0qZGxicrRNDiH2dpu91JAOWqViTxGkNKBY W+tjPDoyaSl/wIv7KYDp1LvT+mVjGJsGNSxZnepRfpUYurOTtjO/wcLckelRbs++Hso7 eF1yqdjtwl3RzpOijrc5P/3Fqzr1rWu30BRmCvhJOUC/6oyRczmE8uDl5p1RyUYCnqOL UMX0JPVtEUQg1NhZ8cqQZgThMXNQRvigbdLYJhmfFwP8NRYQGRFDKxWhY03dcOEnQiU2 ryow==
X-Gm-Message-State: AOAM531jEvpraFzYYeqfamQG2Hu8TxURFeFG5+0vxg/Df8QhgNbn3fks j6vdDcZH3KZiROhYHOrzgMlIfiJYdfGcqTJe2f3Z9cu3Y9U=
X-Google-Smtp-Source: ABdhPJxW1YYdh+wWaJftWjEKagPfwLIJtlvLhGvNKx99KWNJBtq+Bq4IuiJhvS17GcmvXA5wMBQiZQNVcAt1rIOSS4s=
X-Received: by 2002:a6b:f406:: with SMTP id i6mr6327iog.121.1613667201124; Thu, 18 Feb 2021 08:53:21 -0800 (PST)
MIME-Version: 1.0
References: <VI1PR01MB70538541D7ADE18A555B05D6C7869@VI1PR01MB7053.eurprd01.prod.exchangelabs.com> <20210218024606.4727B6E23874@ary.qy> <VI1PR01MB70530199B815F3216D64E9A2C7859@VI1PR01MB7053.eurprd01.prod.exchangelabs.com>
In-Reply-To: <VI1PR01MB70530199B815F3216D64E9A2C7859@VI1PR01MB7053.eurprd01.prod.exchangelabs.com>
From: "Kurt Andersen (b)" <kboth@drkurt.com>
Date: Thu, 18 Feb 2021 08:52:55 -0800
Message-ID: <CABuGu1pC_rh2vDUuNsHF0dLgKGiR3nve8YE1P9trPM-wUi+EfA@mail.gmail.com>
To: Ken O'Driscoll <ken=40wemonitoremail.com@dmarc.ietf.org>
Cc: "dmarc@ietf.org" <dmarc@ietf.org>, John Levine <johnl@taugh.com>
Content-Type: multipart/alternative; boundary="0000000000004f222105bb9f2c3b"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/cmS1Wlyr8OzF2noG8UBee-8Wvqk>
Subject: Re: [dmarc-ietf] Ticket #64 - Contained Data PII Concerns
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" <dmarc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dmarc>, <mailto:dmarc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dmarc/>
List-Post: <mailto:dmarc@ietf.org>
List-Help: <mailto:dmarc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dmarc>, <mailto:dmarc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 18 Feb 2021 16:53:24 -0000

On Thu, Feb 18, 2021 at 7:09 AM Ken O'Driscoll <ken=
40wemonitoremail.com@dmarc.ietf.org> 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