false positives

Vernon Schryver vjs@calcite.rhyolite.com
Tue Nov 1 03:45:12 UTC 2005

> From: Jeff Mincy <mincy@rcn.com>

> So a single misconfigured dcc client can send in many count can
> cause dcc servers to return many for that checksum?  Yuck.  

Why do you persist that?  By now you must know whether bulk mail
has a count of 100, 1000, or "many" is immaterial.

What makes you think that the SourceForge newsletters you're worried
about are not spam?  How do you know that someone hasn't been signed
up involuntarily?  Most important, why do you care whether SourceForge
newsletters are tagged as being sent to 1000 or 1,000,000 targets?

>                                                             Which
> configuration option controls this behavior?

A sendmail alias, .procmailrc file, or anything else equivalent a pipe
sending mail to `dccproc -tmany`.

> Sure.  spamtrap email addresses that are not used for newsletters
> can clearly report without querying.  SpamAssassin users can report spam after
> first classifying messages into spam and ham piles, or can report
> after making sure that all newsletters are properly whitelisted.
> SpamAssassin users should not be reporting messages that they
> consider to be ham.  

You've been told repeatedly that reporting newsletters as bulk mail
is no worse than redundant.  So why do you persist?

(Separately, delaying reporting of spam until a human can get involved
would be a bad idea because of the delay.  I think a major feature
of the DCC is that it starts rejecting a spew of spam within 10s
of seconds after it starts.)

> What is worse?  A freeloader who doesn't report or a misconfigured
> user reporting legitimate bulk email?

Obviously not reporting, unless you insist that the DCC is the unworkable
idea that was Vipul's Razor.  I said when Vipul's Razor was announced
(after I was already testing the DCC) that it was fundamentally flawed,
because any group of more than several dozen people will include plenty
of confused people who do the wrong things innocently and a few evil
doers who do wrong intentionally.  There are 40,000 to 60,000 DCC
installations.  It would be silly to expect none of those installations
to be doing anything wrong, such as reporting as "many" bulk mail that
you consider legitimate.

> I suggest making two changes to the installation instructions
>    http://www.rhyolite.com/anti-spam/dcc/dcc-tree/INSTALL.html

>    If you ignored the 'Whitelist Legitimate Bulk Email' step please
>    add -Q to dcc_options so that you do not report your legitimate
>    bulk email such as newsletters for other SpamAssassin users who
>    also ignored the whitelist step with the following:
>         dcc_options -Q -R

That would be wrong for several reasons.  One is that it would not affect
your complaint about your Sourceforge newsletters being tagged as "many".

> Also, I suggest that the default value for 'dcc_options' in SpamAssassin
> change to include the -Q switch.  The documentation for 'dcc_options'
> should recommend removing the -Q switch after verifying that external
> subscriptions are properly whitelisted in the whiteclnt configuration
> file.  If you agree with this I can put in the request with SpamAssassin
> list.

If that change to SpamAssassin were made, I would be duty bound to
try to find a way to disable default SpamAssassin uses of the DCC,
because they would be pure parasites.  They would be consuming the
bandwidth, CPU cycles, and (worst) human system administration time
of the operators of the public DCC servers without contributing
anything.  They would be worse than the spam appliance vendors who
take and resell that system administration time.

PLEASE do everyone a favor and just stop using both the DCC.  At least
stop trying to sabotage it.  It's been doing all of these terrible
things including accepting reports SpamAssassin and letting newsletters
(including from CERT) be marked "many" for several years without your
"help."  Please start something that conforms to how you think things
should work.  Besides fixing what you think are the major bugs in DCC
reporting, you could distribute your easy to maintain whitelists.  Or
perhaps your wonderful replacement for the DCC would not need whitelists.

Vernon Schryver    vjs@rhyolite.com

More information about the DCC mailing list

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