6.2 Security and Performance

The topics of security and performance go hand in hand. In some cases, such as when preventing system abuse via spam or mail bombing, an improvement in security will result in an improvement in performance. In other cases, increasing security through additional database lookups, DNS requests, or use of strong encryption brings a cost in performance to some aspect of the system. This section will explore some of these trade-offs.

6.2.1 Don't Blame sendmail

A large number of configurable parameters appear under the heading of the DontBlameSendmail option in the configuration file. As the name suggests, it is risky to modify any of these options from their default (safe) settings. If the configuration of a given server seems to call for such a modification, rethink the configuration instead. None of the available options has a significant chance of measurably improving performance, so that excuse should not be used as a rationalization for potentially reducing the security of a server.

6.2.2 Privacy Options

The PrivacyOptions option is primarily designed to fine-tune how sendmail responds to SMTP queries. By default, sendmail is very permissive about what it will tolerate in terms of broken SMTP implementations on the Internet. As the name of this option implies, many sites may want to restrict the information they make available via remote SMTP queries. Some of these options may have modest performance implications. A complete list of the options available appears in the Sendmail Installation and Operation Guide. Some more relevant options are listed here. Note that not all of these options are available in every sendmail version.

novrfy If this option is set, sendmail will no longer respond to the SMTP VRFY command. The VRFY command is used to find out if a given email address is a valid one known to the server. Email administrators often disable this option to make it more difficult for spammers to find out what user names and, therefore, email addresses might be valid on a particular server. However, if this option is taken away, spammers may resort to sending email to all possible names on their list. Nonetheless, I generally recommend disabling this option on email servers connected to the Internet.

noexpn Similar to the situation with novrfy, if this option is set, sendmail will no longer allow the SMTP EXPN command. The EXPN command is a little more resource intensive. That is, it doesn't just return an indicator of whether an email address is valid, but also checks the aliases file, .forward files, and virtusertable to find out whether the email address in question is rewritten to some other email address, and returns that information. Certainly, if novrfy is set, noexpn should be as well.

noverb If either noexpn or novrfy is set, noverb is assumed. VERB is a nonstandard SMTP command that sendmail accepts to switch into a verbose mode. It is very useful for debugging email problems from a remote machine by using telnet to connect to the SMTP port. Unfortunately, it can also give outsiders a great deal of information. VERB should probably be disallowed on any email server connected to the wider Internet.

restrictmailq This option restricts running of the mailq command to the root user and the user who owns the mail queue(s). If a lot of email is queued, running mailq can be quite resource intensive. If general users have access to an email server that often has deep queues, and mailq is abused by being run too often, it may be prudent to restrict its use via this option.

restrictqrun If sendmail is set-user-ID root, then any user may start a queue run by typing sendmail -q.Onlightly loaded servers, this ability shouldn't be a problem and might actually be a useful feature. On a heavily loaded server, the frequency with which queue runners are started may be closely managed. Again, if a potential for abuse exists, it may be necessary to disable this service.

noreceipts If this option is set, then successful delivery return receipt DSNs will not be sent back to people who request them. While this elimination will reduce the amount of email processed by a server, albeit not by very much at most sites, it's not very nice. I wouldn't recommend disabling this feature unless as a temporary measure, or if it is abused by antisocial folks at other sites.

nobodyreturn Usually when a DSN is sent, whether as a warning, a bounce message, a return receipt, or for any other reason, the entire message is returned to the sender. Sometimes this returned message body is useful for the context. If the nobodyreturn option is sent, just the headers are returned, not the body, saving some processing effort. If the email messages at a site tend to be large, or if the server is an outgoing mass mailer where the body contents are well known or don't contain any especially useful information, this option can prove useful. In any case, it is acceptable to set this option even if reducing load isn't the primary goal.

authwarnings This option will cause the addition of "X-Authentication-Warning:" headers to some email messages that originate from it. It indicates the user associated with the process that ran the sendmail command on that server if it's different from the individual who claims to have sent the message. This option adds an extra line to email headers if it's included, but the overall effect on server performance will likely be very minor. Nonetheless, no really good reason exists to enable it. On a relay host, because few, if any, email messages are sent from the command line, whether authwarnings was set is unlikely to make a difference. On a mass mailer, where email is generated and sent, it should probably not be enabled.

6.2.3 Blacklists

Spamming is an enormous problem on the Internet, so much so that some fairly desperate measures are widely used to help combat this scourge. One technique relies on blacklists, like the MAPS RBL [MAP]. This database contains a list of sites that the maintainers, in their estimation, consider to be spammers or havens for spammers, whether through ignorance or malice. Such a site typically works by having the email server query a site's database to see whether a connecting server is coming from a blacklisted network. If it is prohibited, a refusal is issued in response to the MAIL command during the SMTP connection, and the message is simply not transferred.

Of course, this approach requires yet another lookup over the network, and to a faraway server at that. It is possible to keep a copy of the MAPS database at a site, but one needs to jump through some hoops to do so. Information on how to obtain the necessary permission appears on the MAPS Web site. Given the staggering amount of spam traversing the Internet these days, reducing it by any significant extent may be worth the cost of the lookup, but this decision should not be made lightly. Moreover, enabling this service has much more profound consequences than mere performance issues. The folks who maintain these services tend to be more than a little draconian about which sites get blacklisted, and more than a few mistakes have been made. Subscribing to these services will reduce the amount of spam received by a site, but if general connectivity is important, it can carry a steep price.

In the relentless pursuit of cutting down on the amount of spam a site receives at nearly any cost, many choose to subscribe to services that aggregate lists of open relays, known spam sites, and other sites accused of antisocial behavior. In some cases, these aggregation lists require multihop queries to determine whether a given address is on the "bad guy" list. As an example, I might add the following lines in my .mc file:

 FEATURE('dnsbl', 'spam-b-gone.example.org') 

When I receive a message that might be spam, the email server will query the machine listed above. After consulting its own internal databases, spam-b-gone.example.org might turn around and query one, or perhaps many, other blackhole list servers to see whether the sender in question appears on anyone else's blacklist. This step can greatly increase the amount of time required to process each incoming email message. A small site might be able to afford this delay; a site concerned with email performance almost certainly will not.

6.2.4 Security

Beginning with sendmail 8.11, support for opportunistically encrypting email traffic between two SMTP servers became available to the Open Source community, via the Transport Layer Security (TLS) protocol [DA99]. This exciting feature allows two servers to exchange email without having the message contents become available to every prying eye on every intermediate network. The downside is that, like all cryptography, using this feature consumes CPU time.

Currently, very few sites support this option. A quick and unscientific count of my home machine's log file suggests that at the time of this writing, less than 10% of servers that send or receive email support STARTTLS, and I would suspect that I correspond with a crowd that's far more likely to use it than the average site. At the present time, probably less than 1% of all email sites support this option, although this number should rise over time. As long as the adoption rate stays low, supporting STARTTLS is unlikely to affect a server's loading, unless the computer is already CPU bound.

Even if adoption of STARTTLS does spread quickly, it remains unclear how much that change will affect email server load. Again, most email servers have CPU capacity to spare. Do they have enough to support encrypting the bulk of the email that they send or receive over the Internet? No one really knows. My advice would be to enable this option on servers that are not already CPU bound where it can do some good, and then keep an eye on these servers' CPU utilization rates. If CPU loading on the machine spikes up, this feature might be the cause, and evaluating the costs versus benefits of supporting this feature may become necessary.

6.2.5 Mail Filter Use

Beginning with sendmail 8.10, a quasi-official compile-time feature became available, and then became official with 8.12, called the Mail Filter API or "milter" for short. This general mail filter can operate on the envelope, message headers, and bodies to accept or reject messages based on the connection information or message contents. It also provides the ability to perform general header and message rewriting. Some potential applications include, but are by no means limited to, the following:

• Virus scanning

• Header rewriting/stripping

• Spam filtering

• Keyword search/spying on employees

• Removing excessively large attachments

• Removing especially risky attachments, such as Visual Basic programs

A milter application, which remains distinct from the sendmail program, runs as a single multithreaded daemon that can receive messages to examine from any number of sendmail processes. It receives the messages to be processed through either a UNIX domain or a TCP/IP socket, so the milter process doesn't even have to run on the same machine as the sendmail processes with which it communicates.

This technology is already incorporated into commercial products such as TrendMicro's Interscan VirusWall. Open Source projects such as the AMaViS email virus scanner [AMA] also take advantage of milter. While few applications are using milter as of this writing, its use is growing in both volume and sophistication. A milter advocacy Web site exists at http://www.milter.org/.

Of course, the text search-and-replace capability doesn't come cheap. If all email flowing through a busy server, or even a sizable percentage of it, passes through a global search-and-replace algorithm, it will consume significant resources and affect performance of the server as a whole.

Offloading the actual milter processing to another machine can help prevent an already busy server from becoming saturated, but memory will be consumed because sendmail processes will have longer durations due to the processing time of the milter application, the overhead involved in setting up the network connection, and the latency involved in a network round trip to the milter server.

To my knowledge no real-world performance studies using milter at high-volume email sites have yet taken place. I'd speculate that running servers in parallel that handle both email and their own filtering will be more efficient than running sendmail on one set of servers and milter applications on another. This strategy would eliminate network connections and their associated overhead, and most sendmail-only servers have CPU resources to spare that the milter application can use. However, we'll have to wait for real data to be collected to find out if this prediction is correct.