Controlling Relaying

Because being an open relay has potentially bad consequences, the best approach is to not be one. You can accomplish this goal in several ways: disallowing relaying completely, allowing relaying only for specified domains or IP addresses, accepting relay requests only from hosts with particular IP addresses, or requiring authentication from the sender before accepting a message for relay. Microsoft Exchange 2000 supports all these methods. Even better news is that by default Exchange 2000 allows only authenticated senders to relay. However, for reasons discussed earlier you might need to turn relaying back on (at least some of the time).

Note

In early versions of Microsoft Exchange 5.5, the Internet Mail Service (IMS) would act as an open relay by default.

You can control relaying settings on both SMTP virtual servers and SMTP connectors. Because most Exchange sites aren’t using SMTP connectors, the most common place to control relaying is on the SMTP virtual server object, which resides in the Protocols container of each individual server.

Remember that the relaying settings apply to individual SMTP virtual servers and connectors. There is no built-in way to apply and enforce relaying settings on multiple servers at the same time. Each server’s configuration is stored in the Internet Information Services (IIS) metabase on the local machine, so you can’t apply these settings using Group Policy or Exchange system policies. Because most organizations with multiple servers concentrate their SMTP message flow through a small number of bridgeheads or front-end servers, this situation isn’t as dire as it sounds. The individualized nature of relaying settings is worth remembering, though, because if you leave even a single open relay accessible to the Internet, spammers are sure to find it.

Controlling Access for SMTP Virtual Servers

You control relaying settings through the SMTP virtual server Properties dialog box. The Access tab (shown in Figure 8-2) has three buttons of interest for relaying control. The Authentication button lets you control what types of authentication are required for a successful connection; with the Connection button, you can allow or deny specified IP addresses or DNS domains to connect; and the Relay button allows you to control who can relay mail through your server. (The Certificate and Communication buttons, which are used to turn on and manage Secure Sockets Layer/Transport Layer Security [SSL/TLS] for SMTP, are discussed in Chapter 11, “Securing Internet Communications.”)

Figure 8-2: The Access tab of the SMTP virtual server Properties dialog box.

The SMTP server follows a fairly straightforward process for deciding whether or not to accept an inbound message for relaying. Figure 8-3 presents a flowchart that illustrates how this process works:

1. When an incoming connection arrives, if its IP address is on the “deny” list of addresses, the connection is immediately dropped.

2. If the IP address passes muster, the sender can (but isn’t required to) attempt to authenticate by sending the AUTH verb plus an indicator of the authentication method it wants to use (for example, AUTH NTLM indicates that the sender would like to authenticate with NTLM). If the Exchange server doesn’t support the requested method, it responds with an error code (504 Unrecognized authentication type). The two sides go back and forth in this manner until they either agree on an authentication method or until the client gives up and closes the connection.

3. If the two sides agree on an authentication method, the server responds with an SMTP 334 message that includes whatever authentication string the sender must answer. The sender answers, and the receiving server checks the credentials. If they are invalid, the server returns an error code (535 Authentication unsuccessful), but the server doesn’t drop the connection; that allows the sending computer to try again.

4. The sender uses the SMTP commands MAIL FROM and RCPT TO to specify the sender and recipient addresses. If the recipient address specifies a nonlocal recipient, the relaying restrictions are evaluated to see whether the message can be accepted or not. If any of the restrictions apply, Exchange returns the 550 Unable to relay error code.

5. If none of the restrictions apply, Exchange accepts the message, and the sender can proceed to its next transaction. However, if the categorizer determines that the message is addressed to a nonlocal recipient for which relaying is not allowed, the message is returned to the originator with an NDR (and the same 550 Unable to relay error).

Figure 8.3: The SMTP virtual server evaluates the connection control settings before accepting messages for delivery.

Note

The SMTP server can close the connection if it’s idle for the specified timeout period, which defaults at 10 minutes. This default is reasonable, although if you have high volumes of traffic from users on high-latency connections you might consider changing it.

Requiring Authentication

By default, SMTP is an unauthenticated protocol: every SMTP server on the market ships with default settings that allow it to accept anonymous connections. This arrangement is fundamental to the way Internet e-mail works. A public SMTP server may receive mail from any other SMTP server on the Internet; if your server requires authentication, a sender whose server cannot authenticate cannot deliver mail to you. However, there are circumstances when requiring authentication is appropriate. For example, let’s say you want only your remote users to relay traffic through a specific SMTP server. One way to handle this is to create a new relaying- only SMTP virtual server for your mobile users and set it to require authentication.

Clicking the Access tab’s Authentication button opens the Authentication dialog box (see Figure 8-4). From this dialog box, you can require your SMTP server to use any combination of the three basic authentication levels Exchange supports. Its three check boxes allow you to specify which of these methods your server will accept.

Figure 8-4: Setting authentication properties on the SMTP virtual server is one way to control who can relay through it.

• The Anonymous Access check box controls whether your server will accept anonymous SMTP traffic. Leave this selected unless you want to refuse connections from servers that cannot authenticate—in other words, enable anonymous access if you want your server to be able to receive e-mail from Internet SMTP servers.

• The Basic Authentication check box controls whether the SMTP server will allow basic, unencrypted authentication with the AUTH extension (part of the Simple Authentication and Security Layer [SASL] protocol, which you might remember from Chapter 2, “Security Protocols and Algorithms”). Passing credentials over the Internet in cleartext is a really bad idea, so Exchange System Manager and Internet Services Manager warn you when you turn this option on. For additional safety, the Requires TLS Encryption check box allows you to force the use of SSL/TLS, thus encrypting communications between the client and server. When this check box is selected, no credentials are exchanged until the sender and your Exchange server have completed an SSL/TLS negotiation, begun with the STARTTLS verb. Microsoft Outlook Express and Eudora support SSL/TLS. Make sure the clients and servers you want to talk to support SSL/TLS or they will be denied permission to connect. (Note that using SSL/TLS will affect your servers’ performance by as much as 40 percent, depending on the number of simultaneous connections. However, the additional security might well be worth it for your applications.)

• The Default Domain text box lets you enter the DNS or NetBIOS name of an Active Directory domain. Whatever credentials the sender provides are evaluated against this domain.

• The Integrated Windows Authentication check box enables the use of the standard Windows authentication methods discussed in Chapter 3, “Windows and Exchange Security Architecture.” In short, selecting this check box enables the use of NTLM or Kerberos as authentication methods. (AUTH NTLM and AUTH GSSAPI are the verbs to watch for in the SMTP stream.) When this check box is selected, users’ Windows credentials are automatically passed to the SMTP server. This option is quite useful for clients who are logged in with domain accounts when they’re sending to your SMTP server, but it is less useful for those who aren’t.

  Note

  Some firewalls and SMTP proxies block the STARTTLS verb. This blocking might be for one of two reasons: the device might be configured to prevent mail encryption so that it can inspect the data going past for viruses or other bad content, or it might be configured not to allow anything other than the most basic set of SMTP commands. If you have TLS enabled and you find that some clients or servers cannot successfully send mail through your SMTP server, this is one place to look for the cause of the problem.

Remember that the Authentication dialog box just controls who can connect to your server in the first place. An authenticated (or anonymous) user who successfully connects can still be further restricted using the other connection control features.

Controlling Connections by IP Address

You can use the Connection button to specify which IP addresses your virtual server will or will not talk to. This is particularly useful for multihomed servers because you can bind different virtual servers to each of the IP addresses—and it’s even more valuable if your SMTP server happens to have one interface to the Internet and another to a private local area network (LAN). The Connection dialog box (shown in Figure 8-5) has two primary options: Only The List Below specifies that you want to allow connections from listed hosts and no one else, whereas All Except The List Below means you want to allow anyone except the listed hosts to connect. The Add and Remove buttons allow you to manage the contents of the Computers list. When you click Add, you’ll get the oddly named Computer dialog box (shown in Figure 8-6), from which you can add a single IP address, a range of IP addresses (expressed as an IP address plus a subnet mask), or a DNS domain. Note that turning on connection restrictions by DNS domain requires a reverse DNS lookup for every connection. On busy servers, that can reduce performance significantly.

Figure 8-5: Block or allow SMTP connections by specifying IP addresses in the Connection dialog box.

Figure 8-6: Use the Computer dialog box to specify IP addresses, ranges, or DNS domains that you want to block.

Note

When you change the IP address restriction list, you must stop and restart the SMTP virtual server before the changes take effect. Don’t forget to do this, or your restrictions will be ineffectual.

Controlling Who Can Relay

The Relay button in the Access tab is what you use to specify which computers can relay through your SMTP server. The relay restrictions control which computers can use the RCPT TO verb with nonlocal recipients. Remember that the routing engine might still send a non-delivery report after the SMTP server accepts it!

The Relay Restrictions dialog box (shown in Figure 8-7) works in much the same manner as the Connection dialog box: you choose whether the list in the Computers dialog box is a list of those who can relay or a list of those who cannot. The Add and Remove buttons allow you to manage the list. Clicking Add displays the same Computer dialog box you saw earlier in Figure 8-6, with exactly the same capabilities. The Allow All Computers Which Successfully Authenticate To Relay check box lets you override the restrictions so that any user who authenticates can relay—a useful feature for mobile SMTP users.

Figure 8-7: The Relay Restrictions dialog box lets you specify who can and who cannot relay through your server.

Figure 8-7 shows the default Relay Restrictions dialog box, which allows relaying only for clients that authenticate, no matter what their IP address is. That behavior results from a combination of three things: the Allow All Computers check box is set, the Only The List Below option is selected, and the Computers list is empty. If you want to completely prevent relaying, you could clear the Allow All Computers check box so that no one would be able to relay. Conversely, if you wanted to allow certain hosts (say, those on an internal private IP network) to relay while preserving authenticated users’ relay privileges, you’d need to add the internal IP range using the Add button.

Tip

For maximum security, use two SMTP virtual servers. On the default server, allow only anonymous connections and do not allow relaying at all. On the additional virtual server, require authentication, enable SSL/TLS, and allow authenticated users to relay. This arrangement provides maximum separation of privileged and unprivileged access, and it allows you to maintain separate logs for the two virtual servers.

Configuring Relaying on SMTP Connectors

SMTP connectors are slightly different than SMTP virtual servers. The connector uses the virtual server as a transport mechanism, but it has additional features, including the ability to dequeue mail with ETRN or TURN, the ability to schedule when connections take place, and a facility for blocking messages over a certain size. These features make connectors particularly useful for sites connected over low-bandwidth or metered links. In addition, SMTP connectors allow you to force mail to particular domains through a connector that points to a specified smart host. (For more details of how to set up and configure SMTP connectors, see Microsoft Knowledge Base articles Q319426 and Q319407.)

Caution

If you allow relaying on an SMTP connector, its settings might override relay settings on the SMTP virtual server to which the connector points. Remember, when you create a new connector you have to specify the local bridgehead. The bridgehead you point the connector to will have its relaying restrictions, if any, on the default address space overridden by the connector. However, because the connector can point to individual address spaces, you can create multiple connectors with different address spaces—each of which can have different relaying settings. Be careful, and make sure to test your relaying configuration before exposing a new connector or virtual server to the Internet.

When you create an SMTP connector, you specify which address spaces it should accept mail for. Unlike the SMTP virtual server, which accepts mail for all address spaces for which a recipient policy exists, the connector is perfectly capable of accepting mail for an external domain and forwarding it, either through the normal MX record process or by delivering it directly to another computer for further processing.

Creating a connector that allows relaying to specified domains is simple. The following steps walk you through the process of creating a connector that accepts inbound mail for delivery to Microsoft:

1. Launch Exchange System Manager, and navigate to the routing group container in which you want to create the connector (for example, First Administrative Group | Routing Groups | routingGroupName).

2. Right-click the Connections folder, and choose the New | SMTP Connector command.

3. In the General tab of the connector Properties dialog box, fill in the Name field. (Remember, SMTP connectors are unidirectional, so a name like “Toledo – Redmond” makes clear what the connector is for.)

   • Use the two option buttons to specify whether you want to use DNS MX queries to find the other end of the connector, or whether you want to route all mail for addresses that match this connector’s address space to a specified smarthost or smarthosts.

   • Use the Add button to select the local bridgeheads in the routing group that will host this connector. Remember, the SMTP virtual servers you select here will have their relaying settings overridden by the connector’s settings.

4. Click the Address Space tab, and use the Add button to create an address space entry for the remote domain (in this case, *.microsoft.com). Use the Allow Messages To Be Relayed To These Domains option if you want to accept mail for those domains from the outside world (or your IMAP and POP clients that use this SMTP server to send their outgoing mail).

Verifying Your Relaying Configuration

To test whether your machine is open for relaying, the best bet is to check it yourself. Internet relay testing services might actually report you to various spam blacklists if they think you’re an open relay. This threat is worsened by the fact that many poorly written relay testers flag Exchange 2000 as being an open relay even when it’s not. This problem arises for efficiency reasons: if Exchange sees a recipient whose domain isn’t specified (for example, RCPT TO: paulr), it doesn’t immediately reject the message. Instead, it accepts it for delivery so that it can generate an NDR later. This behavior fools some relay checkers that expect to see an immediate 550 5.7.1 Relaying prohibited message, even though Exchange is following RFC 822 and is behaving in an acceptable way. (See Knowledge Base article Q304897 for more information.)

Relay testing is simple if you understand the basics of the SMTP protocol. Each conversation has to specify the sender, the recipient, and the message data, in that order. By using the Windows Telnet client, you can easily pretend to be an SMTP sender who’s trying to relay. (Of course, that’s one of the reasons people turn on authentication and encryption for SMTP sessions: SMTP traffic is trivial to forge.) This testing works only if your SMTP server is set to allow anonymous connections.

Begin by opening a Telnet session on port 25 to your SMTP server, like this:

telnet exchange.mycompany.com 25 

Your Exchange server responds with a banner. Notice that the banner begins with 220, which means that everything’s fine. Every response you get from the SMTP server has a response code at the beginning. Over time, you’ll learn to recognize them. The banner also tells you the DNS name of the server and the version number of its SMTP service:

220 exchange.mycompany.com Microsoft ESMTP MAIL Service, Version: 5.0.2195.5329 ready at Wed, 21 Aug 2002 05:35:19 -0500

Because the server’s last response was a 220, you can now begin your conversation with the HELO verb, followed by the DNS name of your machine:

HELO myworkstation.mycompany.com

The SMTP server responds with a 250 message, signaling that it recognizes you:

250 exchange.mycompany.com Hello myworkstation.mycompany.com

Now the fun begins: you need to tell the server who you are. Type MAIL FROM: followed by your e-mail address. The server respond with another 250 message, indicating that the sender is okay. Next, you’ll need to specify who the mail is going to, which you do by typing RCPT TO, followed by a nonlocal recipient address:

RCPT TO:[e-mail]

The server should immediately tell you that relaying is not allowed:

550 5.7.1 Unable to relay for [e-mail]

If instead you see the message has been accepted (250 2.1.5 [e-mail] in this example), you know your machine might still be capable of relaying. Go back and double-check your relaying configuration to ensure that it’s correct.