Summary

  • In POP3, DELE marks a message inside the locked TRANSACTION state; it does not remove the message from the maildrop. RSET can remove every mark before the session commits to leaving.
  • Only a client-issued QUIT from TRANSACTION enters UPDATE. A broken connection must not delete messages, but UPDATE is not atomic: an error may leave some, all or none of the marked messages removed.

A positive reply could still mean “not yet”

Suppose a home computer dials into a mail server, downloads three messages and asks that the originals be deleted. The server answers positively after each request. Before the computer saves the last message safely to disk, the telephone line drops.

There are two plausible interpretations of what just happened. The server could treat each deletion request as final the moment it was accepted. The user would reconnect to discover that the only remaining copy of a message vanished during the same failure that prevented local storage. Or the server could retain every original unless the client reached an agreed ending.

POP3 chose the second. Its DELE command did not erase a message. It marked the message as deleted for the current session. The user agent could still send RSET and withdraw the entire set of marks. Only QUIT, issued while the session was in its working state, moved the protocol into UPDATE and caused the server to attempt physical removal.

This sounds like a small command-ordering rule. It was really an allocation of uncertainty. The server could know that a client had requested a download; it could not know that the client had durably stored the result. A normal goodbye became the client's limited declaration that the conversation had completed well enough for the server to act on the pending intentions.

The idea began before POP3 had its name

The first Post Office Protocol, RFC 918 in October 1984, already avoided tying deletion to the start of retrieval. A client began either a read-only transaction with RETR or a read-and-delete transaction with RDEL. It then received the data and sent RCVD. Only after this acknowledgment did the server attempt deletion. RSET aborted an active transaction and required the mailbox to be closed and unlocked correctly.

RFC 937, the POP2 revision of February 1985, moved the idea closer to the later design. Its ACKD command confirmed receipt and marked the current message for deletion. The specification emphasized that the actual mailbox change waited until the mailbox was released at the end of the session or when another mailbox was selected.

These early protocols did not provide the exact POP3 machine that survived. They did establish a durable concern: retrieving bytes and surrendering the server copy were related events, but they should not be the same instant. An intermittent network made the gap between them operationally meaningful.

POP3 turned the gap into three states

RFC 1081, published in November 1988, defined POP3 through AUTHORIZATION, TRANSACTION and UPDATE. After authentication, the server acquired the user's maildrop and an exclusive-access lock. Inside TRANSACTION, the client listed, retrieved and marked messages. On QUIT, the session entered UPDATE, the server removed marked messages, released the lock and closed the connection.

The three states kept different kinds of authority apart. AUTHORIZATION decided who could reach the maildrop. TRANSACTION provided a stable, exclusive view in which deletion marks accumulated. UPDATE performed the irreversible work and released the resource. Sending QUIT before authentication merely ended the session; it did not enter UPDATE because there was no authenticated transaction to commit.

Message numbers reinforced the temporary nature of the working view. They were assigned when the maildrop opened. Once a message was marked by DELE, later commands in that transaction could no longer refer to its number successfully, even though the underlying message had not yet been removed. To the session it behaved as deleted; to storage it remained recoverable until the boundary.

RSET made intention visibly reversible

RSET was not an emergency command outside the protocol. It was one of the required minimal POP3 commands. In TRANSACTION, it removed all deletion marks and returned a positive response. The client did not have to remember which individual DELE requests to invert, and the server did not have to reconstruct the user's motive.

That matters because a session can change its mind for mundane reasons. A user may notice that a local folder is full. A client may fail to parse one message. A “leave mail on server” preference may change its decision after retrieval. Before QUIT, the marks remain proposals inside an exclusive conversation.

The lock gave those proposals a stable context. RFC 1725 later clarified that it exists, as necessary, to prevent messages being modified or removed before UPDATE. A second client should not rewrite the ground beneath the first client's numbered view while the first is deciding what to keep.

This was not a rich transaction system. There was no per-message undo after UPDATE, no distributed consensus, and no promise that a crashed server could replay a journal. POP3's economy came from defining one narrow reversible interval well.

A broken conversation had no authority to delete

The early POP3 revisions described the state progression but left broken connections less explicit. RFC 1725's overview lists “clarified behavior on broken connection” among its changes. Its rule is direct: if a session ends for any reason other than a client-issued QUIT, it does not enter UPDATE and must not remove messages. Even an inactivity autologout closes the TCP connection without deletion.

RFC 1939, issued in May 1996 as STD 53, preserved the rule. Its operational explanation supplies the human reason. A server implementing download-and-delete behavior should not remove messages after abnormal termination because the client may not have successfully received or stored them.

The distinction is careful. The protocol does not prove that a normal QUIT means every byte is safely backed up. Nor does it prove that a broken connection means nothing arrived. It chooses a conservative signal available to both parties. Completed conversation permits the pending action; incomplete conversation withholds permission.

This converts silence into safety. TCP disappearance is not interpreted as consent. A timeout is not a substitute for goodbye. The absence of the final command leaves server copies intact, even if the client had already issued several successful DELE commands.

UPDATE was a boundary, not an atomic miracle

It is tempting to call QUIT a commit and stop there. RFC 1939 makes the analogy useful only up to a point. In UPDATE, the server tries to remove every message marked as deleted. If a resource shortage or another error occurs, some, all or none of those messages may be removed. The server can reply that some deleted messages were not removed, then it releases the lock and closes the connection regardless.

One invariant remains absolute: it may never remove an unmarked message. But the set of marked messages is not guaranteed to change storage all at once. A client that times out while waiting for the final reply also cannot infer from the closed connection exactly which removals occurred.

The protocol therefore offers a commit gate, not atomic commit semantics. Before the gate, deletion marks are reversible and abnormal termination preserves all messages. After the gate opens, irreversible work may be partially successful. This is a more honest design than importing guarantees the simple maildrop protocol and its varied storage backends could not reliably provide.

The history also explains why “delete succeeded” is a hazardous rendering of the response to DELE. At that moment the server has accepted the mark. It has not yet reported the outcome of removal.

Later policy still entered through UPDATE

POP3 was designed primarily to download mail and normally delete it, not to provide extensive manipulation on the server. Over time, users and clients increasingly left messages in the maildrop. Extensions had to describe retention policy without breaking the state boundary.

RFC 2449, the 1998 POP3 extension mechanism, defined the EXPIRE capability. EXPIRE NEVER says the server does not delete messages under that policy; EXPIRE 0 says the client may not leave them on the server. Even then, the server may treat a successfully retrieved message as implicitly marked for deletion when the session enters UPDATE. The policy changes which messages are marked, not the meaning of abnormal termination.

That extension reveals the strength of a small state machine. New retention behavior could attach to the existing effect boundary. It did not need every retrieval to become instantly destructive.

The goodbye protected custody, not etiquette

Protocol endings are often dismissed as ceremonial. POP3's ending carried authority. The client controlled the moment at which its reversible requests became a server-side removal attempt. The server controlled whether each attempt succeeded. The transport could interrupt either party, but it could not manufacture the missing authorization to enter UPDATE.

The design placed the cost of ambiguity on duplication rather than loss. After a broken session, a client might retrieve the same message again. Duplicate mail is inconvenient and can require local reconciliation. A missing only copy is harder to repair. POP3 preferred the reversible error.

That priority belongs to the Internet's history of disconnected machines: dial-up links, small disks, brief sessions and clients that could not remain continuously attached to a server. Yet the lesson is not nostalgic. Any system that accepts destructive intent over an unreliable channel needs to distinguish “request recorded” from “effect completed,” and it needs to state what a vanished connection means.

POP3's answer was modest. Mark first. Permit reset. Require an explicit crossing. Preserve on abnormal exit. Admit partial failure after the crossing. The deletion became real only at goodbye—and even then, the protocol refused to pretend reality was always all or nothing.

Sources and limits

The early acknowledgment and deferred-change lineage comes from RFC 918 and RFC 937. The first POP3 state machine is in RFC 1081, with standards-track continuity in RFC 1225 and RFC 1460. The explicit broken-connection rule appears in RFC 1725; RFC 1939 supplies the current normative behavior, partial-failure rule and custody rationale. RFC 2449 supplies the later EXPIRE interaction. These RFCs do not establish current deployment share, the crash-recovery behavior of any implementation, or atomic and exactly-once deletion.