Summary

  • IMAP allows a server to return requested search information while refusing the separate request to keep those results updated. A successful completion response does not erase that refusal.
  • A small visible result window does not necessarily mean a small continuing workload. Update scope, result storage and notification handling have different resource costs.
  • The useful operating promise is not simply that a search worked. It is that the client knows whether its view remains subscribed, when that arrangement ends and what it must do after a gap.

A finance team opens a filtered mailbox view showing messages that still require an answer. The first screen looks right. A count appears, the selected messages are available, and the query completes without a fatal error. The team leaves the view open while new messages arrive and colleagues change flags elsewhere.

Whether that screen should now be described as live is a separate question. The server may have provided the initial search result while declining the additional work of updating it. If the application notices only the command's successful ending, an economical server decision can become an undisclosed product downgrade.

This is an illustrative workflow, not a reported incident. Its value is that it locates the mistake before any debate about performance. A truthful initial result has been promoted into a claim about future observation. The protocol does not require that promotion.

The July 2008 RFC 5267, Contexts for IMAP4, provides the concrete boundary. A client may ask for continuing updates when it searches or sorts a mailbox. A server may refuse that part of the request, for example because an internal limit on update contexts has been reached. It sends an untagged refusal carrying NOUPDATE and the original command's tag. Other requested return options must still be honored. The command can therefore finish successfully while the future update service has not been accepted.

This is neither an impossible response nor a protocol excuse to return arbitrary data. It is a deliberately divided result: answer the query, but decline its proposed continuing obligation. The application has to preserve both parts.

A result has an acquisition cost and a carrying cost

An ordinary query asks the server to discover something about the mailbox. An updating query also asks it to remember enough of the request to recognize relevant changes later and communicate their effects. Those costs need not be incurred in the same place or at the same moment.

A client looking at a handful of rows may not see that distinction. Its interface can make the continuing work appear negligible: the list already exists, so why would keeping it current be a different service? Yet the server must account for the search criteria, relevant mailbox changes and the state needed to maintain the requested order. A sorted view can be more expensive than an unsorted one.

RFC 5267 recognizes that asymmetry without prescribing a price list. A server must support at least one updating context per client and should support more. Refusing updates for a SORT request does not imply that a SEARCH context must also be refused. The document points to unsorted search or cancellation of another context as possible client responses.

That minimum is not a promise of unlimited saved views, a byte allowance per view or a particular commercial service level. It is a protocol floor. Nor does the refusal justify silently changing the user's chosen sort order. If an application uses an unsorted alternative, it has changed what the user is looking at and should make that choice intelligible.

The economically useful question is what each continuing view costs and what user work it supports. Counting completed queries alone misses the obligation that begins after completion.

Three controls that are easy to merge on screen

The names CONTEXT, UPDATE and PARTIAL can suggest a single feature. They do different jobs.

CONTEXT is a hint that the client is likely to reuse the search criteria. The server may ignore it or use it to maintain an index or cached result. It does not create a frozen snapshot. A client does not have to issue that hint before requesting UPDATE.

UPDATE requests changes to the result set. Those changes are carried as additions and removals. Asking for an initial count does not turn the stream into a series of replacement counts. A client can maintain a count from membership changes, but that is work performed by the client, not a promise that every update repeats the initial scalar.

PARTIAL limits which part of the result is returned. It does not limit the update stream to the rows currently visible. A narrow viewport can still subscribe to changes across the entire matching set. Moving most rows off screen is therefore not equivalent to relinquishing the server's continuing work.

The 2023 RFC 9394, IMAP PARTIAL Extension for Paged SEARCH and FETCH, extends the earlier partial-result mechanism and explicitly retains that full-set update scope. It adds result windows counted from the end and a modifier for UID FETCH. Its PARTIAL capability is not interchangeable with CONTEXT=SEARCH. Capability checks remain necessary when combining features.

The same document supplies another useful warning about small outputs. Under its specified combinations, adding COUNT alongside SAVE and PARTIAL makes the saved search result encompass all matches, even though only a partial result is returned. The number of rows crossing the connection does not by itself describe the scope of the state being retained. This does not establish that every implementation allocates memory in the same way; it establishes that the semantic set and the displayed window are different.

Refusal belongs to a particular request

The tag in NOUPDATE is important because more than one command may be relevant on a connection. The application needs to associate the refused update request with the view whose future freshness it was about to promise.

The refusal is made while processing that request. It should not be generalized into a claim that every previously admitted update context was canceled, or that the server has stopped all notifications. Conversely, the command's final success should not overwrite a refusal already received for its UPDATE option.

An active updating search also constrains tag reuse. RFC 5267 requires rejection when a client tries to create another updating search with a tag already used by an existing updating command. The tag is doing continuing correlation work after the original query has finished.

This is not a durable business identifier, an authentication credential or a mailbox identity. Its value is narrower and more immediate: it keeps a request's later additions, removals and admission result attached to the right conversation. A product that discards this relationship when the initial query ends can lose precisely the information needed to label the view honestly.

A changing list is not an event archive

Once updates are admitted, their order matters. Clients must process additions and removals in the order received, including multiple data items inside a single response. Servers must construct them so that the requested result ordering is maintained.

Message sequence numbers add another dependency. An addition resulting from newly delivered or appended messages must follow the mailbox's EXISTS notification when sequence numbers are used. A removal resulting from expunging messages must precede the corresponding EXPUNGE notification. Otherwise the numbers can cease to refer to the messages the update intends.

These are rules for maintaining a result, not evidence that the stream records every business event in a globally comparable order. A list of unread messages, for example, answers a current selection question. It does not automatically preserve a history of who regarded each message as handled, what decision followed or what happened while the client was disconnected.

Notifications should be delivered in a timely manner, but RFC 5267 does not attach a universal number of milliseconds to that expectation. An application that markets a bounded freshness interval needs additional operational evidence and a policy for the period in which that interval cannot be maintained.

The continuing arrangement also has an end. Leaving the selected mailbox ends its updates. CANCELUPDATE names the original command tags whose updates should stop; the server may release associated resources. Neither cancellation nor recreating the context retrieves every intervening historical transition. Recreating a context can restore an adequate current view without restoring a lost history.

Caching does not buy permission to serve old answers

The server can cache search results whether or not the client supplied CONTEXT. But the protocol requires the same observable behavior with or without that internal optimization. A cache must be maintained as the mailbox changes or discarded when it becomes unsuitable.

This is a useful limit on an otherwise legitimate engineering choice. Keeping a result in memory is not the same as promising a snapshot to the client. Evicting it is not the same as canceling the meaning of the next search. The optimization must remain subordinate to the result semantics.

The implementation discussion in RFC 5267 explains why the cost cannot be reduced to a single memory counter. Some unsorted update processing can compare old and new message flags against stored search criteria. A partial search may rerun the criteria, skip early matches and stop after finding the requested window. Sorted contexts are more likely to need retained results. Handling expunged messages can also require knowledge that is no longer available after deletion.

These are implementation strategies, not measurements of a particular server. They explain why two systems may meet the same observable contract with different memory and processing costs. They also explain why deleting an internal result cache does not necessarily eliminate the cost of a continuing search.

Later extensions did not make every notification interchangeable

The 2009 RFC 5465, The IMAP NOTIFY Extension, adds broader controls over unsolicited notifications. When combined with the relevant context capability, it also lets an UPDATE request ask for FETCH attributes when new mail enters the result set.

Its resource refusal has different forms. A prohibitively expensive NOTIFY request may be rejected initially. Later, a server unable or unwilling to supply the requested volume may disable notifications with an untagged NOTIFICATIONOVERFLOW response and behave as if NOTIFY NONE had been received. These are not interchangeable with the command-tagged NOUPDATE decision in RFC 5267. This report does not infer that one signal cancels every context established through another feature.

The RFC 5465 errata record also shows why a successful initial exchange cannot settle all questions of observation. Verified technical erratum 2318 corrects an example that checked mailbox status before arranging notifications. Reversing that order closes an interval in which a change could otherwise be missed. The lesson concerns the handover between an initial observation and continuing coverage, not proof of a current vendor failure.

Another entry requires restraint. Technical erratum 4833 remains Reported and identifies conflicting requirements for the relative order of FETCH and ESEARCH in two sections. It does not provide a settled corrected sequence. Its submitter's reference to deployed behavior is historical testimony, not a contemporary interoperability census. The verified editorial entries correct a typo, example parentheses and a section reference; they do not resolve that technical conflict.

At research time, the RFC 5267 errata search and the RFC 9394 errata search returned no matching records. That is a statement about those records, not an assurance that implementations have no defects.

The promise must survive contact with the budget

Continuing updates are useful precisely because they avoid making every client repeatedly rediscover the same facts. But an authenticated client can still create enough contexts to impose a substantial burden. RFC 5267 discusses limits, implementation choices and logging as possible responses to that risk.

A refusal is therefore not automatically evidence of poor service. It can be a necessary way to keep resource consumption within a feasible boundary. The failure appears when the refusal is converted into a false claim of continuing coverage, or when the advertised product depends on an obligation that nobody has agreed to fund.

Lu Heng's essay on the agency problem offers a structural lens: authority and the consequences of exercising it should not be separated. Here the application can promise freshness, the server can admit ongoing work, and the user can bear the cost of acting on an old view. Those powers and consequences meet at the interface, even if their budgets sit in different teams.

His account of BTW's purpose also argues for describing structures rather than inventing villains. The standards do not establish that developers conceal refusals, that a vendor is underprovisioned or that a particular customer has lost information. No mail account or implementation was tested for this report.

What they do establish is a more demanding definition of a successful product: it should know the difference between having obtained an answer and having secured the work required to keep that answer useful.