Re: [dmarc-ietf] Recipient domain in aggregate reports (#23)

Laura Atkins <laura@wordtothewise.com> Sat, 08 May 2021 11:59 UTC

Return-Path: <laura@wordtothewise.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 31C7E3A10F3 for <dmarc@ietfa.amsl.com>; Sat, 8 May 2021 04:59:12 -0700 (PDT)
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=wordtothewise.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 v1qnns30SgA5 for <dmarc@ietfa.amsl.com>; Sat, 8 May 2021 04:59:06 -0700 (PDT)
Received: from mail.wordtothewise.com (mail.wordtothewise.com [104.225.223.158]) by ietfa.amsl.com (Postfix) with ESMTP id 3C6603A10F2 for <dmarc@ietf.org>; Sat, 8 May 2021 04:59:06 -0700 (PDT)
Received: from [192.168.0.227] (unknown [37.228.231.27]) by mail.wordtothewise.com (Postfix) with ESMTPSA id BE4EC9F149 for <dmarc@ietf.org>; Sat, 8 May 2021 04:59:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=wordtothewise.com; s=aardvark; t=1620475145; bh=9c3JTnqg3GI6Kcj9JpdJqAYYYm4Tyq8pPMdr4IGOsQQ=; h=From:Subject:Date:References:To:In-Reply-To:From; b=pWi0CY8DAo64WKoMEmQmPP43kYVGJmYjvLucPuAYWaJy6UW4wg3hTj7yvdwJrn2Ju qoh5JPLPMPuJrbN8D7w+Sa2r8i5hylnp2um1Svei07zN66MQzUmt+NwmP9jrmXP1aR vXfxUG0OdzVSwRwFzPvwGupxfxkV2SMIqC7iwHDY=
From: Laura Atkins <laura@wordtothewise.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_98E0096F-04BC-4022-AF96-8FA38CEA202A"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\))
Date: Sat, 08 May 2021 12:59:02 +0100
References: <20210502203007.2AE156284F0@ary.qy> <215690a6-2b04-3355-9999-816a1c3d7126@heeg.de> <70E22447-47F6-4B92-B47F-664A81107836@wordtothewise.com> <CAH48Zfy0_jvDAtwQ+MrK4kk=J1iqO=6z1+ToBPiAOYeJ5qWHyg@mail.gmail.com> <692CBE21-4222-4353-8D03-EE4B287405EF@wordtothewise.com> <CAH48ZfzH24kw9Rn8t_r-WmsBVQKcrNnV9Px0Gr7ufJcSncmUuQ@mail.gmail.com> <e9b5abbc-08b3-111a-9563-37a742c72ff3@tana.it> <MN2PR11MB43519672C6029A3FE916C0A1F7599@MN2PR11MB4351.namprd11.prod.outlook.com> <CALaySJJa+LWRmhKUxSBXa-Vbx6uf4pzgfQZ0cZ=KUGP3EWhWJw@mail.gmail.com> <4c6e369a-23a0-7816-33fa-41b8151cae54@wander.science>
To: IETF DMARC WG <dmarc@ietf.org>
In-Reply-To: <4c6e369a-23a0-7816-33fa-41b8151cae54@wander.science>
Message-Id: <3931DE91-A04A-4275-BF03-94010D5492CA@wordtothewise.com>
X-Mailer: Apple Mail (2.3608.120.23.2.4)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/ODqpfC-BVMmp281CPdCHEfLQ7n8>
Subject: Re: [dmarc-ietf] Recipient domain in aggregate reports (#23)
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, 08 May 2021 11:59:12 -0000

> On 8 May 2021, at 10:50, Matthäus Wander <mail=40wander.science@dmarc.ietf.org> wrote:
> 
> Barry Leiba wrote on 2021-05-06 16:16:
>> Chair weighing in, as chair:
>> 
>> We're divided in the sense that there are some who want to add this
>> information, but as I see it the rough consensus is not divided:
>> - This is extra information that's being proposed... so, a new
>> feature.  That requires rough consensus to add it.
>> - Serious privacy issues have been raised with respect to adding that
>> information.
>> - No refutation of those privacy issues has been given, and no
>> adequate mitigation has been proposed.  The suggestion of requiring a
>> minimum level of aggregation is insufficient, as there's ample general
>> evidence that privacy leaks survive aggregation.
>> - We therefore do not have rough consensus to add this.
> 
> Allow me to ask for clarification.
> 
> - "receiving_domains" has been proposed in #23 as new metadata.
> - "receiving_domains" is redundant to "envelope_to", which already
> exists in RFC 7489 and is being used in practice by a small portion of
> reporters.
> - Privacy concerns have been raised, which apply to both elements.
> - The proposed "receiving_domains" gets rejected.
> 
> What happens to the existing "envelope_to"?


The proposal objected to was adding a new piece of information to pass along information that would allow reconstruction of a forwarding pathway. 

Case 1: Identify mail flows along forwarders.

With an increased adoption of DMARC reporting, we will be getting
reports like this:
Report from $ForwarderOrg:
HeaderFrom=$OriginDomain + EnvFrom=$OriginDomain --> $ForwarderOrg
Report from $RecipientOrg:
HeaderFrom=$OriginDomain + EnvFrom=$ForwarderDomain --> $RecipientOrg

envelope_to allows you to automatically correlate these reports and
reconstruct the forwarding path. This helps to identify the culprit who
is breaking DKIM signatures, especially with longer forwarding chains.
Without envelope_to, reconstructing the mail flow requires guessing and
manual work.

The current system does not allow for reconstruction of the forwarding pathway. Additionally, there are privacy concerns with reconstruction of the forwarding pathway, among other objections. It is adding more discoverable PII to DMARC. 

laura 

-- 
Having an Email Crisis?  We can help! 800 823-9674 

Laura Atkins
Word to the Wise
laura@wordtothewise.com
(650) 437-0741		

Email Delivery Blog: https://wordtothewise.com/blog