In "Fortify Your Email Transport, Part 1," December 2001, I explain how to set up SMTP Connectors and Routing Group Connectors (RGCs) to provide redundant and fault-tolerant messaging pathways between your Exchange 2000 Server systems and the Internet. However, connector configuration alone is rarely sufficient to protect your systems and connections from attacks that can inhibit your ability to do business and jeopardize your organization's reputation. With additional configuration of your Exchange servers, you can protect your Exchange organization from authorized use as an open relay, from accidental message loops, and from mail floods resulting from Denial of Service (DoS) attacks.
Open Relays
If you do nothing else, confirm that attackers can't use your Exchange server as an unauthorized SMTP relay. One of SMTP's features lets a server act as an intermediary, accepting a message on behalf of a final destination and retransmitting that message toward that destination. When you fail to configure a server to let only specific machines and users relay email, the unsecured system is referred to as an open relay.
An open relay is dangerous for two reasons. First, SMTP is inherently unsecured, so attackers can easily forge a message and impersonate a particular sender. An open relay compounds the impersonation problem: Sending a forged message from an open relay can add a level of authenticity by making a message appear to have originated from a server in the real account owner's domain.
Second, attackers often use open relays to propagate spam, which usually targets an extensive list of thousands of recipients. When attackers find an open relay, they often use it over and over, which diverts the system from processing your valid email traffic and slows delivery of that email. To make matters worse, you run the risk of losing business because businesses that use spam-blocking software and blacklists such as the Mail Abuse Prevention System (MAPS) might reject legitimate email from your domain if your server earns a reputation as an open relay.
If relaying is such a threat, why would you permit your Exchange servers to relay email? Typically, you permit relaying because you have an application that needs to send SMTP messages but can't determine how to get the messages to their destinations. (Examples of these types of applications are POP clients, IMAP clients, and Web server forms that send email confirmations when users upload information.) Sometimes (e.g., when you design a Web server application) you can engineer an application to use Messaging API (MAPI) instead of SMTP and thus avoid the need for relay. However, the use of POP and IMAP clients always requires SMTP relaying because those clients can only retrieve messages from a mailbox. To send messages, you must pair POP and IMAP with SMTP and configure the client with the name of a server that permits relaying. Providing relay support, however, doesn't mean that your server must be an open relay.
Relay-Control Tactics
By default, an Exchange 2000 SMTP virtual server prohibits all relaying and accepts inbound traffic only for the domains you define (by an SMTP address space or by a recipient policy). When you need to permit relaying, configure your Exchange servers to permit relaying only from authorized senders. To determine which senders are authorized, you need to identify a system by its IP address or authenticate a sender by the sender's logon credentials.
Authorizing by IP address. Limiting relaying according to IP address is the fastest method because it requires only a server-side configuration. To complete this configuration in Exchange 2000, open the Microsoft Management Console (MMC) Exchange System Manager (ESM) console. Expand the Protocols container, expand the SMTP container, then right-click the SMTP virtual server that you want to configure. Choose Properties from the context menu to open the virtual server's Properties dialog box, then go to the Access tab. In the SMTP Relay Restrictions section, click Relay to display the Relay Restrictions dialog box, which Figure 1 shows. Select Only the list below, then click Add and enter an IP address, subnet information, or a domain name—each of which will ultimately resolve to an IP address that the virtual server uses to determine whether a connecting computer can relay mail. (Web Table 1 on the Exchange & Outlook Administrator Web site—http://www.exchangeadmin .com—lists considerations you should take into account for each type of definition.) After you make your entries, stop and restart the virtual server.
Authorizing by user authentication. Restricting relaying by IP address isn't feasible when you support many clients or when those clients connect through an ISP and thus have dynamically assigned addresses. In those situations, you can permit relaying based on user authentication. To do so, open the SMTP virtual server's Relay Restrictions dialog box, select the Allow all computers which successfully authenticate to relay, regardless of the list above check box, then stop and restart the virtual server. This setting requires the sending client to use the Extended SMTP (ESMTP) AUTH command, so your email clients must support that command and you must configure the clients to send logon credentials to the SMTP virtual server. This type of relay security is a bit more time-consuming because you must configure each client, but it's also the most secure way to permit relaying.
Loops and Floods
Looping messages and mail floods are two more threats to the availability of your email transports. With the speed at which thousands of message transfers move between most SMTP servers during a loop or flood, a system can quickly become overwhelmed. Because of Exchange's transaction-log architecture, an undetected mail loop or flood can cause a server to shut down when it runs out of transaction-log disk space.
Looping messages occur when a message moves back and forth between your server and some other (usually external) SMTP server. Sometimes a loop forms when an Exchange user sets up a rule to forward to another account, which has a rule to forward back to the Exchange user. Exchange can usually prevent this type of mail loop by examining the number of Received from stamps in a message's header. When that number reaches the limit you've defined in the SMTP virtual server's Maximum hop count property (on the Delivery tab of the virtual server's Properties dialog box), Exchange refuses to forward the message. (The hop-count default is 15.) Some systems' SMTP gateways, however, keep Exchange from detecting this type of loop because they strip the Received from information out of a message or they generate the forwards such that Exchange sees each one as a new message.
More often, though, message loops occur when an Exchange user sets up a rule to autoforward mail to an external account. The message encounters some external problem (e.g., the external account has exceeded its quota) and generates a nondelivery report (NDR). Because the Exchange account is configured to autoforward new messages, it automatically autoforwards the NDR, which the external account rejects and which causes another NDR—thus forming a loop. Each time the message makes a round-trip, it grows in size as the systems add new message headers and new NDRs.
External email can also be a culprit of mail loops. For example, an external sender on the way out of the office configures an Out-of-Office rule—and sets the rule to request delivery confirmation. Before the user leaves, he or she sends a message to a user in your organization—but mistypes the address. Your system returns an NDR, but the Out-of-Office rule automatically replies right back and requests another delivery confirmation. The Out-of-Office functionality might not keep track of replies-per-sender, so it returns a message no matter how many times that message arrives from the same sender—thus forming another loop.
A mail flood occurs when a server receives an unusually large number of mail messages in a short time. Sometimes these floods are the innocent result of a large distribution list's (DL's) recipients using a reply-to-all function, but the real trouble lies in the type of flood that results from a DoS attack. In that situation, an attacker opens hundreds of connections to your SMTP port or sends thousands of small messages to bogus recipients in your domain. Your queues quickly become backlogged as your systems attempt to process all the nondeliverable traffic.
Loop- and Flood-Fighting Tactics
You can't eliminate message loops or DoS floods. However, Exchange provides some tools to help you combat these problems.
Preventing and breaking loops. You can significantly reduce the possibility of mail loops by configuring your systems to prohibit autoreplies and autoforwarded messages to Internet destinations. With these restrictions in place, any rule to autoreply or autoforward mail to an Internet destination fires and generates a message, but the Exchange 2000 Message Categorizer abandons that message because of the restriction.
To prohibit autoreplies, open the ESM console and expand the Global Settings container, then select the Internet Message Formats object. Right-click the Default format object in the ESM console's right-hand pane, then select Properties from the context menu. Go to the Default Properties dialog box's Advanced tab, which Figure 2 shows. Clear the Allow automatic replies and Allow automatic forward check boxes. Note that unlike Exchange Server 5.5, which applies these settings to the Internet Mail Service (IMS), Exchange 2000 globally applies the settings to all SMTP virtual servers. Configuring the settings only once is convenient when you have an organization in which these types of decisions are made unilaterally, but the feature can be problematic for organizations that operate under a franchise approach (e.g., some US government organizations). In the franchise model, groups of Exchange sites operate independently and autonomously under one organization. Each group has complete control over its sites, but the groups come together for certain purposes, such as forming an integrated directory. Most Exchange 5.5 franchise configurations that I've worked with have a separate IMS for each site in the franchise and therefore have complete control of the site's autoreply and autoforward settings. The loss of that capability in Exchange 2000 means that such settings become one more configuration in which organization- wide consensus is key.
The next step in preventing loops is to configure your SMTP virtual servers to send copies of NDRs to a postmaster mailbox that someone monitors and manages to prevent a buildup of messages. For this configuration, open the SMTP virtual server's Properties dialog box and go to the Messages tab, which Figure 3 shows. In the Send copy of Non-Delivery Report to text box, enter the postmaster mailbox's SMTP address. After you stop and restart the virtual server, the postmaster mailbox will receive copies of all NDRs. If a mail loop forms because of an NDR, many NDRs will accumulate quickly in the postmaster mailbox and act as a flag to investigate the NDRs' source. To help you monitor the postmaster mailbox, you can use software such as NetIQ's AppManager Suite, which can help you look for trends (e.g., an unusual number of inbound or outbound messages per hour) and which can generate an alert (e.g., page an administrator).
Despite preventive efforts, mail loops might still occur. Obviously, you should try to determine and notify the source of a loop to eliminate the condition that started the loop, but in the meantime you can try to break the loop. Two general strategies exist for breaking a loop.
The first strategy works when the loop is a result of a mistyped address for a user in your domain. In this case, the loop propagates because of an "unknown recipient" NDR. To break the loop, create an object that has the mistyped address. A DL with no members is the best choice for this object because it will cause Exchange to discard the message. (This approach works with Exchange 5.5 as well as with Exchange 2000.)
The second strategy involves rejecting messages from a particular sender. To do so, specify a message filter to block the sender's SMTP address. Like the autoreply and autoforward settings, Exchange globally applies the filtering setting. Open the ESM console, expand the Global Settings container, right-click the Message Delivery object, and select Properties to open the Message Delivery Properties dialog box. Go to the Filtering tab, which Figure 4, page 3, shows. Click Add, then enter the SMTP address of the external sender who is propagating the loop. When dealing with loops, select only the Accept messages without notifying sender of filtering check box and clear the other two check boxes on the Filtering tab. When you clear the Accept messages without notifying sender of filtering check box, the sending system receives an SMTP response code of 554 Sender Denied, which can result in an NDR and might cause more loops. When you select that check box, Exchange accepts the connection and immediately proceeds to discard the looping messages.
After you configure the filter, you need to configure the SMTP virtual server to use the filter. To do so, open the virtual server's Properties dialog box and go to the General tab. Click Advanced. Select the IP address that you want to configure, then click Edit. In the Identification dialog box, which Figure 5 shows, select the Apply Filter check box. If your SMTP virtual server has more than one IP address, repeat these steps for each IP address. After you stop and restart the virtual server, Exchange applies the filter and breaks the loop. In most mail loops, the sender is legitimate, so don't forget to remove the filter after you're certain that Exchange has discarded all the loop-generated inbound messages.
Combating mail floods. DoS attacks are a little more difficult to prevent than mail loops because the attacks depend on your server's inherent ability to accept multiple inbound connections. Attackers can flood a server with so many simultaneous connection attempts that legitimate mail can't get in. The usual solution is to review the SMTP protocol logs, determine the IP address of the attacking system, and configure the SMTP virtual server to reject connections from that host. To prevent one or more computers from connecting to your server, open the virtual server's Properties dialog box and go to the Access tab. Click Connection. In the Connection dialog box, which Figure 6 shows, select the All except the list below option, then enter an IP address (to reject one computer) or subnet information (to reject a group of computers). Stop and restart the virtual server.
Although this strategy works against DoS attacks, it isn't always effective against mail loops. When you temporarily restrict a system, the sending system might queue looped messages for later delivery. If these messages are still in the sender's queue when you remove the restriction, the loop can continue where it left off. A better strategy is to break the loop.
Stay on Track
You can never completely eliminate attempted relays, mail loops, or DoS attacks, but you can take steps to reduce the threat of significant email disruption. Carefully and diligently monitoring your systems' activity can help you detect these nuisances before they become problems. When prevention fails, the tools and tactics I've described can help you keep your systems running and get your Exchange servers back on track in no time.
