dccm timeout lets some spam through

Vernon Schryver vjs@calcite.rhyolite.com
Fri Apr 25 19:02:16 UTC 2003

> From: Gary Mills <mills@cc.UManitoba.CA>

> ...
> > Judging from that error message, one of the milter timeouts is too short
> > for your system.
> But, why would connections between sendmail and dccm time out only
> during the time when the local dccd database was being rebuilt?

Perhaps because the whole system becomes very slow as dccd flushes
the memory mapped database files to disk and as dbclean makes new files.
Some operating systems including FreeBSD don't seem to have this problem.
Other systems including BSD/OS 4.2 almost die for 30-120 seconds when
dccd invokes close() on the database file descriptors.

> How long does it take dccm to notice that one dccd is not responding,
> and switch over to the other one?

Dccm switches servers when the current one fails to answer.  Depending
on the measured RTT, that can take as long as 30 seconds.

> ...
> These are my two filter definitions from sendmail.cf:
> 	Xdcc, S=inet:xxxx@electra.cc.umanitoba.ca, F=T
> 	Xismilter, S=inet:xxxx@localhost, F=T, T=S:2m;R:2m;E:5m
> So, dcc is using the defaults, which should be, according to the
> documentation: `T=C:5m;S:10s;R:10s;E:5m'.  Should I increase the `S'
> and `R' timeouts to 2 minutes like the Trend virus filter?  That seems
> awefully long for communications between sendmail and dccm.

Yes, 2 minutes is too long because it is longer than the 30 second
limit on the RTT.  Maybe R:30s would be a good idea on your system.


More information about the DCC mailing list

Contact vjs@rhyolite.com by mail or use the form.