19.15. Troubleshooting a POP3, POP3s, or IMAP Server

What are some tests you can run directly on your POP3, POP3s, or IMAP server to see if it is working correctly? You want to eliminate as many variables as you can and talk directly to the server, if that's possible.

telnet and Netstat will do the job for you. Netstat shows you if it is running and listening to the correct ports and addresses, as this example shows for Dovecot:

	# netstat -plunt | grep :110
	tcp   0   0 :::110 :::*      LISTEN    4654/dovecot

This shows that Dovecot is open to all connections, so if you want to limit it to LAN connections, you'll need to fix its configuration. Then, Netstat will report this:

	tcp  0  0 192.168.1.25:110 :::*   LISTEN   4654/dovecot

POP3s, which is POP3 over SSL, runs on TCP port 995.

IMAP runs on TCP port 143, and IMAP over SSL uses TCP port 993.

To test a POP3 server with telnet, you need to have a user account already set up on the server. Then, do this:

	$ telnet localhost 110
	Trying 127.0.0.1...
	Connected to localhost.localdomain.
	Escape character is '^]'.
	+OK Hello there.
	user carla
	+OK Password required.
	pass password
	+OK logged in.
	stat
	+OK 2 1275
	list
	+OK
	1 748
	2 1028
	3 922
	.

This shows a successful login, and the list command shows there are three messages. At this point, you can quit, or enter retr 1, retr 2, or retr 3 to read your messages. quit closes the session.

Use the s_client command, which is part of OpenSSL, to test POP3s:

	$ openssl s_client -connect localhost:995

This should spew forth bales of SSL certificate information so you can verify that it is indeed using your SSL certificate, and using the right one. Then, you can go ahead and run the usual POP3 commands:

	+OK Hello there.
	user carla
	+OK Password required.
	pass password
	+OK logged in.

Once you have successfully connected directly on the server, try logging in from a remote PC:

	$ telnet xena.alrac.net 110
	$ openssl s_client -connect xena.alrac.net:995

IMAP can also be tested with telnet and openssl s_client:

	$ telnet localhost 143
	Trying 127.0.0.1...
	Connected to localhost.localdomain.
	Escape character is '^]'.
	* OK [CAPABILITY IMAP4rev1 UIDPLUS CHILDREN NAMESPACE THREAD=ORDEREDSUBJECT
	THREAD=REFERENCES SORT QUOTA IDLE ACL ACL2=UNION STARTTLS] Courier-IMAP ready.
	a001 login carla password
	a001 OK LOGIN Ok.
	a002 examine inbox
	* FLAGS (\Draft \Answered \Flagged \Deleted \Seen \Recent)
	*OK [PERMANENTFLAGS ( )] No permanent flags permitted
	* 0 EXISTS
	* 0 RECENT
	* OK [UIDVALIDITY 1085106842] Ok
	* OK [MYRIGHTS "acdilrsw"] ACL
	a002 OK [READ-ONLY] Ok
	a003 logout
	* BYE Courier-IMAP server shutting down
	a003 OK LOGOUT completed
	Connection closed by foreign host.

	$ openssl s_client -connect localhost:993[...]

Following along with tcpdump as you run your other tests is helpful:

	# tcpdump -pi eth0 port 110

And always check logfiles.

To exit a telnet session early, hit Ctrl-], then Q.

Why use telnet? Because it can talk directly to the server, and find out quickly if the server is operating correctly. Bypassing intermediaries is always a good first step.

Follow the previous recipe to send yourself some messages from your SMTP server and see if your POP3 server receives them. If they are on the same machine, and the POP3 server does not receive the messages, then you know you have a configuration problem. If they are on separate machines, then it could be either a connection problem, or a configuration problem. Always make sure your servers are operating correctly before looking for other problems.

Some admins think that operating behind a NAT firewall excuses them from paying close attention to access controls on their internal servers. This is not good thinking—always restrict your server access controls as narrowly as possible.