Giving spammers a hard time

Table of Contents
Remember, you are not alone: blacklisting
List of black and grey, and the sticky tarpit
Setting up spamd
Some early highlights of our spamd experience
Beating'em up some more: spamdb and greytrapping
Conclusions from our spamd experience

At this point we've covered quite some ground, and I'm more than happy to present something really useful: PF as a means to make spammers' lives harder. Based on our recent exposure to PF rulesets, understanding the following /etc/pf.conf parts should be straighforward:

table <spamd> persist
table <spamd-white> persist 
rdr pass on $ext_if inet proto tcp from <spamd> to \
         { $ext_if, $localnet } port smtp -> 127.0.0.1 port 8025
rdr pass on $ext_if inet proto tcp from !<spamd-white> to \
         { $ext_if, $localnet } port smtp -> 127.0.0.1 port 8025

We have two tables, for now it's sufficient to note their names and the fact that these names have a special meaning in this context. SMTP traffic from the addresses in the first table above plus the ones which are not in the other table are redirected to a daemon listening at port 8025.

The application which uses these tables, spamd, is a fake SMTP daemon, designed to waste spammers' time and keep their traffic off our net. That's what lives at port 8025, and the last part of our session here will be centered around how to make good use of that software.

Remember, you are not alone: blacklisting

The main point underlying the spamd design is the fact that spammers send a large number of messages, and the probability that you are the first person receiving a particular message is incredibly small. In addition, spam is mainly sent via a few spammer friendly networks and a large number of hijacked machines. Both the individual messages and the machines will be reported to blacklists fairly quickly, and this is the data which eventually ends up in the first table in our example.