The files in this directory are copies of the same files I use to filter out spam e-mail. Unlike most individuals, I do NOT filter based on content. This is akin to censorship, which I am reluctant to accept. Instead, I filter based on the IP address where the e-mail came from. This approach is based on the theory that incompetently run ISPs will continue to allow spammers to operate on their networks, or allow security-ignorant Windows users to continue to unknowingly operate as "spam zombies", no matter how many abuse reports you send them. These network blocks will simply be cut off from sending me ANY e-mail, since they don't seem to be able to send anything legitimate. All of this e-mail is saved to $SEWER, which is a variable defined by another procmail script to point to a "spamholes" folder. This file is occasionally perused for legitimate messages that might have run afoul of the filter; if a reply is warranted, the author is added to the whitelist, and they are advised that their ISP is known to tolerate spam. I am not looking to punish innocent people. But if you use an ISP that tolerates spam, I am hoping that you will let your wallet do the talking, and take your business elsewhere. For some ISPs, "doing the right thing" absolutely NEVER occurs to them unless there's an obvious, short-term financial incentive associated with it. Most ISPs simply do not have the fortitude to kill off the connections of their clueless users who repeatedly infect themselves with viruses, worms, and "spam zombie" software. ABOUT SPAMHOLES --------------- Previously, I published my "rc.spamholes" procmail recipes. This included the master file, as well as rc.spamholes.ameritech, rc.spamholes.charter, and rc.spamholes.rr, representing some US-based ISPs with vast IP address holdings as well as a profound stupidity. All of these files included the CIDR network listings for "problem" networks, but the actual blocking was performed by very unwieldy regular expressions. Maintaining these lists was a pain, and if a mistake was made, it might never be found. On 22 August 2005, I installed new filtering software, called blocknets (source tarball available in this directory), which is used by procmail. This software is far more efficient, and uses configuration files written in standard CIDR network notation alone. This has allowed me to consolidate the blacklists into a single file, named "spamholes". SERVER-SIDE BLOCKING -------------------- Thanks to having one of the world's best ISPs, I can also enable any of a number of server-side filters. These filters are referenced when our SMTP server receives a message. If the message doesn't pass all of these tests, the sender's mail server will immediately be told of the rejection, with a message like this: 554 Service unavailable; Client host [217.132.243.60] blocked using cbl.abuseat.org; Blocked - see http://cbl.abuseat.org/lookup.cgi?ip=217.132.243.60 The following server-side filters are currently enabled (descriptions from Panix staff): ORDB Tests whether the SMTP client is listed in the Open Relay Database (ORDB - http://ordb.org/). The ORDB tracks mail servers which do not belong to spammers, but are abused by spammers to distribute spam. CBL Tests whether the SMTP client is listed in the Composite Blocking List (CBL - http://cbl.abuseat.org/). The CBL uses spamtraps to find open proxies and spam-emitting zombies, with a conservative approach to listing. SBL Tests whether the SMTP client is listed in the Spamhaus Block List (SBL - http://www.spamhaus.org/sbl/). The SBL tracks verified spam sources. Sender Address This highly effective restriction tests whether the Verification envelope return address is currently accepting mail. Bogus MX Tests whether the envelope sender is listed in bogusmx.rfc-ignorant.org. This is a list of domains which list bogus MXs in the DNS. (See http://www.rfc-ignorant.org/policy-bogusmx.php)