Summary

  • RFC 9585 standardises an untagged INPROGRESS notice for long-running IMAP commands. The notice can mean measurable progress, an unknown amount of work or merely that the server is keeping the connection alive.
  • Completion still arrives in the command’s tagged OK, NO or BAD response. Search results, copied state and other command outputs need their own receipts; PROGRESS and GOAL cannot stand in for them.

The screen says 999 of 1,000. An operator sees one unit left. An automation sees a threshold crossed. A customer sees a promise that the work is effectively done.

The server has made none of those statements.

In RFC 9585, 999 is a progress value inside an untagged IMAP OK response. The goal should be greater than progress, so the display may look nearly complete. But the goal may later change, progress may move backward, the command may end in failure, and the processed units may bear no relation to the number of useful results. The line is evidence of activity under a server-defined counting model. It is not a completion receipt.

That narrow distinction is the entire value of the standard. IMAP commands can take long enough for a client to wonder whether a connection has stalled. Before RFC 9585, a server could send prose such as “Still on it”, but software had no consistent way to parse the claim. The Standards Track extension, published in May 2024, creates the INPROGRESS capability and response code so a client can recognise progress notifications without pretending they say more than they do.

Capability is the first layer. A supporting server must advertise INPROGRESS in its CAPABILITY response. That advertisement means the server understands the extension and emits progress notifications. It does not promise a notice for every command. A command that finishes before the first suggested notification interval may produce none, and the extension allows notices for any command rather than requiring them for a fixed list.

Liveness is the second layer. The server may send INPROGRESS simply to stop a client timing out and terminating the connection. RFC 9585 recommends sending notices every 10 to 15 seconds when the server elects to use them. A bare notice contains no details at all. Its command tag, progress and goal are interpreted as NIL. It says, at most, that the server chose to send a keepalive-shaped status line.

Measured progress is a stronger but still bounded layer. The optional detail tuple contains CMD-TAG, PROGRESS and GOAL. Progress is a non-negative number of processed items. Goal is an optional positive number that progress is expected to reach after the command completes. When the work cannot be expressed as item counts, the RFC permits a percentage model with a goal of 100 and progress from 0 to 99.

The tuple is deliberately tolerant of incomplete knowledge. If progress is unavailable, both progress and goal are NIL. If progress is known but the total is not, goal is NIL. If the command tag is unavailable, or the original tag contains a closing square bracket, the tag becomes NIL too. With only one command in flight, that may still be useful. With several, the client may no longer know which operation the pulse belongs to.

Even a complete tuple is not a stable schedule. Progress should ordinarily rise and goal should ordinarily remain fixed, but a conforming client must handle the opposite. When goal changes or progress goes backward, RFC 9585 recommends interpreting the sequence as an earlier tranche having completed before the server discovered more long-running work. That is a recovery rule for the client. It is not a guarantee that the old denominator described the full job, or that the revised number predicts the finish time.

The protocol boundary becomes unmistakable in the response syntax. IMAP4rev2 uses untagged responses, prefixed with *, for data and status that do not complete a command. A completion result carries the same tag as the originating command. It is OK for success, NO for failure or BAD for a protocol error. RFC 9585 therefore requires INPROGRESS to appear inside an untagged OK and forbids it in a tagged response. Once the tagged response exists, the command is finished and a further progress notice would make no sense.

Activity can therefore precede any of the three outcomes. A series of plausible numbers does not reserve an eventual OK. It cannot make a later NO surprising in protocol terms, and it cannot authorize a client to commit dependent work as if success had already arrived.

Completion is not the same as result authority either. RFC 9585’s SEARCH example separates the artifacts. Two progress notices report that 454 and then 999 items have been processed against a goal of 1,000. An untagged SEARCH response later supplies the matching message identifiers. Only after that does the tagged OK close the command. The goal is not the match count. The progress value is not the result set. The final OK says the command succeeded; the SEARCH output says what it found.

The RFC makes this limit explicit: a client must not treat progress values as authoritative for another purpose, and must not use GOAL in place of proper SEARCH output to determine how many messages are in a folder. The same discipline applies to COPY. Processed units do not prove how many destination objects persisted, whether a retry duplicated work, whether a separate store is reconciled or whether a user-facing workflow may safely advance.

Absence is equally easy to misread. Until a server sends a notice, the client must assume progress zero and an unknown goal. A quick successful command may emit no progress line at all. A silent interval therefore does not prove that no work is happening, just as a stream of keepalives does not prove useful work is happening. The protocol gives the client a signal, not omniscience.

Security turns loose display logic into an implementation risk. A malicious server can send values designed to trigger arithmetic exceptions, impossible ratios or excessive allocation. RFC 9585 tells clients to disregard invalid cases such as zero or negative goals, extreme values and progress greater than goal. A robust client should also keep raw notices, reject ambiguous command binding when it matters, and treat goal revisions as events rather than silently repainting history.

The useful operational model is a small state machine. First, record whether the capability was advertised. Then bind every notice to a connection, authenticated session and command tag where possible. Keep the raw sequence of progress and goal values. Separately collect the command’s untagged output. Do not leave the executing state until the matching tagged completion response arrives. After success, reconcile any state that matters outside the protocol exchange.

That last step matters because a tagged OK is still a server’s protocol receipt, not proof of every business consequence. A successful COPY response may be enough for one client action under the IMAP contract. It is not automatically proof that an archival pipeline indexed the copy, a legal-hold system observed it, a replicated store converged or a customer notification was sent. Each additional claim adds another system and therefore another receipt.

RFC 9585 improves reality rather than disguising it. It makes long-running work more observable and lets clients avoid unnecessary disconnects. Its restraint is also architectural guidance: capability is not use; a keepalive is not measured progress; measured progress is not completion; completion is not result cardinality; and a protocol result is not every downstream effect.

The progress bar may move. The final authority remains elsewhere.

Sources