false positives

Jeff Mincy mincy@rcn.com
Tue Nov 1 01:59:15 UTC 2005

On Mon, 31 Oct 2005, vjs@calcite.rhyolite.com wrote:

>> From: Jeff Mincy 
>> > I think that it mistaken.  The simplest DCC+SpamAssassin installation
>> > will not have reasonable dccifd or dccproc thresholds like 10, 20, 50,
>> > or even 500.  The default DCC client thresholds are "never".
>> SpamAssassin defaults to using 999999 when checking the X-DCC header
>> and interprets 'many' to be 999999 and ok to be 0 when comparing.
> Yes, as I tried to say.  See also the SpamAssassin code (not just
> documentation) that looks for "bulk" in X-DCC headers.
>>   X-DCC-wuwien-Metrics: telesterion.delphioutpost.com 1290; Body=0 Fuz1=many Fuz2=many
>> The Fuz1=many Fuz2=many triggers the DCC_CHECK rule in SpamAssassin.
>> I am using -Q (Only query instead of reporting and then querying), so
>> I have not reported the message.  That header means that 'many' other
>> people have reported receiving this message?
> While it could be that more than 16 million people received that
> message, it is more likely that one or more recipients arranged to
> report its checksums to DCC servers with local recipient counts of
> "many".  Those responable have probably misconfigured their DCC clients.
> An original design goal of the DCC is to not worry about such problems.
> Because it is impossible to keep anonymous bad guys or the merely
> momentarily confused from reporting legitimate mail with inflated
> (e.g. "many") counts, all DCC users should view DCC bulk count as
> saying only "this message is bulky."  If you whitelist your solicited
> bulk mail, the incomptence or evil of others in inflating their counts
> does you no harm.  You won't see any inflated counts for private mail,
> unless you need to trim your lists of correspondents.

So a single misconfigured dcc client can send in many count can
cause dcc servers to return many for that checksum?  Yuck.  Which
configuration option controls this behavior?

>> SpamAssassin uses dcc_options to control which options are passed to dccproc.
>> Anybody using dcc in SpamAssassin (use_dcc 1) and has not whitelisted sourceforge
>> or added -Q to dcc_options will report the sourceforge email.
> If everyone used `dccproc -Q`, then all DCC counts would be 0.  Thus,
> those who do not report their incoming mail but only use DCC -Q queries
> could be considered freeloaders.

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.  

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

>> This gets us back to my original statement 
>>    The easiest installation and use of DCC through SpamAssassin will
>>    wind up reporting newsletters and having newsletters tagged by DCC.
> Which gets back to the responses to your initial question.  We said
> that that the DCC is a bulk mail detector and that it is incumbent on
> DCC users to whitelist their legitimate bulk mail.

I suggest making two changes to the installation instructions

First, Split out the whiteclnt steps from Step 5. 'Create Client Configuration Files'
into a new step - "6. Whitelist Legitimate Bulk Email".

Second, To step 11. 'Configure Uses of dccproc' add a paragraph on using
dccproc with SpamAssassin:

 '11. b  If using dccproc with SpamAssassin you need to enable dcc in
      your user_prefs file with 'use_dcc 1' (See 3.1.0 man page Mail::SpamAssassin::Plugin::DCC)

   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

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


More information about the DCC mailing list

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