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

From: Jose-Marcio Martins da Cruz <Jose-Marcio.Martins_at_mines-paristech.fr>
Date: Tue, 12 Apr 2011 15:46:54 +0200

Murray S. Kucherawy wrote:
> 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.

A bug was found (last month) in the workers version of libmilter. Maybe
this is the issue. In some situations, there may be a lot of threads
being accumulated in the filter and generate some timeouts and block the
filter. I've seen this here once only in many years. If you're using
libmilter compiled with _FFR_WORKERS_MODEL, try this patch (which will
be included in the next libmilter), which set a fd used by the workers
controller to O_NONBLOCK.

Regards,

José-Marcio

-- 
  ---------------------------------------------------------------
  Jose Marcio MARTINS DA CRUZ           http://j-chkmail.ensmp.fr
  Ecole des Mines de Paris
  60, bd Saint Michel                      75272 - PARIS CEDEX 06
  mailto:Jose-Marcio.Martins_at_mines-paristech.fr



Received on Tue Apr 12 2011 - 13:47:37 PST

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