Post Office Protocol

From Wikipedia, the free encyclopedia

Jump to: navigation, search

This article does not cite any references or sources.
Please help improve this article by adding citations to reliable sources. Unsourced material may
be challenged and removed. (November 2007)

The Internet Protocol Suite

Application Layer

BGP · DHCP · DNS · FTP · GTP · HTTP · IMAP ·

IRC · Megaco · MGCP · NNTP · NTP · POP · RIP ·
RPC · RTP · RTSP · SDP · SIP · SMTP · SNMP ·
SOAP · SSH · Telnet · TLS/SSL · XMPP · (more)

Transport Layer

TCP · UDP · DCCP · SCTP · RSVP · ECN · (more)

Internet Layer

IP (IPv4, IPv6) · ICMP · ICMPv6 · IGMP · IPsec ·

(more)

Link Layer

ARP/InARP · NDP · OSPF · Tunnels (L2TP) · PPP ·

Media Access Control (Ethernet, DSL, ISDN,
FDDI) · (more)

This box: view • talk • edit

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. The POP protocol has been developed through several
versions, with version 3 (POP3) being the current standard.

Contents
• 1 Overview
• 2 Dialog example
• 3 POP4
• 4 SDPS
• 5 Server implementations
• 6 Related Requests For Comments (RFCs)
• 7 See also
• 8 References
• 9 Further reading

• 10 External links

[edit] Overview
The design of POP and its procedures supports end-users with temporary Internet
connections, such as dial-up access, allowing these users to retrieve e-mail when
connected and then to view and manipulate the retrieved messages when offline.
Although most clients have an option to leave mail on server, 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.

In contrast, the newer, more capable Internet Message Access Protocol (IMAP) supports
both connected (online) and disconnected (offline) modes of operation. E-mail clients
using IMAP generally leave messages on the server until the user explicitly deletes them.
This and other aspects of IMAP operation allow multiple clients to access the same
mailbox. Many e-mail clients support POP as well as IMAP to retrieve messages;
however, fewer Internet Service Providers (ISPs) support IMAP.

Clients with a leave mail on server option generally use the POP3 UIDL (Unique
IDentification Listing) command. Most POP3 commands identify specific messages by
their ordinal number on the mail server. This creates a problem for a client intending to
leave messages on the server, since these message numbers may change from one
connection to the server to another. For example if a mailbox contained five messages,
and a different client then deletes message #3, the next connecting user will find the last
two messages' numbers decremented by one. UIDL provides a mechanism to avoid these
numbering issues by assigning a string of characters as a permanent and unique ID for the
message. When a POP3-compatible e-mail client connects to the server, it can use the
UIDL command to get the current mapping from these message IDs to the ordinal
message numbers. The client can then use this mapping to determine which messages it
has yet to download. 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.

Irrespective of the mail retrieval protocol, e-mail clients typically use the Message
Submission flavor of the Simple Mail Transfer Protocol (SMTP) to send messages. POP3
contains a protocol extension, known as "XTND XMIT", that allows clients to transmit
outbound mail. The Qualcomm qpopper and CommuniGate Pro servers and Eudora
clients are examples of systems that optionally utilize the XTND XMIT methods of
authenticated client-to-server e-mail transmission.

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 Internet e-mail
comes MIME-formatted, so POP clients must also understand and use MIME. IMAP, by
design, assumes MIME-formatted e-mail.

Like many other older Internet protocols, POP originally supported only an unencrypted
login mechanism. Although plain text transmission of passwords in POP still commonly
occurs, POP3 currently supports several authentication methods to provide varying levels
of protection against illegitimate access to a user's e-mail. One such method, APOP, 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, Eudora, KMail,
Novell Evolution, RimArts' Becky!,[1] Windows Live Mail, PowerMail, and Mutt. POP3
clients can also support SASL authentication methods via the AUTH extension. MIT
Project Athena also produced a Kerberized version.

POP uses the Transmission Control Protocol on port number 110. Transmission may be
encrypted using Transport Layer Security (TLS) or Secure Sockets Layer (SSL). This is
negotiated in the POP3 protocol using the STLS command. Some clients and servers,
such as Google Gmail, instead use the deprecated alternate-port method, which uses TCP
port 995 (POP3S).

[edit] Dialog example

RFC 1939 APOP support indicated by <1896.697170952@dbc.mtview.ca.us> here:

S: <wait for connection on TCP port 110>

C: <open connection>
S: +OK POP3 server ready <1896.697170952@dbc.mtview.ca.us>
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>
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 mrosepass
S: +OK Pass accepted

[edit] POP4
While not yet an official standardized mail protocol, a proposal has been outlined for a
POP4 specification, complete with a working server implementation.

The proposed POP4 extension adds 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.

No progress has been observed in the POP4 specification since 2003.

[edit] SDPS
Demon Internet introduced extensions to POP3 that allow multiple accounts per domain,
and has become known as Standard Dial-up POP3 Service (SDPS).[1]

To access each account, the username includes the hostname, as john@hostname or

john+hostname.

[edit] Server implementations

• Apache James
• Citadel/UX
• Courier Mail Server
 • Cyrus IMAP server
• Dovecot
• Eudora Internet Mail Server
• Nginx
• qmail-pop3d
• Qpopper
• RePOP
• UW IMAP
• Zimbra

[edit] Related Requests For Comments (RFCs)

• 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

[edit] See also

• Internet Message Access Protocol (IMAP)
• Simple Mail Transfer Protocol (SMTP)
• E-mail client
• webmail
• POP3 clients: getmail, fetchmail
• email encryption

[edit] References
1. ^ (Japanese), (Becky! tutorial), 2001/04/26

[edit] Further reading

• Hughes, L (1998). Internet e-mail Protocols, Standards and Implementation.
Artech House Publishers. ISBN 0890069395.
• Johnson, K (2000). Internet Email Protocols: A Developer's Guide. Addison-
Wesley Professional. ISBN 0201432889.
• Loshin, P (1999). Essential Email Standards: RFCs and Protocols Made
Practical. John Wiley & Sons. ISBN 0471345970.
• Rhoton, J (1999). Programmer's Guide to Internet Mail: SMTP, POP, IMAP, and
LDAP. Elsevier. ISBN 1555582125.
• Wood, D (1999). Programming Internet