During a recent 24-hour period, one of Network Computing's small (20 user) mail servers blocked 2,478 messages from known spammers, stopped 61 messages via a spam trap and permitted about 1,000 spam messages to be delivered. That's 177 pieces of spam addressed to each user on this server in a single 24-hour period. Do the math--that's a staggering 64,605 spam messages per year per user. Admittedly, our e-mail addresses are plastered prominently all over the Web, so we're easier targets than most, but based on our experience we don't think the analysts' predictions are off by much. And the saddest part of that story is the 1,000 junk messages that got through despite the costs we've incurred and the protective measures we've implemented in our fight against spam.
Spam Trap: This term has several meanings. One, a spam trap is an address that is incapable of requesting information or subscribing to lists, so if e-mail is sent to it, the originator is sending unsolicited mail. A second definition is those sneaky options that are preselected by default and give spammers permission to bombard you. Advise users to check online forms carefully (see http://www.lecb.ncifcrf).
So what's a harried e-mail administrator to do? Unfortunately, right now there is no perfect answer. Blacklists are reactive, and filtering tools aren't smart enough to block every message that is spam and pass every message that isn't. What you can do now is combine the available spam-fighting tools to help stem the tide.
Ingredient 1: A Soup'on of Secrecy
Some advise you to never give your e-mail address to anyone, or at the very least, to obscure it when using it in electronically visible places, such as the Web or Usenet newsgroups. Others use public e-mail addresses, usually from a free mail service, when conducting business on the Internet or posting to newsgroups, reserving their main addresses for business and personal use. But these strategies are imperfect: It takes just one slipup--once the address is had, it is had.
From an administration standpoint, your first line of defense should be to implement system-wide rules that block known spam. We started getting a number of junk messages that had a particular string in the "From" header. We blocked these by creating a simple server-based rule that rejected mail with that particular header. Problem solved, and it took only a minute or so, at least for that single sender. And therein lies the problem--the target is always moving, and this solution is designed to hit a stationary mark. Many servers let you create your own blacklists of offending IP addresses. This is the same concept, a quick and dirty method for blocking spam but one that doesn't scale well and, again, is reactive rather than proactive.
If you have sophisticated users, they may be able to create rules on a per- user basis, either at the server, if your mail server permits user rules, or locally, using the rules capabilities of their own mail clients. For example, some users on our mail server move all messages originating from free mail servers, such as yahoo.com and hotmail.com, into folders separate from their inboxes so they can deal with them when they have time. Some even go so far as to delete these e-mails automatically because nearly all of them are spam. We don't advocate this method without consulting your users, many of whom will have a legitimate need to get e-mail from free-service users.
Ingredient 2: The Blacklist Du Jour
Spam blacklists, also known as block lists, offer a valuable automated tool as your second line of defense. A blacklist lets your mail server query, via DNS, a list of known spammers maintained by a variety of organizations, such as MAPS RBL (Mail Abuse Prevention System Realtime Blacklist; mail-abuse.org), SpamCop (spamcop.net) or Spamhaus (spam haus.org). If your server's blacklist DNS query returns a hit, meaning that the sending server has a DNS record on the blacklister's DNS zone, the system that is sending mail is a known spammer.
Blacklists are created and maintained in a variety of ways, from sending "robots" out to look for open relays then listing them when they're found, to creating the lists dynamically based on day-to-day, minute-by-minute analysis of user reports. SpamCop uses the latter method, along with a scoring system that factors in the percent of spam sent from a system versus legitimate e-mail, the freshness of the report, and whether the report is for mail sent to a spam trap (SpamCop gives these reports double weight). SpamCop removes a blacklist entry if it has fewer than three reports against it and no report is newer than six hours.
When mail arrives from a server that is on a blacklist, you have some handling options. For instance, the incoming message can be refused, or it can be rerouted away from the user. Also, most mail servers optionally will send a message back to the original sender, assuming his or her return-to address hasn't been forged, stating that the mail server has been blacklisted and your organization won't accept his or her mail.
By the Numbers
$77.50: Amount California small-claims court awarded Ellen Spertus when she sued Kozmo.com for sending spam after she opted out
$4.26: Amount Spertus collected
$27.50: Amount she spent in legal fees
483,000: Hits on Google for "stop spam"
16,500: Square footage of official Austin, Minn., Spam museum
Of course, as you can see from "A Day in the Life of an E-Mail Administrator" (page 63), a return message about blacklisting often causes confusion, but we feel this step is necessary so that senders understand their mail isn't getting through to your users and can open a dialog with you to see what can be done. Consider the wording of your return message carefully to avoid any unnecessary confusion.
Blacklists, when used in the right combination, are a great defense mechanism. We use MAPS, SpamCop and Spamhaus, and that combination is about right for our users--we don't get many complaints from legitimate mail senders, and we're able to block thousands of spam messages a day. Some lists are stricter than others, increasing the risk of blocking legitimate mail, and some don't do enough to block spam. Your mileage will vary depending on your users' needs; it's a good idea to research prospective blacklists to find where they are on the spectrum.
Because these lists are maintained by their creators, administrative overhead is low. Each list does require a DNS lookup per list per message (we do three DNS queries per message plus a reverse DNS lookup to make sure the server is really who it says it is) so there is some expense on the server side in terms of CPU cycles and on the network to perform the lookups.