DNSBL helper not answering

Vernon Schryver vjs@calcite.rhyolite.com
Thu Nov 23 00:21:02 UTC 2006


> From: Daniel Gehriger 

> I'm running the latest DCC as a postfix before-queue filter, as 
> described in the SMTPD_PROXY_README.

When you say "the lastest DCC", do you mean the latest official version
or the lastest version published by third parties such as Debian?

Why not set DNSBL_ARGS instead of DCCIFD_ARGS directly?


> The problem is that it sometimes doesn't automatically start when required:
>
> > Nov 22 09:34:21 vps183 dccifd[6017]: 3jq5Ea no DNSBL helper answer
> > Nov 22 09:34:21 vps183 dccifd[6017]: 3jq5Ea DNSBL failed for sender 64.40.109.130, 15.0 msg-secs remaining
>
> DNSBL lookups continue to fail for anything between a couple of minutes 
> and several hours until the help process starts again:

> Why dccproc sometimes fail to start a new help process ?

You must mean dccifd instead of dccproc.

Are you sure there are no helper processes, and that what is really
happening is that the relays.ordb.org and sbl-xbl.spamhaus.org DNS
servers are taking too long to answer?  Have you tried increasing
the per-URL delay budget with "-Bset:URL-secs=20" or similar?

What version and flavor of UNIX-like operating system are you using?
The main dccifd or dccm process uses waitpid(WNOHANG) to know when
helper processes have gone away.  That works well on FreeBSD, but
maybe not on other flavors.

After every failure to receive an answer from a helper, zombie
helpers are reaped.
After 5 failures to receive an answer, all of the helpers are terminated
and restarted.

There may be a race in restarting idle helpers.  I'll look into it.


Vernon Schryver    vjs@rhyolite.com



More information about the DCC mailing list

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