Three Minimalist spamd Configurations for Your Spam Fighting Needs (With Bonus Points at the End)

Peter N. M. Hansteen

Making life harder for spammers does not necessarily require a lot of effort, if done correctly. Here are a few suggestions for how to use your spamd(8) on an OpenBSD or FreeBSD system that require minimal input but can yield noticeable gains.

Doing your bit to protect your own users and others agains scams, phising or other undesirable mail activity is good netizenship, but unfortunately there is a tendency to think that contributing in any way takes a lot of effort in addition to deep insight into all matters technical and social.

This piece is intended to give you, an aspiring or experienced OpenBSD or FreeBSD user who do not necessarily run a mail service yourself, a taste of some of the options available to you even if you do not want to expend too much effort.

Note: This piece is also available without trackers only basic formatting here.

If your system runs OpenBSD, you only need to enable spamd (overriding the NO defaults from /etc/rc.conf) by adding the following lines to your /etc/rc.conf.local:

spamd_flags=""
spamdlogd_flags=""


And adding the required lines to your pf.conf, cut-and-pasteable from the man page before reloading your ruleset. You may want to look into filling in actual flags later if your setup requires it.

If your system runs FreeBSD, you need to enable PF, install the spamd package, then run through the steps outlined in the package message which is displayed at the end of the package installation.

With those preliminaries out of the way, we can go on to the specifics of each of the low effort scenarios.

Classic imported blacklist-only

When spamd(8) was first introduced, it did only one thing: slow down incoming SMTP traffic from known bad sources. The known bad addresses were the ones fetched from address lists generated locally or elsewhere, as specified in spamd.conf.

The pure blacklisting mode is still available. If you have one or more sources of blocklists that you consider reliable, you can use those. To enable this mode on OpenBSD, add the line

spamd_black=YES

to /etc/rc.conf.local or add the -b flag to any options in the spamd_flags= variable, edit in any lists to fetch in your spamd.conf, restart spamd and add a crontab entry to run spamd-setup at reasonable intervals.

On FreeBSD, the procedure is basically the same, but adding the -b flag to the spamd_flags= variable is the only way to enable the feature.

Once you have the -b mode enabled, any SMTP traffic from the known bad hosts will be stuttered at -- answers arriving at a rate of one byte per second until they give up, and spamd-setup will refresh your lists at the intervals you have specified.

You can then sit back and enjoy the feeling of getting to waste spammers' (or at least spambots') time.

Checking your system logs for spamd log entries occasionally will likely lead to giggles.

Classic greylisting without imported lists

The original version of spamd(8) did not know how to do greylisting, but since the version that shipped with OpenBSD 4.1, greylisting mode is the default mode.

If you simply enable spamd without touching any other options, you will have greylisting enabled.

This means that any SMTP traffic from hosts that have not previously contacted your spamd will be stuttered at (one byte at the time, remember) for ten seconds at first.

If they come back within a reasonable time, they will be added to the allowable list. If you have a real mail server in the back somewhere, the traffic will eventually be let through.

Once set up, this mode is also extremely low maintenance.

After a while, your system logs may offer some occasional entertainment.

Allowed domains only

If you're still reading this article, you more likely than not have at least heard about the greytrapping concept. I have written about the concept and practice at length (see the reading materials at the end), and it is one of the topics that I sense is generally perceived as being complicated and labor intensive.

I am here to tell you that there is in fact an easy, low maintenance way in to greytrapping, by making allowed domains be the only criterion for trapping and blocking. This is the method I described in more detail in the previous article A Simpler Life: Trapping Spambots Based on Target Domain Only (or with nicer formatting and Big G's trackers here).

Simply put, if you are running your spamd in the default greylisting mode, with or without imported blocklists, you can tiptoe into greytrapping by adding the domains you want to receive mail for to your spamd.alloweddomains file. If you want to disallow subdomains of otherwise wanted domains, you add an entry with the otherwise wanted domain with an @ at sign prepended.

Make the configuration changes specified in the article. Do read the man pages and other relevant references, the article has quite a few links.

Once you have input the wanted domains in your spamd.alloweddomains file and reloaded your spamd service, any attempt at delivery to any domain that is not specificed in your configuration will lead to blocklisting and subsquent stuttering until the sender gives up.

With this minimal trapping configuration in place, your logs will soon offer some excellent entertainment. Such as this, which demonstrates that I do not own that domain and do not want to receive or relay mail from elsewhere to it:

Jan 25 16:29:14 skapet spamd[84681]: (GREY) 185.196.10.236: <htg@dataped.no> -> <captainjohnwhite3@gmail.com>
Jan 25 16:29:14 skapet spamd[4259]: Trapping 185.196.10.236 for tuple 185.196.10.236 tTzhEgT <htg@dataped.no> <captainjohnwhite3@gmail.com>
Jan 25 16:29:14 skapet spamd[4259]: new greytrap entry 185.196.10.236 from <htg@dataped.no> to <captainjohnwhite3@gmail.com>, helo tTzhEgT


Bonus tracks: The MX-less merry prankster, and more

All of the things mentioned here will work equally well each on their own or in combination, and those things will, should you choose to go on to set up a mail service, ease the load considerably on the parts of your setup that does the heavier duty computing involved in mail delivery, the content filtering, either for match against known bad code (aka antivirus or antimalware) patterns or text patterns known to be part of scammy spam.

But one fun fact that one of my correspondents pointed out to me some years back is that you can run a spamd service with no real mail service available.

This correspondent reported that sure, they had an OpenBSD machine in an internet facing position, but did not run a mail service.

They set up a combination of the methods outlined earlier, but their mail was handled elsewhere. Anything that finally cleared the barriers of their spamd config would have nowhere to go.

The fact that they did not run an actual mail service did not stop spam senders for trying, and the setup proved ideal for testing how well spamd(8)'s -S and -s options worked.

Please check out the man page to see what they do.

And yes, the effect of -s seemed to be quite linear according to my correspondent's data.

If you want to go further, here is some reading material for you

I hope you find the previous entries informative and possibly even useful.

As you have seen, you can contribute to spam protection efforts even if you do not run an actual mail service. If any of the things suggested earlier suit your needs, enjoy!

However, if you are entertaining the idea of running your own mail service, I have some further reading that I suggest and recommend you spend some time digesting.

First, if you want to run a mail service, do yourself a favor and not only read the relevant man pages, but also sign up for the mailop mailing list, read the Mailop FAQ and the Best Practices for Servers document.

Please also do yourself the favor or lurking, or listening in a bit to get some idea of what kind of discussions are expected there, before posting yourself. Also, familiarize yourself with the mailing list archives. Your question may very well have been answered extensively and well in the past.

If you want to dig deeper in matters related to spam, greytrapping and the OpenBSD spamd(8) program in general, here are a few resources for you:

In The Name Of Sane Email: Setting Up OpenBSD's spamd(8) With Secondary MXes (also with trackers)

Badness, enumerated by robots (also with trackers)

Goodness, Enumerated by Robots. Or, Handling Those Who Do Not Play Well With Greylisting (also with trackers)

Maintaining A Publicly Available Blacklist (tracked only, sorry)

Effective Spam and Malware Countermeasures - Network Noise Reduction Using Free Tools (also tracked only, sorry)

The Book of PF, 3rd edition (now again available as physical copies).

---

Thanks to Michael Lucas, who wrote a message on the mailop mailing list that spurred me to write both this article and the previous A Simpler Life: Trapping Spambots Based on Target Domain Only (or with nicer formatting and Big G's trackers here).