Summary

  • Original IMAP literals were count-framed strings embedded in a command. A client declared {n}, received a + continuation, and only then sent the next n octets and any remaining command syntax.
  • RFC 2088's LITERAL+ changed the marker to {n+} and removed that continuation round trip. The latency saving also meant an unwilling server might have to drain already-authorized bytes or close the connection.
  • RFC 7888's LITERAL- kept the same wire marker but limited unsolicited literals to 4096 octets. APPENDLIMIT separately exposed global or mailbox-specific upload policy; RFC 9051 later folded the restricted form into IMAP4rev2.

The line ended before the command did

Consider the opening of an old IMAP exchange:

C: A001 LOGIN {11}

The CRLF after the brace count looked like the end of a line, but it was not the end of the command. The client had promised that eleven octets of a string would follow. It was required to wait. Only after a server response beginning with + could those octets cross the connection, followed by the rest of LOGIN.

This was not a delimiter convention. A literal could contain CR and LF itself. Its end was determined by the announced octet count, and command grammar resumed immediately after the last counted octet. A space might introduce another argument; a later CRLF might finally complete the command. The protocol receiver therefore had to remember two simultaneous facts: how many raw octets remained and where ordinary command parsing would resume.

RFC 2060, published in December 1996, described the literal as IMAP4rev1's general string form. RFC 3501 carried the rule forward in 2003. Server-to-client literals could follow their count immediately. Client-to-server literals could not. Direction changed authority because the server, not the client, owned admission to the command-processing and storage resources behind the connection.

Even {0} had to wait. No payload time could be saved by approving zero octets. The pause existed because it was a protocol decision point, not because the wire needed breathing room.

The continuation was a narrow veto

The + response meant that the server was ready for more of this command. It did not accept the command's final meaning. A later argument could still be invalid; an APPEND could still fail; authentication could still be refused. The continuation merely prevented the client from committing bytes before the receiver had parsed enough context to invite them.

That invitation also made early error handling clean. If the server found a problem in the command prefix, it could send a tagged BAD completion instead of +. The client then had to stop sending that command. No unwanted literal had entered the byte stream, so the next command boundary remained unambiguous.

This differs from transport flow control. A TCP window says how much stream data the receiving stack can buffer. It knows nothing about mailbox names, IMAP verbs, quotas or string positions. The IMAP continuation was an application-level choice about one syntactic continuation. TCP could have ample capacity while IMAP still said: not yet.

The design bought certainty at the price of a network turn. On a local link, the pause might be barely visible. Across a high-latency path, every literal inserted a request-and-permission exchange inside a command. A command containing several literals could accumulate several such stops.

A plus sign spent the round trip

January 1997 brought RFC 2088. It introduced the LITERAL+ capability and one small grammar change:

{11+}

If the server advertised LITERAL+, the client could use this non-synchronizing form. The server would not issue a continuation for it, and the client did not need to wait before sending the eleven octets. If the capability was absent, the client retained the original synchronizing form.

The example in RFC 2088 makes the consequence concrete. LOGIN carries one non-synchronizing literal for the user name, then another for the password, and the client sends both without intermediate server turns. The protocol has not become unframed: each count still determines exactly how many octets belong to its literal, and later syntax remains part of the same command. What disappeared was permission at the boundary.

Capability negotiation mattered because {n+} was a promise about receiver behaviour. A server that had not agreed to recognize the plus form might parse it as an error and could not be assumed to drain the following bytes correctly. Voluntary adoption let the optimization spread without redefining every existing endpoint at once.

RFC 2088's security section said that no security issues were known. That sentence captured what the extension's authors could close in 1997. It did not settle what operating experience would later reveal about resource custody.

Bytes already in flight were harder to refuse

The original sequence let a server inspect the command prefix and reject it before the literal arrived. LITERAL+ deliberately gave that opportunity away. If a client announced a very large {n+} and immediately streamed the data, the server could decide that the command should fail while the client was still entitled to send all n octets.

RFC 7888, published in May 2016, describes two unattractive choices. The server can read the specified bytes, discard them and reject the command. That preserves stream synchronization but wastes bandwidth and receiver work. Or it can send BYE and close the connection, forcing reconnection and making the error harder for a user or naïve client to understand. A server may send BAD or NO before it has drained the literal, but the octets do not disappear merely because the verdict was early.

APPEND made the problem sharp. Most IMAP arguments are modest. APPEND can carry an entire message and its attachments. Server implementations may impose literal-size limits to protect memory, storage and processing. With unrestricted LITERAL+, a latency optimization could cause a large body to arrive before the server had a practical way to refuse its cost.

This was a change in liability. The client gained time by acting without a fresh reply. The server inherited the cleanup problem when that action crossed a local limit. The syntax remained deterministic; the operational burden moved.

LITERAL- drew a fixed line without changing the marker

RFC 7888 obsoleted RFC 2088 and specified two capabilities. LITERAL+ retained unrestricted non-synchronizing literals. LITERAL- used the same {n+} form but imposed a ceiling: a non-synchronizing literal must not exceed 4096 bytes. Anything larger must return to the synchronizing {n} form.

The minus sign appears in the advertised capability, not in each literal. A server must not advertise LITERAL+ and LITERAL- together. Once the client has seen the capability, the plus inside {n+} means either “unrestricted by this extension” or “permitted only through 4096,” depending on the negotiated contract.

That separation is subtle and useful. The grammar stayed small. Old synchronizing literals remained valid. Small strings could avoid a round trip. Large strings recovered an explicit admission point before consuming substantial resources. The standard did not attempt to calculate a perfect threshold for every server or mailbox. It created a universal maximum for this one permissionless mechanism.

The number is not an upload quota. A 3000-octet APPEND can still fail; a 20-megabyte APPEND can be accepted after synchronization. LITERAL- answers only whether this literal may arrive without a continuation.

Nor does LITERAL- make abusive clients harmless. RFC 7888 says non-synchronizing literals can consume memory and support denial-of-service attacks, and that the restricted extension only partially improves the situation. Many small literals, expensive parsing or repeated connections can still impose cost. A threshold narrows one exposure; it does not replace resource governance.

APPENDLIMIT answered a different size question

The same month produced RFC 7889, the APPENDLIMIT extension. Its concern was not how a string was framed but whether a message upload exceeded a server's known policy.

A capability such as APPENDLIMIT=257890 can advertise one maximum for all mailboxes. Bare APPENDLIMIT tells the client that it can discover mailbox-specific values using STATUS or LIST-STATUS. A mailbox may report a number or NIL. A cooperative client can then avoid attempting an APPEND that is already known to be too large.

The distinction matters. LITERAL-'s 4096 is a protocol-wide ceiling on non-synchronizing literal syntax. APPENDLIMIT can be much larger, can differ by mailbox and applies to the message upload decision. It can prevent waste before either synchronizing or non-synchronizing transfer begins.

APPENDLIMIT is evidence, not a reservation. RFC 7889 says the calculation should be quick and need not include ACLs, quotas or other conditions. A message below the advertised value can still fail. If the limit is unknown, the RFC advises a client to avoid non-synchronizing literals for APPEND. Uncertainty restores the permission turn.

This division follows a durable Internet design pattern. Keep the common grammar rule narrow and deterministic; let operational policy remain local and discoverable. A single magic number would have been unable to represent both jobs honestly.

IMAP4rev2 made the restricted form ordinary

RFC 9051, published in August 2021, folded LITERAL- semantics into IMAP4rev2. It presents synchronizing literals, non-synchronizing literals and quoted strings as the three forms of a string. Unless another extension says otherwise, non-synchronizing literals are limited to 4096 octets; larger ones synchronize.

The integration changes the historical posture. What began as an optional 1997 optimization, then received a 2016 resource boundary, became part of the current base grammar. Yet both forms survive. The newer protocol did not declare waiting obsolete. It retained waiting precisely where advance permission remains valuable.

The IANA IMAP Capabilities registry still lists LITERAL+, LITERAL- and APPENDLIMIT with their standards references. Registration says what tokens mean. It does not show which servers advertise them today, how often clients choose each form or what performance and abuse outcomes result.

The history was about who could commit the next bytes

It is tempting to describe LITERAL+ as a minor latency fix and LITERAL- as a later safety limit. The deeper sequence is about decision rights.

The original literal let the receiver decide at each boundary. LITERAL+ let a capable server delegate that decision to the client in advance. The client used the delegation by adding one plus sign and sending immediately. RFC 7888 then limited the scope of that delegation when large unsolicited data made refusal costly. APPENDLIMIT supplied a different kind of prior evidence so the client could avoid a known policy failure altogether.

No form proved final acceptance. No count reserved storage. No capability measured trust. The standards instead kept each assertion small: exact framing, readiness for continuation, permission to skip the continuation, a fixed ceiling on that permission, or a reported upload limit.

The bytes that waited were not inefficient by accident. Their pause preserved a place where one system could still say no before the other spent its resources. Removing a network turn was easy to express. Assigning the cost of that removal took another nineteen years to state clearly.

Sources and evidence limits

These sources establish the protocol grammar, capability history and specified resource considerations. They do not measure present adoption, product behaviour, latency savings, attack frequency or mailbox policy in any deployed service. A continuation is not final command acceptance; 4096 is not an upload quota; APPENDLIMIT is not a promise that a smaller APPEND will succeed.