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

Douglas Foster <> Mon, 03 May 2021 11:21 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6B6273A03F2 for <>; Mon, 3 May 2021 04:21:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Status: No, score=-2.096 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, FREEMAIL_FROM=0.001, 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 (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id mPUClnrk93kZ for <>; Mon, 3 May 2021 04:21:44 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::335]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 726423A0489 for <>; Mon, 3 May 2021 04:21:44 -0700 (PDT)
Received: by with SMTP id d3-20020a9d29030000b029027e8019067fso4691557otb.13 for <>; Mon, 03 May 2021 04:21:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=MrpflDE6ZcXuQv9dAuYTOdq7F3wZBceQYgP1gLc2wLw=; b=bB6SRrKvehPReYSs94P/1T+eb9TThzxRcM9jEf9xvvmHzQMZLS4dVP06MIYNkPQq4W slYMtvDpc5TVjc4xCfwoiDSWAH5mioygPAZYGY0HzaB2vcs+WrEIE7H5ToVJm4wcK+eb H03JKNsWPwb3/5f5t1EoZyqj8SnvLRHC/ttW3cakuDKMDW5TKYEm/R87wLWwAqPBIJiL l2d+GUTU5E4wzIJxg3amuLn5ovh8pd10XJKhbEfOXlOLlMZ2nstzjej714guxcYGOnfr 4ipTzSu7MUO6rEH9KGkc9YOzDDqwaREJgcF1621ZXPsg86BMmQt8OPBWfSeTgbT7+eVm fAUg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=MrpflDE6ZcXuQv9dAuYTOdq7F3wZBceQYgP1gLc2wLw=; b=luRPgVVuY+7E37driM5BXznR7B/xAQpTxOZxTS4ouGGIO0FqvtnsqtQZNR75XzhDMl yINkGdrUCioUP/7RAmSKOhJbXnBqIBZEFT8GOB6GjwE5LSfCaALdIP/mSUoCage0Qv1w cD+QHjQt6FHfQ+2SVAWhSOm4LmumNHZJFDEuqh+3luYWz/E0ALZwVFC6p1RTueQfmEvJ eoxdCXixmKzEwCPRSVmbsDi1x2xvHwcQRNMMxLau4atzfNsf5veZUnJCjZaIOmMKQU3E NnM/VgDlcbIZtNbLKf3uAut/Mmeu/4v/EeQaWK0o3h3WAGNF/a2DolzkpMS9e6bt4qP6 SxTA==
X-Gm-Message-State: AOAM5300X2IcHiX9QQz0+1mDVXYK235bGa+WgXLCv3Ub/vLaE8r+I7XP mGBz7TxH63joZjG7toQVuRipjDUtZwtJyjPe/QmAlXk0
X-Google-Smtp-Source: ABdhPJyvSqHFrdiyV9JKk4CQ/3NydyVpelQlbzeBA0j7ekZikuY9nkHWsFs9BgDoLLdOiGR2C3eva/Towgi0NYD7n+U=
X-Received: by 2002:a9d:30b:: with SMTP id 11mr13838080otv.298.1620040903171; Mon, 03 May 2021 04:21:43 -0700 (PDT)
MIME-Version: 1.0
References: <20210502203007.2AE156284F0@ary.qy> <> <>
In-Reply-To: <>
From: Douglas Foster <>
Date: Mon, 3 May 2021 07:21:32 -0400
Message-ID: <>
Content-Type: multipart/alternative; boundary="0000000000008e200005c16b2ab4"
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 11:21:49 -0000

To address Laura's concerns about individual targeting, the reporting needs
to ensure a minimum level of aggregation on all reports.

This starts with MailFrom.   If less than N unique recipient addresses are
included, the report should not be sent at all

If a DKIM selector occurs on less than N unique recipient addresses, the
DKIM selector should be replaced with * or Null.

I do not have a strong opinion about N, but am thinking 10.

Doug Foster

On Mon, May 3, 2021 at 4:49 AM Laura Atkins <> wrote:

> 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?
> laura
> --
> Having an Email Crisis?  We can help! 800 823-9674
> Laura Atkins
> Word to the Wise
> (650) 437-0741
> Email Delivery Blog:
> _______________________________________________
> dmarc mailing list