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).
Posts
