Using Telnet to troubleshoot SMTP connectivity
Friday, March 10th, 2006There are situations where you may want to manually test SMTP connectivity. Some of the common ones for me are:
- When messages are queuing for delivery to or being rejected from a particular domain.
- When I have an application that uses SMTP for notifications but none are being sent.
- Running a basic open relay test.
In the case of queued/rejected messages I’ll first check the MX records for the problem domain via www.dnsstuff.com. For small companies you often see the primary MX record pointing to their server and a secondary record pointing to their ISP. It’s been my experience that the ISP’s mail server is often not configured to store and forward for the domain and instead rejects the message as a relay attempt. This becomes an issue when the primary MX record is unavailable (perhaps the company’s server or Internet connection is down).
So here’s my troubleshooting process in detail:
- Check the MX records for the problem domain via www.dnsstuff.com.
- From the mail server that connects to the destination server (in our case a MailSweeper box) open a command prompt.
- Type telnet mailhost 25 (Mailhost is the host name found in the MX record e.g. myserver.mydomain.com)
- If the mailhost is available you should get a response similar to “220 mydomain.com” followed by some text that identifies the email server software. It is also possible that you get a simpler response designed not to give away any information to potential hackers. If you telnet to my company’s external mail servers you’ll simply get “220 SMTP Relay”.
- If the connection fails you may want to take some additional troubleshooting steps like verifying that the mailhost resolves to an IP address. If you still cannot connect then try the next MX record in order of priority as this is what your mail server would do.
- Once you get a response you need to say hello by typing helo.
- The receiving server should respond with “250 mydomain.com yourIPaddress” or something similar.
- Now you have to simulate sending a message from your domain. To do this first type mail from:youremailaddress e.g. mail from:ant@mycompany.com.
- You should see a response similar to “250 Sender OK”. If you get a rejection it will hopefully give you some additional information to identify why.
- Now enter the destination email address by typing rcpt to:destinationemailaddress.
- You should get a response like “250 desinationemailaddress” although this is often the point where you’ll get an “unable to relay” message if there’s a configuration issue or if you are genuinely trying to relay a message through a closed server.
- Next we need to enter the subject and body text so type the command data which should respond with something like “354 Start mail input; end with .”
- To add a subject you need to type Subject:my_subject_text followed by a carriage return.
- You can then type the body text. When you are finished start a new line type a full stop then hit return.
- You’ll see something like “250 message queued for delivery”.
Following this process through allows me to see at which point it fails and hopefully to obtain a clue as to why.
If I’m troubleshooting an application that should be sending SMTP notifications I would run the commands on the same box as the application and telnet to the SMTP server used in the application settings.
If I’m testing one of my boxes to ensure it’s not an open relay I would telnet to it but use an external email address for both the From address and the To address. I would expect to see a rejection after the RCPT TO: command.
