(In reply to comment #0)
> 72_scores.cf:score KHOP_SC_CIDR16                        2.200 1.291 2.200
> 1.291
> 72_scores.cf:score KHOP_SC_CIDR24                        2.649 1.198 2.649
> 1.198
> 72_scores.cf:score KHOP_SC_TOP200                        4.000 3.944 4.000
> 3.944
> 72_scores.cf:score KHOP_SC_TOP_CIDR16                    2.797 0.728 2.797
> 0.728
> 72_scores.cf:score KHOP_SC_TOP_CIDR24                    0.001 0.000 0.001
> 0.000
> 72_scores.cf:score KHOP_SC_TOP_CIDR8                     2.200 0.001 2.200
> 0.001
> 
> it looks like all the other SC rules (scores) take into account 'net', so that
> if you have the ip already in spamcop (you have to be in spam cop to be in sc
> anyway), the other rules seem to take that into account.
> 
> however, if (again, if you are in top200, you ARE in spamcop), so with rbls's
> enabled, and net enabled, anything that is in sc_200 will score 5.3 points:
> 4 points for being in sc_top200, 1.3 points for being in spamcop itself.
> 
> this will put it over the top for (99%?) of all SA installations.
> 
> suggest manual tweaks on score for 'net' scores, lower by the spamcop bl score.


IMO, depending on the kind of traffic you have, its safest to disable these rules completely. (worked for me)

This is pretty much a duplicate of bug 6114. Still open, mind you, so it almost feels like these rules shouldn't have been published yet.

Oh, and the last update of 20_khop_sc_bug_6114.cf with respect to this issue appears to be more than 2 months old!  Adam?

(In reply to comment #2)
> This is pretty much a duplicate of bug 6114. Still open, mind you, so it
> almost feels like these rules shouldn't have been published yet.

I didn't know those were out of my sandbox.  ALL khop-sc rules are marked nopublish.

(In reply to comment #3)
> Oh, and the last update of 20_khop_sc_bug_6114.cf with respect to this issue
> appears to be more than 2 months old!  Adam?

Well crap.  Until last night, I was stalled on figuring out how to automate checkins from my channel to svn.  I gave up on security and stored my password in cleartext on my system, relying upon the system's physical security instead.

khop-sc-neighbors is now synced daily nightly with svn (the channel itself updates every four hours).


(In reply to comment #0)
> 72_scores.cf:score KHOP_SC_CIDR16        2.200 1.291 2.200 1.291
> 72_scores.cf:score KHOP_SC_CIDR24        2.649 1.198 2.649 1.198
> 72_scores.cf:score KHOP_SC_TOP200        4.000 3.944 4.000 3.944
> 72_scores.cf:score KHOP_SC_TOP_CIDR16    2.797 0.728 2.797 0.728
> 72_scores.cf:score KHOP_SC_TOP_CIDR24    0.001 0.000 0.001 0.000
> 72_scores.cf:score KHOP_SC_TOP_CIDR8     2.200 0.001 2.200 0.001

First, this was not published in 3.3.0 or 3.3.1 and has not migrated anywhere on the 3.3 branch, so it will miss 3.3.2 as well.  This affects only the trunk, which is where the above quote originates.

Second, those scores are out of control.  The GA is supposed to notice the overlap with RCVD_IN_BL_SPAMCOP_NET, which KHOP_SC_TOP200 overlaps completely.  The fact that it compensated for anything BUT the top200 is laughable, and the score on top-cidr24 is baffling (if scored that low, why was it promoted in the first place?).


Scoring notes to come tomorrow, I've got to run for now.

Here is how the rules are currently scored on my khop-sc-neighbors channel.  This ensures that the rules do next to nothing when run with net checks, but come back up (and then some) for net checks that lack DNSEval support (which is to say, the DNSBLs).

score    KHOP_SC_CIDR8      0.1 0.01 0.1 0.01
score    KHOP_SC_TOP_CIDR8   0.9 0.1 0.9 0.1
score    KHOP_SC_CIDR16      1.6 0.5 1.6 0.5
score    KHOP_SC_TOP_CIDR16  2.0 0.5 2.0 0.5
score    KHOP_SC_CIDR24      2.5 0.6 2.5 0.6
score    KHOP_SC_TOP_CIDR24  2.7 0.6 2.7 0.6
score    KHOP_SC_TOP200       4   0   4   0    # unnecessary if DNSBLs work

# Bump these up to compensate for expected but absent overlap (94+% noted)
if (! plugin(Mail::SpamAssassin::Plugin::DNSEval) )
  score  KHOP_SC_CIDR8      (0) (0.1) (0) (0.2) # BRBL(98%)
  score  KHOP_SC_TOP_CIDR8  (0) (0.9) (0) (0.9) # BRBL(98%)
  score  KHOP_SC_CIDR16     (0) (1.5) (0) (1.5) # BRBL(99%), PBL(98%)
  score  KHOP_SC_TOP_CIDR16 (0) (1.7) (0) (1.7) # BRBL(99%), PBL(94%)
  score  KHOP_SC_CIDR24     (0) (1.9) (0) (1.9) # SC(99) BRBL(96) ANBREP(96)
  score  KHOP_SC_TOP_CIDR24 (0) (2.1) (0) (2.1) # MSPIKE(99) SC(98) ...
                            # BRBL(97) PSBL(97) HOSTKARMA(97)
  score  KHOP_SC_TOP200     (0) (4.4) (0) (4.4) # SC(99) PSBL(99) ...
                            # HOSTKARMA(99) SEMBLACK(99) BRBL(98) ANBREP(94)
endif


It's nice to see what the GA has to say about these rules, but I would never take the resulting scores if DNSBLs are accessible.

At the moment, BRBL=1.644/1.449, PSBL=2.7, SC=SPAMCOP=1.246/1.347, and PBL=3.558/3.335.  This overlap puts almost all (>96%) of the KHOP_SC_TOP200 hits at 5.590/5.349 *before* the 3.944 is added by the GA's score for this rule, and 9.534/9.440 total.  Though it does have a 1.000 S/O and these /are/ the worst offenders, I think this rule is best left absent from DNSEval-enabled net checks.

A CIDR8 is often out of the relevant network administrator's control.  For this reason, we CANNOT score CIDR8 rules high.  I've got the lesser at near-nothing and the top at 0.9.  CIDR8s aside, my scoring is wholly more conservative than the GA.


(In reply to comment #2)
> This is pretty much a duplicate of bug 6114. Still open, mind you, so it
> almost feels like these rules shouldn't have been published yet.

I just closed that bug since it was mostly about getting the rules into a sandbox for testing and I now have access to do that and a script that syncs nightly.

Hey, I just thought of a way to handle this.  Would it be possible to disable these scores entirely if network rules are enabled, and only enable if network is disabled?  That would eliminate the overlap and make these rules useful.

(In reply to comment #6)
> Hey, I just thought of a way to handle this.  Would it be possible to disable
> these scores entirely if network rules are enabled, and only enable if network
> is disabled?  That would eliminate the overlap and make these rules useful.

KHOP_SC_TOP200 and KHOP_SPAMHAUS_DROP* use this to zero their score on net+DNSEval runs.  I believe the overlap from the other rules is beneficial.

As noted in comment #5, this overlap is intentional and is scored very low on net runs.  When run without net support, it is scored higher.  When using the net rules but DNSEval is disabled, it is also scored higher.

I have adjusted the channel's scores given the current performance from 
http://ruleqa.spamassassin.org/20110226-r1074804-n?srcpath=khop_sc_.  I also lessened the weight of some of the rules.  Spamhaus DROP actually earned more weight due to its surprisingly low average spam scores (it had been zeroed).

score    KHOP_SC_CIDR8         0.3 0.1 0.3 0.1
score    KHOP_SC_TOP_CIDR8     0.2 0   0.2 0
score    KHOP_SC_CIDR16        1.0 0.2 1.0 0.2
score    KHOP_SC_TOP_CIDR16    2.0 0.3 2.0 0.4
score    KHOP_SC_CIDR24        0.1 0   0.1 0
score    KHOP_SC_TOP_CIDR24    2.7 0.5 2.7 0.5
score    KHOP_SC_TOP200        4   0   4   0      # unnecessary if DNSBLs work
score    KHOP_SPAMHAUS_DROP    1   0.2 1   0.2
score    KHOP_SPAMHAUS_DROP_LE 2   0   2   0      # adds to KHOP_SPAMHAUS_DROP
score    KHOP_PSBL_CIDR24      2   0.6 2   0.6
if (! plugin(Mail::SpamAssassin::Plugin::DNSEval) )
  score  KHOP_SC_CIDR8      (0) (0.2) (0) (0.2) # BRBL(98%)
  score  KHOP_SC_TOP_CIDR8  (0) (0.9) (0) (0.9) # BRBL(98%)
  score  KHOP_SC_CIDR16     (0) (1.5) (0) (1.5) # BRBL(99%), PBL(98%)
  score  KHOP_SC_TOP_CIDR16 (0) (1.7) (0) (1.7) # BRBL(99%), PBL(94%)
  score  KHOP_SC_CIDR24     (0) (0.9) (0) (0.9) # SC(99) BRBL(96) MSPIKE(96)
  score  KHOP_SC_TOP_CIDR24 (0) (2.5) (0) (2.5) # MSPIKE(99) SC(98) BRBL(97) ...
  score  KHOP_SC_TOP200     (0) (4.4) (0) (4.4) # SC(99) PSBL(99) ...
  score  KHOP_SPAMHAUS_DROP (0) (3)   (0) (3)   # SBL(93)
  score  KHOP_PSBL_CIDR24   (0) (1.5) (0) (1.5) # BRBL(98) XBL(95)
endif


I believe my response to this bug early last year was sufficient to close it.  These rules exist in SVN with regular updates purely for vetting purposes since SpamAssassin currently lacks a mechanism to automatically publish timely updates.  Anybody looking to use these rules should subscribe to my sa-update channel, which will pull daily+ updates to these CIDR regexps.

Any remaining issue with these rules accidentally getting published is a bug related to the "nopublish" tflag rather than with this rule set.