[prev in list] [next in list] [prev in thread] [next in thread] 

List:       spamassassin-users
Subject:    Re: OT: DCC installation
From:       RW <rwmaillists () googlemail ! com>
Date:       2016-10-29 13:50:37
Message-ID: 20161029145037.1487003d () gumby ! homeunix ! com
[Download RAW message or body]

On Thu, 27 Oct 2016 13:54:27 -0700
mrobti@insiberia.net wrote:

> On 2016-10-25 05:59, RW wrote:
> > On Tue, 25 Oct 2016 06:25:18 +0000
> > mrobti@insiberia.net wrote:
> >   
> >> Hi everyone,
> >> 
> >> Is there any up-to-date howto available for DCC installation for
> >> use with SpamAssassin?  
> > 
> > Nothing will have changed.  
> 
> If nothing else has changed, many systems are now using systemd.  And 
> maybe the howtos and mailing list posts were not very detailed in the 
> first place, but I find there are plenty of unanswered questions,
> such as:
> 
> * Do MX servers and submission clients need to be listed in whiteclnt 
> when DCC is used in SpamAssassin or is that unnecessary?

DCC is a test for bulk mail, rather than spam. The original point was to
treat bulk mail as spam by default, and that needs a lot of
whitelisting. DCC is a fairly minor part of SA with a low score, and
there are better places to do whitelisting IMO.

I think the paid service requires some whitelisting so you don't end-up
reporting your own servers as spam sources.

> * I've never seen a DCC howto that sets up the recommended cron job
> that calls /var/dcc/libexec/cron-dccd so is it for some reason
> redundant? Or is everyone's DCC logs and DCC databases continually
> building up, never being cleaned?

You don't need to run dccd which is what creates the databases on the
server side. Trimming the log files is simple. 

>  And how about the cron that grabs
> standard "empty" messages to
> whitelist: /var/dcc/libexec/fetch-testmsg-whitelist -- the suggested
> cron for both these is here:
> https://www.dcc-servers.net/dcc/dcc-tree/misc/crontab

That fetches a file that was last updated in 2007.

>  but you don't get the benefit from systemd monitoring and
> auto-restarting:

If the daemon terminates, SA just switches to using dccproc. According
to the dccproc documentation moderate use of dccproc causes a dccifd
daemon to be started; SA should then switch to the new daemon.

[prev in list] [next in list] [prev in thread] [next in thread]