- Death
- Taxes
- Spam
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.
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6220
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, SpamTips.org 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.
DANGER: __PILL_PRICE 100% CPU loop
UPDATE 3/21/2011: sa-update has disabled these problematic rules.
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6558
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.
Spamassassin Newsletter
https://admin.fedoraproject.org/mailman/listinfo/spamassassin-news
Spamassassin Sysadmins may be interested in the announce-only Spamassassin Newsletter. You will receive notifications roughly twice a month summarizing everything new at SpamTips.org. 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.”
SMF_BRACKETS_TO Rule
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 score SMF_BRACKETS_TO 1.5
Rule FSL_RU_URL is dangerous
https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6533
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 local.cf.
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 local.cf. It is not recommended though.
DNSBL Safety Report 1/23/2011
UPDATE: See the latest DNSBL Safety Report for current recommendations.
SpamTips.org 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 local.cf. 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 # SpamTips.org approved DNSBL's
header RCVD_IN_PSBL eval:check_rbl('psbl-lastexternal', 'psbl.surriel.com.')
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', 'mailspike.net.')
score RCVD_IN_MSPIKE_BL 2.1
Disable rfc-ignorant.org Rules
rfc-ignorant.org 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 local.cf then restart your spamd score __RFC_IGNORANT_ENVFROM 0 score DNS_FROM_RFC_DSN 0 score DNS_FROM_RFC_BOGUSMX 0 score __DNS_FROM_RFC_POST 0 score __DNS_FROM_RFC_ABUSE 0 score __DNS_FROM_RFC_WHOIS 0
DNSWL – Please List your Mail Server
If you operate a legitimate mail server, please file a request to have your IP address listed at DNSWL.org. 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.
