Summary

  • POP3 assigned a message number only after opening the current maildrop. An earlier LAST command remembered one highest-number-accessed frontier, but it could not give a disconnected client durable, per-message identity when the set changed.
  • RFC 1725 removed LAST and added optional UIDL. The unique-id persisted across sessions within one maildrop, allowing the client to keep its own seen-state, while RFC 1939 deliberately stopped short of promising a worldwide identifier, one identifier per physical copy or indefinite server retention.

On Monday a POP3 client opens a maildrop with three messages. The one it downloads but leaves on the server is number 2. Before Tuesday's connection, message 1 is removed. When the maildrop opens again, the retained message is now number 1.

Nothing is wrong with either number. POP3 assigns positions after it has opened the current maildrop: first message 1, second message 2, and so on. A number is an efficient operand for RETR, DELE or LIST during that transaction. It is not a durable name for the entity across two different views of the mailbox.

That distinction became important because POP3 served machines that could not remain continuously connected. Its founding premise was a smaller workstation or personal computer that lacked the resources or connectivity to run a resident mail transport system. A server held mail in a maildrop; the client connected dynamically to retrieve it. Normally the messages were downloaded and then deleted.

Once clients offered “leave mail on server,” the simple protocol acquired a memory problem. On the next connection, how could a client avoid downloading every retained message again? The server could remain simple if it supplied a stable token and let the client remember which tokens it had processed. But a session position and a single “highest number seen” could not safely carry that responsibility.

The UIDL command was the narrow answer. It paired the current message number with an identifier intended to survive reconnection.

LAST remembered a frontier, not a set

RFC 1460, published in June 1993, called the session positions message IDs. After the server parsed the maildrop, it numbered the first message 1, the second 2 and the nth message n. The terminology could sound durable, but the mechanism was positional.

That version also had a LAST command. The server returned the highest message number accessed in previous transactions. A client could infer that any messages with higher numbers had not yet been accessed. Retrieving or deleting a higher number moved the frontier; RSET returned it to zero.

The model compressed history into one integer. It worked only when “already handled” formed a clean prefix. It could not describe a hole in which messages 1 and 3 had been stored locally but 2 had not. It did not distinguish two clients with different local histories. A reset erased the frontier. Removal of lower messages could change the meaning of later positions.

A high-water mark answers “how far did some access progress under this ordering?” It does not answer “is this particular entity the one this client has already received?”

RFC 1725 made the change unusually visible in its revision list. It removed LAST and added optional UIDL. The text did not claim a single causal chain, but the paired changes replaced one coarse server-held progress marker with a per-message token from which a client could build its own state.

UIDL joined a temporary position to a persistent token

During the transaction state, UIDL can take a message number or no argument. For one message, the server returns the current number and its unique-id. Without an argument, it returns a multiline listing for each message not marked deleted.

The two columns have different lives. The number tells the client how to address the message in this open maildrop. The unique-id tells it whether the server regards the entity as the one identified in a previous session.

RFC 1939 defines the token as an arbitrary server-determined string of one to 70 printable characters. It must uniquely identify a message within a maildrop and persist across sessions. Persistence is required even if the earlier session ended without entering the UPDATE state.

That abnormal-ending clause matters. A client may have received and stored a message before the connection breaks. Because the session did not complete normally, the server must not remove messages marked for deletion. On reconnect, the same message can still be present. If its UID changed merely because the earlier transaction did not reach UPDATE, the client could download a duplicate or make a destructive decision using broken memory.

The server should not reuse a unique-id in that maildrop for as long as the entity using it exists. Reuse would make a new or different entity impersonate an old entry in the client's local ledger.

UIDL therefore created a division of work. The server assigned and preserved a scoped identity. The client stored the policy-specific fact that it had retrieved, displayed, archived or otherwise handled that identity. POP3 did not need to become a full remote mailbox manager to support more careful retrieval.

“Unique” was deliberately narrower than one stored copy

The specification does not turn UIDL into a global message identity. The token is unique within a maildrop. The same string in another account, server or maildrop has no defined relationship. It is not the Internet message header Message-ID, proof of sender identity, proof of delivery or an integrity signature.

Nor is it necessarily one-to-one with physical copies. RFC 1939 says servers generally should store arbitrarily assigned IDs, but explicitly permits calculating them as a hash of the message. Clients must handle a situation in which two identical copies in one maildrop have the same unique-id.

That exception places multiplicity outside the token. If a listing contains the same UID twice at two current numbers, the client cannot silently collapse them into one row merely because its cache uses the UID as a key. The identifier answers a bounded recognition question; it may not answer how many indistinguishable copies the server currently stores.

This is an important evidence discipline. Protocol names often tempt implementations to upgrade scope: unique becomes globally unique, persistent becomes permanent, identity becomes authenticity. UIDL's own text blocks each escalation. Its authority is enough for cross-session recognition inside one maildrop, subject to a specified collision case.

Persistence did not promise retention

An identifier can persist for an entity while the entity exists without requiring the entity to exist forever. RFC 1939 warns that leave-on-server use can accumulate hundreds or thousands of already-read messages. Operators may impose quotas or local retention policies and can delete messages outside the POP3 command flow, provided users are informed.

A client therefore cannot treat an old UID as a storage guarantee. If it no longer appears, the server may have applied policy, another client may have deleted the message, or the listing may have failed. The client needs evidence about the current session before converting absence into a conclusion.

RFC 2449 later introduced the POP3 extension mechanism because optional commands and behavior had previously been discovered by probing, if at all. A UIDL line in the CAPA response tells a client that UIDL is supported. It does not certify the quality of the server's UID assignments or prove that the server will retain any given message.

The same RFC defined EXPIRE to advertise the minimum retention behavior a site may apply: a number of days, zero, or NEVER. Even that capability intentionally cannot name an exact expiry time for a particular message. A site may start its clock on arrival, first listing, retrieval or another event.

Capability, identity and retention were three separate facts. UIDL said how to recognize an entity while served. CAPA said the command was available. EXPIRE bounded site policy. None could substitute for the others.

A simple server moved durable memory to the edge

RFC 1939 strongly encouraged the optional commands instead of augmented listing formats and stated the design philosophy plainly: put intelligence in the POP3 client, not the server. UIDL followed that allocation.

The advantage was architectural economy. The server did not need a synchronized read/unread model for every device. Different clients could keep different local ledgers. A transient connection could resume useful work by comparing a small listing rather than retrieving every body.

The cost was transferred responsibility. If a client loses its UID database, it may redownload retained mail. If a server migration regenerates identifiers, every client may interpret old content as new. If a client assumes a UID is a content identity, identical copies may be missed. If it treats a missing UID as proof of successful local storage, retention policy can turn a bookkeeping error into permanent loss.

The historical value of UIDL was not that it solved mailbox synchronization. It drew a narrow, workable line between two clocks. The server knew which entities still occupied the current maildrop. The intermittently connected client knew which of those entities it had seen before.

The number lasted for the session. The identifier lasted long enough for memory to cross the disconnection.

Sources