Should dccproc always start dccifd?

[Gary Mills]

We run dccd along with the dccm sendmail milter.  We also use dccproc
as a sendmail alias to report spam and feed it into an auto-reporter.
I noticed today that dccproc had started dccifd, even though we don't
use dccifd.  The man page does state that this will happen, for the
benefit of SpamAssassin.  We don't use that product either.

Here are the relevant sendmail log entries:

  May 28 17:08:58 electra dccproc[5556]: [ID 702911 mail.notice] try to start dccifd
  May 28 17:08:58 electra sm-mta[5551]: [ID 801593 mail.info] m4SM8u6o005506: to=|"/usr/local/bin/dccproc -R -t many | /usr/local/sbin/report-spam bin@...", ctladdr=<bin@...> (1/0), delay=00:00:02, xdelay=00:00:00, mailer=prog, pri=35253, dsn=2.0.0, stat=Sent

I assume this is harmless, but it raises a couple of questions.  Can
this be prevented?  Is there a more efficient way to handle these
spamtrap aliases?

--
-Gary Mills-    -Unix Support-    -U of M Academic Computing and Networking-
_______________________________________________
DCC mailing list      DCC@...
http://www.rhyolite.com/mailman/listinfo/dcc

[Vernon Schryver]

> From: Gary Mills

> We run dccd along with the dccm sendmail milter.  We also use dccproc
> as a sendmail alias to report spam and feed it into an auto-reporter.
> I noticed today that dccproc had started dccifd, even though we don't
> use dccifd.  The man page does state that this will happen, for the
> benefit of SpamAssassin.  We don't use that product either.
>
> Here are the relevant sendmail log entries:
>
>   May 28 17:08:58 electra dccproc[5556]: [ID 702911 mail.notice] try to start dccifd
>   May 28 17:08:58 electra sm-mta[5551]: [ID 801593 mail.info] m4SM8u6o005506: to=|"/usr/local/bin/dccproc -R -t many | /usr/local/sbin/report-spam bin@...", ctladdr=<bin@...> (1/0), delay=00:00:02, xdelay=00:00:00, mailer=prog, pri=35253, dsn=2.0.0, stat=Sent
>
> I assume this is harmless, but it raises a couple of questions.  Can
> this be prevented?

I hope it is too harmless to worry about.
Deleting the dccifd program or not running dccproc so will stop dccifd
from running.
However, if you are running dccproc often enough to trigger the
attempt to start dccifd, you might be better served by using dccifd.


>                     Is there a more efficient way to handle these
> spamtrap aliases?

Using dccif-test to send spam to dccifd might be better than using
dccproc.  It would certainly avoid the floods of DCC server health
probing NOPs that waste cycles and bandwidth at the public DCC servers
and why I made dccproc start dccifd.

With sendmail+dccm there are better ways.  One is using
/etc/mail/virtusertable to map spam traps to a mailbox with a
per-user whiteclnt file that declares everything spam.  That mapping
can result in a dccm log file envelope Rcpt_To line like this:

   env_To: <welcome@...>  addr=catchall  dir=userdirs/local/catchall

If /var/dcc/local/usedirs/local/catchall/whiteclnt contains a line like

    option threshold all,0

then all mail to that mailbox is reported to the DCC server with
counts of "MANY" and rejected.

I've switched from that style of spam trap to a new scheme.  It involves
a new option line that reports all mail to the DCC server with counts
of "MANY" but delivers the mail regardless, as dccm or dccifd were
running with -aIGNORE.  I then use a line like
   catchall: /dev/null
to discard the spam.  (Of course that could be a mailbox, real file,
or program.)  The advantage is that mail to spam traps is not rejected,
which might keep spammers from removing traps from their target lists.

I'm not yet ready to document (or name in public) that new option line,
because it might change.


Vernon Schryver    vjs@...
_______________________________________________
DCC mailing list      DCC@...
http://www.rhyolite.com/mailman/listinfo/dcc