How IT WorksPOP3 Delivers
R’ykandar Korra’ti
In the last issue, I discussed SMTP, the most common protocol for sending e-mail across the Internet. Now I’d like to discuss the other Internet protocol that almost all mail clients support: POP3, which lets users access the e-mail on their mail server.
As with many Internet specifications, POP3 is simple. It consists of a small number of commands sent in human-readable form over a line-oriented TCP/IP connection, the same underlying protocol used by Telnet and SMTP. This makes it particularly easy to learn, since a person can play the role of the POP3 client, typing commands and reading responses as they are sent.
In POP3, the client always initiates the connection, requesting access to the user’s mail server over TCP port 110 (by default). The server must return +OK and a greeting message:
C:\> telnet adatum.com 110
Connected to adatum.com.
+OK Microsoft Exchange Server 2003 POP3 server version 6.5.6944.0 (adatum.com) ready.
At this point, the POP3 server is in authentication mode. The client must identify the name of the user whose mail it wishes to retrieve, and provide some password, key, or other validating marker to indicate that the client has authorization to retrieve that user’s mail.
The traditional method is the username/password pair:
USER <username>
PASS <password>
The first is sent in response to the POP3 server greeting. The second is sent after the username is accepted, thusly:
USER dara
+OK
PASS solarbird
+OK User successfully logged on.
Note that accepted commands always gather a +OK response. Bad commands and server-side errors trigger an –ERR response, usually followed by a detailed explanation. A bad username/password pair would have prompted a server response similar to this:
-ERR permission denied
The USER/PASS authentication method has a particularly severe weakness: both the username and password are transmitted unencrypted. Anyone with a network sniffer can gain login information for any user logging on. While this is less of a problem in a properly secured corporate environment, it is a major vulnerability in a public networking environment, such as the free Wireless Access Point (WAP) connectivity found in many public facilities. For more information on how to mitigate this risk, see the sidebar entitled "Securing POP3."
Regardless of the authentication system used, once the server has accepted the user’s credentials, it enters the transaction state, where messages may be retrieved. This is accomplished with a small set of commands: STAT, LIST, RETR, DELE, NOOP, RSET, and optionally TOP and UIDL. These may be entered in any order and may be repeated.
STAT prompts the server to return the number of messages queued and their combined size, in bytes:
STAT
+OK 5 4071
Here, the command response indicates that the server has five messages for the user, and that their total combined size is 4,071 bytes. Including an argument would cause the server to return –ERR, often followed by a detailed message on the same line indicating a protocol error. This is the standard error response for any improperly formatted or unrecognized command.
LIST provides information about individual messages stored on the server, specifically the number and size of messages, the latter again being in bytes. If no parameter is given, data for all messages is returned:
LIST
+OK 5 4071
1 1049
2 204
3 1840
4 474
5 504
.
The period on a line by itself indicates the end of any multiline output. If given a message number as a parameter, it returns that message number and its size alone, all on a single line with the +OK response:
LIST 4
OK 4 474
A client can download these messages using the RETR command, which requires a single message number as parameter as shown in Figure 1.
Figure 1** Downloading Messages with RETR **
Note again the use of a period on a line by itself to indicate the end of the message. The byte count provided must match the size of the output message, which will be presented in RFC 2822 format: the full headers, followedv by a blank line, followed by the message body. Attachments will be presented either as MIME-enveloped sections or as UUENCODED blocks, as determined by the sender’s e-mail client, with the expectation that the receiver’s client will decode them appropriately.
The client may mark the message for deletion with the DELE command, which takes only a single message number:
DELE 4
+OK
If the message doesn’t exist or has been deleted, the server will return error codes:
DELE 6
-ERR The specified message is out of range.
DELE 4
+OK
DELE 4
-ERR The requested message is no longer available; it may have been deleted.
The command NOOP is simply used to avoid server timeouts, if it’s used at all. It takes no parameters and does nothing; the server must return +OK.
The RSET command, which takes no parameters, clears any delete flags that have been set. It returns +OK if the flags clear, or –ERR if, for some internal-to-server reason, they don’t.
QUIT tells the server to actually delete any messages previously marked for deletion and end the session, in that order. Typically, this generates a quick +OK response, followed by a dropped connection. However, since this is the stage when messages are actually removed from the server, the server could, in theory, be unable to delete the messages and return –ERR before closing the port anyway.
In addition to these mandatory commands, the POP3 specification includes two very useful optional commands: TOP and UIDL. Most servers implement both. TOP accepts a message number and a number of lines. The POP3 server returns the requested message’s full headers, followed by the number of lines of the message that were requested, as shown in Figure 2.
Clients often use this command in slow networking environments to pull down headers for an Inbox entry, downloading the full message only on demand.
Figure 2** Message Information Returned by TOP **
UIDL returns unique identifiers for each message or, if a message number is given as a parameter, for one message. Using this unique identifier, the client can identify whether a message is one it has previously downloaded and left on the server and accordingly not download it a second time:
UIDL 1
+OK 1 AAgK5ADAAAAxknrcB3ItECk45jXkigfA
UIDL
1 AAgK5ADAAAAxknrcB3ItECk45jXkigfA
2 AAAL5ADAAAAxknrcB3ItECk45jXkigfA
3 AAwK5ADAAAAxknrcB3ItECk45jXkigfA
4 AAQL5ADAAAAxknrcB3ItECk45jXkigfA
5 AAgL5ADAAAAxknrcB3ItECk45jXkigfA
This very simple and small set of commands provides all the functionality needed to retrieve e-mail from a server. It does not provide more advanced functionality, leaving that to the e-mail client to implement as it sees fit. As a result, it is both simple to implement and commonly supported.
Securing POP3
Three good methods exist to work around the problem of clear text credentials in POP3. One method is the optional AUTH command, borrowed from the Internet Message Access Protocol (IMAP) specification. The AUTH command may be used on some servers in place of the USER/PASS pair. The AUTH includes as its parameter an IMAP-encrypted identification string:
AUTH <IMAP identification string>
This command triggers an encrypted exchange that authenticates the user without having to transmit the username or password in the clear at any time. POP3 then returns to transmitting information in the clear, as if a USER/PASS pair had been sent.
A second solution is the optional Authenticated Post Office Protocol (APOP) command, which requires a timestamp ID to be sent by the server at connect time in the greeting line. This server-sent timestamp ID is then combined with the user’s password by the client and converted into fixed-size hexadecimal "digest" form with the MD5 algorithm (see RFC 1321 for details on MD5). Then the client logs on with a single command:
APOP <username> <digest-form-password>
+OK User successfully logged on.
Since the digest changes each login, thanks to the inclusion of the timestamp ID, there is no single unencrypted token to steal, improving login security.
The third, and probably safest, route is to run the standard POP3 protocol itself over an encrypted channel. By connecting through an encrypted Virtual Private Network (VPN), or by substituting the ssh2 protocol for the basic Telnet connection, the user ensures that nothing is sent in clear text, making sniffing much less a threat for both login information and e-mail content.
R’ykandar Korra’ti postmaster for a small co-op ISP, lives near Seattle with her partner Anna. Having previously shipped mail products at Microsoft, she is now looking at grad school in a CS-related field so esoteric it doesn’t really have a name. Potential faculty advisors can reach her at darako@murkworks.net
© 2008 Microsoft Corporation and CMP Media, LLC. All rights reserved; reproduction in part or in whole without permission is prohibited.