Re: OpenDKIM v2.3.1 released

From: Gary Mills <>
Date: Wed, 30 Mar 2011 08:21:45 -0500

On Wed, Mar 30, 2011 at 12:45:18AM -0700, Murray S. Kucherawy wrote:
> On Tue, 29 Mar 2011, Gary Mills wrote:
> >It's bug 3258459 `bogus response from opendkim-2.3.1'.
> I've attached a patch to the bug. The patch suppresses in-progress
> messages until the EOM phase. If you (or someone) can confirm it works,
> I'll set up for a 2.3.2 release in a couple of weeks.

Thanks. I'll give that a try in a few days. However, this error must
be unusual as it depends on internal and external timing. I may not
be able to reproduce it.

> Just to explain further: There are four milter timeouts to be aware of:
> connect, send, receive, EOM. During EOM, when the MTA is waiting for
> replies from the filter, both the receive (default 10s) and EOM (default
> 5m) timeouts are in effect; the "progress" message only resets the former
> and not the latter. Since EOH doesn't have its own timeout, there's no
> way to give the filter some leeway during the DNS work done in EOH without
> extending the milter timeout, which has to be done in the MTA directly.

I see from the opendkim/README file that this sendmail configuration
is recommended:

    INPUT_MAIL_FILTER(`opendkim', `S=inet:8891_at_localhost')

Is this still reasonable? This is what I use for our three filters:

    INPUT_MAIL_FILTER(`j-chkmail', `S=local:/var/run/jchkmail/j-chkmail.sock, T=C:2m;S:20s;R:40s;E:5m')
    INPUT_MAIL_FILTER(`dkim', `S=inet:8891_at_localhost')
    INPUT_MAIL_FILTER(`dcc', `S=inet:3331_at_localhost, F=T, T=S:60s;R:60s')dnl

-Gary Mills-        -Unix Group-        -Computer and Network Services-
Received on Wed Mar 30 2011 - 13:22:01 PST

This archive was generated by hypermail 2.3.0 : Mon Oct 29 2012 - 23:20:16 PST