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

Laura Atkins <> Mon, 03 May 2021 08:49 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B0B473A1272 for <>; Mon, 3 May 2021 01:49:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Status: No, score=-2.097 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, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id HYxdC4VjVy6X for <>; Mon, 3 May 2021 01:48:59 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 758953A126C for <>; Mon, 3 May 2021 01:48:59 -0700 (PDT)
Received: from [] (unknown []) by (Postfix) with ESMTPSA id E05FE9F149 for <>; Mon, 3 May 2021 01:48:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; s=aardvark; t=1620031738; bh=u6tN1WXOfr6CRqDef+EHiQoa/8Vmg8wtdewvJ5Vvrhw=; h=From:Subject:Date:References:To:In-Reply-To:From; b=RR6oMzQkyDfkG5O1WcT31OXOC2ss4dazrA7bBB0EGdkMun3TW+8gPYX6Q6xUimHX1 HRKxzgZfLQupzEBR69p8xankkk13FkBaOVsNqey/LRIg5Au7Ofy8TWp5tP3nsSZngv ojo46xP5XMVDLImogCIpc3iM8j7NFnksYb1YpuIw=
From: Laura Atkins <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_0496C497-22BD-4BA6-8AF8-12490326FB85"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.\))
Date: Mon, 3 May 2021 09:48:55 +0100
References: <20210502203007.2AE156284F0@ary.qy> <>
In-Reply-To: <>
Message-Id: <>
X-Mailer: Apple Mail (2.3608.
Archived-At: <>
Subject: Re: [dmarc-ietf] Recipient domain in aggregate reports (#23)
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: Mon, 03 May 2021 08:49:06 -0000

> On 3 May 2021, at 07:27, Hans-Martin Mosner <> wrote:
> Am 02.05.21 um 22:30 schrieb John Levine:
>> It appears that Matthäus Wander <> said:
>>> 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.
>> It is none of your business to whom I forward my mail.
> True, unless you (generic you, not John L.) make it my business by complaining about not receiving my mail either in a
> support request (which may cause quite some work) or in a public forum (which might damage my reputation and even cause
> more work).

I will point out that for a lot of us online (specifically those of us who don’t check any or all of the the cis-het-white-male categories) forwarding mail and protecting our identities are crucial to our ability to actually participate in an online life. Stalking and harassment are real. I, personally, have been being low-level stalked by someone for over a decade now. I have been put into positions where I have to make calculated decisions about my ability to participate in places based on my personal safety. I have involved the police in the past for specific threats against me. The first time I was threatened and stalked online was more than 20 years ago. This is not some ‘oh, it only happens to some people’, it happens to a lot of people, regularly. 

The threats I’ve had to deal with, just for being a woman in an online environment, are minor compared to some threats other women, BIPOC and members of other marginalized groups have had to put up with. I’ve never had to move out of my house for my safety. ISPs HAVE doxxed individuals in the past, both accidentally and through deliberate policy decisions. Adding personally identifiable information into DMARC reports is problematic in a way I don’t think many men here realize. 

It is not anyone’s business how I might route mail to protect my safety. And, frankly, the issues of data privacy and safety for people online significantly trump the concern that someone’s reputation might be slightly impacted because they can’t troubleshoot an individual mail failure. 

> I am too often in a position of being requested to solve a problem but the requestors don't even provide the minimal
> logging info or even error texts to even start analyzing their problem. In such cases I want to be able to look at as
> much info as possible so as to provide a decent service.
> I don't snoop on mail logging info to satisfy my curiosity or to increase my revenue, but to solve my user's problems.

This is irrelevant. How, in fact, do you protect your users safety and privacy? How do you ensure that the request is actually coming from your user and not from someone attempting to discover where they are and defeat personal safety measures your user has put in place to protect themselves from harassment and stalking? Maybe they don’t provide the minimum logging info or texts because they’re attempting to social engineer you into revealing someone’s information and identity that forms a chain that leads to their safety being compromised. 

> Whether envelope_to would help my work isn't clear, but apparently it would help Matthäus in his work.

But is that work necessary and relevant? Does that process protect people? Does it faciliate online threats, harassment and stalking? Will someone who is trying to hide their location due to a credible threat be harmed by this protocol decision?


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

Laura Atkins
Word to the Wise
(650) 437-0741		

Email Delivery Blog: