Securing the Mail: Lock Spam and Viruses Out of Sendmail

By Dee-Ann LeBlanc | Jul 9, 2002 | Print this Page
http://www.enterprisenetworkingplanet.com/netsecur/article.php/1382251/Securing-the-Mail-Lock-Spam-and-Viruses-Out-of-Sendmail.htm

Repeat after me: "Spam and viruses bad. Locked down mail servers good. Leaving relaying open bad. Locked down mail servers good. Leaving virus avoidance for the end user to deal with bad. Locked down mail servers good." Okay, now that we've got that over with, let's take a look at some methods for locking down a popular mail server in the Linux and UNIX realm: Sendmail.

Securing Sendmail 8.9 Against becoming A Tool for Spammers
Sendmail 8.9, the latest version, comes locked down against relaying right out of the box: you can find out more about previous versions by going to the Sendmail web site (Resources). So rather than focusing on initial configuration, let's look at a more insidious problem: taking over someone else's Sendmail setup and making sure they haven't punched any holes in it spammers might use.

Don't roll your eyes. There are a lot of administrators who just kind of fell into their jobs, and rather than learning the proper way to do things will punch security holes to get their workarounds to function. Maybe you were even one of them once, but now you know better, but you've forgotten to go back and clean up all of your old messes.

The key files for your Sendmail relaying setup are /etc/mail/access, and /etc/mail/relay-domains. /etc/mail/access is built in a series of single-line entries, and each of these entries consists of two components. The first half of an /etc/mail/access line contains information on whom the rule applies to; for example, 192.168.25.3 means this rule is meant for the machine with this IP address. The second half expresses what the rule is setting: for example, using RELAY here tells Sendmail to allow 192.168.25.3 to relay email through this server.

For more details on /etc/mail/access, be sure to have the Sendmail documentation installed, and then take a look in the file /usr/share/doc/sendmail/README.cf. This is a long document. A great shortcut is to search through it for the term access_db, which will take you faster to the correct spot for data on what terms are available for this file. If you don't know how to search through a file, here's the general sequence of events. Type less /usr/share/doc/sendmail/README.cf to view the file's contents a screen at a time, then type /access_db and press Enter to begin your search. If the first time doesn't bring you to what you're looking for, press N to repeat the search with the same term as before.

/etc/mail/relay-domains is a slightly different beast but only just barely. Where /etc/mail/access is used for allowing external users to relay mail through the server, /etc/mail/relay-domains is used for local relaying. This file utilizes the same format as /etc/mail/access.

For additional information, see
http://www.sendmail.org/~ca/email/relayingdenied.html.

Blocking Spam from Reaching Your Users
So you're sure you're not part of the spammer problem, but your users are buried in the stuff. Fortunately there are tools out there that can help on the server side of things. They have to be utilized carefully, however. Whenever you try to filter out all of the bad, whether we're talking about web pages, email, tuna, or books, you always tend to catch unintended items in the net.

There are outside services you can pay to filter your mail for spam, viruses, and more, but this article focuses on self-help so let's look at what you can do with your own server. The key for many people is something called a real time black hole list, which consists of a web site whose maintainers keep track of servers that are not properly locked down -- and therefore used by spammers to annoy us all -- and then allows other sites access to this information.

There is only so much room to cover so many important things in this article, so I'll leave the details to the Sendmail.org documentation (see Resources, below).

Setting Sendmail 8.9 and Up to Snag Viruses
On the virus front, Sendmail does not natively support virus scanning. That doesn't mean you can't scan email for viruses in conjunction with the Sendmail server. There are a number of tools available out there, and typically you'll need both a gateway (an intermediary program between Sendmail and the antivirus program) and a virus scanner.

You can write your own gateway or make use of one of those already out there. Two gateways known to work well with Sendmail are Tamiz and AMaViS. (See Resources)

There are a larger number of antivirus programs out there that work under Linux and Unix than you might have guessed. These software packages include Sophos Sweep , Trend Micro FileScanner, CAI's eTrust InoculateIt, and McAffee. (See Resources)

Note that AMaViS works with a number of popular Linux and UNIX email servers. Even if you're not using Sendmail on your Linux or UNIX system, there's no excuse to leave virus issues for the end users to deal with. Clean them up at the server end. But don't trust them blindly, make sure they send you notices about what's been blocked, and double-check on occasion to make sure nothing innocent was caught.

Wrapping Up
If you pay for bandwidth, then it's imperative you get spam and viruses under control. A spammer making use of your server can cost you heavy traffic costs. The spam your users have to download from the server costs a bundle in both bandwidth and productivity. And last but not least, when even one of your users activates a virus, that program then sends a surge of activity both internally and out to the Internet.

Unfortunately, it's not usually just one user who falls for a virus. Look at it this way. I have a virus scanner on my Windows box and we run a virus scanner and spam blocker on the Linux Sendmail server. I never even knew the Klez virus existed until I started hearing people complain about it. Even as Klez attacked repeatedly over the weeks, it wasn't something I personally had to deal with: in twenty-five days, our setup stopped 187 viruses from reaching me, 178 of them being from Klez, six of them being the new Yaha one, and some others.

That's enough viruses to count as spam as far as lost productivity time! And 187 times I was not at risk of activating a virus through sloppiness. If I were a non-technical end user, what do you think the chance might be that I might have opened at least one of those?

Resources: