dccifd does not seem to be doing anything

Vernon Schryver vjs@calcite.rhyolite.com
Sat Jan 14 04:42:18 UTC 2006


> From: "Frank Bures" <lisfrank@chem.toronto.edu>
> To: "dcc@rhyolite.com" <dcc@rhyolite.com>
> Reply-To: "Frank Bures" <lisfrank@chem.toronto.edu>

(I hate it when "reply" does the wrong thing.
Why do so many people use reply-to" when sending to a mailing list?
Are modern consumer grade MUAs so broken that they ignore Reply-To?
Do I need to whack on mailman so that it filters Reply-to?)


> I configured the DCC according to the instructions.  I am running sendmail 
> and spamassassin, both working OK.  Unfortunately I cannot use milters as 
> they are not compiled in and for various reasons (mostly lots of manual 
> changes to sendmail.cf) I cannot just replace the sendmail.cf with another 
> one.

The sendmail.cf changes needed to run the DCC milter are about 5 lines
including the global milter settings.  If you can compile a modern
sendmail with the milter code (not sendmail.cf), it should be easy to
copy those lines to a local, old sendmail.cf.  (I notice "8.13.1/8.13.1"
in your headers.)


> When I enable dccifd in dcc_conf and start it with "service DCC start" 
> (renamed rcDCC script) I see two daemons running, but they do not do 
> anything.  No lines are added to headers, no greylisting is active, nothing.  
> Why?

How are have you plumbed mail messages to dccifd? 
  - Are you using SpamAssassin?  If so, you can't use DCC greylisting.
  - Are you using some other mechanism, such as the sendmail procmail hook?


> When I disable dccifd in dcc_conf and run dccproc with relevant hooks in 
> procmailrc it works OK. Lines are added to headers, filtration is active. 
> However, greylisting still does not work.

Can your procmailrc arrangment tell the MTA to reject with a temporary
4yz?  If not, greylisting is impossible.  If so, you must use dccifd
because dccproc knows nothing about greylisting.  Dccproc was intended
to be used with procmail, which I understand to know nothing about 4yz
SMTP rejections.   There are sample C and Perl interfaces to dccifd in
the dccifd/dccif-test directory that have almost the same form, fit,
and function as dccproc and that could be modified to tell a caller
to do a 4yz greylisting rejection.

> What's more, each and every hour, according to logs, dccproc tries to start 
> dccifd.  First time it is successful, subsequently it is not obviously 
> because dccifd is running already.  Why and where it is given that dccproc 
> starts dccifd?  There is nothing in my crontabs and I could not find 
> anything in /var/dcc either.  Yet it repeats itself each and every hour.

This is in the DCC changes file in your copy of the source
or http://www.rhyolite.com/anti-spam/dcc/CHANGES

    1.3.24
	Dccproc starts dccifd after 500 uses at least as fast as 0.1/second.
	    With luck SpamAssassin will notice and switch to dccifd.

Busy sites do themselves and the public DCC servers no favors by using
SA+dccproc when they could be using SA+dccifd.

I guess I ought to document that in the dccproc man page.


Vernon Schryver    vjs@rhyolite.com



More information about the DCC mailing list

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