Telnet has become one of those programs whose use has severely fallen by the way side. Other than nc I can think of no other troubleshooting utility that actually allows one to test if a daemon is functioning properly. While ping will inform you if an IP address is live, and by virtue of DNS resolving can assist in host name look ups. It is afterall a very basic tool
So what is all this ado about telnet? I mean it’s just for remote login to another machine. Albeit unsecured login, which is something I am not necessarily advocating here. No, what I am on about it the usage of telnet to attache to various tcp ports and facilitate manual communication between your keyboard and a service (daemon).
Have you ever received a call from an enraged client screeming that their email isn’t work, but you’ve successfully pinged the mailserver’s IP address which of course answers? Wouldn’t is be nice if you could in less than ten minute determine if it is a sending or recieving anomaly?
Well you could with the use of telnet.
Consider the following command line examples;
SMTP test
> telnet 10.0.0.145 25
POP3 test
> telnet 10.0.0.145 110
IMAP4 test
> telnet 10.0.0.145 143
HTTP test
> telnet 10.0.0.145 80
In each example we are opening a telnet session to the specified IP address on the designated port. Let’s look at the last example of testing http access.
telnet jafdip.com 80
Trying 69.31.85.202…
Connected to jafdip.com.
Escape character is ‘^]’.
HEAD / HTTP/1.1
HTTP/1.1 400 Bad Request
Date: Mon, 28 Jul 2008 16:43:38 GMT
Server: Apache/2.2.8 (Unix) mod_ssl/2.2.8 OpenSSL/0.9.7l DAV/2 PHP/5.2.5 SVN/1.4.4
Connection: close
Content-Type: text/html; charset=iso-8859-1
Connection closed by foreign host.
Here we see the transcript of the transaction. All that I am concerned about is learning the that the HTTP daemon is indeed running. Ok I also find some of the returned information very useful. As I might be trouble shooting an SSL certificut error and it would be handy to know the version of mod_ssl.
Now let us examine how one would determine if the mail service was operational. Notice that I specify the mail server by name and not just by IP address. I do this to determine if there is a DNS resolution error. A common reason mail servers fail is that someone changes their services around while neglecting to properly update their DNS.
telnet mail.jafdip.com 25
Trying 69.31.85.206…
Connected to mail.jafdip.com.
Escape character is ‘^]’.
220 ***************************************************
So what we are seeing here is a filtered respounce. The following is an example of an unfiltered respounce. In the former example the mail server details were obfuscated.
220 Jupiter.Jafdip.com Microsoft ESMTP MAIL Service ready at Mon, 28 Jul 2008 12:47:47 -0400
How your mail server answers is entirely up to your site security policies, and I am in now way saying that the first one is better than the second. I mean even if I were to feel this I wouldn’t necessarily come right out and state. Besides security through obscurity is no real security plan.
I will leave testing IMAP and POP up to you. In the next installment I shall cover how to actually test your mail server by manually keying in the message.
