When creating web pages and WSH scripts that send email it sometimes necessary to test the IIS SMTP service to ensure that it is properly handling and sending email. The technique I’ll be demonstrating today can be used locally or for testing the SMTP service on a remote server.
IIS SMTP as a service that listens on TCP port 25 by default. We can test this by using the Telnet utility to connect to a machine directly on port 25. For those who aren’t familiar with a telnet client, it’s basically a command console that allows you to connect to remote machines on a specified port.
To begin you’ll need to open the Telnet utility by typing telnet
To test the local SMTP service on my machine I simply used telnet localhost 25. Localhost is a DNS host name that refers to the local loopback adapter (127.0.0.1). The result should look something like this:
220 oemcomputer Microsoft ESMTP MAIL Service, Version: 6.0.2600.2180 ready at Tue, 20 Jan 2009 20:58:34 -0500
Once you connect on port 25, the SMTP service identifies itself. Here you can see the version number and the remote time time on the SMTP server. At this point, the SMTP service is waiting for the connecting computer to identify itself. This is part of a standard handshake. You can learn more about the SMTP protocol by reading RFC 2821.
To identify ourselves, we need to use the HELO command followed by a domain name. This identifies the requesting domain to the SMTP server. For our purposes, let’s use helo me. If a connection can be established (and is allowed), the SMTP server will respond with a 250 message indicating that the greeting was accepted.
250 oemcomputer Hello [127.0.0.1]
So far, so good. We know at this point that the SMTP service on the remote server is both running and accepting connections. Now it’s time to attempt sending an email. We’re going to use the command line to build a test email line by line according to the RFC specification. We’ll begin by identifying the sender’s email address. This address originate from any domain allowed by the SMTP service. On most servers this domain will have to be white-listed and the email address will have to actually exist. In IIS, you can almost always use the default postmaster account by typing mail from:[email protected] and pressing <ENTER>.
250 2.1.0 [email protected]...Sender OK
The SMTP service has accepted the originating email address and issued a 250 response to indicate that sending from this address is allowed by the server rules. Now we need to instruct the SMTP service where the email should be delivered to. Type rcpt to:[email protected] and press <ENTER>. If you want to test delivery, you should enter a valid email address here.
250 2.1.5 [email protected]
Another 250 response indicates that the server has accepted the intended delivery address. Next, we’ll begin constructing the contents of the message. Type Data and press <ENTER> to let the SMTP service know that we’ll be sending multi-line data for the message contents. From this point on, the server will no longer recognize line-breaks as the end of commands.
354 Start mail input; end with <crlf>.</crlf><crlf></crlf>
Now enter the following information, pressing <ENTER> to move from one line to the next. When you are finished with your input, press “<ENTER>.<ENTER>”. The server will recognize a line-break followed by a period and then another line-break as the end if multi-line input. Type the contents of a simple email exactly as shown below:
Subject:This is a test Testing .
Pressing enter after the final period will cause the server to process the entered email information. If all is well, the server will respond that the email has been queued for delivery.
250 2.6.0 <oemcomputerowqifoqa00000002 @oemcomputer> Queued mail for delivery</oemcomputerowqifoqa00000002>
You can now type quit and press <ENTER> to end the telnet application and close the current connection.
It’s important to understand that a message being queued for delivery indicates exactly that. It does not indicate that the message will actually be delivered. The message will still need to be accepted by the receiving mail system, etc.