dccm causing tempfails

Vernon Schryver vjs@calcite.rhyolite.com
Fri Sep 1 14:44:19 UTC 2006

> From: Bart Dumon <bartdu@bsp.scarlet.be>

> Did anyone ever run into a problem with dccm where sendmail would be
> tempfailing a lot of incoming connections?

Not without /var/log/maillog entries pointing to dccm.

> Running /xxxxx/spool/clientmqueue/k81Dhg4T011984 (sequence 210 of 214)
> xxxx@xxxxxxx.... Using cached ESMTP connection to [] via relay...
> >>> RSET
> 250 2.0.0 Reset state
> >>> MAIL From:<xxxx.xxxxx@xxx.xxxxxxx.xx.xx> SIZE=267525
> 451 4.3.2 Please try again later
> xxxx@xxxxxxx.... Deferred: 451 4.3.2 Please try again later

Those log entries seem to be from the SMTP client or mail sender.
What are the corresonding log entries on the SMTP server or mail
receiver that is running dccm?

> As far as i am able to trace it down in the sendmail source, the error 
> is caused at milter initialization time. 

When dccm doesn't respond, sendmail should say something explicit, 
usually something about the milter filter not responding.

>                                          Increasing the MilterLogLevel
> did not provide any usefull information btw. The problem may
> dissapear and reappear after a while, restarting sendmail/dccm 
> makes it go away at once. 

Are there complaints from dccm in the system log about too many 
simultaneous jobs?  Or other system log complaints from dccm?

Are you using -B with dccm?

Does the xdcc line in sendmail.cf include "F=T"?
What timeouts are you using in the xdcc line?  The current defaults in
the dcc.m4 file are 30 seconds.

 From the Received header on your message, it looks as if you are using
a fairly old version of sendmail.  Recent versions of sendmail have
improvements in the milter code, including improvements in logging.

Vernon Schryver    vjs@rhyolite.com

More information about the DCC mailing list

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