Reasonable $child_timeout values (pre-queue)
Mark.Martinec+amavis at ijs.si
Mon Jul 4 03:09:42 CEST 2011
> (I just got done switching from post-queue to a pre-queue setup.)
> Is ~45 seconds still the accepted "reasonable" value for $child_timeout
> in a pre-queue setup?
> And, how does its value interact with Postfix's smtp_data_done_timeout?
> Mark once posted that $child_timeout should be less than
> $smtp_data_done_timeout, but does it matter how much less, or to what we
> set $smtp_data_done_timeout?
Yes, I think the ~45 seconds is still a sensible value for $child_timeout
in a pre-queue setup. The limiting upper bound are mainly the unpredictable
SMTP clients expectations.
Provided that required minimal versions of Postfix and SpamAssassin are
available, on can try amavisd in a Postfix proxy setup. The $child_timeout
setting needs to be radically reduced in this setup, matching the longest
time most SMTP clients are willing to wait, and must be less than Postfix
is willing to wait (smtpd_proxy_timeout), which by default is 100 s.
A sensible value is somewhat less then a minute (e.g. 45 seconds). Even
though RFC 5321 (section 188.8.131.52.6) recommends that clients SHOULD be
willing to wait for 10 minutes at data-end stage, it is not uncommon
that this recommendation is not adhered to.
Note that a pre-queue filtering setup (along with its benefits) still
has all its drawbacks, like the need for more filtering processes to
accommodate mail arrival rate peaks (instead of averages), and much shorter
and unpredictable (client-dependent) time limits. The new features of the
three products only rise the thresholds where trouble starts, and make
the whole setup better behaved.
More information about the amavis-users