6.5. Mail Server Configurations

So far we've discussed some of the attacks possible against mail servers and brought up a number of additional security-related issues. We've also introduced several methodologies to protect servers from attack and stem the flow of unwanted mail. That is, we've discussed what the problems are, and to some extent, what solutions exist. We now turn our attention to where you can put some of these solutions into effect.

In order to examine specific "cases" of mail servers, we have to look at our infrastructure purely in the context of mail flow. We no longer care what a server is, only how it handles mail. Figure 6-3 shows four kinds of mail servers: the mail relay, the internal/external mail servers, and the null-client.

Figure 6-3. Four classes of servers

This is by no means the only possible mail architecture, merely one of the most commonly seen in small to medium sized companies with typical electronic messaging requirements. In particular, the flow of mail into and out of an organization may be handled by completely different sets of servers. There may be cases where flows need to be split so that inbound mail is processed by a different set of rules and restrictions than outbound mail. In most situations, however, single servers are capable of handling bidirectional flows.

6.5.1. Null Client

The null client is a workstation or server that performs no local delivery and accepts no mail from outside the system. Any mail generated from the system is immediately sent to one preconfigured server. Most servers that do not handle mail for a living fall into the null client category. Workstations that do not perform local delivery may also be null clients. Virtually all desktop systems, whether they run Windows, Mac OS, or some kind of Unix, should be configured as null clients.

Fortunately configuring null clients is simple:

• Disable any daemons listening for SMTP traffic, or restrict the daemon to the loopback interface.

• Configure the MTA to accept mail originating on the system and to send it to an upstream mail server.

No other mail "intelligence" is required for a null client. Generally, the configuration never changes throughout the life of the machine, even though the mail software will be periodically upgraded.

6.5.2. Internal Mail Server

The internal mail server is a particularly complex system. It not only houses an MTA, which accepts mail from the mail relay and local null clients, it also performs local delivery and provides mail access. Finally, it's responsible for taking any mail not destined for the organization and passing it on to the mail relay.

When configuring your internal mail server, keep in mind the following:

• Only administrators should be able to log in.

• The operating system should be locked down as much as possible. See Chapter 3 and Chapter 4 for more information on system hardening.

• All changes to configuration files (in general, but especially those pertaining to your mail software) should be tracked. Consider using sudo to control which administrators are allowed to make configuration changes. This will also help your audit trail.

• Any mail leaving this server should appear to come from your domain, not the hostname of your mail server. You should take pains to ensure all outgoing email addresses are valid. Some local accounts may be exceptions to this rule, for example root and cron.

• The administrator should know every program to which mail may be redirected through an alias, a .forward file, or an :include: mailing list. Configure your MTA software to restrict the programs which may be used as destinations in these files. You may even restrict it so that no programs may be used as destinations in these files.

• Disable any MTA functionality you don't need.

• Any message size limit you specify in an internal mail server will affect mail between organizational users. You should set a threshold, but it may be higher than similar limits on the mail relay.

• Virus protection may be useful. The virus protection on your relay helps keep viruses from entering or leaving your organization. Internal virus protection is also mandatory to keep viruses from spreading within your organization after having been brought in on a floppy or some other out-of-band mechanism. Use a different vendor than you do on your mail relay as the union of virus signatures from different vendors will be greater than if you only choose one vendor.

• Configure SpamAssassin with per-user controls, if possible.

• Provide secure access. This will include requiring authentication for both sending and receiving mail and protecting the communications channel using some form of encryption.

While this is not an exhaustive list of configuration possibilities on an internal mail server, you should give careful thought to each one.

6.5.3. Mail Relay

A mail relay can provide an excellent strategic opportunity to the mail administrator. Figure 6-3 shows a mail architecture where every message entering and leaving the organization passes through this system. This is the ideal system to make early accept/reject decisions for incoming and outgoing mail.

Some argue that mail originating from internal users is generally legitimate and should not be checked. However, internal users may repeatedly send large attachments outside the organization that bounce. Setting a message size limit ensures you aren't wasting resources. In addition, in a virus outbreak, you wouldn't want infected mail leaving your network and infecting others.

When configuring your mail relay, refer to the first six bullets in the checklist for your internal mail server. They apply here also. In addition, consider the following:

• Message size limits should be configured here and should be more stringent than on the internal server. Values under 10 megabytes are appropriate.

• Use content filtering effectively whether by blocking certain networks, hosts, addresses, domains, or blocking by substrings in message headers or the message body.

• Configure DNS blacklists.

• Virus protection may be useful. Use a different vendor than you do on your internal mail server.

• You may want to configure SpamAssassin on the mail relay with reasonable default settings that apply globally. This will help you, in combination with content filtering, to block all UCE rated above a certain threshold at the relay level.

While these options are not exhaustive, you should carefully evaluate each for your mail relay.

6.5.4. External Mail Server

Not all organizations have an "external mail server." This is the server that lets remote users send and receive mail directly without the use of a webmail gateway or VPN. Sometimes these servers are placed along side a mail relay in the perimeter network. Other organizations choose to place them outside of any firewalls.

The external mail server should be configured just like an internal mail server. However, since these servers often need to relay mail for users from unknown networks, authenticated SMTP and encrypted sessions are mandatory.

In addition, external mail servers sometimes perform all mail duties for an organization, especially for organizations whose business it is to provide mail access to customers. In these cases, they may be strategically important just like the mail relay. You should evaluate all the configuration guidelines recommended for a mail relay on these systems also.

Now that we have covered problems and solutions in a general sense, it's time to get down to specifics. We now examine how to configure our mail servers to ensure they do what we need. To be able to answer these questions, let us first look at the relevant software.