| Downloads |
|---|
| 44469.zip |
In "Exchange Relay Review," December 2004, InstantDoc ID 44183, I showed you how to configure a server to act as a relay without putting that server at risk for exploitation. Now that you've followed that article's configuration steps and set up your server's SMTP virtual server, let's test the configuration to ensure that relaying is functioning the way you want. To do so, you can send a variety of messages from various sources and systems to confirm that the relays are permitted when necessary and otherwise blocked. You might think you'd need to use a client such as Outlook Express to send the messages, but you'd have to define and update configuration profiles multiple times to test all the variations. Fortunately, you don't have to use a full mail client to perform these tests. Instead, you can use a Telnet client from any platform. Once you learn how to do so, you'll find that testing SMTP via Telnet is an invaluable troubleshooting tool. As I walk you through the process, I'll also describe how to specify username and password information during a test session so that you can confirm relay authentication.
SMTP Basics
Because an SMTP session is, more or less, a plaintext stream of commands and data, you can use a Telnet session to test for open relays—as long as you know what sequence of commands and data to send. To conduct a basic SMTP session with the Telnet client, you open the connection on port 25 (the default SMTP port) instead of Telnet's default port 23. Figure 1, page 2, shows the beginning of a typical SMTP session between a sending client and an SMTP server. When the connection is opened, the sending client specifies who the mail is from, followed by the recipient's address. The client uses the MAIL FROM command verb to specify the sender's email address and the RCPT TO verbs to specify each recipient's email address.
As it processes each command verb, the SMTP server returns a numeric response code so that the sending client knows whether the command was successful. The response codes are three-digit numbers with optional text that describes the response code—200-level codes signify success or provide information about server capabilities, 300-level codes signify an intermediate response in which the receiving system is expecting more detail from the sender, 400-level codes signify transient or temporary failures, and 500-level codes signify critical failures. The ability to see these response codes as the session progresses has great value when you're trying to troubleshoot SMTP problems.
Testing Relays
In Figure 1, the 250 OK response code shows that the SMTP server accepted the commands. As the server processes each RCPT TO command, it returns a 250 OK success code if the server accepts delivery for the recipient. If the SMTP server isn't willing to attempt delivery for a recipient, it must return a 500-level failure code. In the case of a message to be relayed, the server returns the specific 550 Relaying Prohibited code. To test whether a server is properly configured to permit authenticated relaying, you use the Telnet session to issue a sequence of SMTP RCPT TO command verbs and look for the 250 (accepted) or 550 (rejected) responses from the server.
You'll want to send RCPT TO commands that specify a recipient that the server should accept as well as some that the server should reject. Your server determines which addresses are accepted according to which recipient policies are defined. To provide an example, let's focus on mail sent to the @exchangefun.com domain. When the SMTP server receives mail for joe@exchangefun .com, the server should accept it and return a 250 response. When the SMTP server receives mail for [email protected], you should get a 550 Relaying Prohibited response, confirming that relaying is prohibited for general use. To verify that relaying is permitted, you'll need to test from a system whose IP address is allowed to relay and again from an account that can authenticate when authenticated relaying is allowed. Don't send these messages from the same system. If you test the authenticated relay from a system whose IP address permits relaying, the test will be invalidated.
To start the Telnet session, open a command window. At the command prompt, type
telnet
and press Enter. At the Telnet prompt, type
set Local_Echo
and press Enter. Doing so sets the Telnet session so that it displays what you type and send to the server. Local _Echo isn't necessary for testing relaying, but it lets you know whether an error return code is the result of a typographical error. At the next Telnet prompt, type
open servername 25
where servername is the name of your SMTP-relay virtual server. For example, if you typed
open smtp-relay.exchangefun.com 25
the Exchange Server system would respond with a message that's similar to this:
220 smtp-relay.exchangefun.com Microsoft ESMTP MAIL Service, Version: 6.0.3790.0 ready at Wed, 29 Sep 2004 21:19:14 -0400
The commands you give to test basic relaying are the same as those that Figure 1 shows, except you'd replace the addressing information that's relevant to your tests (e.g., replace Joe [email protected] with joe@ex changefun.com or you@yourdomain .com).
Testing Authenticated Relays
Testing relays based on IP authorization requires only that you open the Telnet session from the systems whose IP addresses are listed in the relay list. Testing authenticated relays is a little more complex because you need to provide a username and password. During the SMTP session, you need to use Extended SMTP (ESMTP) authentication commands to provide the credentials necessary to permit relaying. Doing so seems easy enough until you realize that you can't simply type the username and password as part of the Telnet session. The ESMTP commands that are related to authentication require Base64 encoding, so you'll first need to convert the account name and password strings from plaintext to Base64.
Base64 was originally devised so that 8-bit data could be reliably transmitted via protocols—such as SMTP—that can handle only 7-bit data. To convert to Base64, you take a grouping of bytes and split them at 6-bit boundaries, then map the results to a Base64 "alphabet" that consists of 64 printable characters (A to Z, a to z, 0 to 9, + and /).
For example, the name JOE represented as binary is 01001010 01001111 01000101 (e.g., E equals ASCII 69 equals binary 01000101). To convert this 8-bit binary representation of JOE to Base64, you'd split the bit string into 6-bit sections—for example, 010010 100100 111101 000101. The first bit group, 010010, is the binary representation of 18, so the first character in the Base64 encoded string would be S (the 18th character in the Base64 alphabet). The entire bit string converted to Base64 is Sm9l.
Fortunately, you don't have to perform all these splits and conversions manually. Listing 1 shows Visual Basic for Applications (VBA) code that you can use in Microsoft Excel to perform Base64 encoding. Open a new Excel spreadsheet, choose Macro from the Tools menu, and select Visual Basic Editor. From the editor's Insert menu, choose Module. After the Module window opens, copy the code in Listing 1 into the window, then close the editor (you don't need to save anything). In cell A1, enter the account name that you'll use to authenticate relaying. In cell A2, enter the account's password (case sensitive). In cell B1, type
=Base64(A1)
and press Enter. In cell B2, type
=Base64(A2)
and press Enter. The Base64 representations of the account name and password will appear in the B1 and B2 cells, respectively. I suggest that you also change the font for the B1 and B2 cells to Courier so that there's no confusion about which characters are numbers and which are letters. Using the default font, the letter O and the number zero (0), as well as the letter I and the number one (1), can appear identical. If you want to ensure that the conversion function is working correctly, type, for example,
exfun\neubauer
in cell A1 and the sample password
Go!Exchange
in cell A2. (Both entries are case sensitive.) The Base64 translations should be ZXhmdW5cbmV1YmF1ZXI= and R28hRXhjaGFuZ2U=, respectively. If you see these values, the conversion function is working correctly. Before proceeding, replace the contents of cells A1 and A2 with the valid credentials from your environment.
After you encode the account and password in Base64, you're ready to test. Use the Telnet session to open a connection on port 25 to Exchange. To start the ESMTP session, type
ehlo
and press Enter. Exchange responds with about seventeen 250 response codes indicating the available ESMTP commands. Next, enter the MAIL FROM verb with the name of a sending mailbox that's permitted to relay. For example, if the sender's email address is [email protected], enter
mail from:
and press Enter. The server should respond with a 250 OK message. The next command you give specifies an account at an external domain. Type
rcpt to:
and press Enter. The server should respond with a 550 response code stating that relaying is prohibited. If it doesn't, your server is an open relay. Assuming you saw the 550 response, type
auth login
and press Enter. The server will respond with a 334 VXNlcm5hbWU6 intermediate response code, indicating that a Base64 encoded account name is expected. Type the case-sensitive text from cell B1 of the Excel spreadsheet (i.e., ZXhmdW5cbmV1Y-mF1ZXI=) and press Enter. The server responds with a 334 UGFzc3dvcmQ6 intermediate response code, indicating that a password is expected. Enter the case-sensitive text from cell B2 and press Enter. If the server responds with a 235 code, you've successfully authenticated. If you're unsuccessful, you should see a 535 failure code. After you successfully authenticate, type
rcpt to:
again and press Enter. This time, you should see a 250 response stating that relaying with authentication is permitted. Finally, type rset and press Enter, then type quit and press Enter to close the SMTP session without actually sending a message. Type quit at the Telnet prompt to exit Telnet.
If you followed the configuration steps in "Exchange Relay Review" and limited authenticated relaying to a group, you should repeat this process with a domain account that isn't a member of the security group that's allowed to relay. Although this second account is valid in the domain, you should receive a 550 response at each RCPT TO command.
Test Well, Test Often
Testing is an important step in the design and configuration of any system. As you develop your testing scenarios to guard against SMTP relays, make sure you document them, then integrate them as a standard operating procedure to be
performed periodically. In most environments, multiple people can make changes, which increases the risk that the system could be misconfigured. Test often to ensure that the system's relay security hasn't been compromised.
