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

Douglas Foster <> Mon, 03 May 2021 12:26 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3E0C43A0D85 for <>; Mon, 3 May 2021 05:26:15 -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 Ep6VVCJjHw0C for <>; Mon, 3 May 2021 05:26:10 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::333]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id DB9683A0DA0 for <>; Mon, 3 May 2021 05:26:09 -0700 (PDT)
Received: by with SMTP id g7-20020a9d5f870000b02902a5831ad705so4845912oti.10 for <>; Mon, 03 May 2021 05:26:09 -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=K7TSOAextDyjomHen9l935g4y86NMogheyKI4R60IBs=; b=ekWQanuzOq5R6YEqqrFg1mzscoULDH4QZAqWF+S5tlmIr8LV7E+yR+h9gd9PVYpRNK ITkpps3FO9e115LDOpvBW/dZE/2M7fRSKbnqkbSmgafnOPNYyQlPHpsMPr4ABMmkmcBa 3GKePq7ZwcQYrwTY2R7f0apfwtMOBre4GlGNVCEgiaCfGbOl9HAUIHUpKMG4ABTGTLla ys/m5bL6xpHte1t9pqQScNFIJb41MiLOjcVmZeg0KugRK0MiIpYhPX1N8wLU2g11210h j5jP3XMbaNGZpNH/laD55Ep11Reogwxxh1KdkQJ2fL3+GUQ8/nkoDSwXgLVcGgvOi1pf 9iMA==
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=K7TSOAextDyjomHen9l935g4y86NMogheyKI4R60IBs=; b=jfrZr9NXLgPdjv97LSfg80CSZfcu0f25Qp1ljl5bp/rbqmiVVooqPzAKlOZKYCfkqa hhcDOYxIqpisqo/hs7DdN+uQNgJKc7hrdztCEdggnlZT+NRWSpNt6PtLR0X7clufmHiH gfp5pJ3doZ3WWUB8x9u/uYF0BHyREK8mRRDPu3nTzyHVvJCEH2onp6Qq5lMGjWf9pKJK y0xehILn8zA+QdeRQys2HiMtL3o6dbXozABZZaFiARXxMUZMuzH/sSi+fneohSyYNkZf 0U6/R7dV2uQ65eYUPKjEuVJQkpjVQQhGpdIA3YdRCYdZ6o+VrPgcCbiFc+xShTxdWmrw daEg==
X-Gm-Message-State: AOAM532jI2K7aX0jgepdt7Ee87Wxu0kfIxKCGmNo8WY1KjGJZ0XbmAEd KDKSQKi5lu0+T63SJyXWqlEZ479B0WeuZhx16zOrijzi
X-Google-Smtp-Source: ABdhPJyzWbp6XrYpSQtxDjGUPPez3IRcZKaSRawAiZ0G4zZxFJ8s9SNiBx1REXnh5KXrHS1qycXKqMHmlcDn0nST34k=
X-Received: by 2002:a9d:666:: with SMTP id 93mr14722101otn.284.1620044766705; Mon, 03 May 2021 05:26:06 -0700 (PDT)
MIME-Version: 1.0
References: <20210502203007.2AE156284F0@ary.qy> <> <> <> <>
In-Reply-To: <>
From: Douglas Foster <>
Date: Mon, 3 May 2021 08:25:54 -0400
Message-ID: <>
Content-Type: multipart/alternative; boundary="000000000000d6fcd305c16c100d"
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 12:26:15 -0000

No.  I can't talk straight.

I meant to say that we need N unique (and valid) smtp TO addresses, so that
an attacker cannot send a single email address and wait for an rua report
to know where it lands.

Valid addresses are needed to hinder usage of bogus addresses to defeat the

Requiring aggregation on DKIM selector follows the sane logic to hinder
tracking an individual.

Using DKIM selectors for tracking will also put a huge load on DNS if
implemented at scale, so it needs to be obstructed.

It is also not enough to null the DKIM selector; the null aggregate still
needs to meet the N recipient requirement.  If not, then additional
selectors need to be nulled or the nulled-selector messages need to be
completely excluded from the report.

If the To domain is included in the report, the aggregation rules should
still apply.  If they cannot be met, then the To domain must be nulled out
or the report not sent.

I favor making To domain an option which the owner domain requests and the
sending domain chooses to follow or ignore.  This provides upward
compatibility.  The request for this data element keeps coming up.  The
protocol can allow flexibility so that the participants make the final

I asked previously whether report senders do any filtering based on domain
reputation, and the answer was "probably not".  I think the specification
should encourage recipients to omit reporting to sources with negative
reputations, as their motive for report collection may be unrelated to

I want the protocol to address all of Laura's concerns.  I think ensuring
aggregation is the best way to do this.


On Mon, May 3, 2021, 7:37 AM Laura Atkins <> wrote:

> In the bulk email space most messages are sent with a unique 5321.from
> address (VERP). Are you suggesting that no DMARC reports should be sent for
> commercial bulk mail?
> laura
> On 3 May 2021, at 12:21, Douglas Foster <
>> wrote:
> 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
> _______________________________________________
> dmarc mailing list
> --
> 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