With a large percentage of e-mail being unsolicited—and that number is increasing every day—there's a growing need to tighten e-mail policies in an effort to block spam. The creators of Sendmail are certainly aware of this issue and continue to create antispam options for mail administrators. Later versions of Sendmail deny open relaying and come with increased tools for verifying just who is trying to make use of your SMTP service. By using built-in options and actively monitoring your mail server, you, too, can lock Sendmail down tight and help the fight against spam. I'll show you how.
Thomas Nooning's "Take advantage of antispam options for Sendmail" looks at the various solutions for implementing antispam measures in Sendmail.
First and foremost
Is your mail server an open relay? If you can answer assertively that it isn't, wonderful. Otherwise, if you’re not sure, it's certainly worth checking. It may be advisable to scroll through your logs and get a feel for what exactly is being sent through your mail server. You can also perform a series of tests at Abuse.net. If any of the tests come up positive, you need to take immediate steps to secure your Sendmail server against a hijack by spammers. If you're running a version of Sendmail earlier than 8.9.3, the recommended approach is to upgrade as soon as possible. If this isn't an option, you can still lock down 8.8.x to a certain degree. For any versions before that, you're probably in trouble and need to make an upgrade a priority.
In 8.8.x, relaying is denied through "check_ entries." These include check_relay, check_mail, and check_rcpt. The check_relay command will not turn off relaying as such, but can deny access based on IP address or hostname. This method is cumbersome and difficult to implement, since you basically need to gather a list of domains and/or IP addresses that should not be allowed. It's much easier to select what IP addresses should be allowed and deny the rest. You can accomplish this with check_rcpt by creating a file containing allowable sources. List the IP addresses you want to allow in a plain text file, for example /etc/mail/LocalIP. You can allow mail from your internal network by placing 192.168.1, for example, on a line by itself. Anything in the 192.168.1.0/24 range will then be allowed to relay mail based on the actual rules. Here is a snippet from Sendmail.org showing the syntax of these rule sets. As you can see, the rules are a bit on the unintelligible side and are probably justification enough to warrant an upgrade to Sendmail 8.9.3 (and above), which is much simpler to configure.
Controls in 8.9.3 and above
Relaying is denied by default in Sendmail 8.9.3. If you want to allow a domain to send mail through your server, add it to /etc/mail/relay-domains. This is just a flat file with domain names listed one per line. Any host that exists in that domain will be allowed to relay. So if you entered "example.net," the host "rogue.example.net" would be allowed automatically. This can be limited by using FEATURE(relay_hosts_only). Individual hosts will then need to be listed in /etc/mail/relay-domains to be allowed through. There are a number of other FEATURES that Sendmail provides to assist with controlling SMTP access. Two of the most valuable are FEATURE('access_db') and FEATURE('dnsbl').
This supports the creation of an access database (not Microsoft Access but access in the generic sense). With such a database, you can be much more specific on how individual e-mails are to be handled. Instead of just a blanket yes or no, you could, for instance, reject mail from a single address while allowing the rest of the domain to send. The file typically used for the database is /etc/mail/access and will look like Listing A.
First, we're telling Sendmail to accept and relay mail to or from the local host, represented in this example by the loopback IP 127.0.0.1. Next, we allow mail from the internal host 192.168.1.25 to be accepted. The “OK” also bypasses other checks that may cause a rejection, for instance, if the internal host is not configured in DNS. This is not the same as allowing the host to relay, but it will accept mail destined for local users. The domain “bulkemail.com,” with such a nefarious name, is of course denied the ability to relay mail.
Finally, we're also denying the individual user "email@example.com" the ability to send mail. This is helpful when you encounter spammers originating from a large domain, such as an ISP (msn.com or comast.net, for example). While you wouldn’t want to stop all mail from those domains since the majority could, in fact, be valid, there are instances when shutting down one or more individuals is highly beneficial. Once you have a list of entries, the database needs to be created using the command in Listing B. Sendmail should then be restarted so that changes will take effect.
The FEATURE('dnsbl’) option will allow you to deny inbound mail from any site listed in the Mail Abuse Prevention System's Realtime Blackhole List (MAPS RBL). The RBL contains a large number of IP addresses found to be friendly or neutral to spammers. Open relays would also fall into this category, since it's impossible to trust such a mail server. Basically, when a remote host attempts to deliver mail to your server, a DNS lookup is performed against the blackhole list. If an entry corresponds to the IP address that is sourcing the SMTP request, the e-mail is rejected. This is a way for you to automatically knock out a lot of spam.
One of the drawbacks of this type of service is that you don't have total control over what is listed. MAPS basically denies entire network blocks based on their willingness to allow spam. While this is beneficial to the overall fight against spam, the bottom line is that you need to consider what's best for your users. If important mail is being denied based on such a service, you may need to open things back up and manually deny specific spam generators on your own.
The syntax for setting up a Sendmail server to use a blackhole list would look something like Listing C. While the MAPS RBL is perhaps the granddaddy of blackhole lists, there are a number of others that can also be used by Sendmail. Here is a large list of available DNS-based spam databases.
Other protection methods
There are a number of alternate antispam methods that have become popular in the last few years. These include POP-before-SMTP and SMTP AUTH. These are more beneficial for private mail servers that have public presences. Users who need roaming or off-site access will be able to use the server, but public parties will not be able to use it.
POP-before-SMTP works on the assumption that if a user has access to POP, which requires authentication, the user should then be allowed to send e-mail. This involves first modifying the POP3 daemon to log the IP address of the authenticated user. Next, you'll have to run a script to watch for these entries in the log. Finally, you'll need to update Sendmail with this information. There are a number of free sources to assist with this configuration, but much will depend on your particular system. Some clients, such as Microsoft Outlook, have an option to automatically log into the inbound server (POP3) before connecting to the outbound server (SMTP). Note that your server would, of course, need to be preconfigured for this behavior before this option would work.
SMTP AUTH allows you to bypass the need to authenticate via the POP3 daemon and authenticate directly into Sendmail. If you look at the options on modern mail clients, you'll typically see one to use authentication on your outbound server. This is usually a username/password combo.
The first step to get such a mechanism functioning with Sendmail is to install Cyrus SASL. SASL, or Simple Authentication and Security Layer, provides the means to verify usernames and passwords. There are a variety of methods for authorizing users, from plain-text passwords to the local system’s /etc/passwd. If you're interested in implementing such a design, you should read up on the docs to see what is best for you. Once Cyrus SASL is configured, you'll need to compile Sendmail with the options in Listing D.
If you're thinking about running SMTP AUTH, remember that no one except verified users will be able to send mail to or through that server. Typically, servers need to be able to accept mail from anyone, which is where many of the problems associated with spam come into play. But if you simply have a private (internal) mail server, there’s no reason not to lock it down completely.
The best protection against spam is a multilevel approach. You should start off by denying open relaying, allowing only specific networks or hosts to use your server to send outbound e-mail. You can further protect against spam being delivered to local mail users by using one or more of the public DNS blackhole lists. This will help prevent known spammers or spam-capable networks from depositing spam in your inboxes. And if you're running a private server, you can lock it down.
The spam problem is not going to go away overnight; it has proven too successful for those willing to distribute it. Working to lock out spammers is the only way administrators can make a difference, and it's one that will have lasting benefits for your company’s employees, as well as Internet users in general.
Here's some additional reading that can help administrators in the antispam battle: