Re: [dmarc-ietf] Which DKIM(s) should be reported? (Ticket #38)

Alessandro Vesely <> Tue, 26 January 2021 12:50 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 65C023A0AD6 for <>; Tue, 26 Jan 2021 04:50:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.21
X-Spam-Status: No, score=-0.21 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_HTML_ATTACH=0.01, 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 vVMM3rgtYc8B for <>; Tue, 26 Jan 2021 04:50:37 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 9D30E3A0AD5 for <>; Tue, 26 Jan 2021 04:50:37 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=delta; t=1611665433; bh=w61rJ7hch0ZG098+JgT+tVnwqJUBjINQtGTuXAIYQXE=; l=7750; h=To:References:From:Date:In-Reply-To; b=Cwii0WQ2oYL149FAK8DykRvJexuEYPlwAG7WjPRVmziXLja9/GmQeml0J54MeU/xi /14F6+M3DXdPFrGfBlEXT1V47dikwLh6ym/t9xGGTClIiu4fJRQi+GuYQ1Bw80fO5B zGSxQ7LQGakYEZCs0M+UGiUgzAkq7NF1eMwZZVN2SGe/9z9LPA+HN847WhdXg
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 00000000005DC0D6.0000000060101019.00004A43; Tue, 26 Jan 2021 13:50:33 +0100
To: Douglas Foster <>, IETF DMARC WG <>
References: <> <> <> <> <>
From: Alessandro Vesely <>
Message-ID: <>
Date: Tue, 26 Jan 2021 13:50:32 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/mixed; boundary="------------6262F3770A673C70EF81536D"
Content-Language: en-US
Archived-At: <>
Subject: Re: [dmarc-ietf] Which DKIM(s) should be reported? (Ticket #38)
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, 26 Jan 2021 12:50:39 -0000

On Tue 26/Jan/2021 13:02:46 +0100 Douglas Foster wrote:
> DKIM Scopes
> I have not heard a compelling argument to require information about 
> authentication tests that are unrelated to alignment testing.    For DKIM 
> specifically, I think one scope should be sufficient, on this hierarchy:
> - The best-aligned scope that verified, or
> - the best-aligned scope that failed verification, or
> - a no-signature result otherwise.
> Anything more complex imposes a gratuitous data collection burden on the 
> reporting domain and reduces aggregation significantly.   On the technical 
> side, it has already been noted that variable-length lists are particularly 
> problematic for calculating aggregates.

Let me attach an HTML rendering of a report I received today, so we can talk 
about something real.

Lines with IP bear a identifier.  I see no reason to 
remove it.  It is useful for understanding the mailflow, which is what DMARC 
reporting is designed to do.

> Aggregation Controls
> We have discussed whether the target domain should be included in the
> report.  I understand that doing so is not reasonable for the large hosting
> services.   On the other hand, including the target domain would be a
> trivial matter for smaller operations, and I think it would be valuable for
> some research.    Similarly, DKIM scopes are known to be useful for most
> investigations, but John has already observed that proliferation of DKIM
> scopes can be used to force disaggregation down to the individual recipient
> level.

Even if this is a small example, learning the disaggregated, or even individual 
recipients does not help my understanding.  Authentication is obviously 
conditioned by how the Mediator treats my messages.

I expect that Fastmail Pty Ltd carries out SPF and DKIM validation using the 
same algorithm, irrespective of the recipient.  That is what I, as a sender, am 
interested in.  Splitting the report in 66 lines wouldn't tell me anything 
more, it would just consume more eyeballs.  And is useless for people who sum 
up all reports and just look at the totals.  In any case, I cannot verify if 
the messages I didn't send directly are real.

If a multi-domain host allows personalized validation algorithms for some 
domains, I'd expect they send separated aggregate reports, if any.