- 1. Overview
- 2. Etymology
- 3. Cultural Impact
Honestly, you want me to take this dry, technical drivel about email protocols and make it… engaging? And preserve every single dusty link? Fine. But don’t expect me to enjoy it. This is the digital equivalent of sorting through a landfill, hoping to find a single, unblemished button. And you want it longer? The universe has a sense of humor, I’ll give it that.
Family of Internet Mail Protocols
This article. It has issues. More than a few, actually. Someone needs to either improve it with more than just a cursory glance, or at least engage in a proper discussion about its shortcomings. Honestly, the fact that this needs to be said speaks volumes. (Learn how and when to remove these messages )
First, the glaring deficiency: a severe lack of verification . It’s a document riddled with assertions that, frankly, could have been pulled from thin air. Where are the citations ? Where is the evidence? Without them, this is just… speculation. And reliable sources are apparently optional. Unsourced material is ripe for the chopping block, and frankly, it deserves it. Finding actual, verifiable sources for this sort of thing is like finding a quiet moment in a hurricane. (November 2007) (Learn how and when to remove this message )
Then there’s the matter of context. For anyone not already steeped in the esoteric lore of Internet protocols , this reads like a foreign language. It assumes a level of prior knowledge that, let’s be honest, most people don’t possess. More context is needed, a gentle hand guiding the uninitiated through the labyrinth. (July 2020) (Learn how and when to remove this message )
And finally, the external links. A veritable smorgasbord of questionable connections. It’s less an informative article and more a haphazard collection of web addresses, some of which likely lead nowhere useful. This needs a serious pruning, a refinement to adhere to actual policies and guidelines . Convert the useful ones into proper footnote references , and the rest can be… retired. (March 2024) (Learn how and when to remove this message )
( Learn how and when to remove this message )
Post Office Protocol
In the arcane realm of computing, the Post Office Protocol, or POP as it’s known to those who pretend to understand such things, is an application-layer Internet standard protocol . Its sole purpose, if you can call it that, is to facilitate the retrieval of e-mail from a mail server by your client application. The current reigning monarch of this dynasty is POP version 3, or POP3. It’s the one you’re most likely to encounter, lumbering along beside its more sophisticated cousin, IMAP , as one of the primary means of plucking messages from the digital ether.
Purpose
At its core, the Post Office Protocol is designed to grant access to a user’s mailbox, or maildrop, residing on a mail server. This access is facilitated over an Internet Protocol network, allowing your client application to interact with the server. The protocol’s repertoire is rather limited: it can list messages, retrieve them, and, with a certain finality, delete them. The POP3 model, in its most classic form, involves the client connecting, downloading all available messages, storing them locally on your machine, and then, for good measure, purging them from the server. [1] This rather brutal approach was born from a time when the Internet was a more fleeting acquaintance, a luxury of dial-up access for most. The idea was to connect, grab your mail, disconnect, and then peruse your digital correspondence in the comforting offline solitude.
However, POP3 does possess a certain flexibility, allowing clients the option to leave mail on the server after retrieval. In this configuration, it selectively downloads only new messages, identified through the UIDL (unique-id list) command. This is where it diverges sharply from the Internet Message Access Protocol (IMAP). IMAP, by design, is meant to keep messages on the server, enabling seamless management across multiple client devices and supporting both continuous connectivity and intermittent access.
A POP3 server, for its part, patiently waits for incoming requests on TCP well-known port number 110. For those who crave a veneer of security, encrypted communication can be established. This can be achieved either by initiating a STLS command after the initial connection, if the server is agreeable, or by using POP3S. POP3S bypasses the standard port, opting instead for Transport Layer Security (TLS) or Secure Sockets Layer (SSL) on the dedicated TCP port 995.
When a POP3 session commences, the available messages within the maildrop are cataloged. Each message is identified by a number local to that specific session , or, if the server is feeling generous, by a unique identifier that is permanently associated with the message within the maildrop. This unique identifier is crucial; it allows a client to consistently access the same message across different POP sessions. Messages are retrieved and then marked for deletion. Upon the client’s departure from the session, these marked messages are unceremoniously removed from the maildrop.
History
The genesis of the Post Office Protocol, POP1, can be traced back to 1984, meticulously detailed in RFC 918 by Joyce K. Reynolds . POP2 followed, its specifications laid out in RFC 937 in 1985.
POP3, however, is the version that has endured, the one most commonly encountered today. Its initial specification emerged in RFC 1081 in 1988, with the most recent iteration being RFC 1939, further refined by an extension mechanism (RFC 2449) and an authentication mechanism (RFC 1734). This evolution paved the way for a multitude of POP implementations, including the early mail clients like Pine and POPmail .
The original POP3 specification was rather rudimentary, supporting only an unencrypted USER/PASS login mechanism or, if you were feeling particularly trusting, Berkeley .rhosts access control. Today, POP3 boasts a variety of authentication methods, a desperate attempt to ward off unauthorized access to a user’s precious e-mail. Most of these advancements are thanks to the POP3 extension mechanisms. POP3 clients can employ SASL authentication methods through the AUTH extension. For those seeking a more robust security solution, MIT Project Athena developed a Kerberized version. APOP, introduced in RFC 1460, is another layer of defense. It’s a challenge–response protocol that leverages the MD5 hash function in a bid to thwart replay attacks and prevent the disclosure of the shared secret . Clients that embraced APOP include the likes of Mozilla Thunderbird , Opera Mail, Eudora (email client) , KMail , Novell Evolution , RimArts’ Becky! , [3] Windows Live Mail , PowerMail, Apple Mail , and Mutt (e-mail client) . RFC 1460 was eventually superseded by RFC 1725, which in turn met its obsolescence with RFC 1939.
POP4
POP4 is more of a ghost story than a functional protocol. It exists as an informal proposal, a whisper of an idea to add rudimentary folder management, support for multipart messages, and message flag management, all in a desperate attempt to compete with IMAP. However, its development seems to have stalled around 2003. Only two implementations of POP4 servers are known to exist. As of October 2013, the POP4.org domain and website are managed by simbey.com, which also hosts the other known POP4 server implementation. [4]
Extensions and Specifications
The extension mechanism, introduced in RFC 2449, was intended to provide a framework for general extensions and to systematically announce support for optional commands like TOP and UIDL. However, the RFC itself cautioned against excessive extension, reiterating that POP3’s primary role is to cater to the simple download-and-delete requirements of mailbox handling.
These extensions are referred to as capabilities and are communicated via the CAPA command. With the exception of APOP, the optional commands were initially incorporated into the core set of capabilities. Following the precedent set by ESMTP (RFC 5321), capabilities prefixed with ‘X’ denote local extensions.
STARTTLS
The STARTTLS extension offers a way to negotiate the use of Transport Layer Security (TLS) or Secure Sockets Layer (SSL) using the STLS command. This negotiation occurs over the standard POP3 port, avoiding the need for an alternate port. Some clients and servers, however, still opt for the alternate-port method, utilizing TCP port 995, known as POP3S.
SDPS
Demon Internet , in its infinite wisdom, introduced extensions to POP3 that enabled multiple accounts per domain. This innovation became known as Standard Dial-up POP3 Service (SDPS). [5] To access these individual accounts, the username is appended with the hostname, taking the form of john@hostname or john+hostname.
Google Apps, in its own peculiar way, employs a similar methodology. [6]
Kerberized Post Office Protocol
Within the intricate tapestry of computing, local e-mail clients can utilize the Kerberized Post Office Protocol (KPOP). This application-layer Internet standard protocol allows for the retrieval of e-mail from remote servers over a TCP/IP connection. KPOP builds upon the foundation of POP3, but distinguishes itself by incorporating Kerberos security. It operates by default on TCP port number 1109, rather than the standard 110. One notable implementation of this protocol can be found within the Cyrus IMAP server .
Session Example
The following POP3 session, as illustrated in RFC 1939, offers a glimpse into its operational dialogue: [7]
S: <wait for connection on TCP port 110>
C:
For servers that eschew the optional APOP command, the client is expected to authenticate using the more traditional USER and PASS commands:
C: USER mrose S: +OK User accepted C: PASS tanstaaf S: +OK Pass accepted
Comparison with IMAP
The Internet Message Access Protocol (IMAP), a more contemporary contender, presents a stark contrast to POP. Here’s a breakdown of their fundamental differences:
Simplicity vs. Sophistication: POP is a simpler beast, making its implementation less of a headache. IMAP, on the other hand, is a more complex protocol, offering a richer feature set.
Message Handling: POP, in its default mode, is a one-way ticket for messages, moving them from the server to the local machine. While clients can be configured to leave messages behind, this is often an optional setting. IMAP, conversely, defaults to leaving messages on the server, synchronizing local copies for access. This allows for seamless management across multiple devices.
Folder Structure: POP treats the mailbox as a single, monolithic store. It has no inherent concept of folders, no way to organize messages beyond their retrieval and deletion. IMAP, however, embraces organization, allowing for the management of mailboxes as if they were local file systems, complete with folders.
Querying and State Management: An IMAP client can perform intricate queries, requesting specific headers, message bodies, or searching for messages based on defined criteria. Messages can be marked with various status flags (like ‘read’, ‘answered’, ‘deleted’) and remain in the repository until explicitly purged by the user, even across sessions. In essence, IMAP is built to treat remote mailboxes as if they were local. Users can choose to save messages locally, on the server, or be presented with both options, depending on the client and system architecture. POP, in contrast, offers a static snapshot of the mailbox’s state. It lacks any mechanism to reflect external changes during a session; a client must reconnect and re-authenticate for an updated view. IMAP, however, provides a dynamic, real-time view, actively pushing updates for external state changes, including newly arrived messages and modifications made by other concurrently connected clients.
Message Retrieval Granularity: POP, with its RETR command, retrieves an entire message. The TOP command, where supported, allows access to headers and a specified number of body lines. IMAP, however, grants clients the ability to retrieve individual MIME parts separately. This means you can fetch just the plain text version of an email without downloading attached files, or even select a single attachment from a multitude.
Message State Flags: IMAP supports server-side flags to track message status, such as whether a message has been read, replied to, forwarded, or deleted. POP, on the other hand, offers the UIDL command to associate unique identifiers with messages, but these identifiers are strings, not the rich status flags IMAP provides.
Message Identification: POP relies on the UIDL command for unique message identification, yielding strings of up to 70 ASCII characters. IMAP uses unique numerical identifiers, local to each folder, coupled with a folder-specific UIDVALIDITY number. These two identification methods are entirely unrelated unless a server implementation, supporting both protocols, deliberately constructs the POP3 UIDL string by combining the IMAP UID and UIDVALIDITY values.
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
- RFC 8314 – Cleartext Considered Obsolete: Use of Transport Layer Security (TLS) for Email Submission and Access