DCC client issues

Vernon Schryver vjs@calcite.rhyolite.com
Wed Apr 14 18:36:15 UTC 2010

> 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.

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.

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).

Vernon Schryver    vjs@rhyolite.com

More information about the DCC mailing list

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