Adding spamhaus to virtualmin

It's already in there.

SpamAssassin, by default, checks against the following DNS blacklists, assuming all of the right Perl modules are available (they are on most modern Linux distributions).

DSBL http://dsbl.org/
NAJBL http://www.njabl.org/dynablock.html
RHSBL dnsbl.ahbl.org
SORBS http://www.sorbs.net/
Spamhaus SBL+XBL http://www.spamhaus.org/
SECURITYSAGE blackholes.securitysage.com
SPAMCOP http://www.spamcop.net/

You can increase the importance of them in determining spamminess by adding explicit settings in the local.cf file. The options from 20_dnsbl_tests.cf:

# Spamhaus SBL+XBL, now called Zen
#
# Spamhaus XBL contains both the Abuseat CBL (cbl.abuseat.org) and Blitzed
# OPM (opm.blitzed.org) lists so it's not necessary to query those as well.

header __RCVD_IN_ZEN eval:check_rbl('zen', 'zen.spamhaus.org.')
describe __RCVD_IN_ZEN Received via a relay in Spamhaus Zen
tflags __RCVD_IN_ZEN net

# SBL is the Spamhaus Block List: http://www.spamhaus.org/sbl/
header RCVD_IN_SBL eval:check_rbl_sub('zen', '127.0.0.2')
describe RCVD_IN_SBL Received via a relay in Spamhaus SBL
tflags RCVD_IN_SBL net
#reuse RCVD_IN_SBL

# XBL is the Exploits Block List: http://www.spamhaus.org/xbl/
header RCVD_IN_XBL eval:check_rbl('zen-lastexternal', 'zen.spamhaus.org.', '127.0.0.[45678]')
describe RCVD_IN_XBL Received via a relay in Spamhaus XBL
tflags RCVD_IN_XBL net
#reuse RCVD_IN_XBL

Which means that to make presence in the SpamHaus SBL a near death sentence for a message (not recommended...any DNSBL can have false positives) add:

score RCVD_IN_SBL 5.0

To /etc/mail/spamassassin/local.cf (or wherever your local.cf lives).

But, as I said, it's already being used, and it's probably already getting a sane value.

If you're getting a bunch of spam with our current configuration, something is probably broken in the configuration and spam filtering isn't working at all. SpamAssassin 3.x is pretty damned good (we were getting a lot of complaints about spam a while back, and so folks were campaigning for lots of additional spam related stuff, but when I dug down to find out what was happening, SA wasn't being run at all!).

Ok, so it's being run. Is procmail delivering it anyway? Check /etc/procmailrc...do you have these two lines at the end:

:0
$DEFAULT

If so, delete those two lines.

I dunno. It's probably worth looking at the messages that get through to see what SpamAssassin thinks about them. Look at the X-Spam- headers for clues about which tests are coming back true, and see how much they're each worth. Maybe crank those particular tests up a bit.

If you're on a particularly old OS (one that has pre-3.x SpamAssassin), it may just be that your SpamAssassin is long in the tooth. We don't replace SA, so older systems will have older versions of SA. SA gets better with every revision, but we're finding that the 3.2.3 version we have on Virtualmin.com is solid, even with no training. I get almost no spam. Maybe one every couple of days.

Modern versions of SA also have Bayesian filtering, and can be trained with salearn. Usermin has a "Report as Spam" button, if you have this command, which uses this command to train the SA bayesian filter. (Note that, as far as I know, you can't use the daemon mode of SpamAssassin--the spamc command in Virtualmin--if you want to use bayesian filtering features, as the bayesian rules are per user.)