Testing Linux Mail Servers with OpenSSL

This is a followup to Juliet Kemp's excellent Troubleshooting Linux Servers with telnet article. This is adapted from my aging but still-excellent Linux Cookbook.

Testing IMAP TLS/SSL

This is how to talk to an IMAP server over TLS/SSL. Again, commands that you type are in bold, and remember to use your own server name and login:

$ openssl s_client -connect localhost.com:993
CONNECTED(00000003)
[snip mass certificate and protocol lines]
* OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE AUTH=PLAIN AUTH=LOGIN] Dovecot ready.

login carla password
a001 OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE SORT SORT=DISPLAY THREAD=REFERENCES THREAD=REFS MULTIAPPEND UNSELECT IDLE CHILDREN NAMESPACE UIDPLUS LIST-EXTENDED I18NLEVEL=1 CONDSTORE QRESYNC ESEARCH ESORT SEARCHRES WITHIN CONTEXT=SEARCH LIST-STATUS QUOTA] Logged in

Hurrah, we're in! Now let's list mailboxes:

a002 list "" "*"
* LIST (\HasChildren) "." "INBOX"
* LIST (\HasNoChildren) "." "INBOX.INBOX_Trash"
* LIST (\HasNoChildren) "." "INBOX.Trash"
* LIST (\HasNoChildren) "." "INBOX.read"
* LIST (\HasNoChildren) "." "INBOX.Queue"
* LIST (\HasNoChildren) "." "INBOX.INBOX_Drafts"

And let's see what's in the Inbox:

a003 examine inbox
* FLAGS (\Answered \Flagged \Deleted \Seen \Draft Junk NonJunk)
* OK [PERMANENTFLAGS ()] Read-only mailbox.
* 10 EXISTS
* 0 RECENT
* OK [UNSEEN 1] First unseen.
* OK [UIDVALIDITY 1291459647] UIDs valid
* OK [UIDNEXT 8026] Predicted next UID
* OK [HIGHESTMODSEQ 2710] Highest
a003 OK [READ-ONLY] Select completed.

There are ten messages; let's read the body of the fourth one without the headers:

a004 4 rfc822.text
* 4 FETCH (RFC822.TEXT {857}
On Tue, 15 Feb 2011 11:44:21 -0800
Edwin Hungrytum wrote:

I hear there is going to be food this weekend-- may I come?

Thanks!
Edwin

a005 OK Fetch completed.

I'm bored with reading email this way, so it's time to go:

a005 logout
* BYE Logging out
a005 OK Logout completed.
closed

There are many different commands for listing messages, and reading headers and selected headers. Read all about them in RFC 3501.

Testing POP3 TLS/SSL

This is a followup to Juliet Kemp's excellent Troubleshooting Linux Servers with telnet article. This is adapted from my aging but still-excellent Linux Cookbook.

Testing POP3 TLS/SSL

Telnet does not support any encryption. If you are protecting your POP3 sessions with TLS/SSL then you need s_client, which is part of OpenSSL. You can query both local and remote mail servers, using your own server names of course. Commands that you type are in bold:

$ openssl s_client -connect localhost.com:995
$ openssl s_client -connect remotehost.com:995

You'll see a whole lot of lines about certificates and protocols, and eventually something like this:

---
+OK Dovecot ready.

Now we know we're talking to a Dovecot server. Dovecot supports both secure POP3 and secure IMAP. Now I can give Dovecot my login. Note that if you enter an invalid username it won't tell you, but will still say +OK:

+OK Dovecot ready.
user carla
+OK
pass password
+OK Logged in.

Let's see if I have any messages:

list
+OK 2 messages:
1 1759
2 12422

Yay, two messages for me! Use the retr command to read them:

retr 1
+OK 1759 octets
[snip headers]
Date: Tue, 15 Feb 2011 11:56:48 -0800
From: Mom
To: carla@example.com
Subject: dinner this weekend
[snip message-id]

Hello Little Carla,

We're having a little get-together this weekend and hope you can come. Bring your fabulous chicken skewers.

Love,
the Mama

To read the second message type retr 2. To delete messages type dele followed by the message number, for example dele 1. Messages are not really deleted until you type quit, so you can change your mind and un-delete with the rset command, which un-deletes all messages marked for deletion.

You may need to use the domain name on a remote server to log in, for example user carla@example.com. RFC 1939 contains a complete listing of POP3 commands.

Troubleshooting Linux Servers with telnet

http://www.linuxplanet.com/linuxplanet/tutorials/7295/1

Completely Insecure But Still Useful

February 14, 2011

The venerable telnet is still a useful tool in the server administrator's toolkit. Juliet Kemp shows how to test basic SMTP, IMAP, HTTP, and IRC server functions with telnet.

Telnet is one of the older ways of doing business over a network: a network protocol running over TCP/IP, which allows a client to talk to a server remotely. Back in the day (such as when I first got online), telnet was the usual means to connect to a remote computer to get a console, and from there do server administration, check email, and run applications. These days ssh is the default for security reasons, but telnet still has its uses. Because telnet transmits all data as-is you can use it to open a raw TCP session, then talk to a server running a network service, and do a little debugging. At the very least, telnetting to a particular port on a server can confirm that you can reach the remote server from your machine, and that there is a running service bound to the port.

It's important to remember that telnet is NOT encrypted, so it's very vulnerable to packet-sniffing and man-in-the-middle attacks. You should never use it to transmit a username and password except for controlled tests using disposable accounts.

SMTP

SMTP servers run on port 25, and you can use telnet to talk to them directly:

telnet smtp.example.com 25

Note that you won't get anything that looks like a prompt as the server doesn't expect to interact with humans. Instead, you'll get a couple of lines of output, then a blank line waiting for you to initiate the connection. Type:

EHLO example.com

to register on the server for the domain example.com. EHLO initiates the conversation with the remote server, tells it the host's name, and specifies that the host wants to use the extended SMTP protocol (to use the regular SMTP protocol, use HELO instead). See this site for a useful summary of SMTP server commands.

Your connection is now established, so you can try sending a mail directly.

MAIL From:
RCPT To:
DATA

At this point, you can type your message in. When you're done, hit return, then type . and hit return again to send the message. Type QUIT to leave the session.

This can be a useful way to check what's happening with your SMTP server. Some SMTP servers require TLS, which means that you won't be able to get any further than initiating the connection. But you can at least check that the server is there and taking connections. (The OpenSSL s_client test program is for testing TLS connections on mail servers; come back tomorrow for a s_client howto.)

IMAP

Similarly, you can talk directly to an IMAP server to find out what's going on there:

telnet localhost 143

Once the connection is established, you'll get a bunch of output that looks a bit like this:

Connected to imap.example.com.
Escape character is '^]'.
* OK [CAPABILITY IMAP4rev1 UIDPLUS CHILDREN NAMESPACE
 THREAD=ORDEREDSUBJECT THREAD=REFERENCES SORT
 QUOTA IDLE ACL ACL2=UNION] Courier-IMAP ready.
Copyright 1998-2010 Double Precision, Inc.  
See COPYING for distribution information.

To log in, use this (note that the 1 is needed):

1 LOGIN username password

Note: this password is going across in the clear! If you definitely want to do this, use a disposable test account and get rid of it afterwards.

Here are a few more commands to try, from WikiQuestions:

1 SELECT Inbox will select the Inbox folder. Look for the EXISTS line of output to tell you how many mails there are.
4 LIST "" "INBOX" will list each item in the inbox, with various pieces of information about the items including the date sent, any flags on the mail, and the subject line.
1 LOGOUT will log you out.

Web and IRC Servers

HTTP servers are also accessible via telnet:

telnet www.example.com 80

Try getting a particular page:

GET /index.html HTTP/1.1
host: www.example.com

Note that you need to hit enter twice after the host name line, and you need to specify both the HTTP protocol version, and the hostname.

If the page is there, you should get a bunch of HTTP header information, then the HTML content of the page. If it's not, you'll get an HTTP 404 Not Found error, and the website's 404 page. Use the same request structure again to request a different page. If you want to experiment more with this, check out the HTTP 1.1 protocol.

Other

Most IRC servers run on port 6667. Try connecting to an IRC server like this:

telnet irc.freenode.net 6667

This will connect you, but you'll need to set your nickname manually (type NICK yournickname) and join channels with the raw protocol command (type JOIN #thischannel). You'll get a lot of output that you may or may not recognise, and the whole thing is a bit more tortuous than using a real IRC client! But it gives you a chance to experiment with the raw commands, which (as discussed in the O'Reilly book IRC Hacks can be useful if you want to write or improve IRC clients.

You can also try port 9 to test that your telnet client is working OK. It's the discard/null port, so you won't affect any other services.

Conclusion

Telnetting to servers won't always work these days, as some (quite reasonably!) insist on only connecting over an encrypted connection for some services, and telnet is plaintext. However, it can be a useful debugging tool, particularly when you're setting up your own servers to make sure that everything is working as it should. Not to mention... it's always kind of fun to be able to talk to people or servers in their own language.

Chapter 20 of the "Linux Cookbook" by your very own Linux Planet editor has detailed sections on testing mail servers with telnet and s_client