dccm and dccd (greylist) - Another newbie-

> From: "Paul R. Ganci" <ganci@nurdog.com>


> >controls?  Why not do as some ISPs do and let individual users monitor
> >and control things themselves?  

> My user base in general does NOT want to do this ... they want it done 
> automatically for them. We have provided user control with an integrated 
> WUI interface to SpamAssassin. That capability has gone mostly unused or 
> has brought complaints just because the end user was required to do 
> something. 

You cannot avoid false positives with anything except per-user decisions
about which mail is objectionable.  All except a few of the very worst
streams of spam including copies that are wanted by some targets.  Any
blanket decision about almost any stream of mail will be wrong for some
targets.

All users want filtering to be effortless and most won't lift a finger.
However, many users that complain about false positives are willing and
even eager to exercise controls such as maintaining their whitelists.
Let them control some things and they'll stop complaining.  Give the
passive majority reasonable defaults, and they'll be happy too.


> >>    3.) How do the scripts work when an organization has multiple Email 
> >>servers with multiple instances of DCC? How is all the data from the 
> >>various logs combined to form one unique whitelist used by all flooded 
> >>servers?

> I am interested because I am running two Email servers with two flooding 
> local greylisters. Therefore I have exactly this problem.

Some of the standard solutions for synchronizing DCC whiteclnt and
log files are:

  - pin each user's logs and whiteclnt file to a single HTTP server
     (perhaps one of several HTTP servers) using the tactics standard
     for that problem such as HTTP redirections.  Use rdist, rsync,
     NFS, or some other, perhaps ad hoc scheme to distribute the
     whiteclnt files to the SMTP servers and to fetch and consolidate
     their log files on the right HTTP servers.

  - use some other distributed data repository that you prefer, and
     translate from it to whiteclnt files.

  - if it hurts, then don't do it
     In all except the largest installations, there are no good technical
     reasons in this century for a mailbox to be served by more than
     one mail system.  10 or perhaps even 5 years ago, MX secondaries
     were a good idea.  Since then SMTP server and Internet connectivity
     have become far more reliable.

     Having multiple MX servers for a single mailbox requires complications
     to deal with problems caused by spammers that have nothing to do
     with spam filtering.  How do you synchronize your valid-mailbox
     databases among your mail systems?  If you don't synchronize them,
     then you are probably spewing spam backscatter, (bounces or NDRs
     of spam (including virus) dictionary attacks).  If you are bouncing
     undeliverable spam, then you *will* be listed by DNS blacklists.

     If you don't bounce undeliverable mail, then you're violating the
     standards by blackholing legitimate messages sent to the wrong
     mailbox by typos.


Vernon Schryver    vjs@rhyolite.com