DCC clients changing Subject header survey

Brandon Long blong@fiction.net
Thu Sep 26 16:27:07 UTC 2002

I'm not sure I like '-t many' as an automated system.  In fact, the more
I use dcc, the more I'm not liking the -t many part.  I know the correct
answer is to whitelist, but I'm starting to have to check mail that is
marked "many" because of several incorrectly marked messages (including
one from the ACLU, of all places).  I know that with the correct
architecture it would be hard, but it would be nice to be able to
opt-out and get the "real" count.  Yes, someone could "game" the system
to artifically raise the number on a message, but if I wanted a communal
spam filter, I would have chosen razor.  Having worked with many opt-in
mailing lists before, I can guaruntee that a large enough audience is
going to include people who don't remember opt'ing in, or are too lazy
to get off the list, and they're going to start marking things as spam.
Or administrators who turn old accounts into spam traps.  The weekly
United E-Fare notices are currently being marked as spam, for instance.
(I had them white listed, but apparently the distribution method

Is it possible for dcc to keep track of both?  That something was marked
as spam and the actual bulk count?  Does anyone use the -t to specify a
count other than many?


On 09/26/02 Vernon Schryver uttered the following other thing:
> > From: Craig Hughes <craig@deersoft.com>
> > SpamAssassin just prefixes the subject (with *****SPAM*****, or a 
> > user-configurable string), and that seems to work for just about 
> > everyone.  Pretty much all MUAs which provide any rules functionality 
> > at all will allow you to search for a particular word or string within 
> > the subject line, or at the very least beginning the subject line.
> So are you recommending that I add an option to add a prefix to
> the Subject line?  I guess such an option might as well take a
> string instead of be a boolean.  The biggest problem is finding an
> unused option character for common to dccm and dccproc.
> By the way, it would be cool if
>   - SpamAssassin could invoke `dccproc` with "-t many" if the score of
>    everything else is higher than some (existing?) threshold.  That
>    could significantly improve the effectiveness of SpamAssassin+DCC
>    particularly when using a private DCC server.  It would let users
>    share determinations of spamishness.
>   - the SpamAssassin instructions could recommend looking for an
>    "X-DCC-.*-Metrics:.*bulk" header instead of running dccproc in
>     configurations where the header is present.  This matters because
>     while running dccproc is not too slow, every bit helps.
> How fast is SpamAssassin?  I was told yesterday that checking a message
> with SpamAssassin needs 1 or a small number of seconds.  Is that true?
> It is consistent with something I've observed on a couple of the public
> DCC servers named by dcc.dcc-servers.net.  There are 86400 seconds in
> a day, and none of the clients using the DCC servers with SpamAssassin
> are handling more than 40,000 or 50,000 mail messages/day.  (Some
> outfits with the DCC wired to their MTAs and their own DCC servers
> are doing a lot more than 100K messags/day/MTA.)
> If that is speed is accurate, it might be best, when possible, for
> organziations to use the DCC in the MTA with fairly high bulk
> thresholds and then SpamAssassin for whacking the remaining spam.
> Vernon Schryver    vjs@rhyolite.com
> _______________________________________________
> DCC mailing list      DCC@rhyolite.com
> http://www.rhyolite.com/mailman/listinfo/dcc

 The code was willing,
 It considered your request,
 But the chips were weak.
   -- Barry L. Brumitt                     http://www.fiction.net/blong

More information about the DCC mailing list

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