Microsoft KB Archive/304897

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

Article ID: 304897

Article Last Modified on 12/13/2006

-

APPLIES TO


 * Microsoft Windows XP Professional
 * Microsoft Windows 2000 Server
 * Microsoft Windows 2000 Advanced Server
 * Microsoft Windows 2000 Professional Edition
 * Microsoft Exchange 2000 Enterprise Server
 * Microsoft Exchange Server 5.5 Standard Edition
 * Microsoft Exchange Server 5.0 Standard Edition

-



This article was previously published under Q304897



INTRODUCTION
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 &quot;open relay&quot; 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 &quot;Applies to&quot; section are not configured for open relay.



MORE INFORMATION
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:

550 5.7.1 Relaying prohibited

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:

823866 How to configure connection filtering to use Realtime Block Lists (RBLs) and how to configure recipient filtering in Exchange 2003

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:

842851 SMTP tar pit feature for Microsoft Windows Server 2003

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:

http://msdn.microsoft.com/library/en-us/smtpevt/html/0e0c3b0d-5b08-42b5-8312-59a9f3cd8fd9.asp?frame=true

SMTP server response to Relay
The recommended RFC-compliant response is similar to the following:

550 5.1.1 @ . ... User unknown

In the products that are listed in the &quot;Applies to&quot; 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   25, where   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:  At the Telnet session prompt, type RSET.

The telnet session responds with text that is similar to the following:

250 2.0.0 Resetting

 Type MAIL FROM: @. , where  is the name of the user,   is the name of the domain, and   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 @ . ....Sender OK

 Type RCPT TO: @. , where  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 @.



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:  At the Telnet session prompt, type RSET.

The telnet session responds with text that is similar to the following:

250 2.0.0 Resetting

 Type MAIL FROM:, where  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 @ . ....Sender OK

 Type RCPT TO: @.

The telnet session responds with text that is similar to the following:

550 5.7.1 Unable to relay for @.

</li></ol>

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:  At the Telnet session prompt, type RSET.

The telnet session responds with text that is similar to the following:

250 2.0.0 Resetting

</li> 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

</li> Type RCPT TO: @.

The telnet session responds with text that is similar to the following:

550 5.7.1 Unable to relay for @.

</li></ol>

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:  At the Telnet session prompt, type RSET.

The telnet session responds with text that is similar to the following:

250 2.0.0 Resetting

</li> Type MAIL FROM: @. , where  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 @ . ....Sender OK

</li> Type RCPT TO: @. , and then press ENTER.

The telnet session responds with text that is similar to the following:

550 5.7.1 Unable to relay for @.

</li></ol>

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 &quot;localhost&quot; 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:  At the Telnet session prompt, type RSET.

The telnet session responds with text that is similar to the following:

250 2.0.0 Resetting

</li> Type MAIL FROM: @10.10.10.10, and then press ENTER.

The telnet session responds with text that is similar to the following:

250 2.1.0 @ ....Sender OK

</li> Type RCPT TO: @. , and then press ENTER.

The telnet session responds with text that is similar to the following:

550 5.7.1 Unable to relay for @.

</li></ol>

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:  At the Telnet session prompt, type RSET.

The telnet session responds with text that is similar to the following:

250 2.0.0 Resetting

</li> Type MAIL FROM:, and then press ENTER.

The telnet session responds with text that is similar to the following:

@ . ....Sender OK

</li> <li>Type RCPT TO: %. , and then press ENTER.

The telnet session responds with text that is similar to the following:

250 2.1.5 % . @ .  @.

Note The local domain is appended to the recipient domain in the e-mail address.</li></ol>

Relay test 7
This test is a variation of relay test 6. Because the quotation mark character (&quot;) 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: <ol> <li>At the Telnet session prompt, type RSET.

The telnet session responds with text that is similar to the following:

250 2.0.0 Resetting

</li> <li>Type MAIL FROM:, and then press ENTER.

The telnet session responds with text that is similar to the following:

@ . ....Sender OK

</li> <li>Type RCPT TO:&quot; @. &quot;, and then press ENTER.

The telnet session responds with text that is similar to the following:

&quot; @. &quot;@.

Note The local domain is appended to the recipient domain in the e-mail address.</li></ol>

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.

<div class="references_section">