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

Alessandro Vesely <vesely@tana.it> Mon, 25 January 2021 18:25 UTC

Return-Path: <vesely@tana.it>
X-Original-To: dmarc@ietfa.amsl.com
Delivered-To: dmarc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAA543A171C for <dmarc@ietfa.amsl.com>; Mon, 25 Jan 2021 10:25:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.221
X-Spam-Level:
X-Spam-Status: No, score=-0.221 tagged_above=-999 required=5 tests=[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: ietfa.amsl.com (amavisd-new); dkim=pass (1152-bit key) header.d=tana.it
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7M9-KNsZjqmR for <dmarc@ietfa.amsl.com>; Mon, 25 Jan 2021 10:25:58 -0800 (PST)
Received: from wmail.tana.it (wmail.tana.it [62.94.243.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 567463A171B for <dmarc@ietf.org>; Mon, 25 Jan 2021 10:25:58 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1611599155; bh=d6fplJWl82RFTsk+ZeUXQaH2wfQA7KNAsKYVsaUstEY=; l=1773; h=To:References:From:Date:In-Reply-To; b=AMl9zcZ3frsvsBpTtEah/7v/1WcJKvfoQ4efLAXEUG4fI0zEGnvcAiN0OQuFtRQd2 BwfgZvscH0A114W+pgYvN+ybOGPNyc2OZEuUgzFd/F/DCRoNelSUiC19sham1c5AEL 58WqUwDSkxNrS8Rg2pA4rs1/rCdFJS86UX4nobzVKQgTfDkRl+AtVoJqVNx+i
Authentication-Results: tana.it; auth=pass (details omitted)
Original-From: Alessandro Vesely <vesely@tana.it>
Received: from [172.25.197.111] (pcale.tana [172.25.197.111]) (AUTH: CRAM-MD5 uXDGrn@SYT0/k, TLS: TLS1.3, 128bits, ECDHE_RSA_AES_128_GCM_SHA256) by wmail.tana.it with ESMTPSA id 00000000005DC0E0.00000000600F0D33.00000245; Mon, 25 Jan 2021 19:25:55 +0100
To: dmarc@ietf.org
References: <MN2PR11MB4351BD7203D41DB25771D3B3F7BD9@MN2PR11MB4351.namprd11.prod.outlook.com>
From: Alessandro Vesely <vesely@tana.it>
Message-ID: <8f7226cc-6ce4-d633-e77e-0a7f7c328d7e@tana.it>
Date: Mon, 25 Jan 2021 19:25:53 +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: <MN2PR11MB4351BD7203D41DB25771D3B3F7BD9@MN2PR11MB4351.namprd11.prod.outlook.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/BZBfG3BrgSMDlLYetln0fKXYlNE>
Subject: Re: [dmarc-ietf] Which DKIM(s) should be reported? (Ticket #38)
X-BeenThere: dmarc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Domain-based Message Authentication, Reporting, and Compliance \(DMARC\)" <dmarc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dmarc>, <mailto:dmarc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dmarc/>
List-Post: <mailto:dmarc@ietf.org>
List-Help: <mailto:dmarc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dmarc>, <mailto:dmarc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 25 Jan 2021 18:26:00 -0000

On Mon 25/Jan/2021 01:25:13 +0100 Brotman, Alex wrote:
> 
> Some time ago, an issue[1] was brought to the list where which DKIM(s) being reported is not clear in RFC7489 [2].  There was a short discussion, though no clear resolution before conversation trailed off.  It seems like there were points that may need to be discussed.  One was whether the reporting SHOULD report all signatures, regardless of alignment or validity, or perhaps just the one that aligns (if there is one).


I think that, in principle, it is good to report all signatures.  Within a 
report, signatures should be ordered by importance.  If the number of 
signatures per report is limited, it is paramount that they be ordered, so that 
the most important ones are reported.

How to define importance is subjective.  A report generators decides the order 
based on internal policies or criteria.  The order in which signatures are 
reported is an additional information, as if each record contained a sort of 
approval index, irrespective of the total number of signatures being reported.

For example, my report generator orders signatures by domain, putting author's 
domain first, and then taking into account alignment and a sort of reputation. 
  That's the order in which validation is attempted.  Afterwards, valid 
signatures are put before invalid ones.  The number of reported signatures is 
limited to 4, because of SQL query limits (the query itself is configurable; it 
does a number of LEFT JOIN, which can be increased.)


>  There was also another question if there should be a limit to the number of signatures reported so that it remains sane.


Yes, I think it's sane to put a limit.  I'd reject messages with more than 128 
signatures.  It never happened.


Best
Ale
--