Hubbry Logo
Post Office ProtocolPost Office ProtocolMain
Open search
Post Office Protocol
Community hub
Post Office Protocol
logo
7 pages, 0 posts
0 subscribers
Be the first to start a discussion here.
Be the first to start a discussion here.
Post Office Protocol
Post Office Protocol
Post Office Protocol
View on Wikipedia
from Wikipedia
Internet protocol suite
Application layer
Transport layer
Internet layer
Link layer

In computing, the Post Office Protocol (POP) is an application-layer Internet standard protocol used by e-mail clients to retrieve e-mail from a mail server.[1] Today, POP version 3 (POP3) is the most commonly used version. Together with IMAP, it is one of the most common protocols for email retrieval.

Purpose

[edit]

The Post Office Protocol provides access via an Internet Protocol (IP) network for a user client application to a mailbox (maildrop) maintained on a mail server. The protocol supports list, retrieve and delete operations for messages. POP3 clients connect, retrieve all messages, store them on the client computer, and finally delete them from the server.[2] This design of POP and its procedures was driven by the need of users having only temporary Internet connections, such as dial-up access, allowing these users to retrieve e-mail when connected, and subsequently to view and manipulate the retrieved messages when offline.

POP3 clients also have an option to leave mail on the server after retrieval, and in this mode of operation, clients will only download new messages which are identified by using the UIDL command (unique-id list). By contrast, the Internet Message Access Protocol (IMAP) was designed to normally leave all messages on the server to permit management with multiple client applications, and to support both connected (online) and disconnected (offline) modes of operation.

A POP3 server listens on TCP well-known port number 110 for service requests. 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 number 995.

Messages available to the client are determined when a POP3 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 the message-number. When the client exits the session, mail marked for deletion is removed from the maildrop.

History

[edit]

The first version of the Post Office Protocol, POP1, was specified in RFC 918 (1984) by Joyce K. Reynolds. POP2 was specified in RFC 937 (1985).

POP3 is the version in most common use. It originated with RFC 1081 (1988) but the most recent specification is RFC 1939, updated with an extension mechanism (RFC 2449) and an authentication mechanism in RFC 1734. This led to a number of POP implementations such as Pine, POPmail, and other early mail clients.

While the original POP3 specification supported only an unencrypted USER/PASS login mechanism or Berkeley .rhosts access control, today POP3 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!,[3] Windows Live Mail, PowerMail, Apple Mail, and Mutt. RFC 1460 was obsoleted by RFC 1725, which was in turn obsoleted by RFC 1939.

POP4

[edit]

POP4 exists only as an informal proposal adding basic folder management, multipart message support, as well as message flag management to compete with IMAP; however, its development has not progressed since 2003. There are now two known POP4 server implementations. As of October 2013, the POP4.org domain and website are now hosted by simbey.com, which also runs the other POP4 server implementation.[4]

Extensions and specifications

[edit]

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. With the exception of 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.

STARTTLS

[edit]

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).

SDPS

[edit]

Demon Internet introduced extensions to POP3 that allow multiple accounts per domain, and has become known as Standard Dial-up POP3 Service (SDPS).[5] To access each account, the username includes the hostname, as john@hostname or john+hostname.

Google Apps uses the same method.[6]

Kerberized Post Office Protocol

[edit]

In computing, local e-mail clients can use the Kerberized Post Office Protocol (KPOP), an application-layer Internet standard protocol, to retrieve e-mail from a remote server over a TCP/IP connection. The KPOP protocol is based on the POP3 protocol – differing in that it adds Kerberos security and that it runs by default over TCP port number 1109 instead of 110. One mail server software implementation is found in the Cyrus IMAP server.

Session example

[edit]

The following POP3 session dialog is an example in RFC 1939:[7] 

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>
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

Comparison with IMAP

[edit]

The Internet Message Access Protocol (IMAP) is an alternative and more recent mailbox access protocol. The highlights of differences are:

  • POP is a simpler protocol, making implementation easier.
  • POP moves the message from the email server to the local computer, although there is usually an option in email clients to leave the messages on the email server as well. IMAP defaults to leaving the message on the email server, simply downloading a local copy.
  • POP treats the mailbox as a single store, and has no concept of folders
  • An IMAP client performs complex queries, asking the server for headers, or the bodies of specified messages, or to search for messages meeting certain criteria. Messages in the mail repository can be marked with various status flags (e.g. "deleted" or "answered") and they stay in the repository until explicitly removed by the user—which may not be until a later session. In short: IMAP is designed to permit manipulation of remote mailboxes as if they were local. Depending on the IMAP client implementation and the mail architecture desired by the system manager, the user may save messages directly on the client machine, or save them on the server, or be given the choice of doing either.
  • POP provides a completely static view of the current state of the mailbox, and does not provide a mechanism to show any external changes in state during the session (the client must reconnect and re-authenticate to get an updated view).
  • IMAP provides a dynamic view, and sends responses for external changes in state, including newly arrived messages, as well as changes made to the mailbox by other concurrently connected clients.
  • POP can either retrieve an entire message with the RETR command, and for servers that support it, the headers, as well as a specified number of body lines can be accessed with the TOP command.
  • IMAP allows clients to retrieve any of the individual MIME parts separately – for example, retrieving the plain text without retrieving attached files, or retrieving only one of many attached files.
  • IMAP supports flags on the server to keep track of message state: for example, whether or not the message has been read, replied to, forwarded, or deleted.
  • POP provides the ability to associate unique identifiers with each message for servers which support the UIDL command. This can be any string of standard visible (non-whitespace) 7-bit ASCII characters up to 70 characters.
  • IMAP instead provides unique numerical identifiers for each message, local to each folder, in conjunction with a folder specific UIDVALIDITY number.
  • The above two message identification methods (POP UIDL and IMAP UID) are not at all related unless a server implementation which supports both protocols purposely builds the POP3 UIDL string by combining the IMAP UID and UIDVALIDITY values.
[edit]
  • 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
  • RFC 8314 – Cleartext Considered Obsolete: Use of Transport Layer Security (TLS) for Email Submission and Access

See also

[edit]

References

[edit]

Further reading

[edit]
[edit]
Revisions and contributorsEdit on WikipediaRead on Wikipedia

Post Office Protocol

View on Grokipedia
from Grokipedia
The Post Office Protocol (POP) is an application-layer protocol that enables clients on resource-limited devices, such as workstations, to dynamically retrieve messages from a remote maildrop on a server host over a TCP/IP connection, typically using port 110. Defined as Standards Track protocol STD 53, POP facilitates the download of to the client, where messages are often deleted from the server after retrieval to conserve storage space on the host. This protocol operates in conjunction with the (SMTP) for sending emails but focuses primarily on inbound retrieval, without providing extensive server-side search or management capabilities. The protocol's development began in the early to address the limitations of SMTP-based mail access on intermittently connected or low-resource systems. Version 1 (POP1) was first specified in RFC 918 in 1984, introducing basic mail retrieval mechanisms. This was followed by POP2 in RFC 937 (1985), which added support for list commands and improved session handling. The most widely adopted version, POP3, was initially outlined in RFC 1081 (1988) and later revised and obsoleted by RFC 1939 in 1996, incorporating enhancements like the APOP command for challenge-response authentication to mitigate password sniffing risks. In operation, a POP3 session progresses through three states: (for and ), Transaction (for listing, retrieving, and optionally deleting messages), and Update (for finalizing changes like deletions). Clients issue commands such as USER and PASS for basic or APOP for secure alternatives, followed by actions like RETR to fetch messages in their entirety. While POP3 remains in use for its simplicity and efficiency in offline scenarios, it has been extended by later RFCs (e.g., RFC 2449 for UIDL unique identifiers and RFC 8314 for implicit TLS on port 995) to address security and compatibility needs in modern environments. Unlike the (IMAP), POP3 does not support synchronized access across multiple devices, making it better suited for single-user, download-and-delete workflows.

Overview

Definition and Purpose

The Post Office Protocol (POP) is an application-layer protocol, designated as STD 53, used for retrieving electronic mail messages from a remote server over TCP/IP networks. It operates primarily in a client-server model where an connects to a mail server to access a user's maildrop, a repository of incoming messages. The primary purpose of POP is to enable email clients to messages from the server, supporting core operations such as listing available messages, retrieving their contents, and optionally marking them for deletion. This design facilitates efficient mail retrieval for end-users, particularly in environments with limited client resources, by allowing the transfer of messages to local storage on the client device. POP typically assumes intermittent network connections, such as dial-up access, where users connect briefly to fetch mail before disconnecting, with messages downloaded to the client and deleted from the server by default to free up server space. Key benefits of POP include its inherent simplicity, which minimizes implementation complexity and supports widespread adoption across diverse email clients; reduced server resource demands, as retrieved messages are removed from the server; and suitability for offline access on a single primary device, where users manage mail locally without ongoing server dependency. POP evolved alongside the (SMTP) to complement systems, handling message retrieval after SMTP delivers incoming mail to the server. POP connections occur over TCP port 110 for unencrypted sessions or port 995 for encrypted ones.

Basic Architecture

The Post Office Protocol (POP) employs a in which a mail user agent (MUA), such as an on a , establishes a connection to a mail server hosting the user's maildrop. The server, which hosts the user's mailbox, maintains incoming emails in a dedicated mailbox for each user, accessible dynamically over the network. This model enables the MUA to retrieve and store messages locally on the client device, contrasting with protocols like SMTP that focus on message transmission. POP sessions proceed through three distinct phases: , transaction, and update. During the authorization phase, the client authenticates with the server, which then locks the user's maildrop to prevent concurrent access. The transaction phase allows the client to interact with the mailbox contents, such as listing or fetching messages, while deferring any permanent changes. Finally, in the update phase, upon session termination, the server processes deletions, releases the lock, and closes the connection, ensuring data consistency. Messages in POP are stored server-side in a single, linear mailbox per user, with the client retrieving entire messages sequentially by their ordinal numbers, typically downloading them in full to the local device. This approach assumes offline access post-retrieval, often resulting in server-side deletion after successful transfer, though clients may choose to leave copies. The protocol uses TCP 110 for unencrypted connections, while secure variants operate on 995 with TLS encryption. At its core, POP is a simple, text-oriented protocol relying on ASCII-encoded commands and responses exchanged over the TCP stream. Commands are short, fixed-length strings (three or four characters) terminated by a and line feed (CRLF), with responses prefixed by "+" for success or "-ERR" for failure. Multi-line data, such as message bodies, is delimited by a single period (.) on a line by itself, supporting efficient transfer of octet-based content without complex parsing.

History

Early Development

The Post Office Protocol (POP) was first introduced in 1984 through RFC 918, which specified version 1 (POP1) as an experimental protocol for the ARPA-Internet community. Authored by J. K. Reynolds, POP1 provided a basic mechanism for workstations to dynamically access and retrieve mail from a mailbox server using TCP. The development of POP1 was driven by the need for simple, client-initiated email retrieval in the ARPANET environment, where limited bandwidth and local storage made it impractical for users to maintain full mailboxes on remote servers. This allowed messages to be downloaded to local systems for offline reading, addressing the growing demand for personal email access amid the network's resource constraints. In 1985, POP version 2 (POP2) followed with RFC 937, authored by M. Butler, J. Postel, D. Chase, J. Goldberger, and J. K. Reynolds, refining the protocol for use over reliable transport like TCP on port 109. POP2 introduced improvements such as enhanced error handling through acknowledgment commands (ACKS, ACKD, NACK) and the READ command to obtain message sizes before full retrieval with RETR, while still emphasizing straightforward download and deletion of entire messages. Despite these advancements, early POP versions shared fundamental limitations, including rudimentary restricted to plaintext username and password exchanges, and no provisions for organizing messages into folders or handling multi-part content. These constraints reflected the protocols' focus on for early network conditions. POP1 and POP2 established the core principles of server-based mail retrieval, setting the stage for more comprehensive standards as traffic on the proliferated.

POP3 Standardization

The Post Office Protocol version 3 (POP3) was first standardized in November 1988 through RFC 1081, which defined a protocol for workstations to dynamically access maildrops on server hosts, enabling efficient retrieval of messages over TCP/IP networks. This initial specification established POP3's core commands and session states, focusing on simplicity to support the growing use of personal computers for access. Over the following years, POP3 underwent several revisions to address ambiguities and implementation issues. RFC 1081 was obsoleted by a series of updates, including RFC 1225 (1991), RFC 1460 (1993), and RFC 1725 (1994), culminating in RFC 1939 in May 1996, which provided clearer specifications and fixed minor bugs while maintaining backward compatibility. RFC 1939 incorporated POP3 into Internet Standard 53 (STD 53), solidifying its status as the definitive reference for the protocol. Key enhancements in these updates included the addition of the APOP command for challenge-response authentication using MD5 digests to avoid transmitting plaintext passwords, the UIDL command for generating unique identifiers for messages to prevent duplication across sessions, and the optional TOP command for previewing message headers and a limited number of body lines without full retrieval. POP3's widespread adoption as the for email retrieval stemmed from its straightforward design, which required minimal server resources and integrated seamlessly with early graphical email clients such as (released in 1991) and Eudora (introduced in 1988). These clients leveraged POP3's efficiency for offline storage and local management of messages, making it ideal for dial-up connections prevalent in the . Since the publication of RFC 1939, POP3 has remained stable with no major revisions, allowing consistent implementation across diverse systems while optional extensions handle evolving needs.

POP4 Proposal

In 2003, an informal proposal for POP4 emerged as an extension to POP3, aiming to remedy key limitations such as the absence of server-side folder management and suboptimal handling of multipart messages, which restricted POP3's utility for more complex email workflows. The proposed protocol incorporated several IMAP-inspired enhancements while preserving POP3's simplicity, including namespace commands for creating and navigating folders (e.g., LISTFOLDERS and SELECTFOLDER), support for up to 32 message flags (such as Read, Deleted, and Answered), and server-side search capabilities via the SEARCH command; these features were designed to enable hybrid POP/IMAP environments where users could maintain server-side organization without fully migrating to IMAP. Development of POP4 stalled shortly after its introduction, overshadowed by IMAP's established dominance in providing advanced email management; as of the last documented update in 2013, only two experimental implementations were available—the O3 mail server and SimbeyServer—neither of which achieved broader deployment. POP4's lack of adoption stems from its functional overlap with IMAP, which already addressed demands for folder support and message flagging, coupled with limited interest in bolstering POP amid the rise of web-based email interfaces that diminished reliance on client-side protocols. No further progress on the proposal has been observed as of 2025.

Protocol Mechanics

Commands and Responses

The Post Office Protocol version 3 (POP3) employs a simple, text-based command structure where clients send commands consisting of case-insensitive keywords, typically three or four characters long, optionally followed by arguments separated by a single space, and terminated by a and line feed (CRLF). Arguments are limited to 40 characters in length. Examples include USER followed by a username or PASS followed by a password string, both used in the authorization phase. Server responses in POP3 follow a standardized format to indicate success, failure, or data transmission. Positive responses begin with +OK, optionally followed by human-readable information, and end with CRLF. Negative responses start with -ERR, also terminated by CRLF, signaling errors such as unrecognized commands or invalid arguments. Multi-line responses, used for transmitting message content or metadata, commence with +OK, followed by one or more lines of data (with lines beginning with a single period byte-stuffed by prepending another period (i.e., to '..') to avoid premature termination), and conclude with a single period on a line by itself followed by CRLF (i.e., ".CRLF"). POP3 operates through a state machine with three primary states: , transaction, and update. In the state, the client must issue USER and PASS commands to before proceeding; successful transitions the session to the transaction state. The transaction state allows message manipulation, and issuing QUIT transitions to the update state, where deletions are finalized before the connection closes. If fails or QUIT is issued prematurely, the connection terminates without entering subsequent states. Key commands in the authorization state include USER name, which identifies the mailbox and prompts for a subsequent PASS or QUIT, and PASS string, which authenticates the user following a valid USER command; both elicit on success or -ERR on failure. In the transaction state, STAT returns the total number of messages (nn) and their cumulative size in octets (mm) as "+OK nn mm". [msg] lists message numbers and sizes, either for a specific message or all messages in multi-line format if no argument is provided. RETR msg retrieves the full content of the specified message in multi-line format. msg marks the message for deletion, which is only executed during the update state to allow transaction rollback if needed. Additional transaction commands enhance functionality without altering the core retrieval model. UIDL [msg] provides unique identifiers for messages, either for a specific one or all in multi-line format, enabling clients to track messages across sessions without relying on sequential numbers. msg n retrieves the message headers plus the first n lines of the body in multi-line format, useful for previewing without full download. NOOP performs no operation but returns +OK, often used to maintain the connection or test server responsiveness. Error handling in POP3 relies on -ERR responses for invalid syntax, unimplemented commands, or state-inappropriate actions, such as issuing transaction commands before . Servers may include descriptive text after -ERR for diagnostics, but clients must not depend on it. The QUIT command handles session termination: in the state, it closes the connection immediately; in the transaction state, it first triggers the update state to remove marked messages and release resources before closing. Unrecognized commands always yield -ERR without state changes.
CommandSyntaxStateDescription
USERUSER nameAuthorizationSpecifies the mailbox name; requires PASS next on success.
PASSPASS stringAuthorizationAuthenticates the password; transitions to transaction on success.
APOPAPOP name digestAuthorizationAuthenticates using challenge-response.
STATSTATTransactionReturns count and total size.
LISTLIST [msg]TransactionLists numbers and sizes (multi-line if no msg).
RETRRETR msgTransactionRetrieves full (multi-line).
DELEDELE msgTransactionMarks for deletion (deferred until update).
UIDLUIDL [msg]TransactionLists unique IDs for (multi-line if no msg).
TOPTOP msg nTransactionRetrieves headers + n body lines (multi-line).
NOOPNOOPTransactionNo operation; returns +.
QUITQUITAnyTerminates session, performing update if in transaction.

Authentication Process

The Post Office Protocol version 3 (POP3) authentication process begins with the server sending a greeting message to the client upon connection establishment, typically in the form of "+OK ", indicating the server is ready for authorization. This initiates the AUTHORIZATION state, where the client must authenticate before proceeding to the TRANSACTION state for mail retrieval. Successful authentication transitions the session to the TRANSACTION state, allowing access to the user's mailbox, while failure results in a "-ERR" response and session termination. The basic authentication mechanism in POP3 relies on the USER and PASS commands, where the client first sends "USER " to identify the account, followed by "PASS

" to provide the password for verification. This sequence transmits credentials in clear text, making it susceptible to by network eavesdroppers if not protected by external layers. To address plaintext vulnerabilities, POP3 supports enhanced authentication via the APOP command, introduced as an MD5-based challenge-response mechanism; the server provides a unique in the , and the client computes an digest of the timestamp concatenated with the shared secret (), sending the username and digest for verification without exposing the password. Additionally, POP3 integrates with the () framework, enabling mechanisms such as DIGEST-MD5 for protected exchanges. Servers advertise supported authentication methods through the CAPA command, which lists capabilities like "APOP", "SASL DIGEST-MD5", or others during the AUTHORIZATION state, allowing clients to select an appropriate method before proceeding. In modern deployments, providers such as have deprecated basic for POP3 since late 2022, mandating OAuth 2.0 or equivalent modern authorization flows for secure access.

Security Considerations

Encryption Methods

The primary encryption method for POP3 communications is the use of (TLS), which protects the confidentiality and integrity of retrieval sessions against and tampering. This integration, specified in RFC 2595, enables secure upgrades from plaintext connections and supports modern cryptographic standards to mitigate risks associated with unencrypted transmissions. RFC 8314 further deprecates cleartext POP3, recommending implicit TLS on port 995 as the preferred method and urging a transition away from unencrypted access. STARTTLS provides an opportunistic mechanism for encrypting POP3 sessions on the standard port 110. After establishing a TCP connection, the client issues the STLS command to initiate a TLS , converting the session to encrypted transport if the server supports it; this typically occurs before to avoid exposing credentials in cleartext. Servers advertise STLS capability via the CAPA command, as defined in RFC 2449, allowing clients to detect and negotiate support early in the session. In contrast, POP3S establishes a dedicated TLS-secured connection directly on port 995, where the TLS begins immediately upon TCP connection without requiring an explicit upgrade command. This implicit TLS approach, outlined in RFC 2595 and reinforced by RFC 8314, simplifies deployment by eliminating negotiation overhead and is recommended for environments prioritizing security from the outset. Additional extensions enhance POP3 security in specialized contexts. The KPOP variant integrates Kerberos V5 on port 1109, replacing passwords with encrypted Kerberos tickets for secure credential verification, though it may still benefit from concurrent TLS for full transport protection. Since the retirement of basic in Exchange Online in December 2022, access requires modern methods like OAuth 2.0 over TLS-secured connections, with TLS 1.2 mandated since October 2020 to support these flows without insecure fallbacks.

Vulnerabilities and Mitigations

The Post Office Protocol version 3 (POP3) is susceptible to several vulnerabilities primarily stemming from its original design, which did not incorporate modern cryptographic protections. One major risk is the transmission of data in over the default port 110, enabling attacks where unauthorized parties can intercept credentials and content during transit. This vulnerability facilitates man-in-the-middle (MITM) attacks, as demonstrated by reports indicating nearly 3.3 million POP3 and IMAP servers exposed to network sniffing in January 2025. Additionally, the default mechanism using USER and PASS commands sends credentials in cleartext, making it prone to brute-force attacks where attackers repeatedly guess passwords without in basic implementations. POP3 also lacks inherent , leaving messages vulnerable after download to the client device. Historically, POP3 faced exploits in the pre-TLS era, where unencrypted sessions allowed widespread packet sniffing to capture sensitive data, a common threat in the and early before widespread adoption of transport-layer security. The APOP extension, intended to provide challenge-response authentication using hashing, has been compromised by vulnerabilities such as collision-based key-recovery attacks and MITM techniques that exploit weaknesses, allowing partial password recovery. To mitigate these risks, administrators should enforce the use of STARTTLS to upgrade connections to encrypted ones or mandate POP3S on port 995 for implicit TLS, as outlined in RFC 2595 and recommended by RFC 8314, which significantly reduces eavesdropping and MITM threats. Integrating (SASL) mechanisms, such as SCRAM-SHA-256, provides stronger password-based authentication resistant to offline attacks, with support available in modern POP3 servers like Dovecot. For providers like Exchange Online, the 2022 retirement of basic authentication mandates 2.0, which uses token-based access over TLS without credentials. Best practices include disabling legacy authentication methods to prevent fallback to insecure options, monitoring CAPA responses to verify support for secure extensions like STLS and advanced AUTH mechanisms, and combining POP3 with TLS-secured SMTP for holistic . In 2025, enterprise trends emphasize restricting insecure POP3 usage through policies rather than full protocol retirement, driven by regulatory pressures and ongoing vulnerability reports highlighting exposed servers.

Practical Usage

Sample Session

A sample POP3 session illustrates the protocol's operation from connection establishment through authentication, message retrieval, deletion, and disconnection, as defined in the core specification. This example demonstrates transitions between the AUTHORIZATION, TRANSACTION, and UPDATE states, showing typical client-server interactions over a TCP connection on port 110. The following is a complete example session extracted from the specification, where the client uses the APOP command for authentication (an optional MD5-based method), retrieves both messages, deletes them, and quits. Lines prefixed with "S:" represent server responses, and "C:" denote client commands; multi-line responses end with a single period (.) on its own line.

S: <wait for connection on TCP port 110> C: <open connection> S: +OK POP3 server ready <[email protected]> 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>

S: <wait for connection on TCP port 110> C: <open connection> S: +OK POP3 server ready <[email protected]> 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>

In this session, the process begins with the server waiting for a TCP connection on port 110, followed by a response indicating readiness and including a for challenges. The client then authenticates using APOP, combining the username "mrose" with an hash of the timestamp and a , prompting the server to report the maildrop status (2 messages totaling 320 octets) and transition to the TRANSACTION state. The STAT command confirms this status with a concise "+OK 2 320" response, where the first number is the message count and the second is the total size in octets. The LIST command elicits a multi-line response listing each message's number and size (e.g., "1 120" for the first of 120 octets), terminated by a single "." to signal the end; the client parses this to identify available messages without retrieving content. For retrieval, RETR 1 requests the full content of 1, starting with "+OK 120 octets" followed by the body (including headers and text), again terminated by "."; the client must handle this termination correctly to avoid incomplete reads. DELE 1 then marks the for deletion (without immediate removal), receiving confirmation; deletions are only finalized upon QUIT to allow transaction if the connection drops. The process repeats for the second , and QUIT triggers the UPDATE state, where marked messages are permanently deleted, the maildrop is reported as empty, and the connection closes. Error handling is integral to robust client behavior; for instance, if the client issues LIST 3 when only two messages exist, the server responds with "-ERR no such message," indicating an invalid message number. Similarly, attempting DELE 2 after it has already been marked yields "-ERR message #2 already deleted," preventing redundant operations. These negative responses (prefixed with "-ERR") require the client to parse and adjust, such as by re-querying STAT to refresh the maildrop view. For secure sessions, the protocol can incorporate TLS encryption via the STLS extension, initiated immediately after the greeting in the state if the server advertises "STLS" capability (via an optional CAPA command). The client issues STLS, receiving "+OK Begin TLS negotiation," after which occurs over the existing connection before proceeding to and other commands; this upgrades the session to protected transport without changing ports. A brief secure variant might thus insert:

C: <open connection> S: +OK POP3 server ready <timestamp> C: CAPA S: +OK Capability list follows S: STLS S: . C: STLS S: +OK Begin TLS negotiation <TLS Negotiation, e.g., ClientHello, ServerHello, key exchange> C: APOP mrose <hashed credentials> ... (remainder as in unsecured session, now over TLS)

C: <open connection> S: +OK POP3 server ready <timestamp> C: CAPA S: +OK Capability list follows S: STLS S: . C: STLS S: +OK Begin TLS negotiation <TLS Negotiation, e.g., ClientHello, ServerHello, key exchange> C: APOP mrose <hashed credentials> ... (remainder as in unsecured session, now over TLS)

This demonstrates state transitions in a protected , enhancing privacy for and data transfer. In contemporary email ecosystems, POP3 remains supported by several established server implementations, including Dovecot, which provides robust POP3 functionality alongside IMAP for secure delivery in self-hosted environments. Cyrus IMAP also offers comprehensive POP3 support, enabling seamless integration for multi-server setups with features like virtual domains and server-side filtering. On the client side, applications such as continue to include full POP3 configuration options, allowing users to retrieve emails via standard ports 110 or 995. maintains POP3 compatibility in its classic version, with reintroduced support in the new Outlook app for legacy accounts, though it requires updated methods. Usage of POP3 has declined in favor of IMAP, particularly for multi-device needs, yet it persists in legacy systems and single-device configurations where local storage is preferred. As of November 2025, major hosting providers continue to support POP3, maintaining its role in environments prioritizing simplicity over real-time access across devices. Modern compatibility for POP3 increasingly mandates OAuth 2.0 authentication, especially with providers like and , to replace less secure app passwords; for instance, enforced OAuth for third-party POP3 access starting March 14, 2025. This shift enhances security but limits seamless integration with mobile apps, as POP3's download-and-delete model does not natively support push notifications or folder synchronization without additional client-side configuration. POP3 addresses server storage efficiency challenges better than IMAP by downloading messages to the client and optionally deleting them from the server, reducing long-term hosting costs in resource-constrained setups. POP3 is used in IoT and embedded systems for lightweight email retrieval, such as device alerts and data logging, with support provided by toolkits like MQX and libraries from EUROS that enable POP3 on constrained hardware. Looking ahead, POP3 is expected to remain a stable but niche protocol, with ongoing maintenance focused on security enhancements like TLS enforcement rather than major feature expansions, ensuring its viability for specialized applications amid the dominance of IMAP and emerging standards.

Comparisons

With IMAP

The Post Office Protocol version 3 (POP3), as defined in RFC 1939, is designed primarily for retrieving messages from a server to a local client, where messages are downloaded in full and typically deleted from the server after retrieval to free up space and enable offline access. In contrast, the (IMAP), specified in RFC 3501, maintains messages on the server, allowing clients to access, manipulate, and synchronize them without mandatory local storage, supporting features like folder management, message flags, and partial content fetching for efficient bandwidth use across devices. This fundamental distinction positions POP3 as a "download-and-delete" model focused on local archiving, while IMAP emphasizes server-centric storage with real-time synchronization. POP3 suits scenarios with limited bandwidth or single-user setups, such as dial-up connections or devices requiring full offline capability, where local storage reduces dependency on constant server access. IMAP, however, excels in collaborative or multi-device environments, like shared inboxes in team workflows or accessing from smartphones, laptops, and web clients simultaneously, as it enables seamless updates such as read status or deletions across all connected devices. Technically, POP3 operates on a single mailbox per session without server-side search capabilities, limiting operations to basic retrieval (RETR) and deletion () commands within that mailbox. IMAP, by comparison, supports multiple mailboxes through namespaces (RFC 2342), enabling clients to discover and organize personal, shared, or public folders, and includes a SEARCH command for querying message attributes on the server without full downloads. Additionally, IMAP's IDLE extension (RFC 2177) allows clients to receive real-time notifications of new arrivals or changes without polling, enhancing responsiveness in dynamic setups. Migrating from POP3 to IMAP often involves tools like imapsync, a command-line utility for transferring messages between servers while preserving metadata, to upload locally stored emails to the IMAP server. As a partial during transition, many POP3 clients offer a "leave messages on server" option, which instructs the server to retain copies for a specified period (e.g., days or until manually deleted), mimicking some IMAP-like persistence but without full . By 2025, IMAP has become the dominant email retrieval protocol due to the rise of mobile devices and cloud services, while POP3 persists mainly for legacy systems requiring offline compliance. This shift is underscored by major providers like deprecating POP3 fetch features starting in January 2026, further solidifying IMAP's prevalence for modern, multi-access email management.

With SMTP

The Post Office Protocol version 3 (POP3) serves primarily as a retrieval mechanism for downloading messages from a server to a client device, while the (SMTP), defined in STD 10 (RFC 5321), is responsible for the outbound transmission of from a client to a server or between servers. SMTP typically operates on port 25 for server-to-server relaying or port 587 for client submission, enabling the reliable transfer of messages across the . In contrast, POP3 focuses exclusively on inbound retrieval, pulling messages stored on the server to the local client without involvement in the sending process. In a complete email workflow, SMTP and POP3 function complementarily: SMTP handles the upload and delivery of outgoing messages from the sender's client to the recipient's server, after which POP3 allows the recipient's client to those inbound messages. This division ensures efficient , with no direct overlap in their command sets; for instance, SMTP employs commands such as MAIL FROM to specify the sender's address, RCPT TO to identify recipients, and to transmit the message content. POP3, by design, lacks any mechanisms for composing or sending , reinforcing its role as a one-way retrieval protocol. A key limitation of POP3 is its inability to send emails, necessitating a separate SMTP configuration in clients for full functionality, which can complicate setup in environments relying solely on POP3 for access. Additionally, SMTP operates as a , where each transaction is independent and no persistent connection state is maintained between sessions, whereas POP3 employs a stateful approach during its retrieval session to track message handling and deletions. This contrast in session persistence highlights their distinct architectural philosophies, with SMTP optimized for transient, high-volume transfers and POP3 for controlled, session-bound downloads. In modern implementations, both protocols commonly incorporate (TLS) for encryption: SMTP via on port 465 for implicit TLS or port 587 with STARTTLS for , and POP3 similarly secured on port 995. As of 2025, clients often bundle POP3 and SMTP configurations for simplicity, but usage trends indicate a decline in POP3 combined with SMTP in favor of IMAP paired with SMTP, driven by demands for multi-device and reduced server storage needs. Despite this shift, the combination remains viable for low-bandwidth or offline-focused scenarios. POP3 and SMTP is prevalent in legacy systems, where they together enable basic exchange without advanced features, though recent authentication deprecations—such as Microsoft's full disablement of Basic Authentication for POP3 since early 2023 and the planned permanent removal of Basic Authentication for SMTP AUTH in Exchange Online beginning March 2026—pose challenges by requiring migration to modern methods like OAuth 2.0 to maintain compatibility. These changes affect both protocols similarly, as legacy clients using plain credentials risk disruption in cloud-based environments.

References

  1. https://www.rfc-editor.org/rfc/rfc1939.html
  2. https://www.rfc-editor.org/rfc/rfc918.html
  3. https://www.rfc-editor.org/rfc/rfc937.html
  4. https://www.rfc-editor.org/rfc/rfc2449.html
  5. https://www.rfc-editor.org/rfc/rfc8314.html
  6. https://www.rfc-editor.org/info/std53
  7. https://nvlpubs.nist.gov/nistpubs/specialpublications/nist.sp.800-177.pdf
  8. https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml
  9. https://datatracker.ietf.org/doc/html/rfc1939
  10. https://datatracker.ietf.org/doc/html/rfc918
  11. https://datatracker.ietf.org/doc/html/rfc937
  12. https://datatracker.ietf.org/doc/html/rfc1081
  13. http://www.tcpipguide.com/free/t_POPOverviewHistoryVersionsandStandards.htm
  14. https://www.pop4.org/
  15. https://www.pop4.org/pop4/pop4spec.html
  16. https://sourceforge.net/projects/pop4/
  17. https://www.mailjerry.com/what-is-pop3/
  18. https://serversmtp.com/smtp-pop3/
  19. https://datatracker.ietf.org/doc/html/rfc1939#section-4
  20. https://datatracker.ietf.org/doc/html/rfc1939#section-3
  21. https://datatracker.ietf.org/doc/html/rfc1939#section-5
  22. https://datatracker.ietf.org/doc/html/rfc1939#section-6
  23. https://datatracker.ietf.org/doc/html/rfc1939#section-11
  24. https://datatracker.ietf.org/doc/html/rfc5034
  25. https://datatracker.ietf.org/doc/html/rfc2449
  26. https://learn.microsoft.com/en-us/exchange/clients-and-mobile-in-exchange-online/deprecation-of-basic-authentication-exchange-online
  27. https://datatracker.ietf.org/doc/html/rfc8314
  28. https://datatracker.ietf.org/doc/html/rfc2595
  29. https://www.magicspam.com/blog/port-110-pop3-explained/
  30. https://www.techradar.com/pro/security/experts-warn-millions-of-email-servers-could-be-vulnerable-to-attack
  31. https://hackviser.com/tactics/pentesting/services/pop3
  32. https://www.huntress.com/cybersecurity-101/topics/post-office-protocol
  33. https://who.rocq.inria.fr/Gaetan.Leurent/files/APOP_IJACT.pdf
  34. https://www.mozilla.org/en-US/security/advisories/mfsa2007-15/
  35. https://www.rfc-editor.org/rfc/rfc2595.html
  36. https://www.pentestpad.com/port-exploit/port-110-pop3-post-office-protocol-version-3
  37. https://doc.dovecot.org/main/core/config/auth/mechanisms/overview.html
  38. https://blog.rebex.net/office365-imap-pop3-oauth-unattended
  39. https://learn.microsoft.com/en-us/entra/identity/conditional-access/policy-block-legacy-authentication
  40. https://practical365.com/switching-off-legacy-authentication-for-exchange-online/
  41. https://www.shadowserver.org/what-we-do/network-reporting/vulnerable-pop3-report/
  42. https://www.cybersecurityattorney.com/still-using-ftp-or-pop3-heres-why-that-could-get-you-sued-in-2025/
  43. https://datatracker.ietf.org/doc/html/rfc1939#section-10
  44. https://datatracker.ietf.org/doc/html/rfc1939#section-11.6
  45. https://datatracker.ietf.org/doc/html/rfc1939#section-7
  46. https://datatracker.ietf.org/doc/html/rfc2595#section-4
  47. https://datatracker.ietf.org/doc/html/rfc2595#section-4.2
  48. https://dovecot.org/
  49. https://www.cyrusimap.org/
  50. https://www.fastcomet.com/tutorials/mail/thunderbird-pop-configuration
  51. https://www.codetwo.com/admins-blog/new-outlook-for-windows/
  52. https://www.enbecom.net/blog/2024/02/07/is-there-still-a-place-for-pop/
  53. https://hostadvice.com/email-hosting/pop3-hosting/
  54. https://support.google.com/a/answer/14114704?hl=en
  55. https://learn.microsoft.com/en-us/exchange/client-developer/legacy-protocols/how-to-authenticate-an-imap-pop-smtp-application-by-using-oauth
  56. https://www.cloudflare.com/learning/email-security/what-is-imap/
  57. https://embedded-access.com/products/email-clients/
  58. https://www.euros-embedded.com/products/system-software/network-protocols/
  59. https://www.technologygee.com/what-is-the-post-office-protocol-version-3-pop3/
  60. https://www.ietf.org/rfc/rfc1939.txt
  61. https://datatracker.ietf.org/doc/html/rfc3501
  62. https://support.microsoft.com/en-us/office/what-are-imap-and-pop-ca2c5799-49f9-4079-aefe-ddca85d5b1c9
  63. https://mailtrap.io/blog/imap-vs-pop3-vs-smtp-email-protocols/
  64. https://www.spiceworks.com/tech/tech-general/articles/imap-vs-pop3/
  65. https://www.rfc-editor.org/rfc/rfc2342.html
  66. https://datatracker.ietf.org/doc/html/rfc2177
  67. https://imapsync.lamiral.info/
  68. https://support.microsoft.com/en-us/office/leave-a-copy-of-the-message-on-the-server-is-missing-in-outlook-c25a68de-f12e-4607-8950-7f567116da8e
  69. https://www.milesweb.ae/blog/technology-hub/pop3-vs-imap/
  70. https://www.thestack.technology/fire-up-the-auto-forward-gmail-kills-pop3-fetch/
  71. https://datatracker.ietf.org/doc/html/rfc5321
  72. https://www.siteground.com/tutorials/email/protocols-pop3-smtp-imap/
  73. https://mailtrap.io/blog/pop3-vs-smtp/
  74. https://www.geeksforgeeks.org/computer-networks/imap-vs-pop3-vs-smtp/
  75. https://web.eecs.utk.edu/~hqi/teaching/ece453f06/hw/hw8_sol.htm
  76. https://www.cloudflare.com/learning/email-security/smtp-port-25-587/
  77. https://techcommunity.microsoft.com/blog/exchange/exchange-online-to-retire-basic-auth-for-client-submission-smtp/4114750
Add your contribution
Related Hubs
User Avatar
No comments yet.