Integration problem, map file !

> From: Matthias Fuhrmann <Matthias.Fuhrmann@stud.uni-hannover.de>

> IIRC, this problem is due to the trouble, sendmail, after invoking a spamd
> child by a milter application, recognizes, that there is no valid user,
> for the adressed email. so the spamd child is idling, invoking dccproc and
> no mail-feed is comming to spamd/dccproc.
> since we are using a new version of miltrassassin, only invoking spamd
> childs, if there is at least one haeder line from within the envelope, we
> never saw this message again.
> so this message does not indicate a problem.

It is undesirable to use even dccifd with sendmail.  Using dccproc
seems even worse.
It is far better to use dccm with sendmail.  If you can produce
a whitelist for dccm, you can reject spam during the SMTP transaction.
This has major advantages:

  - you use far fewer CPU and disk cycles to reject spam during the
     transaction than after with a Perl filter like SpamAsassin

  - senders of legitimate mail hear about false positives and can
     make other arrangements

  - you can use greylisting

  - you could use URL IP address blocking in mail bodies, if I can
     finish figuring out a kludge to deal with the DNS resolver problem.

If you cannot make an organization-wide DCC whitelist and you cannot get
your users to build individual, per-user DCC whitelists with something
like the proof of concept CGI scripts in the DCC source, there is still
something better than running dccifd from SpamAssassin after sendmail.
That is to run dccm with -aIGNORE in DCCM_ARGS in /var/dcc/dcc_conf
and configure SpamAssassin to look for "X-DCC.*bulk" headers.


Vernon Schryver    vjs@rhyolite.com