Thursday, May 24, 2012

Update: Spam sending IP addresses over time



Update: Data through May 23rd, 2012.
Passive Spam Block List (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.  RCVD_IN_PSBL 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 PSBL.org.  Otherwise, if an IP address does not send spam to PSBL within 2 weeks, then it is expired and no longer blacklisted.

Rik van Riel wrote:
A lot of the variation in PSBL zone size seems to be due to both random variations in spam volume, as well as law enforcement shutting down botnets. Whenever a big botnet has been shut down, spam activity tends to be noticably less than before. I expect email spam is down simply because the spammers have also found alternative ways to spam, eg. click hijacking and sharing of spam material through social media.
This is an update to a similar chart from last year.

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 PSBL.org.  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 local.cf then restarting their spamd.

score T_RCVD_IN_SEMBLACK    0
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 SpamTips.org 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

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

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.

Sunday, March 20, 2011

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.

Thursday, February 24, 2011

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