The following sections describe various features you might want to configure in your mail servers. Rather than repeat the descriptions of what these options mean in each section, I describe them once here.
One of the most common configuration changes required of a mail server is address masquerading ”changing the hostname that the mail server claims to be. Ordinarily, most SMTP server installations use the hostname as set in the basic network configuration and as returned by the hostname command. The MTA uses this hostname in its HELO greeting when contacting other mail servers, as well as in the MAIL FROM command and From: message header if the mail doesn't already include that information. The server also identifies itself with this name to connecting computers, as in the 220 response in Listing 19.1.
This approach works fine in most situations, but sometimes you may need to use another name. For instance, suppose your mail server is called franklin.threeroomco.com . You might prefer that outgoing mail never be identified as coming from this computer, but instead from the threeroomco.com domain. (This might be important if you've got separate incoming and outgoing mail servers, for aesthetic reasons, or to allow you to more easily change your mail server without disrupting mail sent as replies to the default address.) You might also want to change the hostname used by a computer on a firewalled network so that return messages go to an externally accessible system. The solution is to use address masquerading to have franklin.threeroomco.com announce itself as threeroomco.com . All the mail servers discussed in this chapter can perform address masquerading, but details differ . Some include extensive options to let you fine-tune which commands, greetings , and headers use the new name, but others give fewer options. Some make it relatively easy to alter existing message headers to reflect some new address, but others discourage such actions.
Accepting Mail as Local
The flip side to address masquerading is telling the mail server what addresses to treat as local. For instance, you might run a mail server that's called franklin.threeroomco.com . The default configuration in most SMTP server installations is to accept mail addressed to users at franklin.threeroomco.com . If your domain is set up with an MX record that points at this system, though, it will also see mail addressed to users at threeroomco.com . Furthermore, you might want to configure the mail server to accept mail addressed to completely different hostnames or domains. Perhaps the company has recently expanded and changed names , so you want to add fourroomco.com to the list of domains that the mail server will accept and deliver locally.
All the mail servers covered in this chapter allow you to specify what hostnames the server is to interpret as local. When you configure such a list, the server accepts mail addressed to users at these addresses and drops the messages into the users' local mailboxes (or forwards the mail, if the server is configured to forward a user 's mail to another system). The details of this configuration differ from one server to another, of course.
One of the trickiest, and potentially most dangerous, aspects of mail configuration today is proper configuration of a mail server to handle mail relays. A mail relay system is one that accepts mail from one computer and delivers it to another. Most networks use at least one mail relay system, because network connections are sometimes unreliable. If a client attempted to deliver mail directly to the recipient and the connection failed, the mail client program would have to continue running to periodically attempt redelivery. An SMTP server configured as a relay, though, can accept mail from the local network with high reliability, then hold onto the mail until network conditions allow its delivery.
Unfortunately , relay configurations can be easily abused. If the MTA is too promiscuous in the systems for which it will relay, the server can be abused by third parties to send spam ( unsolicited junk e-mail). Thus, you must find the appropriate balance to secure your server against unwelcome users while still allowing legitimate users to use the server as a relay. The correct configuration depends upon the role of the mail server program in your network, and that in turn depends in part upon your network structure.
Sometimes you may need to configure your system for third-party relaying. This is allowing an outside system to use yours as a mail relay. This is ordinarily undesirable, but there may be circumstances in which you might want to allow it. For instance, you might want to let employees who are traveling use a mail server on your own network to relay mail. Many MTA relay options that are ordinarily used to permit local relaying can be used to enable third-party relaying. You might enter the third-party IP address, domain name, or the like in the configuration options just as you would a local address or name.
You may also want to configure an SMTP server to deliver all or some of its mail via another SMTP server. You might want local workstations to send mail via the departmental mail server, for instance, despite the fact that the workstations' MTAs are capable of direct delivery, in order to better track e-mail. Systems that use dial-up connections may need to use a relay in order to deliver mail at all, because some ISPs place their dial-up addresses on an anti-spam list that's used by others to block direct SMTP connections. Using the relay on such a network allows for more reliable mail delivery.
When e-mail was invented, it was considered a useful means of personal communication, and it remains that. Unfortunately, advertisers have discovered that e-mail can be an inexpensive way to communicate with potential customers. I say "unfortunately" for two reasons. First, much of the e-mail advertising today is of the lowest kind ”get-rich-quick scams, ads for pornographic Web sites, and worthless products. Second, e-mail advertising is clogging mail servers around the globe, and the potential for serious harm from this form of advertising is still greater. Sending e-mail is very inexpensive, but receiving it is costlier, in terms of disk space used, recipients' time to read or even simply delete the messages, and so on. If spam becomes popular with more businesses than those of questionable repute who currently use it heavily, e-mail will quickly become completely useless, as our e-mail inboxes become clogged with thousands of worthless messages a day.
Because of concerns about spam, mail administrators frequently take steps to block it. These blocks occur at two levels: Stopping spam from getting into a mail server, and stopping it from getting out.
Blocking Incoming Spam
Your own personal concerns about spam probably revolve around the spam that's directed at your system, because this is the spam that's most obvious to you. There are several ways to control such spam. The more popular methods include the following:
As a general rule, you can block a great deal of spam using just one or two methods, such as an MTA-based pattern match or a single blackhole list. One of the problems with any anti-spam measures you might take is that there is no way for a computer program using today's technology to determine with 100% certainty that a given message is spam. All the spam-blocking methods therefore rely upon generalizations of one sort or another, such as patterns that often appear in spam headers or the IP address from which a message comes. These generalizations often catch spam, but they may also discard legitimate e-mail, as well. Occasional false positives like this may be acceptable to you, or they might not be. To minimize the risk of false positives, you can use simple custom pattern- matching rules that match by very narrow criteria. Among the blackhole lists, the RBL and RSS are least likely to produce large numbers of false positives. The blackhole lists operated by the Mail Abuse Prevention System (MAPS) ”the RBL, RSS, and DUL ”are offered on a subscription basis, with an exception made for hobbyist sites.
Table 19.1. Common Anti-Spam Blackhole Lists
How to Avoid Becoming a Spam Source
Although you're probably most concerned with blocking incoming spam, you should pay at least as much attention to preventing your system from being used to transmit spam. On a large network, you may need to be careful to police your own users to be sure they don't originate spam. This may involve creating an acceptable use policy (AUP) that prohibits spamming and ensuring that your users are aware of it. Some users may not realize the extent to which spam is frowned upon.
Especially on a small network or an individual workstation on which a mail server is installed, a more serious concern is that of configuring your system so that it doesn't become an open relay ”a computer that's configured to relay mail from any system on the Internet to any other system on the Internet. (Even relaying between subsets of systems may be problematic , if those subsets are large enough.) Much of the upcoming discussion of individual SMTP servers is concerned with relay configuration. You may need your system to relay for certain systems, but it's important when you create this configuration that you don't open your system too widely.
One way to test whether a system is an open relay is to Telnet from that system to relay-test.mail-abuse.org. Doing this causes a reverse connection to your own mail server. You'll see the tests as they proceed, followed by a statement that your system is or is not an open relay. Although this test can be very useful, it's not absolutely conclusive; there are configurations that can fool the test, but it's a good place to start.
To learn more about anti-relay configurations, including tips for how to configure various mail servers, check the MAPS Transport Security Initiative (TSI) Web page at http://mail-abuse.org/tsi/.