Windows Insider

Be the Exchange Server

By trying to think like an Exchange Server, you can learn the ins and outs of the SMTP protocol.

• By Bill Boswell
• 12/01/2003

Having a full Inbox when you log onto your e-mail in the morning used to give you that warm feeling that comes from knowing that your friends and colleagues want to know how you’re doing and seek your advice. Now a full Inbox just irritates you because most of the messages ask you to buy potions, pills, porn or to help rich emperors in distress.

As featured in Mike Gunderloy’s October article comparing anti-spam solutions, "Outrun the Avalanche," there are a host of products to choose from to battle spam. But eliminating spam can’t be done with the click of a button or the installation of a single anti-spam application. It takes an understanding of how e-mail makes its way to you and your users. Take a Zen attitude toward the problem. Become an e-mail server, get inside the process and use this information to help you select and deploy the right anti-spam measures.

Simple Mail Transfer Protocol
Internet messaging servers and clients use Simple Mail Transfer Protocol, or SMTP, to deliver e-mail. The protocol was originally described in RFC 821 and is currently standardized in RFC 2821. Outlook uses Messaging Application Programming Interface (MAPI) for message delivery to Exchange servers; but from there, Exchange uses SMTP to deliver messages to Internet clients. Exchange 2000 and 2003 use SMTP to send messages between servers within an organization.

You don’t need a full-blown messaging platform like Exchange or Notes to experiment with e-mail delivery. Both Windows 2000 and Windows Server 2003 come with a fully functional SMTP service. The service belongs to the Internet Information Service (IIS); so to do testing, just install IIS and include the SMTP service. Windows 2003 also has a Post Office Protocol version 3 (POP3) service that allows a server to become a simple messaging platform, but you won’t need that service for these experiments.

Observing SMTP Transactions
To stay true to our Zen goal of becoming one with the messaging process, we need a tool that allows us to communicate directly with the SMTP service on a messaging server. Telnet comes in handy for this work. Windows includes a command-line client, Telnet.exe and a GUI communications utility called Hyperterm that can function as a telnet client. For these examples, I’ll use the command-line client.

To configure the command-line client, type “telnet” at a command prompt then type “set ?” to get a list of parameters.

Microsoft Telnet> set ?
bsasdel        Backspace will be sent as delete
crlf           New line mod—Causes return key to send CR & LF
delasbs        Delete will be sent as backspace
escape x       x is an escape character to enter telnet client                prompt
localecho      Turn on localecho.
logfile x      x is current client log file
logging        Turn on logging
mode x         x is console or stream
ntlm           Turn on NTLM authentication.
term x         x is ansi, vt100, vt52, or vtnt

Type “set localecho” so you can see what you’re typing once you connect to an SMTP server. Type “set logfile telnet.log” and “set logging” to save a copy of the commands you type and their responses. Exit the session by typing “quit.”

SMTP Domain
Because your test server doesn’t actually host a messaging system, the SMTP service needs to forward incoming messages onto their ultimate destination. In SMTP parlance, this is called relaying.

By default, Windows SMTP doesn’t relay messages unless configured to do so. This prevents spammers or other bad guys from exploiting the service. An SMTP server that relays messages to any domain on behalf of anonymous users is called an open relay. Spammers love an open relay the same way Bart Simpson loves a Butterfinger bar.

For testing purposes, you’ll need to configure the SMTP service on your test server to relay mail for your domain. For example, let’s say your company uses the DNS domain Company.com for messaging, so that messages sent to recipients in your company have an address such as [email protected]. In the IIS Manager console, drill down through the Default SMTP Virtual Server icon to see the Domains icon. Figure 1 shows an example.

Figure 1. The IIS Management console showing the Default SMTP Virtual Server icon, the Domains icon and a remote domain of Company.com used for message relaying. (Click image to view larger version.)

Right-click the Domains icon and select New | Domain from the flyout menu. This opens the New SMTP Domain Wizard. The Welcome window gives you two options for the domain type: Remote and Alias. Select the Remote option because you’re specifying an SMTP domain hosted by another SMTP server.

Click Next to open the Domain Name window. Enter the DNS domain name for your organization. In this example, that would be Company.com. The entry isn’t case-sensitive. When you click Finish, the wizard adds the domain name to the domain list for the Default SMTP Virtual Server.

Open the Properties window for the new domain icon. Figure 2 shows an example.

Figure 2. SMTP domain properties showing the authorization to relay for this domain name.

Select the Allow Incoming Mail To Be Relayed To This Domain option. This tells the SMTP virtual server to accept messages addressed to recipients in the Company.com domain. Create a domain for your Internet domain address, as well, and configure that domain to accept relay requests. For example, if you have a Yahoo mail address of [email protected], then create a Remote domain for Yahoo.com.

SMTP Routing
Leave the Properties window of the SMTP domain open for a moment. The second set of options plays an important role in determining whether messages from this server will arrive at their intended destination.

Before the SMTP service can relay messages to a recipient in a remote SMTP domain, it needs to identify the SMTP servers in that domain. As you can see in the Properties window, the default setting for a Windows SMTP domain uses DNS for this discovery process.

When confronted with a message to a recipient in a particular domain, the SMTP service queries DNS for any Mail Exchange (MX) resource records in that domain. The DNS server replies with a copy of the MX records and the associated A records that contain the servers’ IP addresses.

You can emulate this query by using Nslookup. Open a command prompt and type “nslookup” to start an interactive session. Set a filter to look for MX records by typing the command “set type=mx” and then type the fully qualified DNS name of the target domain. For example, here’s a partial listing of MX records for Yahoo.com:

C:\>nslookup
Default Server: w2k3-s1.company.com
Address: 192.168.0.1

> set type=mx
> yahoo.com.
Server: w2k3-s1.company.com
Address: 192.168.0.1

Non-authoritative answer:
yahoo.com MX preference = 1, mail exchanger
   = mx1.mail.yahoo.com

yahoo.com MX preference = 1, mail exchanger
   = mx2.mail.yahoo.com

yahoo.com MX preference = 5, mail exchanger
   = mx4.mail.yahoo.com

yahoo.com nameserver = ns1.yahoo.com

mx1.mail.yahoo.com internet address
   = 64.157.4.78

mx2.mail.yahoo.com internet address
   = 64.157.4.78

mx4.mail.yahoo.com internet address
   = 216.136.129.6

The SMTP service selects one of these MX records at random and makes a connection to the SMTP service running on the designated host. The Preference numbers influence this selection. Lower Preference values have precedence over higher values.

This method of using DNS to find mail servers doesn’t always yield optimal results. For example, your SMTP server might resolve the MX records for a target domain, but you’re inside a firewall that doesn’t permit outbound SMTP connections. SMTP uses TCP port 25. If you’re at home, many Internet Service Providers (ISPs) prevent hosts inside their network from completing an SMTP connection to servers outside their network to prevent spamming.

In these circumstances, you can configure the SMTP service to relay messages to another SMTP server, called a smart host. The second SMTP server doesn’t need to be all that smart. As long as it accepts messages from your SMTP server and sends them to an SMTP server in the target domain, it’s smart enough.

SMTP Banners
You’re now ready to send an SMTP message using Telnet. SMTP uses TCP port 25 to send and receive messages, so your first step is to make a Telnet connection to port 25 on your test server. You can do this from the console of the test server or from a workstation in the same network. (Windows Telnet uses NTLM authentication.)

Initiate the connection by typing “telnet 25.” The connection starts with a three-way SYN/SYN-ACK/ACK handshake. Once the client and server complete the handshake, the SMTP server returns a banner similar to this:

ehlo
250-w2k3-s102 Hello [192.168.0.248]
250-TURN
250-SIZE 2097152
250-ETRN
250-PIPELINING
250-DSN
250-ENHANCEDSTATUSCODES
250-8bitmime
250-BINARYMIME
250-CHUNKING
250-VRFY
250 OK

You don’t really need to know details about these capabilities. Just remember that the SMTP service doesn’t accept messages unless you first enter an ehlo (or the older helo) command.

From this point, sending an e-mail message uses three SMTP commands: Mail From, Rcpt To, and Data. Both the Mail From and Rcpt To commands accept a well-formed e-mail address as an argument. The Mail From address doesn’t have to exist. You could use [email protected] if you like, or [email protected]. This kind of spoofing is what makes an open relay so attractive to spammers. They can hide their real names as well as the origin of the messages.

As a first test, give the Rcpt To command an address that lies outside the domains you configured for relaying. You should get a result like this:

mail from: [email protected]
250 2.1.0 [email protected] OK
rcpt to: [email protected]
550 5.7.1 Unable to relay for [email protected]

Now send a message to your e-mail account in the SMTP domain you configured to accept relaying. The transaction looks like this, with your entries in bold:

mail from: [email protected]
250 2.1.0 [email protected] OK
rcpt to: [email protected]
250 2.1.5 [email protected]
data
354 Start mail input; end with <CRLF>.<CRLF>
Subject: Test message from SMTP
This is the message body. Type anything you want to here. When you’re ready to end the data portion, press Enter then type a dot then press Enter again.
250 2.6.0 <[email protected]> Queued mail for delivery
quit
221 2.0.0 w2k3-s1.company.com Service closing transmission channel
Connection to host lost.

In a few seconds, depending on the connection latencies, you should see the message arrive in your Inbox. The long number returned by the SMTP service following the end of the DATA portion is called a Message ID. The SMTP service uses this number to track a message sent to multiple recipients because each recipient gets a separate Rcpt To entry.

SMTP Authentication
In its standard configuration, a Windows SMTP server accepts only anonymous connections. You can view and modify this setting using the IIS Manager console. Open the Properties window for the Default SMTP Virtual Server, select the Access tab, and then click Authentication. This opens an Authentication window that shows three authentication methods: Anonymous, Basic and Integrated Windows.

If you configure your test server to accept all three authentication types, you’ll see a couple of new capabilities in response to an ehlo command.

ehlo
250-w2k3-s1.company.com Hello [192.168.0.248]
250-TURN
250-SIZE
250-ETRN
250-PIPELINING
250-DSN
250-ENHANCEDSTATUSCODES
250-8bitmime
250-BINARYMIME
250-CHUNKING
250-VRFY
250-AUTH GSSAPI NTLM LOGIN
250-AUTH=LOGIN
250 OK

This willingness to accept an authenticated connection is not necessarily a good thing. Many SMTP services, including Windows SMTP, will relay for an authenticated user. You (or a spammer) can take advantage of this if you know the credentials for an account in the SMTP server’s Active Directory domain.

To emulate an authenticated transaction, you’ll need a way to encode a string using Base64. Microsoft provides a Base64 encoder/decoder called Base64.exe as a free download. The code isn’t compiled, but you can compile it using Visual Studio.

Here’s an example AUTH transaction using basic authentication via the AUTH LOGIN option. The bold items on each line aren’t part of the transaction. They show the decodes of the Base64 strings.

Client - AUTH LOGIN
Server - 334 VXNlcm5hbWU6
Client - Y29tcGFueVxwaG9lbml4dXNlcjE=
Server - 334 UGFzc3dvcmQ6
Client - UnVtcGxlc3RpbHQka2lu
Server - 235 2.7.0 Authentication successful.
Username: company\phoenixuser1
Password: Rumplestilt$kin

So, if you know the credentials for a user in a given SMTP server’s domain, you can encode the credentials using Base64, then supply them in an AUTH transaction via Telnet then send mail to a user in some other SMTP domain as follows:

telnet w2k3-s1 25
220 w2k3-s1.company.com SMTP Service Available
Tue, 29 Jul 2003 10:26:27 -0700
ehlo
250-w2k3-s1.company.com Hello [192.168.0.248]
250-TURN
250-SIZE
250-ETRN
250-PIPELINING
250-DSN
250-ENHANCEDSTATUSCODES
250-8bitmime
250-BINARYMIME
250-CHUNKING
250-VRFY
250-AUTH GSSAPI NTLM LOGIN
250-AUTH=LOGIN
250 OK
auth login
334 VXNlcm5hbWU6
Y29tcGFueVxwaG9lbml4dXNlcjE=
334 UGFzc3dvcmQ6
UnVtcGxlc3RpbHQka2lu
235 2.7.0 Authentication successful.
mail from: YourMostEsteemedColleague@    VeryMostRespectableAddress.com
250 2.1.0 YourMostEsteemedColleague@    VeryMostRespectableAddress.com....
   Sender OK
rcpt to: [email protected]
250 2.1.5 InternetUser@
   outsideaddress.com
data
354 Start mail input; end with <CRLF>.<CRLF>
Subject: Your assistance most graciously and desperately needed
Let me introduce myself. I am King KRXWALA from the Far Magellanic Clouds. I am here in your compartment of the galaxy for only a few scant days and I am in great distress. You see.....
250 2.6.0 <[email protected]> Queued mail for delivery
quit
221 2.0.0 w2k3-s1.company.com
Service closing transmission channel
Connection to host lost.

As you can see, the server was happy to relay the message. You can configure the SMTP service to accept relay attempts from certain users or specific workstations.

Enlightenment?
When you consider the hundreds of thousands of potential SMTP relay points on the Internet and the millions of dollars that spammers spend in exploiting them, it’s a wonder that we have any room left on any of our mail servers. When selecting a product to protect you from this onslaught, look for perimeter protection, applications that scan all inbound SMTP messages and their attachments, and desktop protection, because users often get mail directly from external servers. Look for products that understand the ways spammers think and can learn from additional examples. And try to achieve a Zen calm when confronted with the next pile of unwelcome messages.