Re: [dmarc-ietf] reporting documents, Ticket #55 - Clarify legal and privacy implications of failure reports

ned+dmarc@mrochek.com Mon, 28 December 2020 21:00 UTC

Return-Path: <ned+dmarc@mrochek.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 EA4643A0DD1 for <dmarc@ietfa.amsl.com>; Mon, 28 Dec 2020 13:00:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level:
X-Spam-Status: No, score=-2.1 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, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mrochek.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 RQWG0gkuL9uo for <dmarc@ietfa.amsl.com>; Mon, 28 Dec 2020 13:00:37 -0800 (PST)
Received: from mauve.mrochek.com (mauve.mrochek.com [98.153.82.211]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93DF13A0DCE for <dmarc@ietf.org>; Mon, 28 Dec 2020 13:00:37 -0800 (PST)
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01RTPKAI8Y40008CBM@mauve.mrochek.com> for dmarc@ietf.org; Mon, 28 Dec 2020 12:55:31 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mrochek.com; s=201712; t=1609188931; bh=tWhjQrSHhHEsoE7HqH6J0QLP6FP7t2GO0Ro6WNgjNZc=; h=From:Cc:Date:Subject:In-reply-to:References:To:From; b=A42D6bszOEnuWuJov2Wj1piVkBj5xYIu4/NWkLmzgduB6AbX5yInYLpjOb+4OOnvn kxxqrpIUXdpmZTWBygvbGb80cE1295yvFJb92hN6JZQM9lleEL5RCuHExHklRWcH/e J+aZ6P2xk7zYcuGLbiUUyPrnMdqq51vNtnJvA9Js=
MIME-version: 1.0
Content-transfer-encoding: 7bit
Content-type: TEXT/PLAIN; CHARSET="us-ascii"; format="flowed"
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01RTJOWYX49S004QVR@mauve.mrochek.com> (original mail from NED@mauve.mrochek.com) for dmarc@ietf.org; Mon, 28 Dec 2020 12:55:23 -0800 (PST)
From: ned+dmarc@mrochek.com
Cc: Ned Freed <ned.freed@mrochek.com>, IETF DMARC WG <dmarc@ietf.org>
Message-id: <01RTPKA2X6FS004QVR@mauve.mrochek.com>
Date: Mon, 28 Dec 2020 12:41:57 -0800
In-reply-to: "Your message dated Mon, 28 Dec 2020 12:06:18 -0500" <6a4a11ea-fae2-81f5-ce5f-fbd4bc1d41e2@taugh.com>
References: <20201218023900.E73B82ACBB2B@ary.qy> <3034face-b6fc-0ce2-fa1b-f59210bd6f5b@tana.it> <46339b38-3b24-bcb7-5e73-8a97038ed69@taugh.com> <3997c81d-3b30-0823-a752-fb1d60a44593@tana.it> <74a5c37-19a6-6f6f-a51d-6e5cca5b29e8@taugh.com> <CAJ4XoYdXWTgADpdL1eJuYGnpSY038vj-FW_x1f2rEp1JL0r2oA@mail.gmail.com> <01RTICXKLL3E0085YQ@mauve.mrochek.com> <c5f7413e-52c1-6710-16e5-63f59d2c24b9@taugh.com> <CAL0qLwYDeV9CmFg9qCCGPse00JV30WRiSC4orC-EitK=hiahgA@mail.gmail.com> <a79dd75-4d73-d1dc-d6b1-272de866b950@taugh.com> <CAL0qLwZXu3FxH7QGBS7PGbeDwfDTGmC=rbPEQidVV4eDJNHLUA@mail.gmail.com> <CAJ4XoYeK2cJb+easc=mqCi4ap1932LmbDdfxM1dFZKrdo2a2mw@mail.gmail.com> <acfe3d9e-97eb-50ee-26a2-568fdd8359dd@taugh.com> <CADyWQ+GJ62jt=dL9Gzuw_O7USNbS=86BqAzu8Rdv9sCb5OpCdw@mail.gmail.com> <d4a00be5-bd61-0c05-3431-8d56b39a3550@tana.it> <8813331f-f5e4-faa5-c6d-11212fc25797@taugh.com> <5d150251-427c-5c44-a0c3-ad2e7f24b692@tana.it> <01RTP8I70EYI004QVR@mauve.mrochek.com> <6a4a11ea-fae2-81f5-ce5f-fbd4bc1d41e2@taugh.com>
To: John R Levine <johnl@taugh.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/D-69nqzE1k-r-0gD2U5Be3mehM4>
Subject: Re: [dmarc-ietf] reporting documents, Ticket #55 - Clarify legal and privacy implications of failure reports
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: Mon, 28 Dec 2020 21:00:42 -0000

> On Mon, 28 Dec 2020, Ned Freed wrote:
> > I'm not ethusiastic about the split, but if that's what people want then so be
> > it. I will say that my experience has been that doing so is usually more work
> > and provides less benefit than you'd expect.

> I recall agreeing to split out all of the reporting into a separate draft,
> which makes some sense so the two parts can proceed separately, but not
> further splitting aggregate and failure reports.

I was referring to the latter; I thought the reference to the drafts involved
made that clear. Sorry for the confusion.

The outcome of the split of MIME part one into four parts may offer some
limited insight here. IMO splitting message bodies from media types was a sound
logical split and ended up being a good thing. The split of conformance
criteria from media types, however, was a pretty serious lose - they now tend
to get ignored - so much so it's tempting to try and undo it.

But the split of media type registration from MIME/email was the real win, so
much so that it more than justified the entire activity.
 
The lesson, if there is one, is to go just far enough, but no further.
Splitting different reporting types smells a lot like "further" to me.

				Ned