SMTP relay behavior in Windows 2000, Windows XP, and Exchange Server

Microsoft Simple Mail Transfer Protocol (SMTP) relay is a feature that lets an SMTP client use an SMTP server to forward e-mail messages to a remote domain. As described in Request for Comments (RFC) 282, sections 2.1 and 3.7, SMTP was designed with the ability to relay e-mail messages.

However, if relay is not controlled, a malicious user might use relay to send bulk unsolicited e-mail messages. An uncontrolled host is known as an "open relay" host. By sending these unsolicited e-mail messages to the intermediate host, the malicious user can disguise his or her identity. This may also cause excessive resource use on the relay host and prevent the relay host from sending valid e-mail messages. In particular, a malicious user who sends unsolicited e-mail messages may send a single message to many recipients without using their own bandwidth.

By default, the Microsoft products that are listed in the "Applies to" section are not configured for open relay.

When you use some third-party tools to test SMTP servers for relay, the SMTP server may seem to fail the test and your Microsoft SMTP product may seem to be open for relay, although it is not. This is because the SMTP server may not immediately reject the e-mail message. Instead, the SMTP server processes the e-mail message and then sends a non-delivery report (NDR). For more information about SMTP server response to relay, see the SMTP server response to relay section. For more information about how to test your SMTP server for relay, see the Testing for relay section.

Every TO or FROM address in an SMTP protocol conversation contains two parts: the local part and the domain part. If the domain part, that is, the part immediately following the at sign (@), is not specified the e-mail message is assumed to be local. Some Microsoft SMTP products append the local domain because some users configure their SMTP clients to use only a user name as the e-mail address. By adding the default local domain, the Microsoft server can add what is most likely the local domain to reduce the support cost.

This behavior occurs because some Microsoft SMTP products do not perform a directory lookup before they accept SMTP e-mail messages for delivery. Microsoft SMTP products only check the recipient's domain to see if it is a local domain or an explicitly permitted domain. If the recipient's domain is not a local domain or a permitted domain, the SMTP server responds with an error message that is similar to the following: The only requirement to prevent relay is a verification that the domain part of the TO address is local. A check of the mail server's directory to see if the recipient is valid is an option, but it is not required. If a mail server accepts a message and then later decides that it cannot deliver the message, the server must generate an NDR. The Microsoft SMTP products comply with this requirement.

Note Microsoft Exchange Server 2003 can perform directory lookups during the SMTP protocol conversation. This feature can enabled be enabled in System Manager. For more information about recipient filtering in Exchange Server 2003, click the following article number to view the article in the Microsoft Knowledge Base:
Performing a directory lookup during the SMTP protocol conversation may be used to verify addresses. Therefore, we recommend that you turn on the TarpitTime functionality that is described in the following Knowledge Base article: Important If you must perform directory lookups during the SMTP protocol conversation, you can write a Microsoft Windows 2000 SMTP protocol event sink. For additional information, visit the following MSDN Platform SDK SMTP Server Events Web site:

SMTP server response to Relay

The recommended RFC-compliant response is similar to the following: In the products that are listed in the "Applies to" section, Microsoft chose not to perform the directory lookups during the SMTP protocol conversation for the following reasons:

• If the SMTP server returns a 5xx error to a malicious user who is trying to send bulk unsolicited e-mail messages, the malicious user will know instantly which addresses are real. If the malicious user sends a dictionary of names through the SMTP protocol, the malicious user can easily harvest a list of valid e-mail addresses. This may also be a risk to your local users because user account names are frequently the same as e-mail addresses.
• A malicious user can use the FROM address to gain unauthorized access to a system and then use the victim's server to send NDRs to the intended recipient. This attack, known as spoofing, only hits this server with as much data as the attacker sends to it. In other words, if the malicious user wants to send 1 megabyte (MB) of data to a third party, the malicious user must spend 1 MB of his or her own bandwidth to send 1 MB of data to the SMTP server. Typically, such a malicious user tries to send 1 MB of data, but cause tens or hundreds of MB of data to hit a victim or set of victims throughout the Internet.
• If a directory lookup is performed during the SMTP protocol conversation, the SMTP protocol conversation may be much slower. When this article was published, Microsoft was operating under the premise that the SMTP server must operate as fast as possible to prevent blockage of SMTP messages on the Internet or on desktop SMTP clients. Sometimes the directory may also be unavailable, or the relay of a particular domain may be required, but a copy of the directory may not be available. This behavior may occur in an Internet service provider (ISP) hosting environment.

How to test for relay

You can test your SMTP server to determine if it is configured to relay e-mail messages. In the following examples, relay tests 1 through 5 are not accepted by the SMTP server and are immediately rejected. Tests 6 and 7 are accepted by the STMP server, but the e-mail message is not relayed and the server eventually generates an NDR.

To run the following relay tests, first start a Telnet session and connect to port 25 on your SMTP server:

1. Start a command prompt.
2. Type telnet ServerName 25, where ServerName is the SMTP server name or IP address and 25 is the port number, and then press ENTER.
3. Type EHLO, and then press ENTER.

Relay test 1

This is the standard test for SMTP relay. An SMTP client must not be permitted to relay in this manner unless the administrator has specifically permitted it, or unless the client first authenticates. To do this test, follow these steps:

1. At the Telnet session prompt, type RSET.
   
   The telnet session responds with text that is similar to the following:
   250 2.0.0 Resetting
2. Type MAIL FROM:UserName@DomainName.tld, where UserName is the name of the user, DomainName is the name of the domain, and tld is the top level domain such as .com or .net.
   
   The telnet session responds with text that is similar to the following:
   250 2.1.0 UserName@DomainName.tld....Sender OK
3. Type RCPT TO:RecipientName@DomainName.tld, where RecipientName is the e-mail address of the recipient.
   
   The telnet session responds with text that is similar to the following:
   550 5.7.1 Unable to relay for RecipientName@ DomainName.tld

Relay test 2

This test is almost the same as relay test 1, but the sender is a local user instead of a user in a remote domain. Because FROM addresses are generally used to gain unauthorized access to a system, the server must not relay the e-mail message. To do this test, follow these steps:

1. At the Telnet session prompt, type RSET.
   
   The telnet session responds with text that is similar to the following:
   250 2.0.0 Resetting
2. Type MAIL FROM:LocalUser, where LocalUser is a local e-mail name for a user account in the domain, and then press ENTER.
   
   The telnet session responds with text that is similar to the following:
   250 2.1.0 LocalUser@DomainName.tld....Sender OK
3. Type RCPT TO:RecipientName@DomainName.tld
   
   The telnet session responds with text that is similar to the following:
   550 5.7.1 Unable to relay for RecipientName@DomainName.tld

Relay test 3

This test is for a NULL or blank FROM envelope address. NDRs and other notifications have a NULL FROM envelope address. However, notifications must not be relayed unless the domain in the TO address is a local domain. To do this test, follow these steps:

1. At the Telnet session prompt, type RSET.
   
   The telnet session responds with text that is similar to the following:
   250 2.0.0 Resetting
2. Type MAIL FROM:<>, and then press ENTER.
   
   The telnet session responds with text that is similar to the following:
   250 2.1.0 <>....Sender OK
3. Type RCPT TO:RecipientName@DomainName.tld
   
   The telnet session responds with text that is similar to the following:
   550 5.7.1 Unable to relay for RecipientName@DomainName.tld

Relay test 4

This test is the same as relay test 2, but the local domain is explicitly added to the e-mail address. An SMTP server that is closed for relay must not relay this e-mail message. To do this test, follow these steps:

1. At the Telnet session prompt, type RSET.
   
   The telnet session responds with text that is similar to the following:
   250 2.0.0 Resetting
2. Type MAIL FROM:UserName@DomainName.tld, where DomainName is the name of the local domain, and then press ENTER.
   
   The telnet session responds with text that is similar to the following:
   250 2.1.0 UserName@DomainName.tld....Sender OK
3. Type RCPT TO:UserName@DomainName.tld, and then press ENTER.
   
   The telnet session responds with text that is similar to the following:
   550 5.7.1 Unable to relay for UserName@DomainName.tld

Relay test 5

This test is also the same as relay test 2, but the IP address of the server is used instead of the domain name. Although this address format is generally accepted, the server must not accept relay to a remote domain. In various other tests that use "localhost" or the Domain Name System (DNS) name of the server in the FROM address, the server must not relay e-mail messages that use this approach. To do this test, follow these steps:

1. At the Telnet session prompt, type RSET.
   
   The telnet session responds with text that is similar to the following:
   250 2.0.0 Resetting
2. Type MAIL FROM:UserName@10.10.10.10, and then press ENTER.
   
   The telnet session responds with text that is similar to the following:
   250 2.1.0 UserName@10.10.10.10....Sender OK
3. Type RCPT TO:UserName@DomainName.tld, and then press ENTER.
   
   The telnet session responds with text that is similar to the following:
   550 5.7.1 Unable to relay for UserName@DomainName.tld

Relay test 6

This test is specifically for older UNIX-based servers that route e-mail messages by appending the local domain and changing the at sign (@) to a percent symbol (%). The server then relays the mail. Because a percent symbol (%) is a valid character in the local part of the e-mail address, the SMTP server may accept the message and then send an NDR if the directory lookup fails. Microsoft SMTP products are not vulnerable to this kind of relay because the message is not forwarded and an NDR is generated. To do this test, follow these steps:

1. At the Telnet session prompt, type RSET.
   
   The telnet session responds with text that is similar to the following:
   250 2.0.0 Resetting
2. Type MAIL FROM:UserName, and then press ENTER.
   
   The telnet session responds with text that is similar to the following:
   UserName@DomainName.tld....Sender OK
3. Type RCPT TO:UserName%DomainName.tld, and then press ENTER.
   
   The telnet session responds with text that is similar to the following:
   250 2.1.5 UserName%DomainName.tld@DomainName.tldUserName@DomainName.tld
   Note The local domain is appended to the recipient domain in the e-mail address.

Relay test 7

This test is a variation of relay test 6. Because the quotation mark character (") is a valid character in the local part of the e-mail address, the SMTP server accepts the message and then sends an NDR if the directory lookup fails. Microsoft SMTP products are not vulnerable to this kind of relay because the message is not forwarded and an NDR is generated. To do this test, follow these steps:

1. At the Telnet session prompt, type RSET.
   
   The telnet session responds with text that is similar to the following:
   250 2.0.0 Resetting
2. Type MAIL FROM:UserName, and then press ENTER.
   
   The telnet session responds with text that is similar to the following:
   UserName@DomainName.tld....Sender OK
3. Type RCPT TO:"UserName@DomainName.tld", and then press ENTER.
   
   The telnet session responds with text that is similar to the following:
   "UserName@DomainName.tld"@DomainName.tld
   Note The local domain is appended to the recipient domain in the e-mail address.

How to tell whether your SMTP server is closed to relay tests 6 and 7

When you run relay tests 6 and 7 against an Exchange 2000 computer, the tests generate a message to a recipient that does not resolve, and NDRs are received by the mailbox that is specified in Exchange System Manager. You can configure the mailbox for unresolved recipients in the properties of the default SMTP virtual server in the Forward all mail with unresolved recipients to host box on the Messages tab in Exchange System Manager.

The NDRs are evidence that the e-mail messages are not relayed.

For more information about what to do if you are running Exchange Server 5.5 and you want to configure your server so that it is not an open relay, click the following article number to view the article in the Microsoft Knowledge Base: For more information about how to prevent relay in Windows 2000, click the following article number to view the article in the Microsoft Knowledge Base: Common tests exist that you can use to test SMTP servers for relay. For example, you can use the following third-party Web sites and tools:

• http://www.abuse.net/relay.html (http://www.abuse.net/relay.html)

Microsoft provides third-party contact information to help you find technical support. This contact information may change without notice. Microsoft does not guarantee the accuracy of this third-party contact information.

The third-party products that this article discusses are manufactured by companies that are independent of Microsoft. Microsoft makes no warranty, implied or otherwise, regarding the performance or reliability of these products.