Category: planet

Spamassassin Newsletter
Spamassassin Sysadmins may be interested in the announce-only Spamassassin Newsletter. You will receive notifications roughly twice a month summarizing everything new at Rarely you might receive warnings when emergency configuration changes are recommended. Past reasons have been like, “Old DNSBL has gone dead and now blacklists everyone.”

DNSBL Safety Report 1/23/2011

UPDATE: See the latest DNSBL Safety Report for current recommendations. occasionally looks at the results of Spamassassin’s nightly masscheck at RuleQA in order to analyze the performance and safety of add-on DNSBL’s. It is vitally important to know how a DNSBL is performing before deciding if it is a good idea to use it.  Many of the below DNSBL’s were tested because they indicated strong performance in other comparisons. Our analysis demonstrates that raw detection numbers can be misleading, as ham safety ratings and overlaps with other rules must be taken into consideration.

Today’s report examines Hostkarma, SpamEatingMonkey, Tiopan, UCEProtect, Mailspike, and Nix Spam and Lashback UBL.  Recommended scores below are what I personally use in production.

Spamassassin 3.2.x is Unsupported

Upstream has not made any official announcement yet, but it is apparent that continuing to use spamassassin 3.2.x is a bad idea and you should really upgrade to 3.3.x.  Why?

  • Rule updates for 3.2.x effectively stopped late 2008.  The last time an update was pushed was January 1st, 2010 only for the year 2010 bug.
  • Thousands of other bugs were fixed, and 3.3.x has far more effective rules than 3.2.x. 3.3.x continues to receive regular rule updates via its sa-update channel.
  • There is no intent upstream to fix serious problems like RCVD_ILLEGAL_IP in spamassassin-3.2.x.

RHEL5/CentOS5 users may be interested in the custom RPM’s that I personally use on production servers. These builds are essentially identical to the RHEL6 version, but built and tested on RHEL5.

If you are forced to use Spamassassin 3.2.x for some reason, then here are all custom rules that I recommend for your  Please be sure that you have run sa-update at least once to get the last official rule updates.

# Disable Broken Rules
score    RCVD_ILLEGAL_IP 0

# approved DNSBL's
header   RCVD_IN_PSBL eval:check_rbl('psbl-lastexternal', '')
describe RCVD_IN_PSBL Received via a relay in PSBL
score    RCVD_IN_PSBL 2.3
header   RCVD_IN_MSPIKE_BL eval:check_rbl('mspike-lastexternal', '')
score    RCVD_IN_MSPIKE_BL 2.1

DNSWL – Please List your Mail Server

If you operate a legitimate mail server, please file a request to have your IP address listed at If your buddy’s MTA IP address is not listed, suggest that they get themselves listed.  DNSWL is useful for multiple purposes like:

  • Spamassassin adds a negative score if the sending IP address is listed in DNSWL. This can be both good and bad in different ways, but recent measures indicate that it makes almost no difference to spamassassin’s determination. This is because spamassassin is carefully balanced, and DNSWL is rarely wrong.  If you do see cases where DNSWL is wrong, please report it.
  • Some major servers use DNSWL as a means to avoid greylisting for “known good” IP addresses. This eliminates delays during delivery of mail from your server.
  • Some DNSBL’s use DNSWL as additional input in their reputation decision.  Not exactly a “stay out of DNSBL” pass but it does help, assuming you really are not sending spam.

Usage Limits of Spamassassin Network Tests

UPDATED: 1/8/2011

This article describes free usage limits of network test providers used by Spamassassin, along with recommendations if they are worthwhile to pay for service for sites large enough where a data feed is necessary. Recommendations are based upon statistical data in Spamassassin’s weekly masscheck as collected at RuleQA.

It is important for Spamassassin sysadmins to know the limits and usage restrictions of the various network test providers. If those providers deem that you are abusing their service they might choose to silently block your IP address. This can cause significant problems like mail delivery slowdown as Spamassassin waits until DNS timeout during each mail scan, along with test failure which can cripple your spam filter.

Subscribe to announce-only newsletters targeted at Spamassassin Sysadmins.

DNSBL Safety Report 1/2/2011

UPDATE: See the latest DNSBL Safety Report for current recommendations.

This blog will occasionally look at the weekly DNSBL masscheck statistics.  Our measures indicate that the performance and safety of the smaller DNSBL’s can vary wildly from month to month.  If you depend on DNSBL’s, you should pay attention to these safety reports in order to protect your users from the likelihood of false positives and losing mail to the spam folder.  This should help you as a SpamAssassin sysadmin to decide which add-on DNSBL’s to use, and what score to assign with the goal of maximizing spam filter safety.

Here is a quick look at the safety and efficacy of a few add-on and existing DNSBL’s for SpamAssassin.  Today’s report looks into Hostkarma, Spam Eating Monkey, Tiopan, MailSpike, NiX Spam and PSBL.

CACHEREDIR Rule: Prevent Google cache redirector abuse

UPDATE: 2/2/2011
Masscheck results indicate spammers have stopped abusing Google cache as a redirector about 3 weeks ago. It appears that previous redirects already in the cache still work, but perhaps Google changed their system to prevent future redirects from getting into their cache.  We’ll continue to keep an eye on this.

UPDATE: 1/6/2011 – now catches more variations

For the past month or more spammers have been abusing Google’s cache as a link redirector.  Normally if a spammer includes links in their message body, it is easy to identify that message as spam because the domain of that URI is listed in the numerous URIBL’s.  But by using Google cache as a redirector they often sneak past the URIBL’s with an overall low score.  Read more for the custom rule syntax and analysis.