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

Alessandro Vesely <> Tue, 04 May 2021 09:07 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9469A3A2C7F for <>; Tue, 4 May 2021 02:07:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.12
X-Spam-Status: No, score=-2.12 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_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1152-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id c7fPSqi-0crN for <>; Tue, 4 May 2021 02:07:02 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 6EDCF3A2C73 for <>; Tue, 4 May 2021 02:07:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=delta; t=1620119217; bh=SVTh1iLqbye8Uv/lhkx6TCJC58PQpeKzxHABfsjgsIE=; l=3721; h=To:References:From:Date:In-Reply-To; b=AvVpXTO2n3CrtAwRk9P5f1QeJTIrBbN3WFZBdTEEEqV4mdq3dY3VA7POY8JHdVVk1 znMiAlqXqWV2ax2OVVOp+/qFGyEdfOPn8TQzYEBGafAUeuj1NsgFQt/xMNtRC8n93X mHNHp8/CfZYoWoTqK5C0H/pLcCuoTvi7hvqkh3HCnMroBBDmsm6ReGc1qwzJo
Authentication-Results:; auth=pass (details omitted)
Original-From: Alessandro Vesely <>
Received: from [] (pcale.tana []) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLS1.3, 128bits, ECDHE_RSA_AES_128_GCM_SHA256) by with ESMTPSA id 00000000005DC008.0000000060910EB1.00007D1A; Tue, 04 May 2021 11:06:57 +0200
To:, Douglas Foster <>
References: <20210502203007.2AE156284F0@ary.qy> <> <> <> <> <>
From: Alessandro Vesely <>
Message-ID: <>
Date: Tue, 4 May 2021 11:06:56 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.9.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
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: Tue, 04 May 2021 09:07:13 -0000


On Mon 03/May/2021 14:25:54 +0200 Douglas Foster wrote:
> 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.

A simple positive DSN can confirm email addresses better than elaborate DKIM 
design.  To confirm delivery is usually not considered a privacy violation, 
given that the sender learned the recipient's address.  Privacy violation 
occurs when senders track the recipient's opening of each message, which is 
typically obtained by inserting unique images in HTML messages.

Avoiding to reveal final email addresses requires various precautions, which, 
if I understood what Laura wrote, can be put into effect on forwarding.  I 
would *add to the Privacy Consideration section* that, due to reporting, 
changing the envelope from is not enough, From: has to be changed as well in 
order to forward without revealing the final address.

> Valid addresses are needed to hinder usage of bogus addresses to defeat the test.

However, the aggregate report counts the number of messages, not the number of 

> 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.

I think mass mailers have better means to track recipients.  But I agree that 
to generate, publish, retrieve and report million DKIM selectors would be 
somewhat impractical.  Putting a limit on aggregate report size (even if not 
requested by the report consumer) can prevent excessive disaggregation.

> 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.

Most reports I send have <count>1</count>, given my volumes.  Yet, by 
aggregating many of them one could reach significant sums.

> 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.

This is a recipient's choice.  If I wanted to stay anonymous, I'd use a domain 
like rather than

> 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 decision.

It is already optional in the I-D.  (Not that I find it useful.)

> 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 
> self-identification.

Some receivers cannot report mail discarded during early SMTP phases at all, 
for example because the DMARC filter is run after the end of data.

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

DMARC cannot address those concerns directly, IMHO.  However, it can note under 
what conditions aggregate reporting doesn't violate privacy.  It is especially 
useful to note that, in most cases, aggregate reports do NOT constitute a 
privacy risk.