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

Alessandro Vesely <vesely@tana.it> Sat, 26 December 2020 10:47 UTC

Return-Path: <vesely@tana.it>
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 05F3C3A0FE7 for <dmarc@ietfa.amsl.com>; Sat, 26 Dec 2020 02:47:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 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_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: ietfa.amsl.com (amavisd-new); dkim=pass (1152-bit key) header.d=tana.it
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 NKuddeD13sBr for <dmarc@ietfa.amsl.com>; Sat, 26 Dec 2020 02:47:30 -0800 (PST)
Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (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 265F33A0FE2 for <dmarc@ietf.org>; Sat, 26 Dec 2020 02:47:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1608979646; bh=/TQZEe64pTxIv2xWu9cq7nNErDjoDtCKPbdnVbtZTIU=; l=2095; h=To:References:From:Date:In-Reply-To; b=Bv664h617YAbJOjheA/WznWnw6Ht/VMQ30a0Ydk7zavJvsLhtLwvsVbWN/WYWxY3v Y2HXYO0CSCnQN35cKmLQOOgOG/XuRhLiDq2LcE/MSqqineggXXs1AVTWyGqwcKO8EJ cXh+CxyAdW3CWY+rBKt8f9NT8daFglcR2gH3/0rkMHxLe8FAJTIUyYOCEBbL4
Authentication-Results: tana.it; auth=pass (details omitted)
Original-From: Alessandro Vesely <vesely@tana.it>
Received: from [172.25.197.111] (pcale.tana [172.25.197.111]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLS1.3, 128bits, ECDHE_RSA_AES_128_GCM_SHA256) by wmail.tana.it with ESMTPSA id 00000000005DC053.000000005FE714BE.00003D28; Sat, 26 Dec 2020 11:47:26 +0100
To: John R Levine <johnl@taugh.com>, Tim Wicinski <tjw.ietf@gmail.com>, IETF DMARC WG <dmarc@ietf.org>
References: <20201218023900.E73B82ACBB2B@ary.qy> <a8281e16-9417-5189-df73-79ea0a865fbd@tana.it> <c713b9ae-a364-1ae0-e79-55f61624aa3d@taugh.com> <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>
From: Alessandro Vesely <vesely@tana.it>
Message-ID: <5d150251-427c-5c44-a0c3-ad2e7f24b692@tana.it>
Date: Sat, 26 Dec 2020 11:47:26 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0
MIME-Version: 1.0
In-Reply-To: <8813331f-f5e4-faa5-c6d-11212fc25797@taugh.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/i73KOedUpgswCQAa_Vl7qThxjTU>
Subject: Re: [dmarc-ietf] 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: Sat, 26 Dec 2020 10:47:32 -0000

On Thu 24/Dec/2020 19:55:07 +0100 John R Levine wrote:
>> On Thu 24/Dec/2020 03:39:03 +0100 Tim Wicinski wrote:
>>> I Believe I agree with the current version, but can someone post what we 
>>> think is the final text?
> 
> See below, with the two changes mentioned before and Mr Copy Edit's minor 
> tightening up which I hope are not controversial.
> 
> Ale said:
>> I posted it here:
>> https://github.com/ietf-wg-dmarc/draft-ietf-dmarc-failure-reporting
> 
> Hold it. I don't recall that we agreed to break failure reports into a separate 
> document.


The fact that draft-ietf-dmarc-failure-reporting-00 exists on IETF datatracker 
seems to confirm WG consensus.  But see also:
https://mailarchive.ietf.org/arch/msg/dmarc/2DsSazvE9QxFjVSeg_mdNlRMETM


> It makes more work and I see no agreement to change anything beyond the
> security paragraph.  In particular, we have nothing to offer on what one
> might or might not redact.


I still think it'd be a good idea to mention RFC 6590...

Anyway, the change at hand arose from a ticket, as per Subject:.  After a long 
discussion, the new paragraph was explicitly proposed for the Introduction of 
the separated document, where it is most effective.  IMHO, Ned's wording —which 
you said to ship— is more comprehensive than the abbreviated version quoted 
below, hence preferable.

Why did you change your mind?


Best
Ale


> Security considerations
> 
> Failure reports provide detailed information about the failure of a
> single message or a group of similar messages failing for the same
> reason. They are meant to aid domain owners to detect why failures
> reported in aggregate form occurred. It is important to note these
> reports can contain either the header or the entire content of a
> failed message, which in turn may contain personally identifiable
> information, which should be considered when deciding whether to
> generate such reports.
> 
> _______________________________________________
> dmarc mailing list
> dmarc@ietf.org
> https://www.ietf.org/mailman/listinfo/dmarc