How to use telnet to test your mail Exchange server

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.