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

Alessandro Vesely <vesely@tana.it> Wed, 27 January 2021 12:33 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 B7DCC3A0FEB for <dmarc@ietfa.amsl.com>; Wed, 27 Jan 2021 04:33:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.121
X-Spam-Level:
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: 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 p4fAxEd4tlxx for <dmarc@ietfa.amsl.com>; Wed, 27 Jan 2021 04:33:55 -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 713333A0FDE for <dmarc@ietf.org>; Wed, 27 Jan 2021 04:33:55 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=delta; t=1611750831; bh=QIl73DSQD5SOwg8fsE9t7HdVI9dRNmmCWWcvN50vOe4=; l=2076; h=To:References:From:Date:In-Reply-To; b=DV2ldsnnB4e6Ie2W4dUxttoKcmfde7spjxrdy/7AcVPq1fYjFt9UkgNt7Z/eIRwQ8 E3xYfQ4iZccwMGSVq6mNGC4QpOt91s6m7MSQZzEd/AQtnkpLhnrtukb8EEnCizfqEl h5JmIhL5QUvK4gsVy+9O1tg1gO/Arzg/8AP2zftQjjg4Eofx/zVjV3sShXJKL
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 00000000005DC053.0000000060115DAF.000037F3; Wed, 27 Jan 2021 13:33:51 +0100
To: Douglas Foster <dougfoster.emailstandards@gmail.com>, IETF DMARC WG <dmarc@ietf.org>
References: <MN2PR11MB4351BD7203D41DB25771D3B3F7BD9@MN2PR11MB4351.namprd11.prod.outlook.com> <CAH48Zfwat5MmXrvfEp-G=0pTZe2fwwDOJ6s6M1FSWs6M50yk0w@mail.gmail.com> <MN2PR11MB43513C20B5A598496FFBA4AAF7BD9@MN2PR11MB4351.namprd11.prod.outlook.com> <7231cfb1-1553-fd11-e356-57b960c5bfdc@tana.it> <CAH48ZfwvBj3abrAEz1uK2UNyMOBAM1q3pH8cOmazn8VBow3ACQ@mail.gmail.com> <adcede1d-a260-7b78-9439-63eb706989e2@tana.it> <CAH48Zfzp5zDpGkyOwud55-OgNqTkHO5Vo4yL0mT9o2DR+-P51Q@mail.gmail.com>
From: Alessandro Vesely <vesely@tana.it>
Message-ID: <4c43b55a-674e-6aa3-a9f0-7e004c60e4ca@tana.it>
Date: Wed, 27 Jan 2021 13:33:51 +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: <CAH48Zfzp5zDpGkyOwud55-OgNqTkHO5Vo4yL0mT9o2DR+-P51Q@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dmarc/JoC3wGgDpTlrjqgMuLSLYN9r0DM>
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: Wed, 27 Jan 2021 12:33:57 -0000

On Wed 27/Jan/2021 12:31:51 +0100 Douglas Foster wrote:
> Is this already a settled issue?


There doesn't seem to be a consensus, yet.

I repeat what I already proposed:

*  max number of DKIM signatures: 1024 (say)
*  min number of DKIM signatures: 0
*  can report unverified signatures (<result>none</result>)
*  order signatures by descreasing importance (reporter POV)

Would the WG post some +/-1s, please?


> - Another approach, based on E.F.Codd's data normalization rules for relational 
> databases, is to have a table of messages which is keyed on a message ID, and a 
> table of signatures, which is keyed on message ID and sequence number.   Then 
> an outer join can be used to append the list element with sequence number # to 
> the message record.   A separate outer join is required for each sequence 
> number being appended, so the implementation must choose a maximum number of 
> list elements to append.   One recent poster said that he was using this 
> approach.    Outer joins are generally inefficient, and this approach might 
> work for up to 4 list elements, but it will not work acceptable for a list with 
> 100 elements.


Could fill the whole list using transitive closure.  MariaDB implements 
Recursive Common Table Expressions, which can be used for that purpose. 
Although that feature was implemented in 2016, it landed on the distribution I 
use quite recently.  I haven't yet looked at it.


> For report sources with a fixed limit, it seems appropriate to have a metadata 
> element where the report provider states the maximum number of signatures that 
> might be reported by his system.   An indicator would be needed to indicate 
> "many, with no pre-determined limit"


It is probably more useful to report the total number of signatures found.  The 
fixed limit of a given implementation can be deduced after it is hit.

OTOH, a reference to the software version that generated the report would be 
useful in general, and may lead to the documented fixed number in particular.


Best
Ale
--