Table of Contents




Description:

The intent of the Post Office Protocol (POP) is to allow a user's computer to access mail from a mailbox server. POP3 does not support sending e-mail, only receiving e-mail. POP3 is intended to be used in a download-and-delete fashion, which is a very attractive model for ISPs. POP3 has been used for many years, is well understood, and is actually an Internet Standard (STD0053).

POP3 is the most common method for home users to retrieve their e-mail from service providers. It assumes that the user only has one client computer. Although many POP3 clients support an option to leave mail on the server, many ISPs will delete mail after a certain period of time in order to keep storage requirements down. If a user needs to access the same mailbox from multiple computers or leave mail on the server, then IMAP may be a better choice.

Location in the Protocol Stack:

Rides on top of TCP

Port Numbers:

110   standard

995   TLS encrypted/pop3s

1109   Kerberos v4/kpop

IPv6 client/server availability:

Both available.

RFC History:

Development started in 1984. The basic protocol as we know it today dates to 1988. It became an Internet standard in 1994.

POP RFCs:

RFC 0918	POP				1984			
RFC 0937	POP2				1985			
RFC 1081	POP3 				1988	
RFC 1082	POP3 Extended Service Offerings	1988			
RFC 1225	POP3				1991			
RFC 1460	POP3				1993			
RFC 1725	POP3 				1994
RFC 1734**	POP3 AUTHentication Command	1994			
RFC 1939**	POP3 (STD0053)			1996
RFC 1957**	POP3 (informational)		1996
RFC 2095	IMAP/POP AUTHorize Extension	1997
RFC 2195**	IMAP/POP AUTHorize Extension	1997
RFC 2384	POP URL Scheme			1998
RFC 2449**	POP3 Extension Mechanism	1998
RFC 2595**	Using TLS with POP3		1999
RFC 3206**	POP Response Codes (SYS,AUTH)	2002

Related RFCs:

RFC 2222	SASL				1997
RFC 2246	TLS Protocol Version 1.0	1999
RFC 3546	TLS Extensions			2003

Protocol Details/Command set:

POP3 follows a strict client-server model. The client connects to the server and issues simple text commands, and the server responds. The server does not initiate anything. In fact, you can check your mail or do basic troubleshooting by using a TELNET client to connect to the POP3 server on port 110. Then you can issue commands from the keyboard and view the responses. The only complexities in the protocol are additions made in recent years to support encryption and new authentication mechanisms.

Here is a summary of current POP3 commands and responses:

Minimal POP3 Commands:

	USER name		valid in the AUTHORIZATION state
	PASS string
	QUIT

	STAT			valid in the TRANSACTION state
	LIST [msg]
	RETR msg
	DELE msg
	NOOP
	RSET
	QUIT

Optional POP3 Commands:

	APOP name digest	valid in the AUTHORIZATION state
	AUTH [auth type]
	TOP msg n		valid in the TRANSACTION state
	UIDL [msg]

POP3 Replies:

	+OK
	-ERR

Extended Commands:

	CAPA			valid in AUTHORIZATION or TRANSACTION state
	STLS			valid in AUTHORIZATION state
	
Extended Response Codes:

	(These will be enclosed in square brackets following an -ERR reply)
	
	LOGIN-DELAY
	IN-USE
	SYS/TEMP
	SYS/PERM
	AUTH

Server Implementations:

As you can see, Qpopper is the only major "POP3-only" server package. Most of the major POP3 servers are distributed as part of an IMAP server system.

There are other open source/freeware POP3 servers that I have not listed. In addition, there are a number of commercial POP3 servers available, such as Communigate Pro, which runs on Unix, Linux, Win32, and other operating systems.

Security and Authentication:

The only thing that makes POP3 complex to configure and administer (both client and server) is the multiple methods for authenticating users and encrypting traffic. Clients and servers have different sets of capabilities. The POP3 protocol has been supplemented over the years with new extensions to handle new types of authentication and encryption negotiation. The CAPA command allows clients to see what the server supports without probing.

The most basic authentication method is the original USER and PASS commands. All POP3 clients support these. Since this passes the username and password in the clear, it is a trivial matter to capture usernames and passwords as they travel over the network. In the case of Unix/Linux accounts with shell access as well as POP3 access, this can be a grave security flaw. This is why APOP was developed. APOP is a simple method for securely sending a password hash based on a shared secret. The hash changes with every login, so replay attacks won't work. There are three drawbacks to APOP, though:

However, it may be desirable to make the user/pass database separate and distinct from the host operating system's authentication database. For instance, if the only purpose for the server is to serve e-mail, it may be easier to manipulate and administer the plaintext database with scripting tools. Some people say that this is a big security risk, because an attacker who obtains the list now has everybody's e-mail password. I would counter that if somebody has root access on the box, you are already in big trouble. Root can read the mail spools, grab the encrypted database of usernames and passwords and crack them off-line, and other nefarious deeds. Also, if a user's POP3 password is the same as their system password, then it can be lifted from the PC very easily via a number of methods and used to login to enterprise servers.

Your choice is similar with some of the SASL-based AUTH methods, which typically need their own authentication database which is separate from the host operating system's. In some cases, using AUTH CRAM-MD5 or APOP will be a better choice, and in other cases the flexibility of using plaintext passwords with PAM will be the best choice. Since Outlook Express does not support APOP or SASL CRAM-MD5, most ISP's could not mandate the use of these mechanisms. This forces a choice of supporting multiple authentication databases or supporting a single method. The least common denominator seems to be USER/PASS with or without TLS/SSL. Since sending username and passwords in the clear over the network is a bad idea, making TLS/SSL mandatory would be a good strategy. This has some disadvantages, though:

Why do you have to consider running TLS on port 995 and port 110? Because some clients support the newer STARTTLS method (POP3 command: STLS) on port 110, while other clients only support the older alternate-port TLS on port 995. The IETF is pushing the STARTTLS method for all client-server protocols, as it eases the demand for ports. For example, TLS support for SMTP was originally planned for port 465. After much debate, the idea was scrapped, the port was assigned to another application, and STARTTLS is the approved way of using encryption over SMTP. Having to support both methods is a headache for the system administrator. You may also have to recompile the server software so that plaintext methods are not available unless TLS has been been negotiated.

Some clients and servers also support Kerberos authentication for POP3 sessions. This is beyond the scope of this article. Note that Kerberos could be supported through PAM modules on the server side, thus making native support in POP3 clients unnecessary.

If all of this were not enough, there is also a POP3 password changing protocol that is still supported by some client and server implementations. This protocol is called poppwd or poppassd. This is not an IETF standard, but something developed by Eudora. It runs on TCP port 106. Similarly, Outlook Express supports something called "Secure Password Authentication", or SPA. It is actually an NTLM hash, and is sometimes referred to as SPA/NTLM. Furthermore, there is yet another POP authentication scheme called RPA, which is a proprietary SASL method used by CompuServe.

Are you confused yet?

Firewall Considerations:

Fortunately, POP3 works well through firewalls and NAT/PAT devices such as cheap SOHO routers and security devices. Traffic is always initiated by the client from random non-privileged ports to well-known TCP ports on the server. You will probably only need to worry about TCP ports 110 and 995.

Client Implementations:

There are countless POP3 client implementations. I will list major implementations that I have tested, along with some information on each client.

Client OS APOP SASL CRAM-MD5 SASL LOGIN STARTTLS TLS 995
Evolution Lin/Unix Yes Yes Yes Yes Yes
KMail Lin/Unix Yes Yes Yes Yes Yes
Sylpheed Lin/Unix Yes No No Yes Yes
fetchmail Lin/Unix Yes Yes No Yes Yes
Mozilla Mail Lin/Unix/Win/Mac Yes Yes Yes No Yes
Opera M2 Lin/Unix/Win/Mac Yes Yes Yes Yes Yes
Eudora Win/Mac Yes No No Yes Yes
Outlook Exp.6 Win No No Yes No Yes

Client Notes:

Clients are very similar in their implementation of standard commands and options like "leave messages on server". Where they differ widely is their support for encryption (TLS/SSL) and authentication.

Evolution, KMail, and Opera support every combination. Eudora is not far behind, and it supports several Kerberos authentication options that the others do not. Mozilla Mail and Opera M2 would be good choices for Enterprises, as they work on multiple operating systems.

Outlook Express was the weakest client tested, not even supporting APOP, a standard method for authenticating securely over an unencrypted session. APOP has been around for 11 years, but is still not supported by the latest Outlook Express. Furthermore, OE does not support CRAM-MD5 nor STLS.   Note: Outlook Express 5 does support MacOS 8.1-9.x.

Mozilla Mail is an excellent POP3 client, with one exception:  Its lack of support for the STLS extension. This is rather surprising, since the IETF has been pushing the STARTTLS method on standard ports instead of the practice of using "alternate" ports for TLS-wrapped traffic. I also tested the new stand-alone mail client from Mozilla.org named Thunderbird. It currently has the same POP3 configuration parameters as Mozilla Mail.

Fetchmail is a useful command line POP3 client utility. It can also be handy for debugging/trouble shooting POP3 problems, since it can give real-time verbose messages when invoked.

Since Outlook Express and Netscape/Mozilla Mail are dominant in the POP3 client software market, ISPs cannot mandate the use of STLS, APOP, or SASL AUTH methods such as CRAM-MD5. The "least common denominator" is cleartext USER/PASS authentication with or without TLS, and when TLS is used, it uses TCP port 995 without STLS. Any other scheme will cut off Outlook Express users, which make up a high percentatge of the user population.


Installation/Configuration HOWTOs:

The links below will take you to step-by-step instructions for installing, configuring, and using a POP3 server:






| Home | Protocols |