Post Office Protocol (POP3)
|| Home | Protocols ||
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.
Rides on top of TCP
995 TLS encrypted/pop3s
1109 Kerberos v4/kpop
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
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
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.
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?
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.
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|
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.
The links below will take you to step-by-step instructions for installing, configuring, and using a POP3 server: