DCC client issues

Eric Chenard echenard@uottawa.ca
Wed Apr 14 19:04:27 UTC 2010


On Wed, 2010-04-14 at 18:36 +0000, Vernon Schryver wrote:
> > From: Eric Chenard 
> 
> > I noticed that some messages don't contain the DCC headers as though the
> > dcc tests where not done. I know it works in general because I do see
> > messages with the headers and the score and all, but some, usually from
> > a mass mailout, are not. It also seem to happen the day after I
> > restarted the dcc clients, which I usually never have to do. Does anyone
> > know why that would happen?
> 
> In connection with work some people are doing on the SpamAssassin plugin
> for DCC Reptuations, I finally broke and looked closely at the plugin.
> Inevitably (which is why I avoided looking all these years), I have
> a bunch changes that might get into an official SpamAssassin release.
> 
That sounds like a good idea. I think all users of a DCC+spamassassin
solution would certainly benefit from that. Thanks!

> I found a raft of modest problems including one might be relevant.  If
> you are using dccproc instead of dccifd, you pass enough email through
> dccproc to cause it to start dccifd, and you kill dccifd without giving
> dccifd a chance to delete its socket (perhaps with a system reboot),
> then an orphan /var/dcc/dccifd socket might be created.  That will cause
> current version of DCC.pm to presistently try to use dccifd but fail.
> The socket will not be fixed until something somehow starts dccifd.
> 
> 
Actually I'm using dccifd not dccproc. Is it possible the dccifd process
gets overwhelmed and stops responding and so amavis just gives up on the
DCC check?

> The big change in my version of DCC.pm is something I've been asking
> someone, anyone to write forever.  It is to automatically report
> mail that the general SpamAssassin scoring declares "spam" to DCC.
> That should increase DCC effectiveness.
> 
> Note that mechanism is not likely to cause false positives.  Reporting
> non-bulk mail to DCC does no harm except to bloat the global DCC database.
> Reporting bulk mail to DCC is a good thing even when it seems bad.  You
> must whitelist any bulk mail you want to receive or at least use a
> scoring scheme such as SpamAssassin, because someone somewhere will
> report bulk mail you want to DCC with a count of "many".  Those reports
> are usually mistaken, but if the bulk mail really matters, you should
> prepare for malice.  Until someone complained about CERT advisories
> with DCC target counts of "many", I used that CERT advisories as 
> an hypothetical example.
> 
> To see the results of that mechanism, I've changed the DCC graphs at
> http://www.dcc-servers.net/dcc/graphs/?resol=1m&BIG=1 as well as the
> graphs for individual DCC servers that are visible to their operators.
> The yellow areas and lines reflect mail caught by spam traps, manually
> reported by `spamassassin -r`, or otherwise sent to the global DCC
> database with a target count of "many."  I've always had that data, but
> until now did not capture or graph it.  The new graphs surprised me
> with how little spam is hitting traps compared (yellow) to the number
> of messages with "many" targets (pink).
> 
One thing I can say about that is that if the spam filters are on a
separate host than your mail servers, you will only have data for the
trapped messages that are on the mail filter hosts, not the mail
servers. In other words, some places have mail filters on their mxers
and simply tag spam (it might drop high scoring spam) and pass them on
to the mail server where the users might control what is spam for them.


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

-- 
Eric Chenard                  
Systems Analyst / Postmaster
IT Collaboration - Infrastructure Services - CCS
University of Ottawa





More information about the DCC mailing list

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