milter timeouts (was RE: Test of opendkim-2.3.1 on a busy e-mail server)

From: Murray S. Kucherawy <msk_at_blackops.org>
Date: Tue, 12 Apr 2011 06:16:42 -0700 (PDT)

On Mon, 11 Apr 2011, SM wrote:
> The processing after the EOM should be quite fast. There is an overall
> timeout of 5 minutes which is configurable. The progress messages
> restart the timeout period. What is that second EOM timeout?

EOM has two timeouts. The first is the read timeout; the filter has (by
default) ten seconds to reply to the MTA in some way. This timeout is
reset whenever the filter says something, and that something can consist
of a message that changes the SMTP reply, or one that adds/changes/removes
a header field, or one that changes the envelope in some way, one that is
a final response code (reject/tempfail/accept/continue/discard), or one
that is a "still in progress" message. The second is the EOM timeout,
which is (by default) five minutes, that limits how long the above
resetting can go in before the MTA gives up anyway because the filter is
taking too long to come to a final decision, during which time the SMTP
client is still connected and waiting for the reply to the DATA command.

In our case, the filter provides data to libopendkim that enables it to
send the "still in progress" message every few seconds during EOM.
However, that was broken until 2.3.1 and wasn't being sent. However
again, 2.3.1 got it wrong and also send them during EOH, which isn't
allowed, and this will be fixed in 2.3.2.

How this could take five minutes, tripping the EOM timeout, given that
libopendkim provides much shorter DNS timeouts to the resolvers is
puzzling.

-MSK
Received on Tue Apr 12 2011 - 13:16:58 PST