Monday, August 1, 2011

Chart: Spam Sending IP Addresses over Time

Passive Spam Block List or PSBL is a real-time trap-based DNSBL operated by Red Hat kernel engineer Rik van Riel.  It uses the Open Source Spamikaze in order to build and deploy an IP-based blacklist of spam sending offenders.  PSBL is one of the safest DNSBL's, and has been default in Spamassassin as of version 3.3.0 released in early 2010.

PSBL receives millions of spam every day, and after taking some safety precautions, it lists the sending IP addresses.  Then various organizations can download that list via rsync or query its public servers via DNS.  Accidental listings can be removed at any time through the self-serve interface at  Otherwise, if an IP address does not send spam to PSBL within 2 weeks, then it is expired and no longer blacklisted.

Sunday, July 3, 2011

Why run your own DNS server? (Spamassassin)

If you have a sizable quantity of mail delivery, like greater than 20k messages per day, you are advised to run your own caching DNS server as it benefits your Spamassassin deployment in both speed and reliability.  This article describes why it is important to operate your own local caching DNS resolver, and how to enable it on your server.

Monday, June 27, 2011

SEM rules mistakenly enabled again

UPDATE 6/29/2011: If you run sa-update now, it should pick up 1140482 or later and fix this issue.

Due to a bug in the rule auto-promotion system, SEM rules were again mistakenly pushed to the active rules, causing a flood of unexpected DNS queries to this service provider.  A very similar issue happened back in March 2011.  Upstream spamassassin needs to make an emergency sa-update rule update to correct this situation.  Meanwhile, all spamassassin admins should mitigate this issue by adding the following workaround to their then restarting their spamd.

score T_URIBL_SEM           0
score T_URIBL_SEM_FRESH     0
score T_URIBL_SEM_FRESH_10  0
score T_URIBL_SEM_FRESH_15  0
score T_URIBL_SEM_RED       0

Thursday, June 23, 2011

Apache Spamassassin 3.3.2 Released

Today was the official release of Apache Spamassassin 3.3.2.  The primary purpose of this minor release is to fix compatibility with perl-5.12+, but numerous other bugs were fixed.  I made these RPM's for EL5 and EL6 that I personally have been using in production for weeks.  Fedora 14 and 15 updates should be hitting mirrors shortly.

After you have upgraded your Spamassassin, read the Ultimate Setup Guide to learn how to maximize your Spamassassin deployment effectiveness. Spamassassin sysadmins may be interested in subscribing to this announce-only newsletter where you will occasionally receive important news relevant to your deployment.

Sunday, May 15, 2011

DNSBL Safety Report 5/14/2011 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 adding it to your Spamassassin custom rules.  Our analysis demonstrates that raw detection numbers alone can be misleading, as ham safety ratings and overlaps with other rules must be taken into consideration before you decide to use a particular add-on rule.

Today's report shows some big changes since our previous report from January 2011 where some previously good rules have turned bad.   Examined below are Hostkarma, SpamEatingMonkey, Tiopan, UCEProtect, Mailspike, Nix Spam and Lashback UBL.  Recommended scores below are what I personally use in production.

Wednesday, March 23, 2011

SEM Rules Mistakenly Enabled, How to Disable

UPDATED 3/24/2011:
sa-update rules were reverted to an earlier state to avoid this and other possible surprises.  Bug #6560 has a patch under review to avoid this problem in the future.
Some kind of bug in the auto-promotion backend has mistakenly made active several of the SpamEatingMonkey (SEM) network rules including the SEM DNSBL and URIBL's.  It is a matter of policy that Spamassassin NEVER adds new network rules in stable updates because it can cause significant unexpected problems to server administrators.  Furthermore, strongly recommends against the use of  SEM's DNSBL due to its extremely high overlap with the high scoring PBL.  The Bug #6220 indicates one kind of serious issue that can happen when network rules are mistakenly added to sa-update where they very quickly hit usage limits and the provider causes all queries to become false positive hits.  Read more to learn how to workaround this issue.

Sunday, March 20, 2011


UPDATE 3/21/2011: sa-update has disabled these problematic rules.
It seems some mail is triggering a rare bug in re2c (perl) that can cause spamassassin to get stuck in a 100% loop and cause significant problems for a server.  While this is a very serious problem, it affects only non-default configurations that use sa-compile.  Upstream is working on an emergency sa-update rule push to force disable.  Until then you can workaround this problem in two possible ways below.

Thursday, February 24, 2011

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."

Monday, February 14, 2011


Steve Freegard's new rule SMF_BRACKETS_TO seems pretty effective at catching certain recent spam campaigns, roughly 3% of common spam.  While the majority of this spam is already stopped by DNSBL's, this may add a tiny bit of extra confidence in case an unlisted spammer gets through the network rules unscathed.

header SMF_BRACKETS_TO To:raw =~ /<<[^<>]+>>/
describe SMF_BRACKETS_TO Double-brackets around To header address

Friday, February 4, 2011

Rule FSL_RU_URL is dangerous
This rule was accidentally auto-promoted into the live sa-update rules channel.  It might be very effective against the many .ru URL's common in spam, but it is entirely too prejudiced to be safe as a default rule.  Spamassasin upstream has corrected procedures to prevent an issue like this from happening again, but unfortunately they've been having some temporary problems in pushing a new rule update.  Meanwhile, it might be a good idea to disable this rule in your

score FSL_RU_URL 0
On the other hand, if you really never expect to have legitimate mail with a .ru URL, you may want to explicitly include this prejudiced rule in your  It is not recommended though.

Sunday, January 23, 2011

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.

Friday, January 21, 2011

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

Thursday, January 20, 2011

Disable Rules is helpful to detect 0.000008% of spam, and does slightly more harm than good.  While the effect is negligibly rare, you might as well disable the rule entirely to avoid a useless DNS query per e-mail scanned.
# Add these lines to your then restart your spamd
score DNS_FROM_RFC_DSN          0
score __DNS_FROM_RFC_POST       0
score __DNS_FROM_RFC_ABUSE      0
score __DNS_FROM_RFC_WHOIS      0

Tuesday, January 11, 2011

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.

Saturday, January 8, 2011

DNSBL Safety Report 1/8/2011

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

Here is a quick look at the safety and efficacy of a few DNSBL's for SpamAssassin.  Today's report looks into Hostkarma, Spam Eating Monkey, MailSpike, NiX Spam and PSBL.
NEW: This week's analysis looks closer at safety when taking into consideration overlaps with established rules.  See last week's analysis for more details about the masscheck process used to collect the weekly statistical data in RuleQA.

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.


Apparently AHBL_RHSBL has been performing very poorly, detecting 0.072% spam during the August 2009 rescore masscheck and 0.02% spam in recent masschecks.  This is not worth a DNS query for every mail you scan.  Well, this rule is not harmful, but you may want to disable it if you want a little more efficiency.  Insert this line below into your and restart your spamd daemon.

Sunday, January 2, 2011

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.