RE: [postmaster@ivenue.com: DKIM failure report for p2OKvsn2005015]

From: Murray S. Kucherawy <msk_at_cloudmark.com>
Date: Fri, 25 Mar 2011 15:24:54 -0700

> -----Original Message-----
> From: opendkim-dev-bounce_at_lists.opendkim.org [mailto:opendkim-dev-bounce_at_lists.opendkim.org] On Behalf Of SM
> Sent: Friday, March 25, 2011 2:22 PM
> To: Murray S. Kucherawy
> Cc: Andreas Schulze; Todd Lyons; opendkim-dev_at_lists.opendkim.org
> Subject: Re: [postmaster_at_ivenue.com: DKIM failure report for p2OKvsn2005015]
>
> If we want to deal with multiple DKIM signatures, it may be
> worthwhile considering a long-term fix. When we first talked about
> multiple DKIM signatures, it was about whether to take the top-most
> signature or the start from the bottom. Usually, the bottom DKIM
> signature is the first signature affixed to the message. It faces a
> greater probability of being invalidated as it goes through other
> relays.
>
> When we are doing ADSP, it is the bottom signature that matters as we
> are correlating the DKIM signing domain with the Author domain. It's
> not a straight-forward issue to address (re: your comment about the
> processing overhead).

What we have now is:

- if TrustSignaturesFrom is not set, simple top-down selection

- if TrustSignaturesFrom is set, top-down selection of signatures from domains in that list, and then top-down again to fill the limit from what's left

So maybe our algorithm when --enable-maxverify is active should be something like this:

- if TrustSignaturesFrom is not set, make a bottom-up pass selecting author domain signatures, then make a second bottom-up pass filling up the limit with what's left

- if TrustSignaturesFrom is set, first make a bottom-up pass looking for author domain signatures, then make a bottom-up pass looking for signatures from domains in the list, then a third bottom-up pass to fill the limit with what's left

Is that right? Also, should we make the favouring of author domain signatures selectable or required?

-MSK
Received on Fri Mar 25 2011 - 22:25:02 PST

This archive was generated by hypermail 2.2.0+W3C-0.50 : Sun May 15 2011 - 15:59:41 PST