The SpamBouncer
Version 1.9
(12/10/2004: FINAL UPDATE BEFORE 2.0 RELEASE)
Version 2.0 beta, RC8
(5/27/2005)

If you are still running SpamBouncer 1.9, and have not upgraded to SpamBouncer 2.0 yet, please plan to do so soon! :)
Please also read "What's New" for new version information. New users should run with SPAMREPLY and BLOCKREPLY set to SILENT for a week or so until they are sure the program is installed correctly and isn't catching legitimate email. Beta version users should check the Beta Version comments at the top of the SpamBouncer program file when installing a new beta version.
Copyright © 1996-2005 by Catherine A. Hampton. If you abide by the Free Software Foundation's COPYING principles with this document and the spam software and forms, you're home free, but don't try to copyright it yourself or sell this information.

Contents


What's New with the SpamBouncer?

5/27/05


This is an update to the current SpamBouncer beta, release candidate 8, only. It contains a substantial number of housekeeping updates and a couple of very minor bug fixes.

Get more information about the beta version on the SpamBouncer 2.0 What's New page, and download new beta versions from the SpamBouncer Beta versions download page. Users of SpamBouncer 1.9 that are ready upgrade to SpamBouncer 2.0 should read the Upgrading instructions and follow them carefully. All SpamBouncer 2.0 users should review the new configuration instructions and make any appropriate modifications to their .procmailrc files.

 

5/16/05


This is an update to the current SpamBouncer beta, release candidate 8, only. It contains protection against the current German Nationalist/NAZI spam run (probably a second spam run by the makers of the SOBER virus), a number of bug fixes and substantial housekeeping updates.

Get more information about the beta version on the SpamBouncer 2.0 What's New page, and download new beta versions from the SpamBouncer Beta versions download page. Users of SpamBouncer 1.9 that are ready upgrade to SpamBouncer 2.0 should read the Upgrading instructions and follow them carefully. All SpamBouncer 2.0 users should review the new configuration instructions and make any appropriate modifications to their .procmailrc files.

 

4/20/05


This is an update to the current SpamBouncer beta, release candidate 7, only. It contains a few minor bug fixes and some fairly substantial housekeeping updates.

Get more information about the beta version on the SpamBouncer 2.0 What's New page, and download new beta versions from the SpamBouncer Beta versions download page. Users of SpamBouncer 1.9 that are ready upgrade to SpamBouncer 2.0 should read the Upgrading instructions and follow them carefully. All SpamBouncer 2.0 users should review the new configuration instructions and make any appropriate modifications to their .procmailrc files.

 

4/10/05


This is an update to the current SpamBouncer beta, release candidate 7, only. It contains some bug fixes and housekeeping updates only.

Get more information about the beta version on the SpamBouncer 2.0 What's New page, and download new beta versions from the SpamBouncer Beta versions download page. Users of SpamBouncer 1.9 that are ready upgrade to SpamBouncer 2.0 should read the Upgrading instructions and follow them carefully. All SpamBouncer 2.0 users should review the new configuration instructions and make any appropriate modifications to their .procmailrc files.

 

4/04/05


This is an update to the current SpamBouncer beta, release candidate 7, only. It contains a number of bug fixes, and one new feature/new variable.

Get more information about the beta version on the SpamBouncer 2.0 What's New page, and download new beta versions from the SpamBouncer Beta versions download page. Users of SpamBouncer 1.9 that are ready upgrade to SpamBouncer 2.0 should read the Upgrading instructions and follow them carefully. All SpamBouncer 2.0 users should review the new configuration instructions and make any appropriate modifications to their .procmailrc files.

 

3/02/05


This is an update to the current SpamBouncer beta, release candidate 6, only. It contains a bug fix affecting the NOBOUNCE and GLOBALNOBOUNCE features, and a number of housekeeping updates.

Get more information about the beta version on the SpamBouncer 2.0 What's New page, and download new beta versions from the SpamBouncer Beta versions download page. Users of SpamBouncer 1.9 that are ready upgrade to SpamBouncer 2.0 should read the Upgrading instructions and follow them carefully. All SpamBouncer 2.0 users should review the new configuration instructions and make any appropriate modifications to their .procmailrc files.

 

2/28/05


This is an update to the current SpamBouncer beta, release candidate 6, only. It contains a small bug fix and a significant chunk of housekeeping updates. (A spammer moved; the SpamBouncer needed to keep up.) <G>

Get more information about the beta version on the SpamBouncer 2.0 What's New page, and download new beta versions from the SpamBouncer Beta versions download page. Users of SpamBouncer 1.9 that are ready upgrade to SpamBouncer 2.0 should read the Upgrading instructions and follow them carefully. All SpamBouncer 2.0 users should review the new configuration instructions and make any appropriate modifications to their .procmailrc files.

 

2/25/05


This is an update to the current SpamBouncer beta, release candidate 6, only. It contains a number of bug fixes for users with Sun servers running SunOS and Solaris, a new variable that usres can set to control how it handles spam from otherwise legitimate companies, and housekeeping updates. It should be stable, and should catch lots of spam.

Get more information about the beta version on the SpamBouncer 2.0 What's New page, and download new beta versions from the SpamBouncer Beta versions download page. Users of SpamBouncer 1.9 that are ready upgrade to SpamBouncer 2.0 should read the Upgrading instructions and follow them carefully. All SpamBouncer 2.0 users should review the new configuration instructions and make any appropriate modifications to their .procmailrc files.

 

1/31/05


This is an update to the current SpamBouncer beta, release candidate 5, only. It contains numbr of bug fixes for users with Sun servers running SunOS and Solaris, and housekeeping updates. It should be stable, and should catch lots of spam.

Get more information about the beta version on the SpamBouncer 2.0 What's New page, and download new beta versions from the SpamBouncer Beta versions download page. Users of SpamBouncer 1.9 that are ready upgrade to SpamBouncer 2.0 should read the Upgrading instructions and follow them carefully.

 

1/19/05


This is an update to the current SpamBouncer beta, release candidate 4, only. It contains a major bug fix for users with Sun servers running SunOS and Solaris, a minor bug fix for users who have been having trouble with an overly aggressive "Forged HELO" filter, and housekeeping updates. It should be stable, and should catch lots of spam.

Get more information about the beta version on the SpamBouncer 2.0 What's New page, and download new beta versions from the SpamBouncer Beta versions download page. Users of SpamBouncer 1.9 that are ready upgrade to SpamBouncer 2.0 should read the Upgrading instructions and follow them carefully.

 

1/15/05


This is an update to the current SpamBouncer beta, release candidate 3, only. It contains two large bug fixes, several minor bug fixes and housekeeping update. It should be stable, and should catch lots of spam.

Get more information about the beta version on the SpamBouncer 2.0 What's New page, and download new beta versions from the SpamBouncer Beta versions download page. Users of SpamBouncer 1.9 that are ready upgrade to SpamBouncer 2.0 should read the Upgrading instructions and follow them carefully.

 

12/23/04


This is an update to the current SpamBouncer beta, release candidate 2, only. It contains minor bug fixes and a bunch of new spam data. It should be stable, and should catch lots of spam.

Check out the beta version of the SpamBouncer 2.0 web page for information on the update. Users that are ready upgrade to SpamBouncer 2.0 should read the Upgrading instructions and follow them carefully. You can download the new versions from the SpamBouncer Beta versions download page.

Merry Christmas! :)

 

12/10/04


This is probably the final update for SpamBouncer 1.9, before SpamBouncer 2.0 is relesed into production. It contains updates to the basic small fry, haven domains, and other lists, but little else.

I recommend that everyone, not just SpamBouncer 2.0 beta users, check out the beta version of the SpamBouncer 2.0 web page for information on that version. Users that are ready upgrade to SpamBouncer 2.0 should read the Upgrading instructions and follow them carefully. You can download the new versions from the SpamBouncer Beta versions download page.

 

11/23/04


There are a couple of fairly prolific new worms in the wild -- a LovGate variant and a Sober variant -- so I am posting an update to the SpamBouncer prior to the long holiday weekend. In addition to the updates to the virus recipes, there are the usual updates to the spam domains and spam IP lists.

SpamBouncer 2.0 beta users should check out the alpha version of the SpamBouncer 2.0 web page for additional information on that version. Users that want to upgrade from SpamBouncer 1.9 to SpamBouncer 2.0 should read the Upgrading instructions and follow them carefully. You can download the new versions from the SpamBouncer Beta versions download page.

 

11/18/04


Today's update includes a large number of new haven domains and spam sources, and should significantly improve the amount of spam caught.

SpamBouncer 2.0 beta users should check out the alpha version of the SpamBouncer 2.0 web page for additional information on that version. Users that want to upgrade from SpamBouncer 1.9 to SpamBouncer 2.0 should read the Upgrading instructions and follow them carefully. You can download the new versions from the SpamBouncer Beta versions download page.

 

10/29/04


Today's update is a housekeeping update, the primary purpose of which is to add a couple of virus filters to deal with two fast-moving new variants of the Bagle/Beagle virus family. In addition to updating the SpamBouncer, please update your antivirus software, especially if you use any version of Microsoft Windows on any computer you own!

SpamBouncer 2.0 beta users should check out the alpha version of the SpamBouncer 2.0 web page for additional information on that version. Users that want to upgrade from SpamBouncer 1.9 to SpamBouncer 2.0 should read the Upgrading instructions and follow them carefully. You can download the new versions from the SpamBouncer Beta versions download page.

 

10/20/04


Today's update is a housekeeping update. Unfortunately I'm in the middle of a major task at the day job and don't have time to make it more, but I wanted to get a few updates to catch some spam that has been flooding out in the last week or so. Spammers adapt to get around filters; filters must adapt too. <sigh>

SpamBouncer 2.0 beta users should read the information about two bugs discovered and semi-fixed in the last month on the What's New page of the SpamBouncer 2.0 alpha web site. Users that want to upgrade from SpamBouncer 1.9 to SpamBouncer 2.0 should also read the Upgrading instructions and follow them carefully. You can download the new versions from the SpamBouncer Beta versions download page.

 

9/23/04


Today's update is a housekeeping update, but a bunch of new spammers showed up last week, so you will want to upgrade to catch their spew.

SpamBouncer 2.0 beta users should check out the new, alpha version of the SpamBouncer 2.0 web page. Users that want to upgrade from SpamBouncer 1.9 to SpamBouncer 2.0 should read the Upgrading instructions and follow them carefully.

 

9/16/04


A DNS list that the SpamBouncer checked to verify the region certain emails came from has been experiencing problems. That has resulted in the SpamBouncer foolishly waiting for responses and causing delays in delivering email. I got all references to that DNS list out of the SpamBouncer. In the process, I also removed all legacy blocklist code from the SpamBouncer 2.0 beta, which should speed it up considerably.

I also took advantage of a lull at work to get a whole bunch of housekeeping updates done to both the 1.9 production version and 2.0 beta version of the SpamBouncer. The 2.0 beta version is due to go into production in October, and is quite stable. If you haven't upgraded yet, you might want to do so -- it is considerably more effective than the production version.

If you are upgrading from any SpamBouncer production release to SpamBouncer 2.0 beta, be sure to read the configuration information and updates for that release before you do so. This web page hasn't been properly updated for the 2.0 beta release because a brand new web site is under development for SpamBouncer 2.0. So please read the "What's New" info for the last few months carefully before upgrading, just so that you get all the new variables set properly.

 

9/02/04


Today the Apache Software Foundation (APF) posted a statement on their position on Microsoft's Sender ID framework for authenticating the source of email. Sender ID is a union of a proprietary system Microsoft authored and the open Sender Policy Framework (SPF) framework authored by Meng Weng Wong, founder of Pobox.com.

Although SPF was not a magic bullet to end spam, I thought it was an excellent idea that attacked one significant part of the spam problem -- forged senders. I planned to support it in the SpamBouncer when I got around to writing the necessary code.

Unfortunately, the APF is right -- the "free license" Microsoft is requiring that all developers accept prior to implementing Sender ID places an unsupportable burden upon any open source project. With considerable reluctance, therefore, I have put my plans to support Sender ID on hold. While I will happily review this decision if Microsoft should agree to the necessary licensing changes, I'm not holding my breath. <wry grin>

If Microsoft does not relent, it is my hope that Meng or someone else will take his original SPF proposal forward, enabling me and others to support that instead.

 

8/20/04


I managed to get a few bugs fixed this week, and updated the lists of haven domains, spam sources, and spam phone numbers. In the 2.0 beta version, I also updated a few of the "identified spammers" lists with some new IPs and domains. This is a "lick and promise" update, but should still be useful. :)

 

8/13/04


The official "Friday the Thirteenth Edition" of the SpamBouncer is here. <G> I had another free block of time, fixed a few more bugs, added a few more haven domains, and updated a few more data files. I also added a fairly prolific new porn spammer to the list of identified spammers in SpamBouncer 2.0. Please update. :)

 

8/12/04


I had a free evening and so fixed a few bugs, added haven domains and updated various data files. One bug I fixed in SpamBouncer 2.0 beta should result in catching a significant chunk of spam that could sneak by earlier. :)

 

7/31/04


Today's update is was a huge housekeeping update intended to get the SpamBouncer into sufficiently good shape that I can work on other things for the month of August and first couple of weeks of September. :) I fixed one small bug in 2.0 beta, as well.

 

7/29/04


Today's update is another "housekeeping" update -- it contains the usual additions to the virus filters, the spam sources, spam haven domains, and other basic filters.

SpamBouncer 2.0 beta's support for the Spam URI Realtime Blocklist (SURBL) has been refined and expanded considerably. The SURBLCHECK variable has been dropped entirely, and five new variables added to enable support for different SURBL lists. All are disabled by default; you must explicitly enable any of those you want to use. The supported SURBLs are:

  • The AbuseButler List. Contains domains and IP addresses collected by Abuse Butler. You enable this list by setting SURBLABCHECK=yes in the variables section of your .procmailrc file.

  • The OutBlaze List. Contains domains and IP addresses collected by the OutBlaze abuse desk. (The OutBlaze abuse department is run by Suresh Ramasubramanian, a spamfighter with an impeccable reputation.) You enable this list by setting SURBLOBCHECK=yes in the variables section of your .procmailrc file.

  • The Phishing List. Contains domains and IP addresses seen in "phishing" spam -- spam that attempts to trick users out of User IDs, passwords, and other critical information needed to access bank accounts or other financial assets. Collected by Mail Security. You enable this list by setting SURBLPHCHECK=yes in the variables section of your .procmailrc file.

  • The SpamCop List. Contains domains and IP addresses collected by SpamCop from their spam corpus. This is not the same data as is found in the SpamCop list itself; it contains domains and IPs from message body URLs instead of email headers. You enable this list by setting SURBLSCCHECK=yes in the variables section of your .procmailrc file.

  • William Stearns' SA-BLACKLIST List. Contains domains and IP addresses collected by William Stearns for his sa-blacklist module for SpamAssassin. You enable this list by setting SURBLWSCHECK=yes in the variables section of your .procmailrc file.

In addition, if you are upgrading from any SpamBouncer production release to SpamBouncer 2.0 beta, be sure to read the configuration information and updates for that release before you do so.

 

7/15/04


Today's update is another big housekeeping update. It contains the usual updates to the virus filters, a couple of thousand new spam haven domains, a number of new spam source IPs and domains, and yet more upgrades to the pattern matching filters.

SpamBouncer 2.0 beta now supports a new blocklist -- the Spam URI Realtime Blocklist (SURBL). This blocklist tests domains and IPs that appear in the message body of spam against a list of domains and IPs that have previously appeared in spam and appear to be advertized via spam. This blocklist is extraordinarily effective in catching spam; it catches approximately one quarter of all spam to the SpamBouncer spamtrap. It also has had a relatively low false positive rate. It is disabled by default because it is so new, but I highly recommend enabling it. To enable SURBL support, set SURBLCHECK=yes in the variables section of your .procmailrc file.

SpamBouncer 2.0 beta also contains a number of new identified spammers. I have moved recipes for spammers that have not sent spam that appeared in the SpamBouncer spamtrap or other sources I check for over six months to a "retired" file. That file remains available, but is checked only if you have SBCONFIG=Analyze or SBCONFIG=Debug in the variables section of your .procmailrc file. I have also fixed several bugs, none particularly serious or widely reported.

If you are upgrading from any SpamBouncer production release to SpamBouncer 2.0 beta, be sure to read the configuration information and updates for that release before you do so.

 

6/28/04


Today's update is mostly a humongous housekeeping update. It contains approximately 2,000 new spam haven domains, several hundred new spam source IPs and domains, and a number of "upgrades" to the pattern matching filters that should make them more effective in catching today's spam.

In addition, SpamBouncer 2.0 beta contains a number of new identified spammers. The recipes for those spammers have been reorganized so that the most prolific spammers are checked for first, which should reduce the load the SpamBouncer puts on your system considerably. There have also been several new bug fixes.

If you are upgrading from any SpamBouncer production release to SpamBouncer 2.0 beta, be sure to read the configuration information and updates for that release before you do so.

 

5/13/04


Today's update is yet another housekeeping update, but it contains a whole lot of housekeeping. It contains approximately 1,000 new spam haven domains, and a couple hundred new spam source IPs and domains, in addition to a bunch of minor bug fixes. I plan to do some major work on 2.0 features in the next couple of weeks, and wanted the program in good shape before I did so.

If you are upgrading from any SpamBouncer production release to SpamBouncer 2.0 beta, be sure to read the configuration information and updates for that release before you do so.

 

4/21/04


Today's update is mostly a housekeeping update. It contains one new feature that users should be aware of -- a filter to filter out emails that contain an attack targeted to a known vulnerability in Microsoft Windows computers running certain versions of Internet Explorer. I call this the "CHM Exploit". The filter blocks email containing urls like this one:

http://000.000.000.000:8888/help.chm::/exploit.html

For 000.000.000.000, substitute an IP number or (possibly) domain name. For exploit.html, substitute any HTML file name containing the actual attack instructions.

Users who want to disable this filter can set CHMEXPLOITCHECKING=no in the variables section of their .procmailrc file.

In addition, this update contains recipes to catch new viruses, new spam sources, spam haven domains, spam phone numbers, and has a number of minor bug fixes. If you are upgrading from any SpamBouncer production release to SpamBouncer 2.0 beta, be sure to read the configuration information and updates for that release before you do so.

 

3/28/04


This update contains a high-priority bug fix (an innocent domain got into the haven domains list). It also contains new spam sources, spam haven domains, spam phone numbers -- the usual housekeeping stuff.

If you are upgrading from any SpamBouncer production release to SpamBouncer 2.0 beta, be sure to read the configuration information and updates for that release before you do so.

 

3/23/04


This update contains a large number of new spam haven domains, and other housekeeping updates to both the production and beta versions. It contains several minor bug fixes.

In addition to the above, the beta version contains preliminary support for the ISIPP's new IADB whitelist. To enable support for the IADB whitelist, simply set IADBCHECK=yes in your .procmailrc. I also removed the WHITELISTLOCAL feature until I have time to debug it thorougly, in April.

If you are upgrading from any SpamBouncer production release to SpamBouncer 2.0 beta, be sure to read the configuration information and updates for that release before you do so.

 

3/02/04


I posted today's update for one purpose -- to get a virus filter for the new and fast-moving Bagle-J virus out there. <wry grin> There are also a day's worth of small bug fixes, new spam sources and new spam havens.

If you are upgrading from any SpamBouncer production release to SpamBouncer 2.0 beta, be sure to read the configuration information and updates for that release before you do so.

 

3/01/04


Today's update contains recipes for the Bagle-D, Bagle-E, Bagle-F, Bagle-H and Newsky-D viruses, and a bunch of new spam source and spam haven domains.

The beta version contains a bug fix to the recipe that extracts IPs from the headers of email, which affected a number of other recipes.

If you are upgrading from any SpamBouncer production release to SpamBouncer 2.0 beta, be sure to read the configuration information and updates for that release before you do so.

 

2/25/04


Today's update contains a recipe for the new, rather rapidly spreading Newsky-C virus.

The beta version also contains a bug fix -- the ALWAYSBLOCK functionality was broken in yesterday's version because of a typo. :)

If you are upgrading from any SpamBouncer production release to SpamBouncer 2.0 beta, be sure to read the configuration information and updates for that release before you do so.

 

2/24/04


Today's update to SpamBouncer 1.9 (production) contains recipes for the Newsky and Mydoom-F viruses, a bunch of additions to the Small Fry (Spam Source) and Haven Domain (Spam Haven) lists, and a few bug fixes.

Today's update to SpamBouncer 2.0 (beta) contains the aforementioned additions and updates. It also contains bug fixes for the following:

  • Shell error when checking LEGITLISTS file. This is a bug that has been in the SpamBouncer since the LEGITLIST capability was added. The fix may also fix perennial problems on a few systems when checking the NOBOUNCE, GLOBALNOBOUNCE, MYEMAIL, and LOCALHOST files in a number of recipes.

  • SBHOST error. In the default setting for the SBHOST variable, I used a flag that many systems don't support and that caused an error message in the Procmail log. On a very few Sun systems running an older version of Solaris, it also could cause the system to go into a loop and use all avilable CPU cycles. That flag has been removed.

If you want to upgrade from a production release to SpamBouncer 2.0 beta, be sure to read the configuration information and updates for that release before you do so.

 

2/17/04


Today's update to SpamBouncer 1.9 (production) contains a bunch of additions to the Small Fry (Spam Source) and Haven Domain (Spam Haven) lists, and a few bug fixes.

Today's update to SpamBouncer 2.0 (beta) contains the aforementioned additions and updates. All remaining pre-2.0 recipes for specific spammers have been converted to 2.0 format. The data files for a number of prolific spammers have also been updated with new IPs, IP ranges, and domains.

In addition, this release contains a new function, the "Whitelist Local" function, that whitelists email sent from users that use an IP or host listed in your LOCALHOSTFILE file. Most users don't get spam from other, local users, although they get spam with local addresses forged into it. This function is not fooled by the forgeries -- it whitelists only email actually sent using a local server and that did not, at any point in its journey to you, leave the local system. To enable whitelisting of email from local users, set WHITELISTLOCAL=yes in the variables section at the top of your .procmailrc file.

If you want to upgrade from a production release to SpamBouncer 2.0 beta, be sure to read the configuration information and updates for that release before you do so.

 

2/11/04


SpamBouncer 1.9 officially enters production with this release, and SpamBouncer 2.0 officially enters beta. At the request of several users, I am making the archives available in three formats: PKZIP archives, Unix .Z archives, and gzip archives. I hope this makes retrieving and using the files easier for many of you.

SpamBouncer 1.9 Production Release Information

SpamBouncer 1.9 has the usual updates for this release -- lots of new Small Fry and Haven Domains, minor bug fixes, etc. Those of you who have been running SpamBouncer 1.8 can install this version on top of your existing SpamBouncer installation. No new configuration is required.

In the 1.9 release, automatic spam complaints are disabled, as they have been for the past few months. They will return with the 2.0 production release.

If you use MH Mail and have not yet tried SpamBouncer 1.9's MH support, you may want to take advantage of it. See the SBDELIVERY entry for instructions on how to configure the SpamBouncer to deliver to MH folders. If your MH Mail rcvstore program is not in the default location, you may also need to set the MHDELIVER variable to the proper value for your system.

SpamBouncer 2.0 Beta Release Information

SpamBouncer 2.0 beta represents a nearly complete rewriting of much of the SpamBouncer's underlying code. The following, in particular, has changed:

  • Rewritten header information extraction routines. The header information extraction routines were rewritten from the ground up.

  • New message body information extraction routines. The SpamBouncer now extracts IPs and hosts from the message body and generates IPs for the hosts in the message bodies of spam.

  • Rewritten code to test for specific spammers. The new code checks extracted header and body information against internal lists of IP ranges and domains that belong to known, prolific spammers. This catches a lot more spam.

  • Rewritten whitelist/blocklist support. The code used to test both DNS-based whitelists and DNS-based blocklists is brand new and considerably more robust. It catches considerably more spam than the old code did. Those of you who have had trouble getting the SpamBouncer's old blocklist support to work on your systems should find that 2.0 works properly.

  • Lots more in the next few months! :) A number of new features are planned for the 2.0 production release that are not currently present, including much greater user control over scoring, SpamBouncer logs, and a rewritten and considerably more useful autocomplaint mechanism.

Much of the configuration process for 2.0 is the same as for 1.9. You should be able to install and use this release without too much difficulty. I recommend following this procedure to upgrade to SpamBouncer 2.0:

  1. Create a new directory for the SpamBouncer 2.0 installation.

    This will prevent old files from becoming mixed in with the new program files.

  1. Retrieve the SpamBouncer 2.0 beta archive of your choice, put it in the new directory, and uncompress it.

    Uncompressing the archive will create new files and also a number of new subdirectories that contain data files and subroutines used by the SpamBouncer, auxiliary files that users might need (such as a sample Procmail configuration file), and documentation (such as there is). :)

    Note: You can safely delete the archive file after you've uncompressed the program files.

  1. Edit your .procmailrc file and add the following variables to the variables section at the top, before you call the SpamBouncer:

    BLOCKLEVEL=5
    SPAMLEVEL=20
    VIRUSFOLDER=/dev/null

    SpamBouncer 2.0 is considerably better at spotting spam from known spammers than earlier versions have been, and the blocklisting code catches a lot more spam as well. Because of this, actual spam usually piles up quite a score. I find that setting the SPAMLEVEL at 20 with this release prevents false positives without significantly increasing the amount of actual spam missed. Your mileage may vary; start with this setting and vary it to meet your needs. There are currently so many viruses pounding email servers that I recommend deleting viruses outright -- unless you have a great deal of hard disk space that you don't need for better things. :)

  1. If you want to see detailed headers on your email, showing exactly why the SpamBouncer classified particular spam as coming from a specific spammer, set the following variable in your .procmailrc file:

    SBHEADERS=COMPLETE

    With headers set to COMPLETE, the SpamBouncer adds detailed (sometimes irritatingly so) headers indicating exactly which server or IP was identified as belonging to a particular spammer. You probably won't want complete headers for long, but it's fun at first and a good idea when you're debugging.

  1. If you do not want the SpamBouncer to treat IP ranges known to host web sites with trojan programs as "dangerous content" that is blocked before referring to any of your whitelists, set the following variable in your .procmailrc file:

    TROJANURLCHECKING=no

    I recommend that users who use Microsoft Windows, and particularly who use Internet Explorer and/or a Microsoft email client, leave this enabled. Users who browse the web and read email on non-Windows computers can safely turn this off, at least at present. (I don't know of any web-hosted trojans that attack Apple Macintosh or Unix computers.)

  1. If you are upgrading from a production release of the SpamBouncer, edit your .procmailrc file to invoke sb-new.rc rather than sb.rc.

    If you are upgrading from a previous beta version, you can skip this step.

  1. Change the name of your current SpamBouncer directory to an old name, such as sb-old.

  1. Change the name of your SpamBouncer 2.0 beta directory to the name of your default SpamBouncer directory.

You are now live with SpamBouncer 2.0. If you use this beta version, in particular, I need bug reports! Spam that this version misses should be forwarded to spamtrap@spambouncer.org, as always. Bug reports and questions should be sent directly to me at ariel@spambouncer.org.

NOTE: The SpamBouncer web page is being rewritten for the 2.0 release, as well. The current web page does not cover 2.0 features, but a beta release of the new web page will be available soon. Meanwhile, feel free to browse the code if you're curious. (I do comment my code.)

 

2/04/04


I'm putting off release of 1.9 into production, and 2.0 into beta, for a few more days. (A couple of beta features need some debugging.) So here's Yet One More Maintenance Release for your enjoyment. Lots of new small fry and haven domains, a few bug fixes, etc. :)

 

1/26/04


I fixed a couple of bugs and did the usual housekeeping updates, but there were a bunch of them. Spammers appear to be a bit desperate to spam lots while they still can. <wry grin>

 

1/19/04


A ton of new spammers appeared over the weekend, so I decided to issue an update and give you the benefit of all the new small fry and haven domains listings. :)

 

1/15/04


This release contains a large number of mostly housekeeping updates, including a number of bug fixes to annoying, although minor, bugs. There are a number of updates to recipes for specific spammers, to the Small Fry and Haven Domains lists, and to other parts of the SpamBouncer. This is in preparation for the pending release of Version 1.9 of the SpamBouncer, due in a couple of weeks.

NOTE: You may have heard of the current spam run that contains forged Habeas SWE headers. Even those of you who enabled Habeas whitelisting won't have seen this spam unless you checked your BLOCKFOLDER or SPAMFOLDER, because the SpamBouncer whitelists only Habeas email that comes from IPs on the Habeas User's List (HUL), not email that contains the Habeas SWE headers but does not come from an IP on that list. You can safely leave Habeas whitelisting enabled during this spam run; the forged headers will not fool the SpamBouncer.

Update to catch more annoying spam. :)

 

Return to Table of Contents

What Does the SpamBouncer Do?

The SpamBouncer is a set of procmail recipes, or instructions, which search the headers and text of your incoming email to see if it meets one or more of the following conditions:

The SpamBouncer sorts suspected spam into three categories -- email sent by a virus, email from known spam sources which is definitely spam, and email which is probably spam, but might also be legitimate. It then tags each email with appropriate headers for the spam classification, and responds according to the parameters you have set.

Depending on how you set it up, it will:

If you get mail from friends who have accounts at a site listed in the SpamBouncer, you can put their names and email addresses in a text file and set the NOBOUNCE variable to point to it. If you want to receive mail from a site I have listed as a spam site, you can add the entire site name to the NOBOUNCE file. The SpamBouncer will check the NOBOUNCE file before filtering your email and will skip any email from a person or site listed in the NOBOUNCE file.

Please note that you can put entire domain names, not just email addresses, in NOBOUNCE. For example, if you want to accept all email from concentric.net without checking for spam, just put concentric.net in your NOBOUNCE file, with no username@ section. This will cause the SpamBouncer to skip all email from anyone at Concentric. (I do not recommend doing this except for small domains which you =KNOW= will not be sources of spam, though.)

What Do I Need to Run the SpamBouncer?

The SpamBouncer itself must run on a Unix server which has the Procmail mail filtering program installed, so only users who have access to a Unix shell account with Procmail installed can use it. This means that AOL users, Earthlink users, Mindspring users, Netcom Netcruiser/Netcomplete users, Compuserve users, Prodigy users, and others who do not have a Unix shell account as part of their service will have to find some other means of filtering spam. Sorry!

It is possible, however, for people who use Eudora, Pegasus Mail, and other POP clients to use the SpamBouncer on their Unix shell accounts to filter their email, and then use their favorite POP mail client to retrieve their filtered mail from the server. If their POP client programs can filter mail by headers, they can filter and delete known spam and probable spam directly into appropriate folders via the SpamBouncer's headers.

This means that anyone running any kind of computer, operating system, and software can use the SpamBouncer, provided they have and use a Unix shell account, and (if they want to use a POP mail program) have software capable of filtering their mail based on user-configurable headers.

If you are totally confused by now, PLEASE find a friend who understands what this means before you try to install the SpamBouncer. While I have made this as user-friendly as I could, using the SpamBouncer requires a certain level of knowledge about computers and the internet. It is not for computer or internet novices.

Return to Table of Contents

Before You Begin...

Because someone who evidently likes the SpamBouncer listed it for me in Yahoo and other search engines <wry grin>, I need to include the following disclaimers and warnings.

First, this is free software. No warranty is provided or implied -- users use the SpamBouncer at their own risk.

I wrote the SpamBouncer originally to filter my own mail, when spam started drowning out the real mail. I originally posted these filters to my web site so that users at my old ISP, Best Internet (long since bought out by Verio), and a few other experienced users could help me test them. I recommend that Procmail neophytes get help from an experienced Procmail user on their system to install the SpamBouncer, and run it in default "Silent Mode" until they are more confident of their skills.

The SpamBouncer is being developed on a Pentium-based server running OpenBSD, and running Procmail 3.15.

In addition to the Pentium-based system where I am developing the SpamBouncer currently, I have developed and tested the earlier versions of it on Linux, FreeBDS, SGI systems running Irix 5.3 and 6.2, SunOS 4.1.3, and Solaris 5.2. I know of no problems running on these systems. A number of users have also run the progrem under various flavors of SunOS, Solaris, HPUX, and other versions of Unix with no trouble.

So please be careful, and keep a close eye on your account for a few days after installing to be sure it works properly.

Return to Table of Contents

Installing the SpamBouncer

Installing Procmail

To use these filters, you will need to have procmail installed on your system, and have set it up for your account. This does not mean you must read mail on your unix account -- if you have a shell account, these filters can be configured to filter mail and then deliver it to your POP mail box. If you don't know what kind of account you have, you probably shouldn't be using these filters until you learn something about Unix and shell accounts.

Since the way Procmail should be installed is different on different systems, if you do not already have Procmail installed, you will need to ask your system administrator or people on your local internet service provider for help. Those who have never used Procmail and want to get started with a simple Procmail setup can jump to Getting Started With Procmail, a tutorial with clear instructions about what information you will need to get from your system administrator to set up Procmail properly on your account, and a basic .procmailrc configuration file which should work well on most systems.

If you are an experienced Procmail user, please make sure that your .procmailrc file is configured to filter out your mailing lists before filtering for spam. The SpamBouncer tries to identify list mail and skip it, but some mailing lists do not use standard list "Precedence:" headers or headers recognisable by Procmail as coming from a daemon or list program. So please be sure you filter out your lists first, especially if you are running with SPAMREPLY set to BOUNCE or COMPLAIN!

In any event, you should always run in SILENT mode for a few days, until you are sure you have your mailing lists filtered out properly and that the filter is working properly on your account.

If you did not use procmail.rc from Getting Started With Procmail, here's a recipe to filter out list mail and other mail from automatic mailer programs, or mailer daemons, as they are usually called on Unix machines. Put it in your .procmailrc file before the INCLUDERC statement that calls the SpamBouncer.

# Filter out Mailing List Mail
:0:
* ^TO(listmom-talk@skylist.com|\
      orthodoxy@lists.best.com|\
      procmail@Informatik.RWTH-Aachen.DE)
$BULKFOLDER

You should substitute all mailing list addresses for mailing lists you receive for the list I gave -- you and I don't read mail from the same lists, at least as far as I know! :)

Return to Table of Contents

Retrieving the SpamBouncer Program Files

After you have installed Procmail for your system, you can install the SpamBouncer. You will need to download the SpamBouncer program files to your Unix account first. You can do this one of two ways -- by downloading them from the links below to your personal computer, or by ftp'ing them. The advantage to ftp is that it ensures that the file format will be right. Often, when you retrieve a text file using a WWW browser and then save it to your hard disk, the browser reformats the file. This type of reformatting can break Procmail configuration files like the SpamBouncer.

Lynx users should note that lynx reformats text files when downloading them via a normal link access command, which will break the SpamBouncer and most other Procmail scripts. If you're a lynx user, please remember to use the "D" command to download the SpamBouncer files instead of just accessing the link, or (even better) ftp the files from the links in the FTP column instead of trying to retrieve them from the http:// links in the WWW/HTTP column.

Via FTP
Via WWW/HTTP

To ftp the SpamBouncer, you must do this:

  1. Log on to your shell account, and type "cd" to be sure you are in your home directory.
  2. Type, "ftp ftp.spambouncer.org", and press <Enter>.
  3. When ftp prompts you to login, type "anonymous", press <Enter>, and then when prompted for your password, type your email address, and press <Enter> again. (This will log you in and take you to the location where the SpamBouncer files are stored.)
  4. Depending on whether you want to download the complete SpamBouncer archive or update an existing installation, you will need to do slightly different things at this point:
    • To retrieve the entire SpamBouncer program archive as a Unix .Z (compress format) file, when your prompt returns, type "binary" and press <Enter>. When your prompt returns, type "get sb.tar.Z" and press <Enter> to retrieve the production version SpamBouncer archive. To retrieve the beta version, type "get sb-new.tar.Z" and press <Enter>.
    • To retrieve the entire SpamBouncer program archive as a Unix .gz (gzip format) file, when your prompt returns, type "binary" and press <Enter>. When your prompt returns, type "get sb.tar.gz" and press <Enter> to retrieve the production version SpamBouncer archive. To retrieve the beta version, type "get sb-new.tar.gz" and press <Enter>.
    • To retrieve the uncompressed individual files to update an existing SpamBouncer installation, when your prompt returns, type "cd sb" (for the production version) or "cd sb-new" for the beat version, and then press <Enter>. When your prompt returns, type "ascii" and press <Enter>. When your prompt returns, type "get filename" to retrieve an individual file, or "mget *" to get all files, and press <Enter> .
  5. When your prompt returns, type "bye" and press <Enter> to end your ftp session.

To download the SpamBouncer via your WWW browser, choose one of the links below and, when your web browser prompts you, save the file to your hard disk. The ZIP archives contain files intended for your PC, while the tar.Z and tar.gz archives contain files intended for your Unix server.

Here are FTP download URLs for the convenience of Lynx users or users of other browsers who are having trouble with file corruption when downloading the SpamBouncer from the standard HTTP urls above. Please use the links below only if the other links don't work for you.

Now, if you saved the SpamBouncer files on your local PC, you will need to ftp or upload them to your unix shell account. They should be put in their own directory.

To unarchive the ZIP format archive, type "unzip spambnc.zip" and press <Enter>. (Your Unix machine may respond with an "unzip: command not found" error message. If it does, you may not have the Unix program unzip, and should retrieve the tar.Z archive.) To unarchive the tar.Z file, type "uncompress spambnc.tar.Z", press <Enter>, and then type "tar -xvf spambnc.tar" and press <Enter> to extract the individual files.

Return to Table of Contents

The SpamBouncer Files and What They're For

The index file of the SpamBouncer, which may be named sb.rc, sb-old.rc or sb-new.rc depending on which version you downloaded, contains the basic script that calls all other files and scripts that comprise the SpamBouncer. The current production version of the SpamBouncer is the one containing sb.rc. The version containing sb-old.rc is the previous production release of the SpamBouncer. The version containing sb-new.rc is the current somewhat stable beta version.

Inexperienced users or users who don't want problems should not use the beta version, and all beta version users need to follow any warnings/instructions listed among the comments at the top of sb-new.rc and in the What's New section.

All other files ending in .rc are subsidiary parts of the SpamBouncer that are called by sb.rc or sb-new.rc.

The freemail file contains a sample text file which you may install and then set your FREEMAIL variable to point to. You do not need to install this file unless you want to customize the list of free email sites -- the SpamBouncer will use its own internal list if it can't find the text file.

The "legitlists" file contains a text file with the names of legitimate email lists (the opt-in variety), which you may getting trapped by the SpamBouncer. Just put each mailing list address on a separate line, just as you would with the NOBOUNCE file.

The other three files contain standardized autoresponder messages for the program. You may customize these to your taste. I do recommend that you leave the references to the SpamBouncer bypass email address in any edited version of the file spam, though, so that people know how to contact me if their mail is getting bounced because of a problem with the filter itself, or how it is installed. That way, I can contact you (hopefully), and prevent further damage.

If you customize the autoresponder messages, you probably will want to keep them reasonably polite. There's no point flaming some poor innocent system administrator at a large ISP just because you're p*ssed at a spamming slimeball. :)

Return to Table of Contents

Where to Put the SpamBouncer

Where you should store the SpamBouncer program files depends on how you are installing the SpamBouncer.

In either case, as you proceed through these instructions and configure the SpamBouncer, you should put the configuration files that you create and will modify somewhere outside of the SpamBouncer program directory. In particular, your .procmailrc file, LEGITLISTS file, LOCALHOSTFILE file, MYEMAIL file, and NOBOUNCE file should all be located outside of the SpamBouncer program directory. That way, when you update the SpamBouncer, you won't overwrite your configuration.

Return to Table of Contents

Configuring the SpamBouncer

The SpamBouncer is a highly configurable program with an often-bewildering number of options. If you are an individual user installing the SpamBouncer, however, you can safely accept the default configuration for many of those options when first installing the program. The default configuration is designed with safety first in mind; even if it catches legitimate email, it will not delete it or autocomplain about it.

Some configuration is required before you start, though, or the SpamBouncer will simply do nothing and pass your email to you unfiltered. In addition, to get the best use out of the SpamBouncer, you will need to understand more about configuring it so that you can enable options that will catch a lot more spam.

In particular, if you are a system administrator who will install and configure the SpamBouncer for unsophisticated users, or users who will have only POP access, you must make sure you understand how the SpamBouncer works before you implement it. The SpamBouncer was designed originally by a Unix geek for Unix geeks to use on Unix shell accounts. :) I have added a number of featurs to make it possible to use the SpamBouncer on a system-wide basis and have users that successfully do this, but I am not a system administrator of a mail server myself. I cannot test various configurations of this type myself as a professional software company would. So please be careful, and give me lots of feedback!

Basic Configuration

There are a few variables that every user must set when first installing the program, and a few more that you will want to set to make the SpamBouncer work in the most efficient manner. All users must first set the following variables in their .procmailrc files:

After you have set the variables above, you should next create four text files: .legitlists, .localhostfile, .myemail, and .nobounce. You can put them in your home directory, where the SpamBouncer looks for them by default, or in any other directory. If you put them in a directory other than your HOME directory, you must set the LEGITLISTS, LOCALHOSTFILE, MYEMAIL, and NOBOUNCE variables to point to the proper location and filename. For example, if you name your NOBOUNCE file my-friends and put it in ${HOME}/configfiles, put the statement NOBOUNCE=${HOME}/configfiles/my-friends in your .procmailrc file.

Each of these text files must be in Unix text format. That means that you must use a text editor to edit them. DO NOT USE a word processing program like Microsoft Word or Microsoft Wordpad! (Windows users should use Windows Notepad, if they do not have another text editor they prefer.) If you edit these files on a Windows- or Macintosh-based computer, you must upload them using ftp in ASCII mode or some other means that will create Unix, not DOS, text files.

In each file, you must include email addresses or domain names, one on each line of the file. Ensure that there are no blank lines in each of these files, and that the last email address or domain name is followed by a carriage return. (That may create what looks like a blank line in some text editors, but it isn't actually a blank line.) To avoid problems on a few older Unix systems, you should ensure that the email addresses you list in these files are entirely in lower case letters.

junkfax-l@trashbusters.org
html-wizards-l@earlham.edu
outback@yahoogroups.com

hrweb.org
spambouncer.org

abuse@hrweb.org
abuse@spambouncer.org
ariel@hrweb.org
ariel@spambouncer.org
postmaster@hrweb.org
postmaster@spambouncer.org
webmaster@hrweb.org
webmaster@spambouncer.org

friend@home.com
anotherfriend@home.com
boss@work.com
coworker@work.com
mom@juno.com
brother@yahoo.com
kid@highschool.kids.us

Next, If you use MH Mail, want to forward email to other email addresses after the SpamBouncer has filtered it, or want to write you must set the SBDELIVERY variable so that the SpamBouncer won't simply deliver your email to a standard Unix flat-file mailbox. If you use MH Mail, set SBDELIVERY=MH in your .procmailrc. If you are configuring the SpamBouncer to filter email for an entire mail server, or want to write your own customized delivery recipes, set SBDELIVERY=FILTER in your .procmailrc.

NOTE: Users who use the SpamBouncer to filter email for their own account, and who use a POP mail program or a Unix-based program such as elm or mutt, do not need to set this variable. The default setting, SBDELIVERY=FILE, is the correct setting for most individual users.

After you have created these files, you should choose one of the following three sections and do what is indicated in that section. The sections are Risk Averse or New Users, Ready to Fight Back, and I HATE SPAM AND WANT IT GONE NOW!. I've tried to make it easy to tell which section you want. :)

You can also check out the Tracking Spam or SpamCop web sites to learn how to complain about spam manually. Manual complaints take time, but are always the best way to get a spammer shut down if you do it right.

Return to Table of Contents

Risk-Averse or New Users

Users who do not want to risk false positives should use this configuration. This is also the configuration you should start with, regardless of what you do after you become comfortable with Unix and the SpamBouncer.

Return to Table of Contents

Ready to Fight Back :)

Users who are willing to accept a low false positive rate, and who want to use the SpamBouncer's autocomplaining features, should set the following variables:

In addition, look through the list of blocklists the SpamBouncer supports and enable those that look interesting. :)

Return to Table of Contents

I HATE SPAM AND WANT IT GONE NOW!

If you feel this way, then you and I obviously have some common ancestors or early environmental influences in common. <grin> Set the following variables if you want to autocomplain aggressively, bounce spam back, and notify users whose mail is blocked by the SpamBouncer, and are willing to check the BLOCKFOLDER frequently for false positives:

In addition, look through the list of blocklists the SpamBouncer supports and enable those that look interesting. Many of them are somewhat redundant, but I find that one often catches what the other does not. For example, the Five-Ten-SG blocklists are much better at catching spam from Asian spammers (such as Chinese spammers) than the other blocklists are, but the NJABL lists are better at catching European spam. The SpamBouncer uses a weighted scoring system with blocklist matches, so you can safely enable more aggressive blocklists if you wish without seeing a significantly higher numbr of false positives.

I prefer to use a lot of blocklists, and when one catches legitimate email, add the sender to my NOBOUNCE file.

Return to Table of Contents

Special Instructions for Users of POP Mail Clients

Users who get their mail using Eudora, Netscape Communicator, Pegasus Mail, or another POP mail client which can filter email by any header will need to set up their filters to look for the following headings:

X-SBClass: Admin
This header indicates mail sent to the ADMINFOLDER. You should create a folder for Admin mail on your client program, and then set your client program's filter to look for this header and filter mail which has it into the Admin folder.

X-SBClass: Blocked
This header indicates mail flagged as probable spam, but not certainly so. Create a folder for Blocked mail and set your client program's filters to put mail with this header into the Blocked Mail folder.

X-SBClass: Bulk
This header indicates mail flagged as bulk mail which is probably legitimate, such as that from known opt-in mailing lists or sent using known legitimate mailing list software, and which passed spam filtering. I recommend creating a separate folder for such mail, though, since that will make it easier to spot personal email, which is usually more important and should get priority.

X-SBClass: OK
This header indicates personal email which passed the spam checks. Set your client program's filters to put this mail in the normal incoming folder.

X-SBClass: Spam
This header indicates mail flagged as definitely spam. Most POP users will simply set the SpamBouncer to delete this mail outright. If you have set the SpamBouncer to deliver it to your POP mail account, though (perhaps because you want to learn more about spam), it will arrive with this header. Create a folder for Spam and set your POP client's program filters to put mail with this header in the Spam folder.

X-SBClass: Virus
This header indicates mail flagged as a virus. POP users should set the SpamBouncer to delete this mail outright.

Users that use Microsoft Outlook or Outlook Express who cannot upgrade to a better email program can set OUTLOOKTAGGING=yes in their .procmailrc file to cause the SpamBouncer to embed the X-SBClass: header in the Subject: header of incoming email if that email is classifed as a virus, as spam, or as blocked. The users can then use Outlook's filters to put all email with embedded X-SBClass: headers into a junk email folder.

Return to Table of Contents

Finishing Your Configuration

After setting the variables in your .procmailrc, add this line to your .procmailrc file at the point where you want to filter your mail for spam:

     INCLUDERC=${SBDIR}/sb.rc

This line should appear after recipes for mail you don't want to filter for spam and before recipes for mail you do want to filter for spam. Users of the sample procmail.rc that comes with the SpamBouncer will have the correct lines in the correct location already, and will just need to uncomment whichever one they want to use.

Return to Table of Contents

A Reference to SpamBouncer Features

This section contains a reference to the blocklists supported by the SpamBouncer, and all the SpamBouncer variables. If you need to know what a particular feature does, or want to look "under the hood" of the SpamBouncer, this section will provide it.

Supported Whitelists

Anti-spam whitelists contain the IP addresses (and, in some cases, the domain names) of the following types of servers:

Accepting email sent from whitelisted servers without further filtering can be a highly effective way to reduce false positives resulting from aggressive blocklists and pattern matching filters. This also reduces load on your mail server and speeds delivery of email.

In addition to the SpamBouncer's internal whitelists, the SpamBouncer supports the Abusive Host Blocking List (AHBL) Exemptions whitelist, the Habeas Whitelist (HWL), the Ironport Systems Bonded Sender (IBS) list, and the Web-O-Trust whitelist. All of these lists are DNS-based whitelists (DNSWLs).

The AHBL Exemptions whitelist contains the IPs of SMTP servers that the operators of the AHBL consider trustworthy. The HWL contains the IPs of SMTP servers that are bound by the Habeas Compliance Standard and associated contract. The IBS contains the IPs of SMTP servers that are part of the Ironport Bonded Sender program. The Web-O-Trust whitelist is unique, in that it contains the IPs of SMTP servers vouched for by those system administrators whom the Web-O-Trust operator considers trustworthy, and the IPs of SMTP servers whom those sysadmins consider trustworthy, and so on.... Read the web site before enabling it to understand what it is and how it works.

Supported Blocklists

Anti-spam blocklists contain the IP addresses (and, in some cases, the domain names) of the following types of servers:

Blocking email sent from blacklisted servers can be a highly effective way to stop spam from reaching your mailbox. In the last year, as the volume of spam on the Internet has surged, the number of blocklists has multiplied, allowing users to choose blocklists whose policies closely match their needs. Blocklists are frequently updated, so a filter that uses them is effectively updated as often as the blocklist is, considerably more frequently than the filter itself is usually updated.

The following is a list of blocklists supported by the SpamBouncer, sorted by category. I explain what type of spam problem each blocklist category addresses, and then list the available blocklists in that category. The name of each blocklist is hyperlinked to the blocklist maintainer's web site, which you can consult for more information about blocklist policies.

Spam Sources. IPs and sites listed as spam sources are persistent sources of spam that have continued to spam for a considerable length of time and despite many efforts to stop them. Many have gone through multiple ISPs, being repeatedly disconnected for breaking their provider's terms of service by spamming. Included in these lists are the SMTP servers used to send spam and the web servers that host web sites advertised by spam. Most of these lists are maintained manually.

One of these blocklists, the SpamHaus blocklist, is enabled by default in the SpamBouncer because it blocks a considerable amount of spam and has a very low false positive rate. Because the most carefully maintained blocklist will make occasional errors, though, the SpamBouncer treats email from all blocklisted servers as suspicious rather than as outright spam, unless that email comes from a server on several blocklists or also meets the SpamBouncer's internal criteria for spam.

Open Relays. Open relays are SMTP servers that accept email from any user on the Internet and deliver it to any other user on the Internet. Properly configured SMTP servers require that either the sender of the email or the recipient be a local user. Spammers LOVE open relays because open relays allow them to avoid spam blocks and deliver more spam, and because some open relays also hide the actual origin of the spam. (The latter are called anonymizing open relays.)

Blocking open relays is inherently aggressive and will block legitimate email along with spam. It is also an extremely effective way to get spam out of your mailbox, however. While no open relay blocklist is enabled by default in the SpamBouncer, I recommend strongly that you enable one or more of them.

Multi-Stage Open Relays/"Smart Hosts". Multi-stage open relays are SMTP servers that are themselves secure; they accept email only from their own users or for their own users. Among their users, however, are SMTP servers that are open relays. This allows a spammer to use a customer site of a multi-stage open relay to send email via that site's SMTP server, increasing the amount of spam he can deliver and further obscuring the origin of his spam.

Blocking email from a multi-stage open relay is inherently risky. Most multi-stage open relays are SMTP servers for large ISPs or companies, and most email they send is legitimate. They have been abused to send large spam runs, however. Blocking email from these relays should reduce the amount of spam you get considerably.

Dynamic IP Ranges. Blocklists of dynamic IP ranges include IP addresses assigned dynamically to dial-up users, and sometimes IP addresses assigned to DSL users and cable modem users. Most of these users are not spammers. Users with this type of connection, however, will rarely (if ever) send email directly from their computer to a recipient's SMTP server. Instead, they send outgoing email via their ISPs SMTP servers.

Spammers, on the other hand, frequently use software that sends email directly from their computer to the recipient's SMTP server, bypassing their own ISP's SMTP server. This allows them to evade security and anti-spamming measures the ISP might have taken. By rejecting email sent directly from a dial-up IP address, you are unlikely to reject legitimate email, but will catch a lot of spam.

The NJABL Dial-Up Spam Sources List is enabled by default. I highly recommend that you use it or another list below; these lists catch a lot of spam.

Insecure Web Forms. These blocklists list the IP addresses of web servers that have insecure web forms or scripts that allow any user to send email to any other user, such as old versions of formmail.pl. Email from such web servers is likely to be spam. While none of these blocklists is enabled by default, I recommend enabling one or more of them.

Open Proxies. An open proxy is a proxy server that accepts anonymous connections from anyone on the Internet. Open proxys are abused by spammers to hide the origin of outgoing spam. None of the open proxy blocklists below is enabled by default, but I recommend that you enable one or more of them.

Other Spam Support. The blocklists below contain the IP addresses of sites that host bulk email servers that don't properly confirm subscriptions, and that have other spam-related problems.

RFC-Ignorant.org. The rfc-ignorant.org blocklists are unique -- they target computer systems and services that do not properly implement the RFCs (the "building blocks" of the Internet), rather than those that send spam. Systems that do not implement the RFCs properly often are misconfigured in other ways and therefore easily abused by spammers. In addition, many of these systems lack any publicly available, valid email addresses that you can use to contact the system administrator when there's a problem.

There are five blocklists on rfc-ignorant.org.

All-In-One Blocklists. The following list is the Swiss Army knives of blocklists -- it contain multiple types of listings. SPEWS is not enabled by default in the SpamBouncer; it is extremely aggressive and, unless you configure your system carefully, you are likely to block legitimate email by using it. I feel that most users will do better using a judicious selection of the other, more narrowly focused blocklists. I personally use SPEWS, however, in addition to other Spam Sources lists, because it often lists a spammer who moved to a new ISP before the other lists do.

A Quick List of Variables and Default Settings

This section contains a quick list of all variables supported by the SpamBouncer, with each with its default setting. A complete list of each variable, a description of what it does, and all available settings, can be found in the following section.

     DEFAULT={NO DEFAULT}
     FORMAIL={NO DEFAULT}
     SBDIR={NO DEFAULT}
     ADMINFOLDER=${DEFAULT}
     AHBLCGICHECK=no
     AHBLDDOSCHECK=no
     AHBLDOMAINCHECK=no
     AHBLEXEMPTCHECK=no
     AHBLPROXYCHECK=no
     AHBLPSSLCHECK=no
     AHBLRELAYCHECK=no
     AHBLSPAMCHECK=no
     ALTFROM=${LOGNAME}@${HOST}
     ALWAYSBLOCK=NONE
     ARABIC=no
     BASE64BLOCK=yes
     BLOCKFOLDER=${DEFAULT}
     BLOCKLEVEL=5
     BLOCKREPLY=SILENT
     BULKFOLDER=${DEFAULT}
     BYPASSWD=syzygy
     CBLCHECK=yes
     CHINESE=no
     CHMEXPLOITCHECKING=yes
     CSLIDCHECKING=yes
     CWHOISBOGONCHECK=no
     CWHOISHIJACKCHECK=no
     CYRILLIC=no
     DATE=date
     DEBUG=no
     DOMAIN=`domainname`
     DORKSLCHECK=no
     DSBLCHECK=no
     DSBLMULTICHECK=no
     DULCHECK=no
     ECHO=echo
     EXECHECKING=yes
     EXEDOCCHECKING=yes
     EXELINKCHECKING=yes
     FILTER=no
     FREEMAIL=INTERNAL
     FREEWEB=yes
     FTSGDIALCHECK=no
     FTSGIGNORECHECK=no
     FTSGMULTICHECK=no
     FTSGOPTOUTCHECK=no
     FTSGOTHERCHECK=no
     FTSGRSSCHECK=no
     FTSGSRCCHECK=no
     FTSGWEBFORMCHECK=no
     GARBLEDCHARSET=yes
     GLOBALNOBOUNCE=NONE
     GREEK=no
     GREP=fgrep
     HABEASINFRINGERS=no
     HABEASVERIFIED=no
     HEBREW=no
     HTMLBLOCK=no
     IBSCHECK=no
     IFRAMECHECKING=yes
     JAPANESE=no
     KOREAN=no
     LANGFILTER=yes
     LEAN=yes
     LEGITLISTS=NONE
     LOCALHOSTFILE=${HOME}/.localhostfile
     MHDELIVER='/usr/lib/mh/rcvstore +'
     MYEMAIL=${HOME}/.myemail
     NJABLCGICHECK=no
     NJABLDULCHECK=yes
     NJABLMULTICHECK=no
     NJABLPROXYCHECK=yes
     NJABLRSSCHECK=no
     NJABLSRCCHECK=no
     NOBOUNCE=${HOME}/.nobounce
     NOLOOP=${ALTFROM}
     NSLOOKUP=nslookup
     NUKEBOUNCES=no
     OPMBLITZEDCHECK=no
     ORDBCHECK=no
     OUTLOOKTAGGING=no
     PATTERNMATCHING=SILENT
     RBLCHECK=no
     RFCABUSECHECK=no
     RFCDSNCHECK=no
     RFCIPWHOISCHECK=no
     RFCPOSTMASTERCHECK=no
     RFCWHOISCHECK=no
     RM=rm
     RSLCHECK=no
     RSSCHECK=no
     RUSSIAN=no
     SBDEBUG=no
     SBDELIVERY=FILE
     SBSHELL='/bin/sh -c'
     SBTEMP=/tmp
     SBTRAP=NONE
     SCRIPTCHECKING=yes
     SED=sed
     SENDMAIL=/usr/sbin/sendmail
     SORBSCGICHECK=no
     SORBSDYNCHECK=no
     SORBSPROXYCHECK=no
     SORBSPROXY2CHECK=no
     SORBSRELAYCHECK=no
     SORBSSOCKSCHECK=no
     SORBSSPAMCHECK=no
     SORBSZOMBIECHECK=no
     SPAMCOPCHECK=no
     SPAMFOLDER=${DEFAULT}
     SPAMHAUSORGCHECK=yes
     SPAMLEVEL=10
     SPAMREPLY=SILENT
     SPEWSCHECK=no
     SPEWSL2CHECK=no
     TEST=test
     THISISP=${HOST}
     TURKISH=no
     VIRUSCHECKING=yes
     VIRUSFOLDER=${SPAMFOLDER}
     WOTCHECK=no
     ZIPCHECKING=no

The variables are shown with the default values which the SpamBouncer will assign if they are not already set in your .procmailrc file. These defaults will prevent problems, but also will cause the SpamBouncer not to do very much. So you want to set the correct variables for your system and account.

A Comprehensive Description of All Variables

This section contains a description of each configuration variable in the SpamBouncer, what it does, and what the valid values for it are. Many of these variables have default settings that will work for the vast majority of users; you should not need to set most of them in your .procmailrc file. If a SpamBouncer feature is not working properly, though, setting the correct variable may fix the problem.

Please note that those variables in red have no defaults and MUST BE SET or the SpamBouncer will simply pass all your mail on to you unfiltered!

DEFAULT
The email inbox to which your system delivers mail by default, or (if you use your shell account to read mail) to which you want your mail delivered by default. If you normally read email using a POP mail program, like Eudora, Internet Explorer, Netscape, or Pegasus mail, ask your system administrator for the name and location of your POP mailbox, and set DEFAULT to that path and file name.

FORMAIL
The full path to your system's copy of formail. If this is not set properly, the SpamBouncer is unable to sort and tag your email, and so will simply pass it on unfiltered to you.

SBDIR
The directory where your SpamBouncer program and auxiliary files are located.

ADMINFOLDER
ADMINFOLDER is for mail from mailer daemons (usually bounced mail -- mail that could not be delivered), and for mail from administrative addresses like root, admin, sysadmin, and abuse. Shell readers will want to set this to an appropriate folder separate from their DEFAULT folder. (I use admin.incoming.) POP mail readers should set this to DEFAULT, and use their POP program's filters to sort it into a separate folder after downloading.

ADMINFOLDER is set to your DEFAULT mailbox by default.

AHBLCGICHECK
If set to yes, tells the SpamBouncer to check the Abusive Hosts Blocking List (AHBL) to see if an IP hosts a web server that contains an insecure formmail script, and block email sent to your system via one of these IP addresses. See the AHBL Formmail List entry for more information about this blocklist and how to use it.

AHBLDDOSCHECK
If set to yes, tells the SpamBouncer to check the Abusive Hosts Blocking List (AHBL) to see if an IP belongs to a computer that is running a trojan program or is virus-infected, and block email sent to your system via one of these IP addresses. See the AHBL Compromised Hosts entry for more information about this blocklist and how to use it.

AHBLDDOSCHECK is set to no by default.

AHBLEXEMPTCHECK
If set to yes, tells the SpamBouncer to check the Abusive Hosts Blocking List (AHBL) to see if an IP belongs to a computer that is running a trojan program or is virus-infected, and block email sent to your system via one of these IP addresses. See the AHBL Exemptions whitelist entry for more information about this whitelist and how to use it.

AHBLEXEMPTCHECK is set to no by default.

AHBLPROXYCHECK
If set to yes, tells the SpamBouncer to check the Abusive Hosts Blocking List (AHBL) to see if an IP belongs to a computer that is running a trojan program or is virus-infected, and block email sent to your system via one of these IP addresses. See the AHBL Open Proxies entry for more information about this blocklist and how to use it.

AHBLPROXYCHECK is set to no by default.

AHBLPSSLCHECK
If set to yes, tells the SpamBouncer to check the Abusive Hosts Blocking List (AHBL) to see if an IP belongs to a computer that is running a trojan program or is virus-infected, and block email sent to your system via one of these IP addresses. See the AHBL Provisional Spam Source Listing entry for more information about this blocklist and how to use it.

AHBLPSSLCHECK is set to no by default.

AHBLRELAYCHECK
If set to yes, tells the SpamBouncer to check the Abusive Hosts Blocking List (AHBL) to see if an IP belongs to a computer that is running a trojan program or is virus-infected, and block email sent to your system via one of these IP addresses. See the AHBL Open Relays entry for more information about this blocklist and how to use it.

AHBLRELAYCHECK is set to no by default.

AHBLSPAMCHECK
If set to yes, tells the SpamBouncer to check the Abusive Hosts Blocking List (AHBL) to see if an IP belongs to a computer that is running a trojan program or is virus-infected, and block email sent to your system via one of these IP addresses. See the AHBL Spam Sources entry for more information about this blocklist and how to use it.

AHBLSPAMCHECK is set to no by default.

ALTFROM
ALTFROM should be set to a valid address that you will use for the notifications, bounces, and complaints sent by the SpamBouncer. It is wise to set this to an email address that you do not use for another purpose, and preferably one that does not forward to your main email address. Some ISPs forward spam complaints to their spamming customers. Spammers often add the addresses of complaining users to a list of known "live" email addresses and sell them to other spammers. Some spammers also retaliate against complainers in various ways. It is best to avoid giving out your usual email address when complaining about spam.

I recommend using an account at a free email site, like Hotmail or Yahoo, for this purpose. You can check it occasionally for responses to your complaints. If it gets on too many spam lists, you can close it and open a new one.

ALTFROM is set to ${USER}@${HOST}.${DOMAIN} by default.

ALWAYSBLOCK
If set to point to a file, tells the SpamBouncer where to find your ALWAYSBLOCK file, a text file of email addresses and domains whose email you want to place in your BLOCKFOLDER without further filtering and without notifying the sender that his email was blocked.

ALWAYSBLOCK is set to NONE by default, and must be explicitly enabled if you want to use it.

WARNING! ALWAYSBLOCK IS DANGEROUS IF MISUSED. If you put a blank line in your ALWAYSBLOCK file, it will match every incoming email it sees. If you put a partial email address or entire domain in your ALWAYSBLOCK file, it may match email that you did not intend to block. The same code is used as with the NOBOUNCE file, and the same precautions apply, except that the consequences of a mistake are greater, especially if your BLOCKFOLDER is set to /dev/null. (I highly recommend against doing that.) Use ALWAYSBLOCK at your own risk -- and be careful!

If you want to keep a local list of email addresses from which you do not want to receive any email, set ALWAYSBLOCK to point to the directory and filename where you keep that file. I suggest naming the file .alwaysblock and keeping it in your home directory. If you do this, put the statement ALWAYSBLOCK=${HOME}/.alwaysblock in your .procmailrc file.

Your ALWAYSBLOCK file (whatever you name it and wherever you put it) should contain one email address per line of text, and nothing else, like this:

     spammer@spamsite.com
     jerk@roguesite.net

Please note that these names and addresses should be in plain text -- don't use Procmail regular expressions or wildcards, and don't try to escape the "." (period) using a "\" (backslash). This will just confuse the SpamBouncer and cause your ALWAYSBLOCK file not to work.

ARABIC
Tells the SpamBouncer what to do with email in Arabic. Set ARABIC=yes if you receive email in Arabic. Otherwise, the SpamBouncer will assume that any email in Arabic is probably spam and put it in the BLOCKFOLDER.

ARABIC is set to no by default.

BASE64BLOCK
Tells the SpamBouncer to negatively score text or HTML email that uses Base64 encoding, and that does not use a character set that requires or benefits from that encoding. Legitimate email in Unicode normally uses Base64 encoding, and email in a number of Asian languages often does as well, so Base64-encoded email that is in Unicode or a Chinese, Japanese, or Korean charset is not scored negatively. Set BASE64BLOCK=no to prevent the SpamBouncer from negatively scoring any email that uses Base64 encoding.

BASE64BLOCK is set to yes by default.

BLOCKFOLDER
Tells the SpamBouncer where to store email that it classifies as probable spam, but not absolutely certain spam. I recommend setting the BLOCKFOLDER to a folder if you read email on your Unix server (such as block.incoming, or leave it set to ${DEFAULT} if you read email via a POP3 client. Users of POP3 clients can set up their local filters to put BLOCKFOLDER email into an appropriate folder in their email program so that it doesn't clutter up their inbox.

Unix users whose clients use MAILDIR (a directory) instead of a folder to store email may set BLOCKFOLDER to a directory rather than a filename. Users with exotic ideas about spam management <grin> may also forward this email to a different address by setting the FILTER variable to yes and then writing the appropriate recipe in their .procmailrc file.

BLOCKFOLDER is set to ${DEFAULT} by default.

BLOCKLEVEL
Tells the SpamBouncer which score to use as the threshold for considering email suspicious. Email that scores at this level or above, but not at the level set for the SPAMLEVEL, is considered suspicious. It receives an X-SBClass: Blocked header, and unless you have FILTER=yes in your .procmailrc, puts that email in the BLOCKFOLDER.

BLOCKLEVEL is set to 5 by default. Increase this score to loosen the SpamBouncer's criteria for considering email suspicious; decrease it to tighten the SpamBouncer's criteria.

BLOCKREPLY
How to handle mail which the filter tags as probable spam, but which may contain some real email as well. Valid values are SILENT, which simply files the mail in the BLOCKFOLDER, and NOTIFY, which sends a notice and copy of the email back to the sender with instructions on how to bypass the SpamBouncer if the email is not spam. Very few spammers will resend their email after receiving such a notice. (Most don't even look at bounces or email sent back to them.)

BLOCKREPLY is set to SILENT by default.

BULKFOLDER
How to handle bulk mail which the filter does not tag as probable spam -- bulk email which is probably legitimate. If you read mail on your shell account, set this to a separate folder from your normal incoming folder, especially if you get a lot of email or are on many mailing lists, and you'll be able to find your personal mail much more easily. :) If you read email using a POP3 client, leave it set to ${DEFAULT} and use your POP client's filters to sort it into a separate folder from your personal email.

BULKFOLDER is set to ${DEFAULT} by default.

BYPASSWD
A password which, when included on the Subject: line of an email, causes the SpamBouncer to pass the mail immediately into your incoming mail box without further filtering. It allows people who happen to have accounts at ISPs which are blocked in the SpamBouncer, or whose email is being trapped by an error in the SpamBouncer, to contact you and arrange to have the problem fixed or get into your nobounce list. Change this if spammers start using it, but it is very unlikely that they will. (It never has happened to me in the three years since I started developing the SpamBouncer.)

BYPASSWD is set to zeugma by default.

CBLCHECK
If set to yes, tells the SpamBouncer to check the Combined Blocklist (CBL), which lists IP addresses taken from a number of other blocklists covering spam sources, haven domains, open relays, open proxies, and other spam concerns, and block email sent to your system via one of these IP addresses. See the CBL entry for more information about this blocklist and how to use it.

CBLCHECK is set to yes by default.

CHINESE
Tells the SpamBouncer what to do with email in Chinese. Set CHINESE=yes if you receive email in Chinese. Otherwise, the SpamBouncer will assume that any email in Chinese is probably spam and put it in the BLOCKFOLDER.

CHINESE is set to no by default.

CHMEXPLOITCHECKING
Tells the SpamBouncer whether to check for email with URLs that attack a known Internet Explorer vulnerability, and to block any email containing such a URL. To disable this feature, set CHMEXPLOITCHECKING=no in your .procmailrc file.

CHMEXPLOITCHECKING is set to yes by default.

CSLIDCHECKING
Tells the SpamBouncer whether to check for email with URLs that contain a CSLID-based link, and to block any email containing such a link. To disable this feature, set CSLIDCHECKING=no in your .procmailrc file.

CSLIDCHECKING is set to yes by default.

CWHOISBOGONCHECK
If set to yes, tells the SpamBouncer to check the Complete Whois Bogons blocklist, which lists unallocated IP ranges and IANA reserved IP ranges, which should never appear in the headers of email. See the Ccomplete Whois Bogons List entry for more information about this blocklist and how to use it.

CWHOISBOGONCHECK is set to no by default.

CWHOISHIJACKCHECK
If set to yes, tells the SpamBouncer to check the Complete Whois Hijacked Netblocks blocklist, which lists IP ranges that have been hijacked and are no longer controlled by their registered owners. See the Ccomplete Whois Hijacked Netblocks List entry for more information about this blocklist and how to use it.

CWHOISHIJACKCHECK is set to no by default.

CYRILLIC
Tells the SpamBouncer what to do with email in a language that uses any Cyrillic character set except Russian. (Russian is handled separately.) Set CYRILLIC=yes if you receive email in a language that uses a Cyrillic alphabet. Otherwise, the SpamBouncer will assume that any email in a Cyrillic character set is probably spam and put it in the BLOCKFOLDER.

CYRILLIC is set to no by default.

DATE
The local Unix date program. The date program is usually in a directory that is on your PATH. (The PATH variable contains a list of directories that your Unix shell searches when you tell it to run an executable program and do not provide a full path with the program name.)

If your SpamBouncer installation is refusing to send complaints or notification emails despite your having configured it to do so, set the DATE variable to point to your system's date program, and that should fix the problem. If the SpamBouncer is working properly, there is no need to set this variable.

DATE is set to date by default.

DEBUG
DEPRECATED -- DO NOT USE. Use the SBDEBUG variable instead to run the SpamBouncer in debugging mode.

DOMAIN
Your system's domain. Unless you set this variable in your .procmailrc file, the SpamBouncer attempts to set it automatically by calling the domainname program that exists on many, but not all, Unix systems. Since the canonical domain for a server may or may not match the domain for which you are processing email, however, you should set this manually. Those who are filtering email for accounts at multiple domains should refer to the LOCALHOSTFILE variable description, as well.

DSBLCHECK
If set to yes, tells the SpamBouncer to check the DSBL Main blocklist at <http://dsbl.org>, to see if an IP address or domain name is on the main dsbl.org blocklist. See the DSBL entry for more information about this blocklist and how to use it.

DSBLCHECK is set to no by default.

DSBLMULTICHECK
If set to yes, tells the SpamBouncer to check the DSBL Multihop Relays blocklist at <http://dsbl.org>, to see if an IP address or domain name is on the multi-hop relays dsbl.org blocklist. See the DSBL Multi-Stage entry for more information about this blocklist and how to use it.

DSBLMULTICHECK is set to no by default.

DULCHECK
If set to yes, tells the SpamBouncer to check the Mail Abuse Prevention System (MAPS) Dial-Up List (DUL), which lists IP addresses that are part of ISP dial-up pools, and block email sent directly to your system from these IP addresses. See the DUL entry for more information about this blocklist and how to use it.

DULCHECK is set to no by default.

ECHO
The local Unix echo program. The echo program is usually in a directory that is on your PATH. (The PATH variable contains a list of directories that your Unix shell searches when you tell it to run an executable program and do not provide a full path with the program name.)

If your SpamBouncer installation is not properly renaming executable file attachment extensions, <IFRAME> tags, or <SCRIPT> tags, or if you have a domain-based blocklist enabled and it isn't working, set the ECHO variable to point to your system's echo program, and that should fix the problem. If the SpamBouncer is working properly, there is no need to set this variable.

ECHO is set to echo by default.

EXECHECKING
Tells the SpamBouncer whether to check for email with embedded executable file attachments and put any such email directly into your SPAMFOLDER. To disable this feature, set EXECHECKING=no in your .procmailrc file.

EXECHECKING is set to yes by default because executable attachments are so dangerous these days.

EXEDOCCHECKING
Tells the SpamBouncer whether to check for email with embedded document file attachments of a type that can contain executable code, to block any email containing such attachments. To enable this feature, set EXEDOCCHECKING=yes in your .procmailrc file.

EXEDOCCHECKING is set to no by default.

EXELINKCHECKING
Tells the SpamBouncer whether to check for email with links to Windows executable files, and to put such email in the BLOCKFOLDER. To enable this feature, set EXELINKCHECKING=yes in your .procmailrc file.

EXELINKCHECKING is set to no by default.

FILTER
If set to yes, tells the SpamBouncer not to file blocked email, spam, suspected virus-laden email, admin email or legitimate bulk email in the appropriate location, but to pass it on to the user along with the other email. The user must then use his/her own filters to file this email in the proper location.

FILTER is set to no by default.

The FILTER variable is intended for administrators who want to use the SpamBouncer to filter incoming email for an entire server before delivering it to individual users. The individual users can then choose whether to filter their own email using the SpamBouncer's headers, or to ignore the headers and receive their email unfiltered.

FREEMAIL
Tells the SpamBouncer where to find your freemail file, a text file of domains offering free email accounts commonly used or forged by spammers. The SpamBouncer then scores email that comes from one of these domains negatively. Email from a free account at a site with insufficient anti-spamming features is not blocked simply because it comes from a free account, but it is treated with a greater level of suspicion. You can set FREEMAIL to INTERNAL, NONE, or the name of an external file. If you set FREEMAIL to INTERNAL, the SpamBouncer uses its internal list of free email sites. If you set it to NONE, the SpamBouncer does not negatively score email that comes from free email sites.

If you set it to an external filename, the SpamBouncer uses that file for FREEMAIL filtering. The file should be formatted in the same fashion as your LEGITLISTS, MYEMAIL, or NOBOUNCE files, with domains listed one per text line, and with no blank lines in the file.

FREEMAIL is set to INTERNAL by default.

WARNING! Do not create an empty FREEMAIL file -- that will cause all incoming email to be treated as coming from a free email address!

FREEWEB
Tells the SpamBouncer to score negatively any email that has URLs hosted on free web providers in the message body. A lot of spam uses free web sites to host pages that redirect to the real URL, so filtering for free web site URLs can be a useful Pattern Matching tool. Valid settings for this variable are no and yes. If you set this variable to no, the SpamBouncer does not negatively score email with URLs hosted on free web site providers.

FREEWEB is set to yes by default.

FTSGDIALCHECK
If set to "yes", tells the SpamBouncer to check blackholes.five-ten-sg.com, a blocklist hosted by Five-Ten-SG.com, to see if an IP address belongs to a pool of addresses assigned to dial-up users of an ISP. See the FTSG Dial-Up entry for more information about this blocklist and how to use it.

FTSGDIALCHECK is set to no by default.

FTSGIGNORECHECK
If set to "yes", tells the SpamBouncer to check blackholes.five-ten-sg.com, a blocklist hosted by Five-Ten-SG.com, to see if an IP address belongs to a company or ISP that ignores spam complaints. See the FTSG Ignores Spam Complaints entry for more information about this blocklist and how to use it.

FTSGIGNORECHECK is set to no by default.

FTSGMULTICHECK
If set to "yes", tells the SpamBouncer to check blackholes.five-ten-sg.com, a blocklist hosted by Five-Ten-SG.com, to see if an IP address belongs to an SMTP server that is itself secure, but that relays for one or more insecure SMTP servers. See the FTSG Multi-Stage Open Relays entry for more information about this blocklist and how to use it.

FTSGMULTICHECK is set to no by default.

FTSGOPTOUTCHECK
If set to "yes", tells the SpamBouncer to check blackholes.five-ten-sg.com, a blocklist hosted by Five-Ten-SG.com, to see if an IP address belongs to an email list server that adds email addresses to its lists without first properly confirming that the user wants to be on that list. See the FTSG Opt-Out Lists entry for more information about this blocklist and how to use it.

FTSGOPTOUTCHECK is set to no by default.

FTSGOTHERCHECK
If set to "yes", tells the SpamBouncer to check blackholes.five-ten-sg.com, a blocklist hosted by Five-Ten-SG.com, to see if an IP address belongs to a server with which there are other, undefined spam-related problems that the maintainers of the Five-Ten-SG blocklist feel warrant blacklisting. See the FTSG Other Issues entry for more information about this blocklist and how to use it.

FTSGOTHERCHECK is set to no by default.

FTSGRSSCHECK
If set to "yes", tells the SpamBouncer to check blackholes.five-ten-sg.com, a blocklist hosted by Five-Ten-SG.com, to see if an IP address belongs to an SMTP server that is an open relay, that is, that allows any user on the Internet to use it to send email to any other user on the Internet. See the FTSG Single-Stage Open Relays entry for more information about this blocklist and how to use it.

FTSGRSSCHECK is set to no by default.

FTSGSRCCHECK
If set to "yes", tells the SpamBouncer to check blackholes.five-ten-sg.com, a blocklist hosted by Five-Ten-SG.com, to see if an IP address belongs to a server that is a direct spam source. See the FTSG Spam Sources entry for more information about this blocklist and how to use it.

FTSGSRCCHECK is set to no by default.

FTSGWEBFORMCHECK
If set to "yes", tells the SpamBouncer to check blackholes.five-ten-sg.com, a blocklist hosted by Five-Ten-SG.com, to see if an IP address belongs to a web server that has one or more insecure web forms, such as web forms using insecure versions of formmail.pl, that are abused by spammers to send spam. See the FTSG Insecure Web Form entry for more information about this blocklist and how to use it.

FTSGWEBFORMCHECK is set to no by default.

GARBLEDCHARSET
Controls the GARBLEDCHARSET filter, which tests for email with non-Latin character sets, and missing, wrong or corrupted MIME headers which should accompany any such character sets. This filter has been refined considerably, but may still occasionally catch email in heavily-modified Latin character sets (such as Baltic or some Eastern European languages), and will tend to catch email with non-Latin character sets, such as Russian, Greek, Arabic, Hebrew, etc.

The default for this variable is yes, which enables this filter. Users who expect to receive email in a non-Latin character set, or who find it is catching too much legitimate email, can set this variable to no to disable the filter.

GLOBALNOBOUNCE
Points to a system-wide nobounce file, if your system administrator has provided one or if you are the system administrator and want to provide one. Please note that this is in addition to each user's individual NOBOUNCE file, and does not replace it. If you do not set this variable, it is automatically set to NONE, so you need to set it only if you have a system nobounce file.

See NOBOUNCE for a more complete description of how this file works.

GREEK
Set GREEK=yes if you receive email in Greek. Otherwise leave it set to no (the default), and the SpamBouncer will send any email in this language to the BLOCKFOLDER.

GREP
A variant of Unix grep, a set of programs which searches files on Unix systems for specified strings of characters. This is set by default to "fgrep", a fast version of grep which is usually found in a normal system programs directory on Unix machines. Most versions of fgrep work properly with the SpamBouncer.

If NOBOUNCE and LEGITLISTS are working on your system, there is no need to set this variable. If NOBOUNCE is not working, set this variable to point to one of your system's grep programs other than fgrep. Usually egrep will work, or agrep if that does not.

HABEASINFRINGERS
If set to "yes", tells the SpamBouncer to check hil.habeas.com, a blocklist hosted by Habeas, Inc., to see if an IP address found in the headers of an email has been used to send spam in violation of the Habeas SWE program. See the Habeas entry for more information about this blocklist and how to use it.

HABEASINFRINGERS is set to no by default.

HABEASVERIFIED
If set to "yes", tells the SpamBouncer to check hul.habeas.com, a whitelist hosted by Habeas, Inc., to see if an IP address found in the headers of an email is registered with Habeas as a guaranteed source of only non-spam email. See the Habeas entry for more information about this whitelist and how to use it.

HABEASVERIFIED is set to no by default.

HEBREW
Set HEBREW=yes if you receive email in Hebrew. Otherwise leave it set to no (the default), and the SpamBouncer will send any email in this language to the BLOCKFOLDER.

HTMLBLOCK
If set to "yes", tells the SpamBouncer to block HTML-only email. Some years ago I set the SpamBouncer to block email in pure HTML (as opposed to the hybrid text and HTML email produced by Outlook and Netscape at the time), because such email was almost always spam. That is no longer the case -- brain-dead software from Microsoft, AOL, and others enables HTML email by default these days. (Can you tell that I really do not like HTML email?) ;> I have therefore disabled HTML blocking by default in this release. You can manually re-enable HTML blocking by setting the HTMLBLOCK variable to yes in your .procmailrc file.

HTMLBLOCK is set to no by default.

IBSCHECK
If set to yes, tells the SpamBouncer to check the Ironport Bonded Sender list (IBS), which lists IP addresses of participants in the Ironport Bonded Sender program, and whitelist email sent to your system via one of these IP addresses. See the IBS entry for more information about this whitelist and how to use it.

CBLCHECK is set to yes by default.

IFRAMECHECKING
Tells the SpamBouncer whether to check for email with embedded IFRAME tags, to block any email containing such active content. To disable this feature, set IFRAMECHECKING=no in your .procmailrc file.

IFRAMECHECKING is set to yes by default.

JAPANESE
Set JAPANESE=yes if you receive email in Japanese. Otherwise leave it set to no (the default), and the SpamBouncer will send any email in this language to the BLOCKFOLDER.

KOREAN
Set KOREAN=yes if you receive email in Korean. Otherwise leave it set to no (the default), and the SpamBouncer will send any email in this language to the BLOCKFOLDER.

LANGFILTER
If set to "yes", tells the SpamBouncer to filter incoming email and block email in Arabic, Chinese, any Cyrillic-based alphabet, Greek, Hebrew, Japanese, Korean, and Turkish. For most users who do not receive email in any of these languages, language filtering will delete a lot of spam and catch very little, if any, legitimate email. Users who do receive email in one or more of these languages will usually want to disable filtering only for those languages in which they normally receive email. For the rare polyglot, or shared account, that receives legitimate email in many languages, you can disable all language filtering by setting LANGFILTER=no.

LANGFILTER is set to yes by default.

LEAN
This variable turns off Pattern Matching on the body text only of messages over a certain size, and is set to yes by default. This is to prevent the SpamBouncer from hogging system resources on your server while filtering extremely large messages. The SpamBouncer is a large filter and can use a lot of CPU cycles and RAM if this limit is not in place.

Set LEAN=no only if you receive large quantities of spam with attached files, and then only if you run your own server or know that the server on which your email is filtered has sufficient resources to run the SpamBouncer on the full text of all incoming email.

LEGITLISTS
Tells the SpamBouncer about legitimate mailing lists which the SpamBouncer should not filter, but should deliver to the BULKFOLDER. Your LEGITLISTS file (whatever you name it and wherever you put it) should contain one email list address per line of text, and nothing else, like this:

     chitchat@borg.besties.com
     dylan-fanatics@lists.musicman.net

If you do not set this variable, it is automatically set to ${HOME}/.legitlists. If the file does not exist, the SpamBouncer just skips this recipe.

LOCALHOSTFILE
Tells the SpamBouncer which domains are local to you -- that is, which domains you receive email for. The SpamBouncer needs to know this to know which IP addresses and domains in the Received: headers should be checked against various blocklists. Your LOCALHOSTFILE file (whatever you name it and wherever you put it) should contain one domain name per line of text, and nothing else, like this:

     hrweb.org
     spambouncer.org

If you do not set this variable to point to another location, the SpamBouncer automatically checks your home directory for ${HOME}/.localhostfile. If the file exists, the SpamBouncer uses it. If it does not exist, the SpamBouncer uses the contents of the DOMAIN variable.

MHDELIVER
Points to the MH Mail rcvstore program, which is used to deliver email to MH Mail folders and update the indexes, and sets the necessary flags. On most systems, this program is located in /usr/lib/mh/rcvstore. If it is located in a different place on your system, you must set this variable manually in your .procmailrc file. Most MH Mail users do not need to set this variable.

MYEMAIL
Points to a text file similar to the NOBOUNCE file, containing a list of email addresses which belong to you. This helps the SpamBouncer with a number of internal routines, and will be implemented in future spam tests, as well. The default is ${HOME}/.myemail. If you do not set this variable to a different value, and if there is no .myemail file in your ${HOME} directory, the SpamBouncer will assume that ${LOGIN}@${HOST} is your email address.

NOBOUNCE
Tells the SpamBouncer where to find your NOBOUNCE file, a text file of email addresses and domains whose email you want the SpamBouncer to skip filtering and deliver directly to you. Set this to point to the directory and filename where you keep that file. I name mine ".nobounce" and keep it in my home directory, and this is where the SpamBouncer looks if you don't set this variable.

Your NOBOUNCE file (whatever you name it and wherever you put it) should contain one email address per line of text, and nothing else, like this:

     goodguy@spamsite.com
     niceguy@roguesite.net

Please note that these names and addresses should be in plain text -- don't use Procmail regular expressions or wildcards, and don't try to escape the "." (periods) using a "\" (backslash). This will just confuse the SpamBouncer and cause your NOBOUNCE file not to work. :)

You can also include entire domain names (the portion of the email address to the right of the @ sign) if you want the SpamBouncer to accept all email from anyone at those domains without checking. I do not recommend doing this, however, except for small domains which you know will not either send spam or be forged into spam by spammers. Since spammers often forge false email addresses in the From: and Reply-To: lines of their messages, you need to be careful or you will make it too easy for them.

In particular, do not put your own domain in your NOBOUNCE file, since a number of spammers use mailmerge spam programs to forge their victims' own email addresses or a phony email address at their victims' domains into their spams, specifically in order to evade filters like the SpamBouncer.

NOLOOP
Sets the X-Loop: header. I recommend leaving the default setting, which uses your ALTFROM address.

NSLOOKUP
Tells the SpamBouncer the path and filename of your system's nslookup program. You need to set this only if nslookup is not in your path (the list of directories which your system will search for a program), if you have an alias set up for nslookup on your account, or if you are running Debian Linux or another Linux system that fills up your logs with error messages indicating that nslookup is deprecated. (If you aren't having trouble getting blocklists to work on your system, you can leave this alone.)

Linux users whose systems object to nslookup can safely set NSLOOKUP=host. Users of other Unix-based systems can also do this provided your version of Unix has the host program. Check before you change this setting!

This variable is set to nslookup by default.

NUKEBOUNCES
If set to yes, tells the SpamBouncer to delete bounces to SpamBouncer complaints, abuse autoresponse messages, and other "junk mail" that most users do not care to see. It will not delete abuse responses that are not autogenerated.

This variable is set to no by default.

OPMBLITZEDCHECK
If set to yes, tells the SpamBouncer to check the Blitzed.org Open Proxy Monitor (BOPM), at <http://www.blitzed.org/bopm/>, to see if an IP address is an open proxy.

This variable is set to no by default.

ORDBCHECK
If set to yes, tells the SpamBouncer to check the Open Relay Database, at <http://www.ordb.org>, to see if an IP address is an open relay. This list closely corresponds to the old ORBS inputs list. An email server listed in the ORBL has not necessarily been used to send spam; it merely can be used to do so. Using this or any open relay blocklist can result in blocking a considerable amount of legitimate email as well as spam, if you correspond with people at sites that host open relays.

This variable is set to no by default.

OUTLOOKTAGGING
If set to yes, tells the SpamBouncer to embed its X-SBClass: header in the Subject: line of any email it classifies as a Virus, Spam, or Blocked. Since Microsoft Outlook and Outlook Express lack the ability to filter on any headers other than From: and Subject:, this allows users of these programs to filter the this email into a backup folder, as users of email programs with more powerful filtering capabilities can already.

This variable is set to no by default. I do not recommend enabling it unless you use a POP mail program that cannot filter directly on the X-SBClass: header. It leaves the Subject: lines of spam looking a bit awkward.

PATTERNMATCHING
How to handle mail which the generic pattern matching filter tags as probable spam, but which may be legitimate email. Valid values are NONE, which skips pattern matching entirely; SILENT, which simply files the mail in the BLOCKFOLDER; and NOTIFY, which sends a notice to the sender that his email was blocked, and explains how to bypass spam filtering if his email was legitimate.

I recommend that users set this value to SILENT. Pattern matching occasionally filters out legitimate email -- there is no way to prevent this entirely. Since more and more spammers are using throwaway accounts, though, and forging their headers so heavily that it is difficult to spot spam through header analysis alone, setting PATTERNMATCHING to NONE will reduce the effectiveness of the SpamBouncer considerably.

The default setting for this variable is NONE, however, because I want to be sure that if you're using it, you have actually read these instructions and know that you are using it. So, if you want to enable it, you must set PATTERNMATCHING to SILENT in your .procmailrc.

RBLCHECK
If set to yes, tells the SpamBouncer to check the Mail Abuse Prevention System (MAPS) Realtime Blackhole List (RBL), which lists IP addresses associated with domains which have spammed repeatedly, and which have failed to clean up their acts despite the RBL team's efforts and assistance. As of August 1, 2001 you must subscribe to MAPS to use the MAPS RBL (Realtime Blackhole List). If you want to use the RBL, contact MAPS <http://www.mail-abuse.org> and become a subscriber. Sites listed on the RBL are highly likely to be the sources of spam, and will rarely be sources of email you want to receive.

This variable is set to no by default. To enable RBL-based filtering, set RBLCHECK=yes in your .procmailrc file.

RFCABUSECHECK
If set to yes, tells the SpamBouncer to check the rfc-ignorant.org list for domains with no valid abuse@ address. Lack of an abuse@ address makes it difficult to report spamming or other abuse from a domain, and is often a sign of a badly-managed domain or a domain owned by a spammer.

This variable is set to no by default. To enable the rfc-ignorant.org abuse blocklist, set RFCABUSECHECK=yes in your .procmailrc file.

RFCDSNCHECK
If set to yes, tells the SpamBouncer to check the rfc-ignorant.org list for domains that do not accept bounced messages. Domains that fail to accept bounced messages can engage in dictionary attacks and other kinds of extremely abusive spamming practices without consequences, since they do not have to accept notifications when they send to an address that does not exist. Failing to accept bounces is often a sign of a badly-managed domain or a domain owned by a spammer.

This variable is set to no by default. To enable the rfc-ignorant.org DSN blocklist, set RFCDSNCHECK=yes in your .procmailrc file.

RFCIPWHOISCHECK
If set to yes, tells the SpamBouncer to check the rfc-ignorant.org list for IP blocks with no valid whois information. Lack of such information makes it difficult or impossible to contact the person responsible for a netblock to report abuse.

This variable is set to no by default. To enable the rfc-ignorant.org IP whois blocklist, set RFCIPWHOISCHECK=yes in your .procmailrc file.

RFCPOSTMASTERHECK
If set to yes, tells the SpamBouncer to check the rfc-ignorant.org list for domains with no valid postmaster@ address. Lack of an postmaster@ address means that it is not possible to contact the person responsible for a domain's mail system. Domains that lack a postmaster address are often badly-managed or owned by a spammer.

This variable is set to no by default. To enable the rfc-ignorant.org postmaster blocklist, set RFCPOSTMASTERCHECK=yes in your .procmailrc file.

RFCWHOISCHECK
If set to yes, tells the SpamBouncer to check the rfc-ignorant.org list for domains with invalid whois information. Invalid whois information is often a sign of a badly-managed domain or a domain owned by a spammer.

This variable is set to no by default. To enable the rfc-ignorant.org whois blocklist, set RFCWHOISCHECK=yes in your .procmailrc file.

RM
Tells the SpamBouncer the path and filename of your system's rm program -- the program which deletes files. You need to set this only if rm is not in your path (the list of directories which your system will search for a program) or if you have an alias set up for rm on your account. If you aren't having trouble with the SpamBouncer leaving temporary files on your system, you can leave this alone.

RSLCHECK
If set to yes, tells the SpamBouncer to check the Relay Stop List (RSL) at <http://relays.visi.com>, to see if an IP address belongs to an open relay. This list contains the IP addresses of open relays, insecure SMTP servers that allow any user on the Internet to send email to any other user via this SMTP server. This list expires entries after 90 days, or automatically on request by anyone, so it is a very conservative list. That means it is unlikely to block much legitimate email, but that it is also likely to fail to block spam that other lists would block.

This variable is set to no by default.

RSSCHECK
If set to yes, tells the SpamBouncer to check the MAPS Relay Spam Source (RSS) blocklist, which lists IP addresses associated with mail servers which are open relays, and through which spam has been sent at least once. As of August 1, 2001 you must subscribe to MAPS to use the RSS. If you want to use the RSS, contact MAPS <http://www.mail-abuse.org> and become a subscriber.

A relay listed in the RSS is not just an open relay; it is an open relay known to spammers which has been used to spam. The RSS blocklist is generally considered less aggressive than the other open relay blocklists, although they both list open relays. As such, it should block less legitimate email than the other blocklists, but will also miss spam sent through relays which have not been abused previously.

This variable is set to no by default. To enable RSS-based filtering, set RSSCHECK=yes in your .procmailrc file.

RUSSIAN
Set RUSSIAN to yes if you receive email in Russian. Otherwise leave it set to no (the default), and the SpamBouncer will send any email in Russian to the BLOCKFOLDER.

SBDEBUG
Set SBDEBUG=yes if you want to run the SpamBouncer in debugging mode. In this mode, the SpamBouncer runs all filters on all incoming email; it does not quit filtering email after it is already classified as spam or as a virus. It also generates verbose Procmail logs. Running in this mode can be useful for diagnosing problems with the SpamBouncer or your configuration. Otherwise, do not turn on debugging mode; it eats up system resources.

SBDELIVERY
Sets the SpamBouncer's delivery mode. The valid options are:

SBSHELL
Sets the SpamBouncer's internal shell appropriately. Unless your Bourne shell program (sh) is not on your system path (highly unlikely), you do not need to set this variable.

SBTEMP
Set SBTEMP=yes if you want the SpamBouncer to put its temporary files in a specific location. Otherwise, the SpamBouncer will use your system's /tmp directory. (You do not normally need to set this.)

SBTRAP
Set SBTRAP=yes if you want a copy of all email that the SpamBouncer classifies either as blocked or as spam to be sent to a particular email address. Useful for debugging a systemwide installation; otherwise, leave this unset.

SCRIPTCHECKING
Tells the SpamBouncer whether to check for email with embedded JavaScript, to block any email containing such active content. To disable this feature, set SCRIPTHECKING=no in your .procmailrc file.

SCRIPTCHECKING is set to yes by default.

SENDMAIL
The full path to your system's copy of sendmail. The default value is /usr/sbin/sendmail, which will work on some systems, but not all. On almost all systems which use sendmail, however, this variable is set correctly as a global default by the system administrators. It does not hurt to check and be sure, though. If SENDMAIL is not set correctly, the SpamBouncer will be unable to send any autoreplies.

SORBSCGICHECK
If set to yes, tells the SpamBouncer to check the SORBS Insecure Web Sites blocklist, described at at <http://www.dnsbl.us.sorbs.net>, to see if an IP address is listed as a web server that hosts insecure CGI scripts, is known to be infected with Code Red, NIMDA, or a similar virus, or has other vulnerabilities that allow spammers to send spam.

This variable is set to no by default.

SORBSDYNCHECK
If set to yes, tells the SpamBouncer to check the SORBS Dynamic IP Ranges blocklist, described at at <http://www.dnsbl.us.sorbs.net>, to see if an IP address is listed as part of a dynamic IP range.

SORBSPROXYCHECK
If set to yes, tells the SpamBouncer to check the SORBS HTTP Proxy Servers blocklist, described at at <http://www.dnsbl.us.sorbs.net>, to see if an IP address is listed as an open HTTP proxy.

This variable is set to no by default.

SORBSPROXY2CHECK
If set to yes, tells the SpamBouncer to check the SORBS Other Open Proxy Servers blocklist, described at at <http://www.dnsbl.us.sorbs.net>, to see if an IP address is listed as an open proxy of any type other than an HTTP proxy or a Socks proxy.

This variable is set to no by default.

SORBSRELAYCHECK
If set to yes, tells the SpamBouncer to check the SORBS Open SMTP Relays blocklist, described at at <http://www.dnsbl.us.sorbs.net>, to see if an IP address is listed as an open SMTP relay.

This variable is set to no by default.

SORBSSOCKSCHECK
If set to yes, tells the SpamBouncer to check the SORBS Open Socks Proxy Servers blocklist, described at at <http://www.dnsbl.us.sorbs.net>, to see if an IP address is listed as an open Socks Proxy server.

This variable is set to no by default.

SORBSSPAMCHECK
If set to yes, tells the SpamBouncer to check the SORBS Open Socks Proxy Servers blocklist, described at at <http://www.dnsbl.us.sorbs.net>, to see if an IP address is listed as a spam source, host of web sites advertised by spam, or provider of other spam support services.

This variable is set to no by default.

SORBSZOMBIECHECK
If set to yes, tells the SpamBouncer to check the SORBS Zombie IP Ranges blocklist, described at at <http://www.dnsbl.us.sorbs.net>, to see if an IP address is listed as having been hijacked and no longer under the control of the registered owner.

This variable is set to no by default.

SPAMCOPCHECK
If set to yes, tells the SpamBouncer to check the SpamCop blocklist, described at at <http://www.spamcop.net>, to see if an IP address or domain name is on the main spamcop.org blocklist. This list contains the IP addresses of all sorts of sites that have spammed, host sites that are advertised by spamming, or that the maintainers believe are involved in spamming in some other way.

This variable is set to no by default.

SPAMFOLDER
Where to store messages tagged as spam by the filter. If you want to just delete spam, set SPAMFOLDER to /dev/null. If you want to put the stuff in a backup folder, set SPAMFOLDER to a filename, perhaps spam.incoming. POP mail users whose client programs have the ability to filter mail into separate folders (like Eudora and Pegasus mail) can also set this to DEFAULT, and let their mail filters sort it into the trash folder or a special spam folder, if they want to engage in some spam tracking. :) Users of MAILDIR may set BLOCKFOLDER to a directory rather than a filename, or you may forward this email to a different address using normal sendmail syntax.

SPAMHAUSORGCHECK
If set to yes, tells the SpamBouncer to check Steve Linford's <http://www.spamhaus.org> blocklist to see if an IP is listed. These sites are mostly unrepentant and aggressive spammers. You are very unlikely to get legitimate email from any of them.

This variable is set to yes by default. To disable spamhaus.org filtering, set SPAMHAUSORGCHECK=no in your .procmailrc file, but I recommend leaving it enabled.

SPAMLEVEL
Tells the SpamBouncer which score to use as the threshold for considering email definitely spam. Email that scores at this level or above is considered spam. It receives an X-SBClass: Spam header, and unless you have FILTER=yes in your .procmailrc, puts that email in the SPAMFOLDER.

SPAMLEVEL is set to 10 by default. Increase this score to loosen the SpamBouncer's criteria for considering email spam; decrease it to tighten the SpamBouncer's criteria.

SPAMREPLY
How to handle mail which the SpamBouncer tags as definitely spam, and which should contain no valid mail whatsoever. Valid values are SILENT, which simply files the mail in the SPAMFOLDER; BOUNCE, which sends a simulated MAILER-DAEMON bounce message to the spammer in hopes that he will think your address is no good and remove it from his list; COMPLAIN, which sends a complaint and copy of the spam to the spammer's postmaster for spammers which the SpamBouncer knows about and has this information, and in most cases also the upstream ISPs; and BOTH, which (not surprisingly) both sends a bounce and complains.

New users should set this to SILENT until they're sure everything is working properly.

SPEWSCHECK
If set to yes, tells the SpamBouncer to check the SPEWS blocklist, described at at <http://www.spews.org>, to see if an IP address or domain name is on the SPEWS Level 1 or Level 2 blocklist. The SPEWS blocklists used by the SpamBouncer are maintained by SORBS, at l1.spews.dnsbl.sorbs.net and l2.spews.dnsbl.sorbs.net. These blocklists contain the IP addresses of all sorts of sites that the SPEWS maintainers believe are likely to be sources of spam, whether they have actually spammed or not as of the time of listing. Most of the entries appear to be of long-time spammers and providers of spam support services, in addition to sites that are actively spamming or hosting spammers and refusing to shut them down. Entries to this list are from trusted users only; SPEWS does not accept submissions for listing from the public.

This variable is set to no by default.

TEST
A variant of Unix test program, a small program which looks for a file or directory and reports whether it exists or not. This is set to "test" by default, since this program is normally found on the system path.

If NOBOUNCE and LEGITLISTS are working on your system, there is no need to set this variable. If NOBOUNCE is not working, set this variable to point directly to your system's test program.

THISISP
DEPRECATED! Use the LOCALHOSTFILE variable and a text file containing your local hosts instead. Tells the SpamBouncer the domain name of your domain or ISP.

THISISP is set to ${HOST}.${DOMAIN} by default.

TURKISH
Set TURKISH=yes if you receive email in Turkish. Otherwise leave it set to no (the default), and the SpamBouncer will send any email in this language to the BLOCKFOLDER.

VIRUSCHECKING
Tells the SpamBouncer whether to run its internal virus checking filters. This variable is set to yes by default, enabling the internal virus checking filters. To disable them, set VIRUSCHECKING=no in your .procmailrc file.

I recommend that you turn off virus checking only if you have a good anti-virus program running on your mailserver itself, rather than just on your local computer. The SpamBouncer's virus checking is not a substitute for an anti-virus program, but it can get rid of a lot of virus-laden email before you download it. If you use a local antivirus program instead of a server-based program, the SpamBouncer's virus filters will save time downloading your email, and also CPU cycles on your workstation or PC.

NOTE: Setting VIRUSCHECKING=no will NOT disable the SpamBouncer's filters for dangerous file types and code. The SpamBouncer will always look for and block email with embedded hidden executable attachments, iframes, and scripts. It will also look for and block email with any embedded executable attachments unless you set EXECHECKING=no, and email with any embedded documents of a type that can contain executable code unless you set EXEDOCCHECKING=no.

VIRUSFOLDER
Where to store messages that the SpamBouncer tags as viruses. This is set by default to the SPAMFOLDER. After you have tested your setup and are certain it works, you may want to change this to /dev/null. Virus-infected email is almost always email the user has no idea he/she sent. It contains nothing most people would want to see, and if you retrieve it into most of the popular Windows-based email programs, you might infect your system.

AHBLRELAYCHECK is set to no by default.

WOTCHECK
If set to yes, tells the SpamBouncer to check the Web-O-Trust whitelist to see if an IP belongs to a computer on it, and whitelist email sent to your system via one of these IP addresses. See the Web-O-Trust entry for more information about this whitelist and how to use it.

WOTCHECK is set to no by default.

ZIPCHECKING
If set to yes, tells the SpamBouncer to block email with attached files in the ZIP archive format. A number of viruses are using this format to bypass virus filters that block email with active content. If you do not normally receive email with ZIP archive attached files, you can enable this feature and block any virus that tries this trick. Otherwise, do not enable it or legitimate email may be blocked.

This variable is set to no by default. To enable ZIP archive filtering, set ZIPCHECKING=yes in your .procmailrc file.

Upgrading the SpamBouncer

Upgrading is easy. You just check the "What's New" notice to see if there are any new variables you should set or features you should be aware of, and then ftp the new version (or grab it with your WWW browser) and copy it over the old version. If you prefer, you can subscribe to the SpamBouncer Updates mailing list to get automatic notifications of updates via email. The mailing list is described in the next section.

That's all there is to it.

The SpamBouncer should be upgraded regularly -- weekly if you are using it with SPAMREPLY set to COMPLAIN and monthly otherwise. Spammers move around a lot. Prolific spammers tend to get disconnected quite a bit, even by spam-friendly providers, because they cause their providers so much trouble. This means that the complaint addresses in the Spam Bouncer's complaint lists must be updated constantly or complaints will go to the wrong place.

Providers get annoyed when they get complaints about a problem they've already fixed, or at least done everything they can to fix. Once they've kicked a spammer off their system, there is very little else they can do, and sending complaints to them just wastes their time and resources.

I do my part by updating the addresses, but that helps only if you do yours by keeping your copy of the SpamBouncer up to date.

So, if you can't upgrade frequently or don't want to bother updating all the time, please set SPAMREPLY and BLOCKREPLY to SILENT. That way you'll still get the benefits of the filter, but you won't risk causing trouble for an ISP that has already kicked its spammers off.

In addition, today's rogue ISP may be tomorrow's good guys. An example of that is erols.com, which a few years ago was the source of a huge amount of spam and which today is one of the leaders in the fight against it. (Erols also has one of the most entertaining "abuse@" people in the business -- Afterburner.) I regularly review the sites on the blocked list and retire those who have adopted and enforced solid no-spamming policies. That reduces the size of the filter and the resources it takes while keeping it as efficient as possible.

So, please keep up to date! :)

Return to Table of Contents

How to Troubleshoot and Report Trouble

If you are having trouble with the SpamBouncer, first please make sure you:

The SpamBouncer is set up to avoid replying to bounced messages and autoreplies to its own bounces, but some spammers set their adminstrative accounts to autoreply to spam complaints and misconfigure their autoresponders to remove the "X-Loop" header, which should NEVER be removed by any autoreply script. In general, it is not a good idea to autoreply to mail from administrative accounts at all, so the SpamBouncer is set up to filter it out first.

I commonly hear from new users who examine the log that Procmail keeps, and are concerned when they see lines like the following:

*** host.domain.tld can't find 000.000.000.000.list.dsbl.org: Non-existent host/domain
*** host.domain.tld can't find 000.000.000.000.blackholes.five-ten-sg.com: Non-existent host/domain
*** host.domain.tld can't find 000.000.000.000.relays.ordb.org: Non-existent host/domain
*** host.domain.tld can't find 000.000.000.000.ipwhois.rfc-ignorant.org: Non-existent host/domain
*** host.domain.tld can't find 000.000.000.000.sbl.spamhaus.org: Non-existent host/domain

Please note that these are normal and simply indicate that your system did not find the IP address in question on that blocklist. All is well; do not worry. :)

Please report spam which the SpamBouncer does not catch to <spamtrap@spambouncer.org> so that I can modify the SpamBouncer to catch it. Many spammers have gotten wise to me -- I'm on their remove lists even if they won't put you or others there. <wry grin> So I depend on my users to keep me up-to-date on what kind of spam is out there.

Report any problems to me at ariel@spambouncer.org, and I'll get to work on fixing them ASAP.

Return to Table of Contents

The SpamBouncer Updates Mailing List

Unfortunately this list is down at present. I'll announce it here when it returns from the dead.

Updates to the SpamBouncer are announced via the SpamBouncer Updates mailing list, in addition to this Web page. The list is a low-volume announcements-only list that gets less than one email per week. I keep it this way so that people who hate getting spammed :) can subscribe without being overwhelmed with email. (If you want to discuss spam and how to fight it, I recommend the SPAM-L mailing list, described in the following section.)

The SpamBouncer Updates list runs on a Majordomo list server, a widely used mailing list management program. If you are unfamiliar with Majordomo, the instructions below should explain how to subscribe to and unsubscribe from the SpamBouncer Updates list. For more information on Majordomo and how to use it, refer to Majordomo Mailing List User Commands at the University of Rochester. For more information on Majordomo itself and how it works, refer to the Majordomo FAQ.

I must approve all subscriptions to the mailing list, so I suggest you send me email letting me know who you are and why you are subscribing before you subscribe to the list. :) (Where possible, I would prefer to keep spammers off of it.)

Subscribing

  1. Send email to updates-request@lists.spambouncer.org, with any subject line you like (the list server will ignore it), and the following text in the message body:

subscribe <your email address>
end
This will tell the Majordomo list server that you want to subscribe to the SpamBouncer Updates mailing list.
The list server will then send you two messages: a notice to the email address from which your subscription was sent and a confirmation message to the email address that you asked to have subscribed to the list. The notice explains that the subscription must be confirmed from the address that was subscribed to the list. The confirmation message asks you to copy a line of text from it, paste that line of text in a new email, and send the email back to the list server. The message will read like this:
Someone (possibly you) has requested that your email address be added to or deleted from the mailing list "spambouncer-updates@aziz.devnull.net".
If you really want this action to be taken, please send the following commands (exactly as shown) back to "Majordomo@aziz.devnull.net":
auth 3de6896e subscribe spambouncer-updates someone@example.com
If you do not want this action to be taken, simply ignore this message and the request will be disregarded.
The text you need to copy is the line beginning with auth. The jumble of letters and numbers after auth is called a token, and will be different for each person. Because it is different for each person, if you send back the exact token, the mailing list knows you really asked to subscribe. That prevents others from subscribing you to the mailing list without your permission.

  1. Copy the line of text beginning with auth and containing the token from the message the Majordomo list server sends to you into a new email, and send the new email back to updates-request@lists.spambouncer.org.

!
CAUTION!

  • Do NOT copy the line of text from the example shown above -- it is just an example and will not work for you. You must copy the line of text from the confirmation email sent to you.

If you followed these instructions correctly, the Majordomo list server will send you two more messages. The first is a short, machine-generated message showing that your subscribe command worked. The second is a message welcoming you to the SpamBouncer Upgrades list.

Unsubscribing

Send email to updates-request@lists.spambouncer.org, with any subject line you like (the list server will ignore it), and the following text in the message body:

unsubscribe <your email address>
end

This will tell the Majordomo list server that you want to unsubscribe from the SpamBouncer Updates mailing list. Majordomo will send you a message confirming that you have unsubscribed from the list. If you no longer have access to your old address, send me email and I will unsubscribe your old address manually.

Switching your Subscription to a Different Email Address

To switch your subscription to a new email address, you must unsubscribe your old address and subscribe the new one, following the instructions above.

Return to Table of Contents

Acknowledgments

First, I would like to thank Stephen van den Berg, the creator of procmail, for his wonderful tool. It is truly the friend of those who hate email spam and want it out of their lives. (It is also the friend of anyone who gets a lot of email.)

I would also like to thank the readers of the Procmail Mailing List for answering lots of often elementary questions, especially at the beginning, as I learned the program. I highly recommend the list for people who use the SpamBouncer. You can subscribe at procmail-request@Informatik.RWTH-Aachen.DE.

Finally, I'd like to thank one of the best sets of users anyone ever had -- you guys do a superb job keeping me up to date on what spammers are doing. I couldn't do it without you, seriously.

These filters are the result of several years of work and learning about Procmail. I hope the results will be as useful to others as they have been to me.

Return to Table of Contents


©1996-2005 by Catherine A. Hampton <ariel@spambouncer.org>. All rights reserved.