So, we have the _RBL_ header tag and now the NetCache plugin to attempt
some sort of off-in-the-future real-time network results thing, but
those aren't going to work unless all the corpus mail has those header
modifications headers.

I'm just wondering if those aren't overkill (and it seems to be too much
work for us to implement) and whether we should just modify our code to
suck out rule hits from the X-Spam-Status: header.  Most of our DNSBL
checks are fairly stable in name and we can map the ones that aren't.
If X-Spam-Status: doesn't exist, then do the test at mass-check time.

That part should be easy, the harder part is then not running those
DNS/network queries for weekly checks if not needed, but I'm more
concerned about accuracy than performance at the moment.  I think the
20/20 hindsight of the network tests is the primary reason why the BAYES
scores are so low in the bayes+net score set.

Here's a possible option to add to the rules files:

to reuse:

  reuse <current rule name> [<old rule name>]

to not reuse (for masses/spamassassin/user_prefs)

  reuse <current rule name> 0

For example:

reuse DCC_CHECK
reuse DIGEST_MULTIPLE
reuse DNS_FROM_AHBL_RHSBL
reuse DNS_FROM_RFC_ABUSE
reuse DNS_FROM_RFC_BOGUSMX
reuse DNS_FROM_RFC_DSN
reuse DNS_FROM_RFC_POST
reuse DNS_FROM_RFC_WHOIS
reuse DNS_FROM_SECURITYSAGE
reuse HABEAS_INFRINGER
reuse HABEAS_USER
reuse NO_DNS_FOR_FROM
reuse PYZOR_CHECK
reuse RAZOR2_CF_RANGE_51_100
reuse RAZOR2_CHECK
reuse RCVD_IN_BL_SPAMCOP_NET
reuse RCVD_IN_BSP_OTHER
reuse RCVD_IN_BSP_TRUSTED
reuse RCVD_IN_DSBL
reuse RCVD_IN_NJABL_CGI
reuse RCVD_IN_NJABL_DUL
reuse RCVD_IN_NJABL_MULTI
reuse RCVD_IN_NJABL_PROXY
reuse RCVD_IN_NJABL_RELAY
reuse RCVD_IN_NJABL_SPAM
reuse RCVD_IN_SBL
reuse RCVD_IN_SORBS_BLOCK
reuse RCVD_IN_SORBS_DUL
reuse RCVD_IN_SORBS_HTTP
reuse RCVD_IN_SORBS_MISC
reuse RCVD_IN_SORBS_SMTP
reuse RCVD_IN_SORBS_SOCKS
reuse RCVD_IN_SORBS_SPAM
reuse RCVD_IN_SORBS_WEB
reuse RCVD_IN_SORBS_ZOMBIE
reuse RCVD_IN_WHOIS_INVALID     RCVD_IN_RFC_IPWHOIS
reuse RCVD_IN_XBL
reuse ROUND_THE_WORLD

-- 
Daniel Quinlan
http://www.pathname.com/~quinlan/

Reply via email to