Setting up spamd

With the necessary rules in place in your pf.conf, configuring spamd is fairly straightforward[1]. You simply edit your spamd.conf (traditionally stored in the /etc directory, but on OpenBSD 4.1 and newer the file has migrated to /etc/mail), according to your own needs. The file itself offers quite a bit of explanation, and the man page offers additional information, but we will recap the essentials here.

This is about the OpenBSD spam deferral daemon spamd(8), not the Spamassassin component

Please note that this text describes the OpenBSD spam deferral daemon spamd(8), not the similarly named program that is part of the Apache project's SpamAssassin content filtering system. The spam deferral daemon and the content filtering system complement each other well and can even coexist on the same system (the binaries install to different paths unless you've done something you shouldn't have). If you're primarily interested in the content filterling system, please head over to spamassassin.apache.org for information on that system.

One of the first lines without a # comment sign at the start contains the block which defines the all list, which specifies the lists you actually use:

all:\
:bsdly:whitelist:

Here you add all black lists you want to use, separated by colons (:). If you want to use whitelists to subtract addresses from your blacklist, you add the name of the whitelist immediately after the name of each blacklist, ie :blacklist:whitelist:.

Next up is a blacklist definition:

bsdly:\
        :black:\
        :msg="SPAM.  Your address %A has sent spam within the last 24 hours.  See http://www.bsdly.net/~peter/traplist.shtml for details.":\
        :method=http:\
        :file=www.bsdly.net/~peter/bsdly.net.traplist

Following the name, the first data field specifies the list type, in this case black. The msg field contains the message to display to blacklisted senders during the SMTP dialogue. The method field specifies how spamd-setup fetches the list data, here http. The other options are fetching via ftp, from a file in a mounted file system or via exec of an external program. Finally the file field specifies the name of the file spamd expects to receive.

The definition of a whitelist follows much the same pattern:

whitelist:\
        :white:\
        :method=file:\
        :file=/etc/mail/whitelist.txt

but omits the message parameter since a message is not needed.

Choose your data sources with care

Enabling the suggested blacklists in earlier versions of the default as distributed spamd.conf could lead to blacklisting of quite large blocks of the Internet, including several countries such as Korea. I work in a company which actually does the odd bit of business with Koreans, and consequently I needed to edit out that particular entry from our configuration. You are the judge of which data sources to use, and using other lists than the default ones is possible.

Put the lines for spamd and the startup parameters you want in your /etc/rc.conf or /etc/rc.conf.local, for example

spamd_flags="-v -G 2:4:864" # for normal use: "" and see spamd-setup(8)
spamd_grey=YES              # use spamd greylisting if YES

Once again, on OpenBSD 4.1 onwards, the spamd_grey variable is superfluous. If you want spamd to run in pure blacklist mode without greylisting, you use the spamd_black variable to turn off greylisting and enable blacklisting mode.

Note for that you can fine tune several of the greylisting related parameters via spamd command line parameters. Check the spamd man page to see what the parameters mean.

When you are done with editing the setup, you start spamd with the options you want, and complete the configuration using spamd-setup. Finally, you create a cron job which calls spamd-setup to update the tables at reasonable intervals.

Once the tables are filled, you can view table contents using pfctl or other applications. If you want to change or delete entries, you are advised to use the spamdb utility instead of pfctl table commands. More about that later.

Note that the example above uses rdr rules which are also pass rules. If your rdr rules do not include a 'pass' part, you need to set up pass rules to let traffic through to your redirection. You also need to set up rules to let legitimate email through. If you are already running an email service on your network, you can probably go on using your old SMTP pass rules.