Summary

  • DELE did not remove a POP3 message. It marked one current-session number, made that number unavailable to later commands, and left RSET able to cancel the intent.
  • Only client-issued QUIT from TRANSACTION entered UPDATE. An abnormal disconnect or inactivity timeout bypassed UPDATE and therefore had to preserve the marked messages.
  • The boundary reduced loss after an interrupted download, but it was not an atomic commit. RFC 1939 allowed an UPDATE error to remove some or none of the marked set, while forbidding removal of anything unmarked.

A successful deletion that had not happened

POP3's smallest dangerous sentence was reassuringly plain: +OK message deleted. Read as ordinary English, it sounded final. Read in the protocol state machine, it was only the server's acceptance of a deletion mark.

The distinction was already present in RFC 1081, the 1988 specification of POP3. A client authenticated, the server opened the user's maildrop, and the session entered TRANSACTION. DELE 4 referred to the fourth position in that opened view. Once marked, that number could no longer be used by later POP3 commands. The bytes and storage object, however, remained. RSET could unmark every pending deletion.

Actual removal waited for UPDATE. The state was entered only when a client in TRANSACTION issued QUIT. The same four-letter command sent during AUTHORIZATION merely ended the unauthenticated session. One verb therefore had two endings because only one context contained a protected set of messages and pending destructive intent.

The positive line after DELE was real evidence, but evidence of a smaller fact: the server had recorded the mark in this open transaction. It did not prove disk reclamation, a durable tombstone, a backup mutation or even that a later UPDATE would remove every marked message.

The lock made the list temporarily coherent

Before entering TRANSACTION, the server acquired an exclusive-access lock on the maildrop where necessary. The purpose stated by the standards was narrow: prevent messages from being modified or removed before UPDATE. The server could then number the opened messages 1, 2, 3 and onward, and the client could use those positions for LIST, RETR and DELE without having the numbered set collapse underneath the conversation.

The lock did not make a message number a permanent identity. A later session could open a different set and assign different positions. Nor did it confer ownership of the maildrop on the client. Delivery and site policy existed outside this command sequence. The lock protected the meaning of destructive operands long enough for the server to know which currently opened entities the client had marked.

This was a useful allocation of state. The client knew whether it had safely stored a downloaded message. The server knew which maildrop entities existed and could be removed. POP3 did not require both parties to share one durable transaction log. It instead bounded a vulnerable interval with a lock and postponed destruction until the client deliberately closed it.

RFC 1225 in 1991 and RFC 1460 in 1993 preserved this design. The important history is continuity: mark, allow reset, remove at UPDATE, release the lock, report, close.

A broken connection was not a substitute for goodbye

The architecture became sharper in RFC 1725. It stated explicitly that a session ending for any reason other than a client-issued QUIT did not enter UPDATE and must not remove messages. Its inactivity timer followed the same rule: after at least ten minutes under the permitted policy, an autologout closed the connection without a response and without deletion.

This was not ceremonial politeness. POP3 was designed for intermittently connected machines retrieving mail from a server. The server could finish transmitting a message while the client still had not safely committed it to local storage. Power might fail during a filesystem write. A link could die after the last network byte but before an application completed its own work. If TCP disappearance counted as consent to delete, transport failure could turn an incomplete local copy into permanent loss.

The server therefore required a protocol act, not merely absence. QUIT was the client's declaration that the transaction could cross into its destructive phase. An EOF, reset, timeout or vanished process was deliberately weaker evidence.

That rule also explains why the opening message returns. The server's +OK after DELE was not withdrawn; the mark was valid while TRANSACTION lasted. The abnormal ending discarded the pending path to UPDATE. On reconnect, a new maildrop view began with no deletion marks.

UPDATE was a boundary, not an atomicity promise

It is tempting to call QUIT a commit. The analogy is useful only if its limit remains visible. RFC 1939, published in 1996 as STD 53, made the limitation explicit.

In UPDATE, the server removes messages marked as deleted and reports the result. A resource shortage can leave some or none of those messages removed. The specification permits -ERR some deleted messages not removed. Whether removal succeeds or fails, the server releases the exclusive lock and closes the TCP connection. It may never remove a message that was not marked.

This is not all-or-nothing database commitment. It is a bounded destructive attempt. The marked set limits what may be touched; the final reply distinguishes reported success from a known problem; the next session supplies the current state. A batch of three marks can produce two removals and one survivor.

The ordering creates another ambiguity the protocol cannot wish away. A server may perform removal and then lose the connection before the client's copy of the final reply arrives. From the client side, silence does not say whether UPDATE was never entered, failed before any removal, succeeded partially or succeeded fully. Retrying DELE 4 blindly is unsafe because message number 4 in the new session may name another entity.

Recovery needs reconciliation. UIDL, where supported, can help correlate surviving maildrop entities across sessions, but it does not prove why a missing item disappeared. Another client or site retention policy may also remove mail. The correct question after an ambiguous farewell is not “did QUIT probably work?” but “which expected entities are present now, and what independent local copies are durable?”

Policy could enlarge the marked set without moving the gate

RFC 2449 later added capability discovery and the EXPIRE signal. EXPIRE 0 says that leaving mail on the server is not permitted. When the session enters UPDATE, the server may assume an implicit DELE for each message downloaded with RETR.

That policy is easy to overread. Retrieval still does not cause immediate deletion. The implicit marks take effect at UPDATE, so abnormal termination retains the same protection. EXPIRE changes how the set of authorized removals is constructed; it does not move irreversible authority into RETR or TCP closure.

Other retention policies remain distinct. A site can remove old mail under its announced rules, which means later absence is not a causal receipt for one client's QUIT. Capability, client intent, server attempt and observed future state are separate records.

The IANA service registry still records pop3 at port 110. That preserves a standardized rendezvous name. It does not measure current deployment or prove that any server implements the failure boundary correctly.

POP3's deletion design was modest enough to remain instructive. It did not promise a distributed transaction. It decided which evidence could authorize irreversibility. Marking was reversible. Abnormal silence was not consent. Goodbye opened the destructive phase. Even then, the result could be partial and had to be observed or reconciled.

The protocol's most important deletion reply was therefore not the first +OK. It was the distinction between what had been requested, what the server attempted, what the client learned and what the next maildrop still contained.

Sources