The main point underlying the original 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 that eventually ends up in the first table in our example.
Classic spamd: Blacklists and the Sticky Tar Pit
In the classic mode, spamd employs a method called tarpitting. The daemon presents its banner to SMTP connections from addresses in the blacklist and then immediately switches to a mode where it answers SMTP traffic one byte at a time, intending to waste as much time as possible on the sending end while costing the receiver pretty much nothing.
The specific implementation with 1-byte SMTP replies is often referred to as stuttering. Blacklist-based tarpitting with stuttering was the default mode for spamd up to and including OpenBSD 4.0.
Setting up spamd to run in traditional, blacklisting-only mode is fairly straightforward. Start by putting the redirections and table definitions
just mentioned in your pf.conf file, and then turn your attention to the
spamd.conf file.
NOTE Note that on FreeBSD, spamd is a port, mail/spamd/. If you are running PF on FreeBSD 5.x or newer, you need to install the port, follow the directions given by the port’s messages, and then return here.
A Basic spamd.conf File
As distributed, the file itself offers quite a bit of explanation, and the man page offers additional information, but we will recap the essentials here.
NOTE On OpenBSD 4.0 and earlier (and by extension, ports that are based on versions prior to OpenBSD 4.1), spamd.conf was in /etc. Starting with OpenBSD 4.1, the file is to be found in the /etc/mail directory instead.
Near the beginning of the file, you will notice a line without a # comment sign that says all:\. This line specifies the lists you actually use, such as
all:\
:uatraps:whitelist:
Here you add all blacklists you want to use, separated by colons (:). If you want to use whitelists to subtract addresses from your blacklist, add the name of the whitelist immediately after the name of each blacklist, for example, :blacklist:whitelist:.
Next up is a blacklist definition:
uatraps:\ :black:\
:msg="SPAM. Your address %A has sent spam within the last 24 hours":\ :method=http:\
:file=www.openbsd.org/spamd/traplist.gz
Following the name, the first data field specifies the list type, in this case black. The msg field contains the message displayed to blacklisted senders during the SMTP dialog. The method field specifies how the spamd-setup program fetches the list data, in this case http. Other possibilities include fetching via ftp, from a file in a mounted filesystem, 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, as shown below, follows much the same pattern but omits the message parameter, since a message is not needed:
whitelist:\ :white:\ :method=file:\
WARNING Choose your data sources with care. The suggested blacklists in the default spamd.conf as distributed could potentially exclude quite large blocks of the Internet, including several address ranges that claim to cover entire countries. It goes pretty much without saying that if your site expects to exchange legitimate email with any of the countries in question, those lists may not be optimal for your setup. Other popular lists have been known to list entire /16 ranges as spam sources, and it is well worth the effort to find out the details of the list’s maintenance policy before putting a blacklist into production. You are the judge of which data sources to use, and using lists other 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, this line
spamd_flags="-v" # for normal use: "" and see spamd-setup(8)
enables spamd to run in blacklisting mode on OpenBSD 4.0 and earlier. The -v flag enables verbose logging, which is useful for keeping track of spamd’s activity for debugging.
NOTE If you want spamd to run in pure blacklist mode without greylisting (described in the
next section) on OpenBSD 4.1 or newer, set the spamd_black variable to YES and then restart spamd to turn off greylisting and enable blacklisting-only mode.
When you have finished editing the setup, start spamd with the options you want and complete the configuration using spamd-setup. Finally, create a cron job that calls spamd-setup to update the tables at reasonable intervals. By default, spamd logs to your general system logs. If you want the spamd log messages to go to a separate log file to reduce the clutter in your system logs, you may want to add an entry similar to this to your syslog.conf file:
!!spamd
daemon.err;daemon.warn;daemon.info /var/log/spamd
When you’re satisfied that spamd is running and does what it is supposed to do, you will probably want to add the spamd log file to your log rotations, too.
Once spamd-setup has been run and 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. (We’ll talk more about that later.)
Note that in the example pf.conf fragment at the beginning of “Giving Spammers a Hard Time with spamd” on page 72, the redirection (rdr) rules 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 target. 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.
Pure blacklisting mode is here mostly for historical reasons. Given a set of reliable and well-maintained blacklists, it does a good job of keeping known spam-sending machines occupied. However, the real gains in spam prevention