Beating'em up some more: spamdb and greytrapping
Behind the scenes, rarely mentioned and barely documented are two of spamd's helpers, the spamdb database tool and the spamlogd whitelist updater, which both perform essential functions for the greylisting feature. Of the two spamlogd works quietly in the background, while spamdb has been developed to offer some interesting features.
 | Restart spamd to enable greylisting |
|---|---|
If you followed all steps in the tutorial exactly up to this point, spamlogd has been started automatically already. However, if your initial spamd configuration did not include greylisting, spamlogd may not have been started, and you may experience strange symptoms, such as your greylists and whitelist not getting updated properly. Under normal circumstances, you should not have to start spamlogd by hand. Restarting spamd after you have enabled greylisting ensures spamlogd is loaded and available too. |
spamdb is the administrator's main interface to managing the black, grey and white lists via the contents of the /var/db/spamdb database.
Early versions of spamdb simply offered options to add whitelist entries to the database or update existing ones (spamdb -a nn.mm.nn.mm ) and to delete whitelist entries (spamdb -d nn.mm.nn.mm) to compensate for shortcomings in either the blacklists used or the effects of the greylisting algorithms.
By the time the development cycle for OpenBSD 3.8 started during the first half of 2005, spamd users and developers had accumulated significant amounts of data and experience on spammer behaviour and spammer reactions to countermeasures.
We already know that spam senders rarely use a fully compliant SMTP implementation to send their messages. That's why greylisting works. Also, as we noted earlier, not only do spammers send large numbers of messages, they rarely check that the addresses they feed to their hijacked machines are actually deliverable. Combine these facts, and you see that if a greylisted machine tries to send a message to an invalid address in your domain, there is a significant probability that the message is a spam, or for that matter, malware.
Enter greytrapping
Consequently, spamd had to learn greytrapping. Greytrapping as implemented in spamd puts offenders in a temporary blacklist, dubbed spamd-greytrap, for 24 hours. Twenty-four hours is short enough to not cause serious disruption of legitimate traffic, since real SMTP implementations will keep trying to deliver for a few days at least. Experience from large scale implementations of the technique shows that it rarely if ever produces false positives[1] . Machines which continue spamming after 24 hours will make it back to the tarpit soon enough.
Your own traplist
To set up your own traplist, you use spamd's -T option. In my case, the strange address I mentioned earlier[2] was a natural candidate for inclusion:
peter@delilah:~$ spamdb -T -a "<wkitp98zpu.fsf@datadok.no>"
Sure enough, the spammers thought this was just as usable as almost two years ago:
Nov 6 09:50:25 delilah spamd[23576]: 210.214.12.57: connected (1/0) Nov 6 09:50:32 delilah spamd[23576]: 210.214.12.57: connected (2/0) Nov 6 09:50:40 delilah spamd[23576]: (GREY) 210.214.12.57: <gilbert@keyholes.net> -> <wkitp98zpu.fsf@datadok.no> Nov 6 09:50:40 delilah spamd[23576]: 210.214.12.57: disconnected after 15 seconds. Nov 6 09:50:42 delilah spamd[23576]: 210.214.12.57: connected (2/0) Nov 6 09:50:45 delilah spamd[23576]: (GREY) 210.214.12.57: <bounce-3C7E40A4B3@branch15.summer-bargainz.com> -> <adm@dataped.no> Nov 6 09:50:45 delilah spamd[23576]: 210.214.12.57: disconnected after 13 seconds. Nov 6 09:50:50 delilah spamd[23576]: 210.214.12.57: connected (2/0) Nov 6 09:51:00 delilah spamd[23576]: (GREY) 210.214.12.57: <gilbert@keyholes.net> -> <wkitp98zpu.fsf@datadok.no> Nov 6 09:51:00 delilah spamd[23576]: 210.214.12.57: disconnected after 18 seconds. Nov 6 09:51:02 delilah spamd[23576]: 210.214.12.57: connected (2/0) Nov 6 09:51:02 delilah spamd[23576]: 210.214.12.57: disconnected after 12 seconds. Nov 6 09:51:02 delilah spamd[23576]: 210.214.12.57: connected (2/0) Nov 6 09:51:18 delilah spamd[23576]: (GREY) 210.214.12.57: <gilbert@keyholes.net> -> <wkitp98zpu.fsf@datadok.no> Nov 6 09:51:18 delilah spamd[23576]: 210.214.12.57: disconnected after 16 seconds. Nov 6 09:51:18 delilah spamd[23576]: (GREY) 210.214.12.57: <bounce-3C7E40A4B3@branch15.summer-bargainz.com> -> <adm@dataped.no> Nov 6 09:51:18 delilah spamd[23576]: 210.214.12.57: disconnected after 16 seconds. Nov 6 09:51:20 delilah spamd[23576]: 210.214.12.57: connected (1/1), lists: spamd-greytrap Nov 6 09:51:23 delilah spamd[23576]: 210.214.12.57: connected (2/2), lists: spamd-greytrap Nov 6 09:55:33 delilah spamd[23576]: (BLACK) 210.214.12.57: <gilbert@keyholes.net> -> <wkitp98zpu.fsf@datadok.no> Nov 6 09:55:34 delilah spamd[23576]: (BLACK) 210.214.12.57: <bounce-3C7E40A4B3@branch15.summer-bargainz.com> -> <adm@dataped.no>
This log fragment shows how the spammer's machine is greylisted at first contact, and then clumsily tries to deliver messages to my greytrap address, only to end up in the spamd-greytrap blacklist after a few minutes. By now we all know what it will be doing for the next twenty-odd hours.
Deleting, handling trapped entries
spamdb offers a few more options you should be aware of. The -T option combined with -d lets you delete traplist mail address entries, while the -t (lowercase) option comined with -a or -d lets you add or delete trapped IP address entries from the database.
Exporting your list of currently trapped addresses can be as simple as putting together a simple one-liner with spamdb, grep and a little imagination.