Summary

  • IMAP's CLOSE command did two jobs: it returned a connection from Selected to Authenticated state and permanently removed every message carrying the \Deleted flag. It sent no per-message EXPUNGE responses while doing so.
  • RFC 3691 added UNSELECT, an explicit way to release selected-mailbox resources without expunging. The small extension made authority legible: leaving a working context and committing destructive work became separate choices.

Imagine a mail program that has finished looking at the inbox but intends to keep its authenticated server connection. It no longer needs the server to maintain the selected-mailbox view. It does not intend to approve any deletion. Some messages, however, already carry \Deleted: perhaps this client marked them earlier, perhaps another operation did, or perhaps the user has not yet decided whether to commit the cleanup.

In early IMAP the command whose name sounded like the natural exit was CLOSE. Its wire meaning was stronger than its name. CLOSE permanently removed every message with \Deleted set, then returned the connection from Selected state to Authenticated state. The client received a tagged completion, but no individual EXPUNGE responses naming the changing sequence positions.

The client wanted to surrender a view. The command also exercised authority over stored mail.

That coupling was not an accidental implementation detail. It appeared in the protocol definition. It also had a performance rationale: when many messages were ready for removal, a client leaving the mailbox often did not need a stream of sequence-number adjustments it would immediately discard. Yet efficiency made the semantic boundary easier to miss. The fewer messages the server sent, the less the command resembled a visible deletion sequence, even though its durable effect was exactly that.

RFC 3691, published in 2004, supplied the missing verb. UNSELECT performed the state transition and resource release without permanent removal. Its historical importance lies less in its size than in the distinction it made explicit. A state machine could arrive at the same next state through two commands while preserving different mandates over data.

A selected mailbox was a protocol state, not merely a screen

IMAP separated the connection into states. After authentication, a client could list or choose mailboxes, but commands that acted on messages required a mailbox to be selected. Selection established a working context: the server could report message counts and flags, and the client could search, fetch, store, copy or remove within that mailbox.

Leaving that context did not necessarily mean ending the TCP connection or logging out. A desktop client could move from Inbox to Drafts. A synchronizer could release a costly selected view and remain authenticated for later work. A server could therefore recover resources associated with selection while keeping the account session alive.

The state diagram gave CLOSE a clear place. A successful command moved the connection from Selected to Authenticated. But the command's data semantics reached beyond that arrow: all messages already marked \Deleted in the selected mailbox were permanently removed.

That flag deserves precision. Setting \Deleted did not by itself erase the message. It marked the message for later removal. An expunge operation crossed the irreversible boundary. This separation allowed clients to mark several messages, inspect or revise the selection, then commit removal. It also meant that the authority to set a flag and the authority to trigger expunge could arise at different moments.

When CLOSE performed both exit and expunge, the later, quiet state transition became the moment that committed every outstanding mark.

Silence made CLOSE faster, not harmless

The ordinary EXPUNGE command permanently removed all \Deleted messages and sent an untagged EXPUNGE response for each removal. Those responses used message sequence numbers. Because sequence numbers are positions in the currently selected mailbox, removing one message shifts the numbers of later messages. A series of responses could therefore describe several removals with changing positions.

CLOSE did not send those untagged responses. The standards explained the economy: if the client was leaving the mailbox, it would probably ignore the positional updates. Omitting them could be considerably faster when many messages were deleted.

But the absence of a response list did not change the operation. A tagged OK meant the close completed; it did not mean the command was a non-mutating resource release. Nor did it provide a per-message inventory that a client could use afterward to reconstruct exactly what disappeared.

Read-only selection added another subtle boundary. If a mailbox had been opened with EXAMINE, or was otherwise selected read-only, CLOSE removed no messages and returned no error merely because the removal did not occur. The same command token could therefore have different durable effects depending on the selected mode.

An operator looking only at command success would miss the important evidence: which mailbox was selected, whether it was writable, which messages carried \Deleted, and whether the chosen exit path included expunge.

The protocol already contained indirect exits

IMAP4rev1 did not force every departure through CLOSE. A client could issue SELECT or EXAMINE for another mailbox, or LOGOUT, without first closing the current mailbox. Those commands implicitly ended the current selection without doing an expunge.

That rule protected a useful distinction, but it did not provide a clean command for a client that wanted only to stop selecting a mailbox and remain authenticated. RFC 3691 recorded two workarounds. A client could try to select a nonexistent mailbox, causing selection to fail and returning to Authenticated state. Or it could reselect the same mailbox using EXAMINE, changing the manner in which the context was held.

Both techniques used another operation's side effect to obtain the desired state transition. The first intentionally asked for something that should fail. Its meaning depended on failure semantics. The second opened a read-only view merely to escape a read-write one. Neither said plainly, “release this selected context and do nothing to the messages.”

Workarounds of this kind are operationally expensive even when they are interoperable. Logs record a failed selection rather than an intended exit. Error counters mix planned control flow with genuine mistakes. Server implementations must preserve edge behavior because clients depend on it. Future maintainers can easily “repair” the apparently unnecessary failure and break the hidden exit path.

The missing primitive was not a new mailbox feature. It was an honest name for an existing intention.

UNSELECT gave the intention its own wire act

RFC 3691 defined UNSELECT with no arguments. A successful command freed server resources associated with the selected mailbox and returned the connection to Authenticated state. It performed the same state-management actions as CLOSE, except that it permanently removed no messages.

For IMAP4rev1 servers, support was advertised with the UNSELECT capability. That mattered because an unknown command was not a safe substitute for a supported non-expunging transition. A client first learned whether the peer understood the verb, then chose it. Capability negotiation kept the new meaning explicit rather than asking implementations to guess from syntax or version folklore.

The response remained intentionally small: no arguments, no command-specific untagged responses, and a tagged completion. The safety property did not come from a verbose receipt. It came from the definition of the command. The client could know before sending it that this verb lacked the permanent-removal mandate carried by CLOSE.

The distinction also sharpened failure analysis. If UNSELECT succeeded, the selected context ended without expunge. If it failed, the client could not silently pretend that state had been released. If a client instead chose CLOSE, it had to treat permanent removal as part of the intended operation, not as cleanup performed by the server behind the command.

Two commands could reach one state without being equivalent

State diagrams are powerful because they compress behavior. They can also conceal effects that are not visible in the destination node. Both CLOSE and UNSELECT move a normal read-write session from Selected to Authenticated. Looking only at the before-and-after state would make them appear interchangeable.

They are not. One transition may destroy stored messages; the other must not. The destination state describes what commands are legal next. It does not fully describe what happened to data along the edge.

This is a recurring problem in distributed systems. A database connection may be closed with either commit or rollback. A file handle may be released after a flush or after discarding a buffer. A lease may end by clean surrender or by expiry. If monitoring records only “resource closed,” it erases the decision that determined the durable result.

IMAP's paired verbs show a better model. Record the state transition, the mutation decision and the evidence separately. selected_state_left=true does not imply deleted_messages_committed=true. A server resource can be freed even when the data decision remains deliberately unresolved.

The extension did not undo earlier choices

UNSELECT did not clear the \Deleted flag. It did not restore messages that another expunge had already removed. It did not identify who set a flag, reserve a future decision, or make concurrent mailbox access transactional. It simply refused to convert outstanding deletion marks into permanent removal while leaving the selected state.

That limit matters. Suppose a client marks messages, uses UNSELECT, and later selects the mailbox again. The marks may still exist. A later EXPUNGE, CLOSE or targeted operation can still remove the messages. The safe exit preserves the decision point; it does not decide in favor of retention forever.

Nor did capability negotiation authenticate the operator or prove access rights. Authentication and authorization remained separate. A server that advertised UNSELECT promised command semantics, not the truth of a user interface or the completeness of an activity log.

The feature was narrow enough to be dependable because it did not claim more.

IMAP4rev2 made the distinction ordinary

RFC 9051 incorporated UNSELECT into IMAP4rev2's selected-state command set. Its state model lists both successful CLOSE and successful UNSELECT as routes back to Authenticated state. Their command definitions preserve the decisive difference: CLOSE permanently removes all \Deleted messages in a writable selected mailbox; UNSELECT removes none.

The evolution from extension capability to base command is a useful record of protocol repair. The original grammar had enough expressive power to escape without expunge through indirect means. What it lacked was a first-class operation whose name, precondition and result matched the client's intention. Standardizing that operation reduced dependence on error paths and made destructive authority reviewable at the call site.

This was not a wholesale redesign of IMAP. It was a correction at a semantic seam. The server still owned mailbox state and resource management. The client still chose commands. The change made the boundary between those roles less surprising: requesting resource release no longer had to imply permission to make every outstanding delete mark final.

Sources