Post Office Protocol
|This article needs additional citations for verification. (November 2007)|
|Internet protocol suite|
A visualization of routing paths through a portion of the Internet.
In computing, the Post Office Protocol (POP) is an application-layer Internet standard protocol used by local e-mail clients to retrieve e-mail from a remote server over a TCP/IP connection. POP and IMAP (Internet Message Access Protocol) are the two most prevalent Internet standard protocols for e-mail retrieval. Virtually all modern e-mail clients and servers support both. POP has been developed through several versions, with version 3 (POP3) being the current standard. Most webmail service providers such as Google Mail, Microsoft Mail and Yahoo! Mail provide both an IMAP and POP3 service.
POP supports simple download-and-delete requirements for access to remote mailboxes (termed maildrop in the POP RFC's). Although most POP clients have an option to leave mail on server after download, e-mail clients using POP generally connect, retrieve all messages, store them on the user's PC as new messages, delete them from the server, and then disconnect. Other protocols, notably IMAP, (Internet Message Access Protocol) provide more complete and complex remote access to typical mailbox operations. Many e-mail clients support POP as well as IMAP to retrieve messages; however, fewer Internet Service Providers (ISPs) support IMAP.[dubious ]
A POP3 server listens on well-known port 110. Encrypted communication for POP3 is either requested after protocol initiation, using the STLS command, if supported, or by POP3S, which connects to the server using Transport Layer Security (TLS) or Secure Sockets Layer (SSL) on well-known TCP port 995.
Available messages to the client are fixed when a POP session opens the maildrop, and are identified by message-number local to that session or, optionally, by a unique identifier assigned to the message by the POP server. This unique identifier is permanent and unique to the maildrop and allows a client to access the same message in different POP sessions. Mail is retrieved and marked for deletion by message-number. When the client exits the session, the mail marked for deletion is removed from the maildrop.
POP (POP1) is specified in RFC 918 (1984), POP2 by RFC 937 (1985). The original specification of POP3 is RFC 1081 (1988). Its current specification is RFC 1939, updated with an extension mechanism, RFC 2449 and an authentication mechanism in RFC 1734.
POP2 has been assigned well-known port 109.
The original POP3 specification supported only an unencrypted USER/PASS login mechanism or Berkeley .rhosts access control. POP3 currently supports several authentication methods to provide varying levels of protection against illegitimate access to a user's e-mail. Most are provided by the POP3 extension mechanisms. POP3 clients support SASL authentication methods via the AUTH extension. MIT Project Athena also produced a Kerberized version.
RFC 1460 introduced APOP into the core protocol. APOP is a challenge/response protocol which uses the MD5 hash function in an attempt to avoid replay attacks and disclosure of the shared secret. Clients implementing APOP include Mozilla Thunderbird, Opera Mail, Eudora, KMail, Novell Evolution, RimArts' Becky!, Windows Live Mail, PowerMail, Apple Mail, and Mutt.
An informal proposal had been outlined for a "POP4" specification, complete with a working server implementation. This "POP4" proposal added basic folder management, multipart message support, as well as message flag management, allowing for a light protocol which supports some popular IMAP features which POP3 currently lacks. However, in doing so, it shared with IMAP the embedding in a communication protocol a specific model of a mailbox, which, although common, is not universal. No progress has been observed in this "POP4" proposal since 2003.
An extension mechanism was proposed in RFC 2449 to accommodate general extensions as well as announce in an organized manner support for optional commands, such as TOP and UIDL. The RFC did not intend to encourage extensions, and reaffirmed that the role of POP3 is to provide simple support for mainly download-and-delete requirements of mailbox handling.
The extensions are termed capabilities and are listed by the CAPA command. Except for APOP, the optional commands were included in the initial set of capabilities. Following the lead of ESMTP (RFC 5321), capabilities beginning with an X signify local capabilities.
The STARTTLS extension allows the use of Transport Layer Security (TLS) or Secure Sockets Layer (SSL) to be negotiated using the STLS command, on the standard POP3 port, rather than an alternate. Some clients and servers instead use the alternate-port method, which uses TCP port 995 (POP3S).
Demon Internet introduced extensions to POP3 that allow multiple accounts per domain, and has become known as Standard Dial-up POP3 Service (SDPS). To access each account, the username includes the hostname, as john@hostname or john+hostname.
Google Apps uses the same method.
Comparison with IMAP
Clients that leave mail on servers generally use the UIDL command to get the current association of message-numbers to message identified by its unique identifier. The unique identifier is arbitrary, and might be repeated if the mailbox contains identical messages. In contrast, IMAP uses a 32-bit unique identifier (UID) that is assigned to messages in ascending (although not necessarily consecutive) order as they are received. When retrieving new messages, an IMAP client requests the UIDs greater than the highest UID among all previously retrieved messages, whereas a POP client must fetch the entire UIDL map. For large mailboxes, this can require significant processing.
MIME serves as the standard for attachments and non-ASCII text in e-mail. Although neither POP3 nor SMTP require MIME-formatted e-mail, essentially all non-ASCII Internet e-mail comes MIME-formatted, so POP clients must also understand and use MIME. IMAP, by design, assumes MIME-formatted e-mail.
The APOP usage is a direct example from RFC 1939 page 18.
RFC 1939 APOP support indicated by <email@example.com> here:
S: <wait for connection on TCP port 110> C: <open connection> S: +OK POP3 server ready <firstname.lastname@example.org> C: APOP mrose c4c9334bac560ecc979e58001b3e22fb S: +OK mrose's maildrop has 2 messages (320 octets) C: STAT S: +OK 2 320 C: LIST S: +OK 2 messages (320 octets) S: 1 120 S: 2 200 S: . C: RETR 1 S: +OK 120 octets S: <the POP3 server sends message 1> S: . C: DELE 1 S: +OK message 1 deleted C: RETR 2 S: +OK 200 octets S: <the POP3 server sends message 2> S: . C: DELE 2 S: +OK message 2 deleted C: QUIT S: +OK dewey POP3 server signing off (maildrop empty) C: <close connection> S: <wait for next connection>
POP3 servers without the optional APOP command expect the client to log in with the USER and PASS commands:
C: USER mrose S: +OK User accepted C: PASS tanstaaf S: +OK Pass accepted
- Apache James
- Courier Mail Server
- Cyrus IMAP server
- Eudora Internet Mail Server
- UW IMAP
Related requests for comments (RFCs)
- RFC 918 – POST OFFICE PROTOCOL
- RFC 937 – POST OFFICE PROTOCOL – VERSION 2
- RFC 1081 – Post Office Protocol – Version 3
- RFC 1939 – Post Office Protocol – Version 3 (STD 53)
- RFC 1957 – Some Observations on Implementations of the Post Office Protocol (POP3)
- RFC 2195 – IMAP/POP AUTHorize Extension for Simple Challenge/Response
- RFC 2384 – POP URL Scheme
- RFC 2449 – POP3 Extension Mechanism
- RFC 2595 – Using TLS with IMAP, POP3 and ACAP
- RFC 3206 – The SYS and AUTH POP Response Codes
- RFC 5034 – The Post Office Protocol (POP3) Simple Authentication and Security Layer (SASL) Authentication Mechanism
- Dean, Tamara (2010). Network+ Guide to Networks. Delmar. p. 519.
- Komarinski, Mark (2000). Red Hat Linux System Administration Handbook. Prentice Hall. p. 179.
- Allen, David (2004). Windows to Linux. Prentice Hall. p. 192.
- (Japanese), (Becky! tutorial), 2001/04/26
- "POP4 specification although pop is used to receive mail after system is not online.". 2003. Retrieved 2011-10-17.
- Demon Online Help Centre. E.demon.net (2013-01-23). Retrieved on 2013-07-17.
- Hughes, L (1998). Internet e-mail Protocols, Standards and Implementation. Artech House Publishers. ISBN 0-89006-939-5.
- Johnson, K (2000). Internet Email Protocols: A Developer's Guide. Addison-Wesley Professional. ISBN 0-201-43288-9.
- Loshin, P (1999). Essential Email Standards: RFCs and Protocols Made Practical. John Wiley & Sons. ISBN 0-471-34597-0.
- Rhoton, J (1999). Programmer's Guide to Internet Mail: SMTP, POP, IMAP, and LDAP. Elsevier. ISBN 1-55558-212-5.
- Wood, D (1999). Programming Internet Mail. O'Reilly. ISBN 1-56592-479-7.