https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6247
--- Comment #55 from Justin Mason <[email protected]> 2009-12-21 05:19:51 UTC --- (In reply to comment #54) > > rescore masscheck logs with mcsnapshot + today's trunk Scores > > HABEAS, BSP and SSC and DNSWL Disabled > > ========================== > > # SUMMARY for threshold 5.0: > > # Correctly non-spam: 703899 99.93% > > # Correctly spam: 2565063 98.49% > > # False positives: 467 0.07% > > # False negatives: 39257 1.51% > > # TCR(l=50): 41.597904 SpamRecall: 98.493% SpamPrec: 99.982% > > So that means that > > 467-387 > --> 80 > 80/(703899+467) > --> 0.000113577316338381 > > => 0.01135% of hams were rescued from being FPs by the DNSWL rules. > > 41888-39257 > --> 2631 > 2631/(2565063+39257) > --> 0.00101024451680285 > > => 0.101% of spams were, conversely, allowed through by them. actually, I've realised this may be measuring the wrong thing -- since FP% is much lower (by design) than FN%, it's quite likely that we'll see a comparatively high rate of hits against spam, even if the rules are useful. A better way to think about it is in terms of those values compared against the FP%/FN% rates. => 80 hams rescued from the 467 FPs = 17.13% of FPs rescued => 2631 spams added to the 39257 FNs = 6.70% additional FNs when looked at this way, they look more practical. a reliable way to cut the FP rate by 17% is definitely useful, although obviously it'd be nice if the 6.7% additional FNs was reduced. -- Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.
