SMTP Server Configuration Options

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.

Address Masquerading

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 . You might prefer that outgoing mail never be identified as coming from this computer, but instead from the 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 announce itself as . 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.



Some mail administrators look down on the practice of altering mail headers, because these headers are supposed to provide a clear path back to the originating system. Other mail administrators consider the ability to rewrite mail headers absolutely vital to avoid problems that might otherwise result from mail crossing firewalls or the like. If you're unfamiliar with mail administration, you're probably best off doing as little masquerading as possible, and adding these features only if you find you have problems. If used incorrectly, masquerading can result in confusion and even bounced mail.

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 . The default configuration in most SMTP server installations is to accept mail addressed to users at . 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 . 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 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.

Relaying Mail

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.



Traveling users can be particularly troublesome , because such users frequently use dial-up ISPs with very large sets of IP addresses. You probably don't want to enable all of these IP addresses to relay, since a spammer who uses the same ISP might stumble upon your system and use it as an open relay. In such situations, it's usually better to have the traveling user use the ISP's outgoing mail server. Another option is to use an SMTP-after-POP configuration, in which a POP server can tell the SMTP server to accept relays from a particular IP address for some period after that IP address successfully checked or retrieved e-mail. This allows the remote user to relay mail, but only after accessing the POP server. Yet another option is to have the traveler use SSH to log on to a local system, or configure an SSH tunnel for the outgoing SMTP connection.

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.



If you're configuring a system that has multiple transient Internet connections, such as a notebook that you use with different ISPs, using a mail relay may be inconvenient. Many ISPs reject relays except from systems on their own networks, so this approach will work with just one ISP. You can work around this problem by creating two SMTP server configuration files, one for each ISP, under names other than the one used by the standard configuration file. You can then add lines to your PPP dialing scripts that copy the appropriate configuration files and restart the SMTP server. For instance, if you're using sendmail, you might call the files and , and copy one of these to in your PPP dialing scripts.

Anti-Spam Configuration

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:

  • Mail server pattern-matching blocks ” Most mail servers provide some way to block e-mail that matches certain criteria, such as mail from particular users or networks. You can use these facilities to block incoming mail from known spammers or ISPs that generate nothing but spam. Unless you review such blocks, though, you may go too far ”for instance, you might block an ISP, but if the ISP cleans up its act, you'll block its legitimate users for no reason. Indeed, even an ISP that knowingly hosts spammers may also host legitimate users. Other pattern matches may be less likely to cause problems because they're more specific.

  • Blackhole lists ” Several organizations now publish lists of IP addresses that you might want to use as a basis for blocking e-mail. IP addresses on these lists may be known to have sent spam, may be open relays that are easily abused by spammers, may be associated with PPP dial-up accounts that should ordinarily relay mail through their ISPs' mail servers, or may be otherwise suspect as direct senders of e-mail. Most mail servers can be configured to use one or more such anti-spam blackhole lists. Table 19.1 summarizes some of these services, but this list is incomplete.

  • Post-MTA pattern matches ” The Procmail system, described in the upcoming section, "Using a Procmail Filter," can be used to perform more sophisticated pattern matches than are supported by most mail servers. In fact, some sophisticated anti-spam systems, such as SpamBouncer (, are built atop Procmail. You can use such a system or design a Procmail filter yourself.

  • Distributed pattern matching ” A fairly recent anti-spam tool is Vipul's Razor (http://razor. sourceforge .net). This system relies upon a catalog of spam identified by a database of spam message Secure Hash Algorithm (SHA) codes maintained by Vipul's Razor servers. You can configure your mail system to compute SHA codes on incoming mail, and if it matches the Vipul's Razor codes, you can be reasonably sure it's spam.

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
List Name URL Server Address Description
Dial-Up List (DUL) This is a list of IP addresses associated with ISPs' dial-up PPP connections. The rationale is that such users shouldn't need to send mail directly, because they can use the ISP's mail relay, but spammers frequently bypass the ISP's relay.
Realtime Blackhole List (RBL) This list includes systems that are known to have spammed, supported spammers in various ways, or relayed spam and not corrected the problem.
Relay Spam Stopper (RSS) This list holds systems that have been documented as having relayed spam, and which have been shown to be an open relay by a semi-automated test.
Open Relay Database (ORDB) This list is similar to the RSS, but its criteria for adding hosts are looser. Therefore, ORDB blocks more spam, but also mistakenly blocks more legitimate e-mail.
RFC Ignorant Various;see Web site The RFC Ignorant organization maintains several blackhole lists of systems that demonstrate ignorance of one or more Request for Comments (RFC) Internet standards. Spammers often use such misconfigured systems, hence the rationale for using this as an anti-spam criterion.
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 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

Advanced Linux Networking
Advanced Linux Networking
ISBN: 0201774232
EAN: 2147483647
Year: 2002
Pages: 203

Similar book on Amazon © 2008-2017.
If you may any questions please contact us: