One of the best tools available for troubleshooting mail flow issues is right at your fingertips. It is quick, simple, and only requires a little training to use effectively. I am always surprised at how very few Exchange administrators seem to use it. You can see some of this in action in my previous NDR troubleshooting post. So let’s delve into some of the basics of how to use telnet for troubleshooting your mail flow issues.
First off, it is a great way to see if your SMTP service is even available. If you cannot connect to it via telnet then you immediately know that you need to check on the health of your services and if that is ok then you most likely have a firewall or other networking issue. So to execute this basic check pop open a command prompt and run
telnet myserver.contoso.com 25
Substituting your server address and if you are troubleshooting an alternate port change the 25 to whatever port you are troubleshooting. The majority of the time it will be port 25 though. If you receive a successful connection you should be greeted by your mail server’s banner, probably something along the lines of below
220 myserver.contoso.com Microsoft ESMTP MAIL Service ready at Mon, 27 May 2013 08:19:44 -0700
This is also a good time to check whether you are seeing the correct server address in your banner. If you are seeing the internal address for myserver.contoso.local you will want to update this.
At this point you need respond with a HELO or EHLO command to start the SMTP conversation. What is the difference between them? HELO is for SMTP while EHLO is for eSMTP. In the context of sending an e-mail via telnet it won’t matter which you use but it mail be useful to use EHLO to see what verbs are being offered, especially if you are suspecting that there mail be a problem with eSMTP.
You should receive a response similar to what is below
250-myserver.contoso.com Hello [220.127.116.11] 250-SIZE 250-PIPELINING 250-DSN 250-ENHANCEDSTATUSCODES 250-STARTTLS 250-AUTH NTLM LOGIN 250-8BITMIME 250-BINARYMIME 250 CHUNKING
If you have seen all of the above then so far so good. Your routing is good (assuming you aren’t being routed to the wrong SMTP server, but if you are and you don’t know it then you have bigger problems), your firewall configuration is correct and your hub transport is listening. Also note from the verbs sent above you can see that this service supports TLS and authentication as you can see in the STARTTLS and AUTH NTLM LOGIN verbs.
Now we want to start sending an email to someone on this server. Most likely your postmaster account since you are just testing your mail flow.
MAIL FROM: email@example.com
You should receive a Sender OK response. If not then you’ll know that you need to look into sender permissions.
250 2.1.0 Sender OK
We need to specify who we are sending to
RCPT TO: firstname.lastname@example.org
Here you should receive a Recipient OK response. This is the part where the conversation is most likely to break down and you will get an error code that you can start working with.
250 2.1.5 Recipient OK
So far so good, now we can send the actual email. Start off with the DATA command
And the server will be ready to receive your input. You can get as fancy or as simple as you like here but once you are done with the message use a . to end the mail input
354 Start mail input; end with <CRLF>.<CRLF> . 250 2.6.0 <email@example.com> [InternalId=47975] Queued mail for delivery
Assuming everything is still going well you should see either a queued mail for delivery or a spam rejection, depending upon how strict your spam filter is. You also may get an error message that would be worth researching as well. If everything is still going well you can close out the conversation.
QUIT 221 2.0.0 Service closing transmission channel
This is all for sending an email similar to how an anonymous server on the Internet would send an e-mail. There are a few variations that you will want to be aware of as well though. The first is for testing relaying. When you get to the part where you input the recipient you will input a remote server recipient.
RCPT TO: firstname.lastname@example.org
If you are NOT wanting the server to relay the expected response would be
550 5.7.1 Unable to relay
This is a good thing as you do not want open relays sitting around. But on the other hand if this is an internal connector that is supposed to be relaying then you could have a permissions problem on your hand.
The other method that you would normally use telnet testing for is authentication. This is a bit more complex. After your HELO/EHLO command you will issue
To which if basic authentication is supported you will receive a response of
This gibberish is actually a base64 encoded response that says “Username:”. The expected response to this is a base64 encoded username. An online utility I recommend is at this site which is pretty simple for encoding/decoding base64 message. So translate the username you are attempting to use into base64 and respond with that. I responded with “logon” encoded.
You should receive a response of
Which translates to “Password.” So now you need to response with the account’s password encoded in base64. My response was “My simple password”
You should now receive an Authentication successful message
235 Authentication succeeded
And you can continue with the rest of your steps of sending an email.
Was this post helpful? Do you have any topics you would be interested in seeing me cover in a later blog post? Just leave your suggestion in the comments below or shoot me an email.
[…] focus you in on what is going on really fast. Continuing with what you learned from the post on Essential Exchange Troubleshooting – Send Email via Telnet you will want to telnet into the server from outside the organization. You may immediately get a […]
[…] extremely vital tools in your Microsoft Exchange swiss army knife. I’ve already talked about the usefulness of telnet in previous posts so I won’t bore you all over again. Nslookup is a fantastic way to quickly […]
I got stuck on the first step – timeout exceeded. What does that mean?
I’m guessing you are referring to after you have connected to the host via telnet on port 25? If you’re receiving a timeout while sending over the commands then most likely the host has some very strict timeouts configured for SMTP commands to be sent. Depending upon what you are testing you may want to use a testing tool like mxtoolbox.com or if you’re testing something outside of the norm perhaps put together a script for your specific test so that the commands be executed in swift succession and hopefully avoid the timeout.
Just ref your article Exchange troubleshooting. I follow the procedure and can send an email by telnet – or not if I don’t have an open relay.
I can see the telnet commands for sending with basic auth but no reference to what the procedure is for auth ntlm which is what you have in the example in the article
250-myserver.contoso.com Hello [18.104.22.168]
250-AUTH NTLM LOGIN
Is it the same? If so then it’s not working for me as I don’t get a response after putting gin the encoded username except authentication unsuccessful
Here is a good flow diagram for NTLM authentication: https://msdn.microsoft.com/en-us/library/Cc246870.aspx
So the flow would be you send AUTH NTLM and the server should respond with 334 ntlm supported. Unfortunately that is as far as we can get with basic text. The next message is a BASE64 encoded NTLM negotiate which is pretty much as far as you can get without NTLM software support. Your best option for testing NTLM authentication would be a mail client. If you are needing to troubleshoot something besides authentication then for testing via telnet you’d be best served by temporarily turning on basic authentication. Good luck troubleshooting and let me know if you have any other questions!