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

Alessandro Vesely <> Sat, 08 May 2021 14:31 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 438B03A19AA for <>; Sat, 8 May 2021 07:31:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.121
X-Spam-Status: No, score=-2.121 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_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 oEvd_ZMuxHcq for <>; Sat, 8 May 2021 07:30:56 -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 AD1E23A19AC for <>; Sat, 8 May 2021 07:30:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=delta; t=1620484248; bh=ziD9hMQo3AcExGpAH5OPcw8KTBvP5fTiwg6TqJ0uq2I=; l=2040; h=To:References:From:Date:In-Reply-To; b=A5fhEGVNFXADPnrlCTVB9m1erjo2TksIa5HhSOVS9aHV4tUTSpXGovByVrub9Dszn FAGkxzFtVfi9kYVxgI4cp8nkMrEe/qdK8SWdi2sa4/fOPo+ei0n6qf7CNpFIwTnAAM W1eFn9fZ1dj/gzinvaKS2be5fv6ZP4QWTUp1ij2C8kbetCmVZFz3PkIeUJsPX
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 00000000005DC028.000000006096A098.0000208F; Sat, 08 May 2021 16:30:48 +0200
References: <20210502203007.2AE156284F0@ary.qy> <> <> <> <> <> <> <> <> <> <> <>
From: Alessandro Vesely <>
Message-ID: <>
Date: Sat, 8 May 2021 16:30:48 +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: Sat, 08 May 2021 14:31:01 -0000

On Sat 08/May/2021 14:29:11 +0200 Matthäus Wander wrote:
> Laura Atkins wrote on 2021-05-08 13:59:
>> The current system does not allow for reconstruction of the forwarding
>> pathway.
> I agree in that envelope_to makes it easier for reconstruction of the
> pathway, but disagree otherwise. DMARC reporting in principle allows for
> reconstruction of the pathway, as noted in the privacy considerations:
> <>

The second paragraph says:

    Aggregate report may expose sender and recipient identifiers,
    specifically the RFC5322.From addresses.

It is bogus.  The email addresses contained in a DMARC aggregate report are 
limited to <report_metadata>.

I'm realizing now that envelope_from has a minOccurs="1".  How come?  I never 
generated one, yet I syntax-checked generated reports and never noticed that 
defect.  And I cannot comply in case of NDRs.

Anyway, given:

     Report from $ForwarderOrg:
     HeaderFrom=$OriginDomain + EnvFrom=$OriginDomain --> $ForwarderOrg

Is the meaning of "-->" the guessing of envelope_to?

     Report from $RecipientOrg:
     HeaderFrom=$OriginDomain + EnvFrom=$ForwarderDomain --> $RecipientOrg

The latter implies $ForwarderDomain changed the envelope sender.  More often 
it's left intact or emptied.

> Other proposals in the current I-Ds contribute to this privacy threat
> and may be worth a separate discussion:
> - #57 requires reporting of selectors, which can be exploited for tracking.

Yes.  Sender has to keep the selector <---> recipient association.  That way it 
can track the forwarding chain.  Yet, the information gathered isn't much more 
than positive DSNs.  In particular, this method doesn't disclose the local 
parts of the addresses.

> - #62 makes reporting mandatory, which leaves the mail receiver with no
> means to mitigate the privacy threat.

Making it mandatory is possible since RFC 8962 established the protocol police.