Home | About Spam | About SpamBouncer | Downloads | Configuration | Reference | Resources
Welcome! | What's New? | Disaster Relief | FAQs | Licensing | Acknowledgments
New production and beta releases of the SpamBouncer are announced here, and a summary of any new features is provided.
Today's release of SpamBouncer 2.2 and 2.3 beta contains huge number of housekeeping updates, probably the single most comprehensive housekeeping update in the history of the program. It also contains a number of bug fixes, but no significant additions to the SpamBouncer code. Because the beta release has now been in use for over four months without a hitch, it has been released into production. The new beta release has no significant differences from the production release as of today, although that will of course change in the coming weeks.
As some of you know, I broke my arm shortly after Christmas. I've been a bit slow at the keyboard, and had to focus my time and energy on the day job and other parts of my life til the arm healed. I don't plan to allow another four month hiatus in the SpamBouncer, however. ;)
Please update, and catch a lot more spam!
Today's release of SpamBouncer 2.1 and 2.2 beta contains a bunch of bug fixes, large and small. There's one new content pattern matching filter, a filter that catches at least some of the spam that uses ASCII art to obfuscate its message. There are no new variables, however -- just a massive cleanup.
In addition, a month's worth of housekeeping updates are in this release. For those new to SpamBouncer, that means that the data files of spam sources and spam havens, phish information, etc. have been updated from the last two days of spam in the SpamBouncer spamtrap. Please update -- you'll catch a lot more spam!
In today's release of SpamBouncer 2.1 and 2.2 beta, a small but annoying bug was fixed that resulted in double "X-SBClass: OK" headers on non-spam email for users with SBDELIVERY=FILE set in their .procmailrc files. Thanks to a long-time SpamBouncer user (who knows who they are) <G> for noticing and reporting it!
In addition, the usual housekeeping updates are in this release. For those new to SpamBouncer, that means that the data files of spam sources and spam havens, phish information, etc. have been updated from the last two days of spam in the SpamBouncer spamtrap. If you updated a couple of days ago, you don't need to update again unless you find the duplicate header annoying, or *really* want to be sure you catch every last bit of spam. Otherwise, enjoy!
Today SpamBouncer 2.1 goes into production, and SpamBouncer 2.2 goes into beta.
Today's release of SpamBouncer 2.1 contains only housekeeping updates and bug fixes, but no new features from last week's SpamBouncer 2.1 beta RC3. It has a number of new features, however, that users of SpamBouncer 2.0 should be aware of:
Users who are upgrading from SpamBouncer 2.0 should refer to the Upgrading page for specific instructions on how to upgrade to SpamBouncer 2.1. Users who are upgrading from versions of SpamBouncer prior to 2.0, and new SpamBouncer users, should do one of the following:
) and want to get up and running quickly without having to read the whole web site, go to theQuick Start page and follow the instructions.If you skipped the instructions for SpamBouncer 2.1, please go back and read them. They all apply to SpamBouncer 2.2 beta.
SpamBouncer 2.2 beta currently has only one significant new feature -- the spamtrap delivery option. If you set the spamtrap delivery option, the SpamBouncer sorts email by a number of criteria, and delivers a copy of each email into the directory (folder) and file for each criterion it matches. This allows you to track the spam sent to your spamtraps. The SpamBouncer development team uses this feature to sort out spam that the SpamBouncer misses, or caught using less powerful generic filters, so that they can update the SpamBouncer. <G> Others may want to use it to identify specific spammers that can be blocked at the router, or to prepare a "case" against a particular spammer to get that spammer terminated by his ISP or (if appropriate) prosecuted by law enforcement, or for other reasons.
The spamtrap delivery feature is designed to work with Analyze mode (SBCONFIG=ANALYZE), and only on spamtrap collection accounts -- accounts that should receive no legitimate email whatsoever. You should not attempt to set up a spamtrap account on a busy production server: Analyze mode is CPU intensive and even a small spamtrap collection account receives hundreds or thousands of spams a day. See the spamtrap entry on the SpamBouncer Delivery web page for more information.
The spamtrap delivery code is definitely beta code. If you use it, please send bug reports to bugs@spambouncer.org. The feature will change and expand considerably over the next few weeks and months.
SpamBouncer 2.1 beta RC3 has several bug fixes and a thorough update of the spam data files. SpamBouncer 2.1 beta RC2 had a bug that caused the SBDELIVERY=FILE directive to fail, and behave as if you'd set SBDELIVERY=FILTER at the top of your .procmailrc file. This build fixes that bug, and a couple of minor bugs as well.
If you haven't upgraded to SpamBouncer 2.1 yet, this release should perform like a production release in safety and stability. If (as I expect) it does, you should see SpamBouncer 2.1 in production shortly. <fingers crossed>
In this release, SpamBouncer 2.0 has only a few data file updates. This will be the final update for SpamBouncer 2.0 before SpamBouncer 2.1 goes into production.
SpamBouncer 2.1 beta RC2 (yeah, I know I sort-of promised I wouldn't string out the release candidates. Sorry.) contains serveral code changes that improve its ability to catch some tricky kinds of spam, changes I wanted to include in the 2.1 release. It also contains a number of new identified spammers and a huge number of housekeeping updates and minor bug fixes.
If you haven't upgraded to SpamBouncer 2.1 yet, this release should perform like a production release in safety and stability. If (as I expect) it does, you should see SpamBouncer 2.1 in production in another week. <fingers crossed>
In this release, SpamBouncer 2.0 has some data file updates and a few bug fixes. SpamBouncer 2.1 beta is now a release candidate -- this release represents the first and (I hope) only release candidate that will be necessary before it goes into release. <G> It contains a massive number of data file updates and lots of bug fixes. It also contains code changes that make it run faster and better. If you've been waiting to upgrade to SpamBouncer 2.1, now is a good time.
The SpamBouncer Hurricane Katrina Appeal has been moved to a web page of its own, and expanded. It appears that the aftereffects of this disaster will be with us for months, at very least. In addition, there are a whole lot of needs and many things people can do to help meet those needs. You don't have to have a lot of spare income to make a difference!
Several of you reported a "file missing" error in SpamBouncer 2.0 that was related to bits of SpamBouncer 2.1 code that I didn't get removed from the SpamBouncer 2.0 release yesterday. My apologies. This stuff did no harm -- the "missing" file wasn't supposed to be there and the call to it was pointless. But I just posted a fix of SpamBouncer 2.0 only.
Users of SpamBouncer 2.1 -- not to worry. This doesn't affect you. :)
Today's updates to SpamBouncer 2.0 and 2.1 beta include bug fixes to repair the LOCALHOSTCHECKING functions and Habeas Safelist whitelisting. I also added the option of whitelisting non-confirmed opt-in email from the Habeas Safelist for users who want to do so. To do that, you set HABEASVERIFIED=OI in the variables section at the top of your .procmailrc file. (This mirrors the support levels available with the IADB and Bonded Sender whitelists.) AS always, by default the SpamBouncer whitelists only confirmed opt-in email, so this change will affect only those users who explicitly choose it.
The Habeas Blacklist is no longer being actively maintained by Habeas and support for it has been removed from the SpamBouncer. If you have been using it, when you get around to it, you should remove any HABEASINFRINGERS settings from the variables section at the top of your .procmailrc file.
In addition, a number of housekeeping updates have been done, including new recipes for new viruses, updates to the spam sources and spam haven lists, etc.
In SpamBouncer 2.1 beta, a whole lot of files have been moved around and some have been renamed. This should not affect the functionality of the program, but as usual you should install SpamBouncer 2.1 beta in a new/clean directory rather than on top of an existing SpamBouncer installation.
Today's updates to SpamBouncer 2.0 and 2.1 beta consist of the usual housekeeping, including recipes for several new, fast-moving viruses and trojans, and a bunch of bug fixes. In particular, I moved a code change I made to SpamBouncer 2.1 beta some time ago into SpamBouncer 2.0 because it became clear that the change not only improves performance, but prevents crashes.
SpamBouncer 2.0 has a number of file name changes. These do not represent changes in the type of content or functions of the files. I changed those filenames because I wanted to be able to update the data portions of SpamBouncer 2.0 as easily as possible from the development version of the SpamBouncer. (Yeah, lazy -- I admit it.)
In SpamBouncer 2.1 beta, there are also a number of file additions and name changes. These changes are more substantive; they represent new data and improved filtering. There are two new variables available -- the IPRDNSCHECKING variable, which enables/disables filtering for email from servers that HELO with an IP instead of a valid FQDN, and the NORDNSCHECKING variable, which enables/disables filtering for email from servers that have no rDNS at all. Both are set to yes by default. The IP rDNS check leads to occasional false positives, so if you don't want to block email from those servers, you should set IPRDNSCHECKING=no in the variables section of your .procmailrc file. If your local mail server does not check the rDNS of sending servers, the "No rDNS" check will lead to substantial false positives, so if this describes your server, you should set NORDNSCHECKING=no in the variables section of your .procmailrc file.
NOTE: Both SpamBouncer 2.0 and SpamBouncer 2.1 beta have a number of renamed files in this release, so you should install it in a new/empty directory instead of on top of an existing installation.
In addition, the Standalone Scripts page has a new section for data files from the SpamBouncer. The files currently posted there contain the following:
I posted these files for the use of other spam fighters who don't use SpamBouncer or even Procmail, but who could use the data they contain. Updated files will be posted at least as often as the SpamBouncer is updated, so if you are relying on this data for anything important, please plan to keep current!
Today's SpamBouncer releases are to patch a fairly serious problem in both the beta and production release. One version of the Mitglieder.EO worm is causing Procmail hangs in previous versions of SpamBouncer due to some strange formatting. These hangs eat up a lot of CPU time and slow email processing significantly. Everyone should update ASAP.
This update also contains the usual number of housekeeping updates, including recipes for several new, fast-moving viruses. Even if you didn't notice any Procmail hangs, you'll like what this release does for your spam detection rates. 
SpamBouncer 2.1 beta has some additional structural changes. Since filenames have changed, you should install this version in a new/empty directory instead of over an existing version.
Both of today's SpamBouncer releases contain a bunch of housekeeping updates, including new virus recipes, new identified spammer recipes, additional spam source and spam haven data, and additional pattern matching filters to catch some annoying new spam that isn't easily caught by other means.
SpamBouncer 2.1 has a new variable, the LOCALHOSTCHECKING variable, that controls how the SpamBouncer searches your .localhostfile. It has two valid values, RELAXED and STRICT. The default value, RELAXED, tells the SpamBouncer to allow you to list domains in the .localhostfile instead of just the FQDNs of your mail servers, and to treat any IP within the same /24 as a listed IP as local. This makes the .localhostfile easier to configure, at the cost of possibly allowing spam from within your domain or IP block. The other value, STRICT, causes the SpamBouncer to work as it has since the 2.0 release, requiring that you list exact FQDNs and IPs of your mail servers.
In addition, SpamBouncer 2.1 beta has continued to undergo structural changes. A number of functions have been rewritten to improve accuracy and speed. Various data files have been converted from the relatively slow Procmail recipes used in previous versions to text data files that can be searched more quickly. Since filenames have changed, you should install this version in a new/empty directory instead of over an existing version.
Today's releases of SpamBouncer 2.0 and SpamBouncer 2.1 beta contain the following:
In addition, a number of new encrypted viruses have been added to the Dangerous Content filters. Since encrypted viruses cannot be caught using a straight, zero-false-positive match on the virus itself, they are caught using a normal header and message body pattern match that is somewhat more prone to false positives. For this reason, emails caught using a normal pattern match are treated as "probable viruses", classified as Dangerous, and put in the SPAMFOLDER instead of the VIRUSFOLDER.
Fortunately, none of the bugs affected more than a small number of users, and none had a major effect on the SpamBouncer's ability to do its job.You download the new releases from the appropriate Downloads web page. Please send copies of missed spam to spamtrap@spambouncer.org, and bug reports to bugs@spambouncer.org. See the SpamBouncer bug reports web page for more information on reporting bugs, false positives, and missed spam, and making whitelist requests.
Today's version of SpamBouncer 2.0 has only the changes discussed above. It does not have any modifications that require changes to your configuration.
In addition to the updates listed above, which apply to both versions of the SpamBouncer, today's beta version changes include the following:
In coming weeks, the *-ips.rc files in the ${SBDIR}/data directory will be replaced with CIDR-format text files. This will make the data files much easier to maintain, and allow other changes to the SpamBouncer that should improve its execution speed considerably.
NOTE: Today's release of SpamBouncer 2.1 beta has a number of structural changes, and more such changes are coming in the next few weeks. For that reason, I recommend that SpamBouncer beta users make a habit of performing a "fresh install" each time by creating a new, empty directory and unpacking the SpamBouncer archive there. Then, rename the old SpamBouncer directory to a backup name. Finally, rename the new directory to the name set in your SBDIR
Today's releases of SpamBouncer 2.0 and SpamBouncer 2.1 beta contain several new virus recipes, updates to a number of specific spammers, a fix to a small bug in the logging feature (it won't have affected most of you), and a week's worth of housekeeping updates. Since spammers rarely take holidays off, I wanted you to have time to update before the holiday weekend, when I fully expect the floodgates to open. <wry grin>
You download the new releases from the appropriate Downloads web page.
Today's releases of SpamBouncer 2.0 and SpamBouncer 2.1 beta contain two more new virus recipes, an update to an aggressive and prolific SpamHaus ROKSO-listed spammer (Brian Haberstroh/Atriks), and a couple of days of housekeeping updates. I have a sneaking suspicion that Haberstroh is planning a busy weekend, hence the quick update.
Today's releases of SpamBouncer 2.0 and SpamBouncer 2.1 beta contain two new virus recipes, one for the wildly prolific new Mytob-GB variant that appears to be filling up mailboxes all over. (I should have known better than to post a major release yesterday, on midsummer day.) <wry grin> In addition, they contain today's housekeeping updates. You download the new releases from the appropriate Downloads web page.
The new standalone email virus, drop-box email, and spam haven phones recipes have also been updated. These will be updated automatically whenever that recipe is updated in the current SpamBouncer release.
SpamBouncer 2.0 goes into production, and SpamBouncer 2.1 goes into beta, today. Thank you for your patience as we went through what probably is the world's record for number of release candidates. In addition, the new SpamBouncer web site goes live. Since most of you have been poking through the alpha version of this web site for months, I won't describe how to navigate it in general.
New users who are sick of spam and want to get the SpamBouncer up and running in minimum time in a safe, conservative configuration should check out the new Quick Start page for instructions. Long-time SpamBouncer users who haven't really been paying attention to the changes over the previous year should read the Configuration page, and probably browse the rest of the site as well.
NOTE: (SB 2.1) The preceding note appears at the beginning of any discussion of a SpamBouncer 2.1 beta feature in the new web site.
Today's update to SpamBouncer 2.0 has no new functionality, but has an enormous number of housekeeping updates and a few minor bug fixes since the last release of SpamBouncer 2.0 beta RC8. Please update; you will catch more spam.
SpamBouncer 2.1 officially goes into beta testing today. At present, it is similar to SpamBouncer 2.0, but contains two additional features that the SpamBouncer development team has been playing with for some months:
If you have a SpamCop reporting account, you can enable reports through it instead of through the generic SpamBouncer quick reporting feature. To enable reporting through your personal SpamCop reporting account, you must set the SPAMCOPEMAIL variable to the email address you already use for SpamCop reporting. Then, you can either set SPAMCOPREPORT=NORMAL or, if you want to submit both normal reports and quick reports, SPAMCOPREPORT=MIXED.
NOTE: Eventually, SpamBouncer will support direct spam reporting to a wide range of subscribers. Keep an eye on the beta announcements for this. :)
To enable the URIBL black list, set URIBLCHECK=yes in the variables section of your .procmailrc file. To enable the URIBL grey list, set URIBLGREYCHECK=yes. To enable the URIBL red list, set URIBLREDCHECK=yes.
NOTE: Read the URIBL web page before you enable these blocklists so that you understand what these blocklists contain and what the risks are in enabling each one.