DCC 1.2.14 and "temp failing commands"

Vernon Schryver vjs@calcite.rhyolite.com
Thu Oct 23 22:38:27 UTC 2003

> From: Spike Ilacqua <spike@indra.com>

> > Probably something unrelated such as the size of some code or data
> > somewhere.
> Or maybe traffic patterns since having never done this before under
> 1.2.11 it just did.

Perhaps.  On some days but not most I've seen heavy spikes of TCP
connections from spammers.

> How come sendmail sendmail defers mail in this case instead of just
> delivering it as it does when dccm dies? 

Whether sendmail temporarily or permanently rejects the message or
ignores the milter when a milter fails is controlled by the F=x
parameter on the xdcc line in sendmail.cf.  That is often generated
from the FEATURE(dcc) line in a .m4 file and the dcc.m4 feature file.
See the misc/dcc.m4 and the sendmail milter documentation for more
Whether you want F=T or nothing probably depend on how bad it is to
leak spam.  The low FDSET limit and so low limit on concurrent dccm
jobs in BSD/OS might cause a lot of leaking spam with no F=T.

>                                           This is a major problem as it
> effectively shuts down sendmail, but in away that's hard from network
> monitoring software to detect...

What about this script run from cron:

    if test ! -z "`(echo mail from: postmaster; sleep 1) 	\
		    | telnet localhost 25			\
		    | grep '^451 4.7.1 Please try again later'`" ; then

> > If our theories that the problem is related to the BSD/OS 4.2 and 4.1
> > resolver library are true, the only tactic likely to be effective is
> > to look at the source to that library.
> I'm not convinced, I've tried building dccm linked with the BIND 9
> library to no avail.

Not convinced of what, the theory that the problem is in the BSD/OS
resolver or that the problem can't be fixed except by figuring it out?

When things are sick it might be worthwhile checking that there are
not a zillion SMTP sessions stuck.  On some days it has seemed that
a spammer will start a zillion SMTP sessions and just abandon them.
This could happen if the spammer is not using a real TCP stack
and just forgetting the connection when it has an answer for a dictionary
probe.  This could exhaust the available dccm jobs.  If this this is
the problem, then reducing the sendmail timeouts should help.

Vernon Schryver    vjs@rhyolite.com

More information about the DCC mailing list

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