The abuse of email by unsolicited bulk mailers continues to increase. One of the reasons it is so appealing to advertisers is that very large numbers of people can be contacted for a very small investment (by the spammer) in time and resources.
Setting up a tarpit for spam attacks both of these economies. If the spammer's bulk mail program comes to a halt when it tries to send messages to a particular mail server, the spammer's investment in time (the time to send an individual message and the total time to send a bulk mailing) and resources (the number of simultaneous messages in the process of being delivered and the system load that causes) go up. If many sites implement spam tarpits, the investment goes way up.
For the same reasons this can also be useful as negative feedback for the operator of an open SMTP relay. A small ISP operating an open relay may simply ignore messages that bounce from sites employing a RBL filter, particularly if those sites are not sites that the ISP or their legitimate customers regularly communicate with. The ISP may also not notice the extra load on their SMTP server caused by the relayed spam messages. If a spammer relays a large number of messages via their server, and all of the delivery threads on that server get tarpitted, then the ISP will notice - their regular mail delivery will be severely interfered with, and the costs of the spammer's trespass will be highlighted.
The ethical aspects of this response to spam deserve discussion. Is it a Denial-of-Service attack if you have not initiated the communication? Is it “polite” to cause a third-party SMTP server to completely bog down when they try to send mail to you? Is it ethical to actively entice spammers to add tarpitted email addresses to their mailing lists? The responses will, of course, cover the full spectrum based upon how rabidly spam is despised. For the purposes of discussion I'll offer four possible paths of action: passive, reactive, proactive and aggressive trapping.
Note: In the current version of LaBrea (2.5-stable-1) there is no provision for producing a welcome banner message. The prevents effective tarpitting of SMTP traffic since the SMTP procotol specifies the server must send a welcome banner before the client attempts to send any data. The client will hit the tarpit, not see a welcome banner, and time out after a brief delay.
Patches are available on SourceForge to add the ability to send a greeting banner so the mail client can be tarpitted when they attempt to send the HELO command. See http://sourceforge.net/tracker/index.php?func=detail&aid=1612818&group_id=70896&atid=529395 (there are related bugfix and other capability patches referred to on that page as well, you want them all). If the current version is greater than 2.5-stable-1 these patches may already have been incorporated into the mainline version.
Set up SMTP tarpitting on unused IP addresses in your netblock. This will serve to trap people scanning for open relays.
Set up a SMTP-only tarpit on your public mail server and only tarpit repeat abusers; for example, clients that have already been rejected more than twice by your MTA based on DNS RBLs you are using ("three strikes, you're out"), or clients that ignore the SMTP RFC by sending data before receiving the server's greeting banner (see "Greet_Pause").
A script that does this for sendmail on Linux is available at http://www.impsec.org/~jhardin/antispam/spammer-firewall - it requires the above patches to be applied to LaBrea. This script can be installed on the same system as your public sendmail MTA and it will only tarpit repeat offenders' SMTP traffic.
The above script could be used as a basis for setting up a static proactive SMTP tarpit that firewalls and captures any clients that appear in various RBL lists (if the RBL data is available in CIDR format), rather than only tarpitting clients who have already attempted delivery and been rejected.
This requires a source for regular updates of the desired RBLs in CIDR format. Such a feed may require a contract and a monetary investment, and consumes greater resources on the tarpitting system than the Reactive method.
briefly:
Set up a SMTP tarpit on a machine that does not otherwise receive
email. Configure LaBrea to accept SMTP traffic to that host from any other
host (e.g. don't limit the tarpit clients by IP). Publish that machine as the
MX host for a subdomain of your domain (e.g. @tarpit.example.com).
Then invite the spammers in.
Post to newsgroups that spammers troll using email addresses from that domain
(e.g. spam-me@tarpit.example.com).
Respond to spamlist “remove” addresses with your From: set to that address.
Publish the email address in non-visible mailto: links on web pages.
Publish the SMTP tarpit server in publicly-accessible open relay lists (which
spammers no doubt use for their purposes).
Etc.
This may get you sued. Implement at your own risk. I specifically disclaim any responsibility for any legal issues or punishment you may experience from doing this.