One of the more satisfying aspects of OpenBSD’s spam management is how it stutters conversations with mail exchangers, taking up valuable resources of spammers. If every MTA took an advesarial approach to dealing with untrusted MX hosts, spam would be a lot less profitable.
First, the basics:
Greylisting is a method of defending e-mail users against spam. A mail transfer agent (MTA) using greylisting will "temporarily reject" any email from a sender it does not recognize. If the sender re-attempts mail delivery at a later time, the sender may be allowed to continue the mail delivery conversation.
Spammers deal in volume. For this reason alone, greylisting filters out a lot of adversaries. It is a tactic employed by many MTAs. What separates spamd from others is that it stutters conversations as well. From the man page:
When a sending host talks to spamd, the reply will be stuttered. That is, the response will be sent back a character at a time, slowly. For blacklisted hosts, the entire dialogue is stuttered. For greylisted hosts, the default is to stutter for the first 10 seconds of dialogue only.
More than once, this twist on greylisting has caused my users to be removed from the recipient list of spam senders. Clearly someone is taking notice. Digging into the spamd code, we see why:
1 2 3 4 5 6 7 8
1 2 3 4 5 6 7
It’s clear that a few blacklisted spammers have noticed that conversations with my domains take a prohibitively long time, checked their logs, been properly insulted (I hope), and have given up trying to send garbage to my domains.
Spam Deferral Overview
I employ three components in the spam deferral system:
- tags new hosts as ‘grey’ in the spam database
- wastes the time of blacklisted mail exchangers via stuttering
- updates the packet filter so that whitelisted hosts speak directly to the MTA
- monitors the pflog(4) interface and detects when grey-listed hosts re-attempt mail delivery
- promotes hosts from ‘grey’ to ‘white’ when the delivery retry threshold is met
- allows administrators to view and modify entries in the spamd database
- allows email addresses to be added to spam database for greytrapping consideration
Our first step is to configure the packet filter such that any MTA connection that is not already whitelisted is redirected to the spamd daemon. The following lines are added to
1 2 3 4 5 6 7 8
The above configuration achieves the following:
- The nospamd table contains a list of addresses in CIDR netmask notation. These are addresses of mail exchangers belonging to well-known companies (google, AOL, etc.). I have chosen to exempt these mail exchangers from the greylisting process because these organizations employ a pool of mail exchangers; it is likely that the host which first attempts mail delivery will be different form the host which retries later.
- The spamd-white table contains the list of addresses which have been whitelisted by the greylisting process. That is, after an initial temporary rejection, these hosts properly retried mail delivery within a reasonable window, and thus are permitted to speak with the local MTA. This table is maintained by spamd.
- Any MTA that my domain contacts in order to deliver outgoing mail is automatically exempt from greylisting. This ensures that any replies to mail sent by my users will be delivered immediately.
Now we must configure spamd and spamlogd to start on boot:
1 2 3
I also elected to create a special log file to keep track of events:
1 2 3 4 5
man syslog.conf(5) to understand this configuration.
Greytrapping with spamdb
A grey trap is a bogus email address used to lure spammers into attempting mail delivery. Since the address is bogus, all hosts which attempt delivery to the spam trap address are automatically blacklisted. People tend to embed grey trap email addresses into their websites. Spammers inevitably scrape the html, looking for valid email addresses. Lured by the grey trap, they fall immediately into a blacklist.
Grey traps are added as follows:
We can use the spamdb utility to see the current MTA state for each host that has attempted delivery, and grey traps in the system.
1 2 3 4 5 6
In the above output, two hosts are whitelisted. The first entry was whitelisted after properly re-attempting mail delivery. The second is whitelisted because it falls in the list of corporate conglomerate addresses in the nospamd table.
The final three entries are grey trap addresses. These entries inform spamd that if any MTA attempts delivery to any address in this list, they are to be blacklisted.
/var/log/spamd we see the payoff:
1 2 3 4
For 392 seconds the spammer conversed with the local MTA at a rate of one character per second. Eventually, the shitheel gave up. Grey listing and trapping are only the first line of defense against spammers. In future posts I’ll dig into what countermeasures are available once mail reaches the MTA.