Hitting back at spammers with OpenBSD and spamd

OpenBSD’s spamd – A lightweight spam-deferral daemon. Spamd works directly with SMTP connections, and supports features such as gray-listing. It minimizes false positives compared to a system that does full-body analysis. It is not a replacement for spam-filters, but an elegant method of segregating the spammers.

This HOWTO is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. ©2008 Strykar

The lowdown

I hate spammers; I mean I really hate their kind. It stems from a crevasse deep inside me since Sabir Bhatia sold Hotmail.

There are plenty of excellent methods for spam-control, none of them fool-proof, and almost all the good ones need you to ’train’ the filters to differentiate between what’s spam and what’s not.

I am not going to delve into this here, suffice to say, that I use the same RBLs that sendmail.org does and some selective country/host based filtering keeps out most of the spam from my mail-servers. If you use Windows, try this: www.cloudmark.com/desktop – it’s by the author of Vipul’s Razor.

The subject of today’s rant is the burning desire we all have to smack a spammer, or bludgeon his gonads with a 9 Iron. We all wanna get back at spammers, and let’s face it, there’s very little chance that we actually will.

Here’s why YOU and I won’t:

They hijack misconfigured mail-servers shifting identity and location.

  • Tracking them takes time and effort and isn’t trivial, ask Spamhaus.
  • It gets boring unlike watching Mplayer compile in Linux.
  • The enemy only knows the system because Bruce Schneier wants him to know the system.

We typically secure our mail servers to relay using AUTH or whatever else takes your fancy. They still bombard us nagging your MTA to send email, VRFY email addresses and bloat our logs with useless details.

That’s in the past – It’s payback time.

Well, a start at least, remember that the concept of RBLs started with a bunch of SF email administrators sharing spammer host IP lists. I have no illusions that this will kick off like that, but take a gander, if it brings you the same joy it has brought me; follow the simple instructions to set it up yourself. At the end of the article, take a minute and imagine a 100'000 people running spamd and slowing spammers. Who would mind getting back at spammers?

This will only work on *BSD, the few Linux hacks floating around simply don’t work. This is NOT a method to prevent SPAM. This is NOT a How-to on using spamd and relaydb to gray-list spammers. This is intended for machines that have a public IP address and receive no external mail. You can be running Sendmail/Postfix/Exim locally for system mails etc. This typically means your MTA listens only on localhost.

If you’re not familiar with spamd, read these and come back:

Read the spamd and spamd.conf manuals and my setup below will make sense to you. Edit spamd.conf to use your own blacklist file. If you’re not listed as an MX record anywhere, the ONLY people speaking to your SMTP port are spammers and zombies.

$ cat /etc/mail/spamd.conf
# spamd.conf for machine having no MX record.

# List everyone specifying in /var/db/myblack.txt
:msg=”I'm not listed as an MX record anywhere. You are a zombie\n\
or a spammer. Die a slow stuttered death %A”:\

We ensure every IP address is included by using this CIDR notation.

$ cat /var/db/myblack.txt

Setup spamd to run from /etc/rc.conf The switches -bvh mean blacklist, log verbose and ‘display hostname as’.

$ cat /etc/rc.conf|grep spam
spamd_flags="-b -v -h tarpit.spamtrap.host" # for normal use: "" and see spamd-setup(8)
spamd_black=YES # set to YES to run spamd without greylisting
spamlogd_flags="" # use eg. "-i interface" and see spamlogd(8)

Now comes the easiest part. We tell pf not to send anything from our public/external interface to the SMTP port at localhost. This is a fail-safe for those running a mailserver locally. We also tell pf to route incoming connections to our SMTP port on the public interface to spamd running on localhost.

$ cat /etc/pf.conf|grep smtp -A 1
no rdr on $ext_if proto tcp from any to port smtp
rdr pass log on $ext_if proto tcp from any to any port smtp \
-> port spamd

Setup syslog to log spamd to /var/log/spamd so we have one log to rule them all.

$ touch /var/log/spamd
$ cat /etc/syslog.conf|grep spamd
daemon.err;daemon.warn;daemon.info;daemon.debug /var/log/spamd

Now you’re all set to waste spammer processor cycles. kill -HUP spamd and syslog; reload pf rules. Watch with unabated joy as the bastards get stuck in your tarpit by: $ tail -f /var/log/spamd


Here are some snipped results from my /var/log/spamd:

$ tail -f /var/log/spamd
Sep 17 18:22:27 barge spamd[14558]: listening for incoming connections.
Sep 18 11:24:04 barge spamd[14558]: connected (1/0)
Sep 18 11:24:07 barge spamd[14558]: disconnected after 3
Sep 18 15:00:15 barge spamd[14558]: connected (1/0)
Sep 18 15:04:35 barge spamd[14558]: (GREY) gdnrpt@
- abcc.1234@gmail.com
Sep 18 15:06:20 barge spamd[14558]: From: gdnrpt@
Sep 18 15:06:20 barge spamd[14558]: Subject:,25,webmaster,webmaster,,-SMTP-Dx1784E
Sep 18 15:06:20 barge spamd[14558]: To: abcc.1234@gmail.com
Sep 18 15:06:20 barge spamd[14558]: Body:
Sep 18 15:07:09 barge spamd[14558]: disconnected after 414

Now let’s see what and by how much.

# grep disconnected /var/log/spamd | awk '{print $9}' \
> | sort -rn | uniq -c | head
1 55574
1 40390
1 8888
1 909
1 898
1 872
7 805
1 803
2 801
1 800

The first at 55574 seconds took over 15.43 hours trying to finish delivering a single email! The second at 11 hours.

Hah haaa, bastards! Say EHLO to my personal spam decelerator.

Lookup my sendmail article for its default SMTP protocol timers. By seeing how much time each attempt took to finish the SMTP dialogue, we can make educated guesses as to which mailserver the spammer machine is running. Most run dowdy FreeSMTP or SmartSMTP on Windows. The rest are misconfigured *NIX SMTP servers being abused as open relays. Of course, you need to know the default configuations that they ship with.

All of the above is on a P-200Mhz with 32MB of EDO RAM and repeated top / vmstat runs with and without spamd showed absolutely no extra resources used. That’s how well it’s written. For those of you running BSD on a machine not as archaic as mine, you’ll have zero worries running spamd and resource hogging. You’ll forget you have it running, I have.

To sum up, just watch one spammer connect and waste time. The pleasure of watching is almost, ahem, anal. 50 bucks says you’ll keep it running.

All this is for personal machines. You definitely want to use spamd in front of mailservers, it doesn’t matter what it’s running, yes, even Exchange. The links at the bottom will get you up and doing that in no time.

Read Steve Williams’ October 20th, 2006 message to the OpenBSD-misc mailing list where he reports that a pure greylisting configuration immediately rid his company of approximately 95% of their spam load.

The video shows you how spamd stutters the conversation with the spammer, backing up his mail queue. Spamd sets its socket receive buffer size to one character, forcing the sender to send one TCP packet for each byte of data, even if it’s a non-compliant “dump and disconnect” mailer, so the spammer wastes CPU cycles and network bandwidth in addition to a delayed queue.

The video link is me telnetted into a spamd install. The SMTP transaction is recorded at real-time speeds to show what a tarpitted, stuttered, SMTP conversation looks like. Download it and scroll ahead – you get the drift.


  1. Use addresses logged by spamd to setup my own RBL. Have sendmail use it from our DNS servers as a private and guaranteed spammer-only list. Nobody should be talking SMTP to a dynamic home IP netblock!

  2. Document the process to setup and test a private RBL with the required steps for BIND so this writeup can be a walkthrough for the process.

Additional reading: