When troubleshooting email, one tool I use again and again is my trusty telnet client. With that one simple command line tool, and a little knowledge of the RFCs, I can usually debug network issues related to email delivery, or at least narrow them down quickly without resorting to packet captures, reconfiguring clients, or other legerdemain. While most old school colleagues will go to telnet without a second thought, many others seem to think this is eldritch magick, so today we are going to learn how to use telnet to test SMTP.

One reason many of the newer IT professionals may not be as comfortable with telnet is because it is not included be default in the newer Microsoft operating systems. Starting with Vista, Microsoft decided to make you ‘opt in’ to using it, probably because it does transmit all traffic in the clear, and as such, could expose passwords or other confidential information. While that is true, and a very important thing to understand, using it to connect to services, grab banners, and send simple mail is safe enough, and I keep a generic account handy for things that require logins so that I can test without exposing my true domain account credentials. Here’s how to get started.

If you don’t have the telnet client installed, open an administrative command prompt, and run this command to install it.

servermangercmd.exe -i telnet-client [enter]

Once you have it installed, you will want to run it from a cmd prompt, and not from the RUN dialog. You do not have to run it from an administrative cmd prompt. The telnet.exe can be launched by simply running the command, which will give you an interactive prompt. Or you can invoke it with arguments, that include the destination host (by ip.addr or FQDN) and port number, where the telnet protocol’s well-known port 23 is the default. Since we are going to look at troubleshooting SMTP, lets get right into it. When I use telnet to connect to an SMTP server for testing, I usually launch it like this (since the client’s default settings are usually sufficient for this).

telnet mail.example.com 25 [enter]

If you want to see other options, run it, and enter a ? to see the other options. You will see that ntlm is an option in the Windows client; that is only useful to protect credentials when connecting to a server running Microsoft’s telnetd. It will not encrypt creds to anything else, nor will it encrypt any data. Once you connect to your destination server on port 25, you should see the server’s banner, like this.

 If you see something like this instead…

then you have a PIX or ASA doing fixup or inspect, respectively, on SMTP. The important piece is that little 220. RFC821 defines the response codes SMTP servers use. 220 means you have connected, and the server is ready to communicate with you over SMTP.

*See that quirky banner? That is so a malicious user can’t easily tell what kind of SMTPd I am running. See How to change your SMTP banner for fun and profit for how to change your banner.

 There are several commands that are supported by SMTP, and you can consult RFC821 for those, or RFC2821 for the ESMTP command, but here are the ones you want to know off the top of your head.

• HELO this is your way of identifying the sending system. MTAs that do reverse DNS lookups will take what you put in the HELO command, and see if they ip.addr of your connection maps to what you assert here. YMMV.
• MAIL FROM: Note the colon. This is the email address your cmd-line email comes from.
• RCPT TO: Note the colon. This is the email address you want the server to deliver the email to.
• DATA This tells the server that you are ready to start sending the actual email.
• SUBJECT: Note the colon. Places the subject line, and must be followed by a CR. Then you can begin to type your message, using single CRs for each line break you want to enter.
• CR.CR This is how you end the message.
• QUIT Does exactly that.

The server will respond with certain codes to each of your inputs.

• 220 Means the server has accepted your initial connection and is ready to accept further SMTP from you.
• 221 In response to a quit command, it means the session has been gracefully terminated.
• 250 Means that the server has accepted your input.
• 354 In response to the data command, it means the server knows who the mail is from, who it is to, and is ready for the message.

There are some other responses that you might encounter.

• 250 2.0.0 Resetting A response the RSET command, indicating the session is being reset.
• 252 2.1.5 Cannot VRFY user A response to a request to VeRiFY an address.
• 421 4.7.0 Too many errors on this connection, closing transmission channel. What happens when you make too many typos, or ask for too many things that the server will not do.
• 500 5.3.3 Unrecognized command
• 501 5.5.4 Unrecognized parameter
• 501 5.5.4 Invalid arguments
• 503 5.5.2 Send hello first
• 503 5.5.2 Need mail command
• 503 5.5.2 Need rcpt command
• 550 5.7.1 Unable to relay

With these, you are ready to submit a mail to the server from the telnet prompt, and determine whether the system will accept the mail, relay the mail, or drop the mail. Be careful, one thing you cannot do using telnet is backspace, so if you make a mistake typing, you can enter a RSET command on the next line, just keep going, or kill the connection and try again. Here is how a connection would look, where everything you type is in red, and everything the server responds is in black.

telnet server.example.com 25
220 This is the example.com mailserver. How you doin’?
helo example.com
250 server.example.com Hello [192.168.217.64]
mail from:elvis@graceland.com
250 2.1.0 ed@example.com….Sender OK
rcpt to:ed@example.com
250 2.1.5 ed@example.com
data
354 Please start mail input.
subject: peanut butter and banana sandwich recipe
This is delicious.
Thank you, thank you very much.
.
250 Mail queued for delivery.
quit
221 Closing connection. Good bye.
Connection to host lost.

If you make it through from the 220 to the 221, then you have successfully queued an email for delivery. When testing your external SMTP gateway, try to send an email to an external recipient. Make sure your server responds with a 550 5.7.1. With the above information at hand, you are ready to amaze your friends, impress your boss, and troubleshoot mailservers without having to break out any tools or even log onto the server. Enjoy.

Using telnet to test your mail server

Free ebook download: Top 10 Most Popular Troubleshooting Posts for Email Administrators

An essential skill for email administrators is being able to dive into the command line to troubleshoot email delivery and connectivity problems.  In this post I will explain some of the simple command line techniques you can use for diagnosing these email issues.

NSLookup

NSLookup is the command line utility for querying the Domain Name System (DNS).  Because email delivery relies so heavily on the Mail Exchanger (MX) records contained within DNS you need to know how to use it for verifying DNS configurations.

When someone reports a problem sending email to an outside party and you want to investigate it one of the first things you’ll need to determine is the name or IP address of their mail server.  This is the job of the MX record, which you can query using NSLookup.

Open a command prompt (Start -> Run, cmd.exe) and type “nslookup” and press Enter.  First test a few well known web addresses to make sure that your own DNS servers are working properly.

C:\>nslookup
Default Server:  UnKnown
Address:  192.168.0.1

> www.gfi.com
Server:  UnKnown
Address:  192.168.0.1

Non-authoritative answer:
Name:    www.gfi.com
Address:  216.134.217.17

> www.theemailadmin.com
Server:  UnKnown
Address:  192.168.0.1

Non-authoritative answer:
Name:    theemailadmin.com
Address:  69.89.31.227
Aliases:  www.theemailadmin.com

Now change the query type to MX by typing “set” and press Enter.

> set type=mx

Next type the domain name for the organization you are trying to send to, e.g. contoso.com.

> contoso.com

If their DNS zone exists, is correctly configured, and their name servers are responding, you should receive a response similar to this.

Server:  UnKnown
Address:  192.168.0.1

Non-authoritative answer:
contoso.com     MX preference = 10,
mail exchanger = mail.global.frontbridge.com

mail.global.frontbridge.com
internet address = 216.32.180.22

If there is a problem you may receive a response more like this.

*** UnKnown can't find contoso.com: Non-existent domain

When a successful response is received it tells us that they have one MX record with a preference of 10 (this only matters when there are more than one MX records), and that its name is mail.global.frontbridge.com.  Furthermore we can see that mail.global.frontbridge.com resolves to IP address 216.32.180.22.  This is the IP address we want to connect to for testing email connectivity.

Telnet

Telnet is the command line utility to use for testing connectivity.  Telnet allows us to connect to any IP address and TCP port to perform testing.

For Windows Server 2003 and earlier Telnet is already installed, but for Windows Server 2008 Microsoft took the standpoint that Telnet is potentially a hacking tool and so is not installed by default on new servers.  You can install it when necessary by launching an elevated privilege command prompt and running this command.

servermanagercmd.exe –i telnet-client

From a command prompt type “telnet [name/IP address] 25” and press Enter.  This tells Telnet to connect to the given name or IP address on TCP port 25 (the SMTP port).

At a successful connection you will see status code 220 (meaning Service Ready) followed by the welcome banner for the server (this will vary depending on the mail server software that they are running plus whatever customization the email administrator applies).

220 TX2EHSMHS026.bigfish.com Microsoft ESMTP MAIL
Service ready at Thu, 19 Nov 2009 12:44:27 +0000

Now it is time to learn how to issue basic SMTP commands using Telnet.  A simple SMTP session will contain these steps:

EHLO – Identifies the sending server (you).  You can also use HELO, but EHLO is widely supported.

MAIL – Identifies the sending email address.

RCPT – Identifies the receiving email address.

DATA – The contents of the email message itself.

So to test email to the contoso.com email server you can use this command sequence.

ehlo
250-TX2EHSMHS026.bigfish.com Hello [202.173.145.153]
250-SIZE 157286400
250-PIPELINING
250-ENHANCEDSTATUSCODES
250-STARTTLS
250-AUTH
250-8BITMIME
250-BINARYMIME
250 CHUNKING
mail from: paul@exchangeserverpro.com
250 2.1.0 OK
rcpt to: name@contoso.com
250 2.1.5 OK
data
354  Go ahead
Subject: This is a test email
This is a test email
.
250 2.0.0 OK

Note how the message is sent after the DATA verb is issued, the data itself entered, and then a “.” (period) indicating the end of the data.

If there are any problems with this SMTP session the error messages that are returned by the server will indicate exactly what is going on.  For example, the server may return a message saying that message relay is denied, or that the intended recipient is not valid.  From this you can determine the next steps to take in troubleshooting the email problem.

Diagnosing Email Server Problems with the Windows Command Line

Free ebook download: Top 10 Most Popular Troubleshooting Posts for Email Administrators