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.