Re: Limiting the number of domains/signatures verifications

From: Murray S. Kucherawy <msk_at_blackops.org>
Date: Tue, 9 Oct 2012 12:15:41 -0700 (PDT)

On Tue, 9 Oct 2012, SM wrote:
>> Opendkim is limiting the total number of verified signatures since
>> v2.3.0 (feature request #SF3109963). I'm adding a prescreen callback
>> now, in order to do something similar. However, my filter sorts
>> signatures using an O(n^2) algorithm (gnome sort) which is good for a
>> few signatures only. Dealing with thousands of signatures might cause
>> it to hiccup even if most of them are set to be ignored. One question
>> is: Does it make sense, in your opinion, to reject outright the
>> messages that have more than, say, 100 signatures?
>
> I don't have a plausible reason for using more than 100 DKIM signatures in
> production. I'd say that you shouldn't encounter even half that number.

I agree.

I also think you can use the prescreen callback to apply a more efficient
sort. Even quicksort would be better, and libc provides that on every
system I've ever seen (see qsort(3))..

>> The second point is about grouping signatures by domain. A domain may
>> sign the same message multiple times, e.g. if they are changing
>> selector, experimenting with different canonicalizations, or because
>> the message happened to pass through their MTAs multiple times. In
>> the latter case, I reason, the topmost signatures are the first ones
>> in the dkim_siglist array; that is, the ones added to the message more
>> recently, and thus having more chances to verify. Is it harsh to just
>> consider the topmost, say, four signatures of each signer?
>
> It depends on your usage of DKIM. Four is on the low side even though it
> covers the general cases.

When the array is created, the order represents the sequence found in the
message header, top-to-bottom. There's no reliable way to say which one
was most recent, but you can apply heuristics such as presuming the MTAs
all prepend them (which is generally true) and/or the "t=" values are
correct (in which case you can sort by those).

-MSK
Received on Tue Oct 09 2012 - 19:16:00 PST

This archive was generated by hypermail 2.3.0 : Mon Oct 29 2012 - 23:33:36 PST