IMAP4 Non-synchronizing Literals
obsoletes
- rfc-2088 — IMAP4 non-synchronizing literals
Extracted elements (18)
LITERAL- was introduced to address the problem that LITERAL+ servers facing oversized literals must choose between wasteful bandwidth consumption (reading then rejecting) or closing the connection with BYE (risking infinite reconnect loops in naive clients). Restricting non-synchronizing literals to 4096 bytes except for APPEND mitigates denial-of-service risk while retaining performance benefits for small literals.
The literal is not delimited by CRLF; it ends after the number of bytes specified by the octet count. A CRLF may immediately follow (ending the command) or additional parameters may follow before the CRLF, with SP characters placed after the literal as needed.
RFC 4466 updated the non-terminal 'literal8' (from RFC 3516 BINARY extension) to allow non-synchronizing literals when both BINARY and LITERAL+ are supported. This document extends that to also permit the extended literal8 syntax when both BINARY and LITERAL- are supported.
The APPENDLIMIT extension (RFC 7889) allows a server to advertise its APPEND size limit, enabling well-behaved clients to avoid uploading oversized messages and thereby reducing the scenarios where oversized non-synchronizing literals become a problem.
The LITERAL- extension can be used with the MULTIAPPEND extension (RFC 3502) in the same way LITERAL+ can, as described in RFC 3502.
A server MAY still process commands and reject errors on a line-by-line basis, as long as it checks for non-synchronizing literals at the end of each line.
If a LITERAL- server responds to an APPEND command with a tagged BAD due to an oversized non-synchronizing literal, the BAD response MUST contain the TOOBIG response code (RFC 4469). If responding with an untagged BYE, it SHOULD include the TOOBIG response code.
IMAP servers MUST NOT advertise both LITERAL+ and LITERAL- capabilities at the same time; a server may offer a configuration option to select which one to advertise.
Non-synchronizing literals may only be used with servers that advertise LITERAL+ or LITERAL- capability. If neither is advertised, the client can only use synchronizing literals.
The non-synchronizing literal form MUST NOT be sent from server to client; it is exclusively a client-to-server construct.
The protocol receiver of an IMAP server MUST check the end of every received line for the pattern '{' octet-count '+' '}' immediately preceding the CRLF, and MUST treat the specified number of following octets and the following line as part of the same command.
When LITERAL- is advertised, non-synchronizing literals MUST NOT be larger than 4096 bytes. Any literal larger than 4096 bytes MUST be sent as a synchronizing literal.
LITERAL- is an IMAP capability identical to LITERAL+ except that non-synchronizing literals used in any command MUST NOT exceed 4096 bytes; larger literals must be sent as synchronizing literals per RFC 3501.
LITERAL+ is an IMAP capability that allows non-synchronizing literals of any size in all IMAP commands. Servers advertise this via the CAPABILITY response.
The non-synchronizing literal is an alternate form of IMAP literal distinguished by a plus ('+') between the octet count and the closing brace ('}'), e.g., {11+}. It may only appear in client-to-server communication; the server does not generate a command continuation request in response.
IANA updated the IMAP Capabilities registry so that the reference for 'LITERAL+' points to this document (RFC 7888), and added 'LITERAL-' as a new capability with this document as the reference. The registry is at http://www.iana.org/assignments/imap-capabilities.
Use of non-synchronizing literals can consume extra resources (e.g., memory) on IMAP servers and can be exploited for denial-of-service attacks. The LITERAL- extension partially mitigates this by capping non-synchronizing literal size at 4096 bytes.
The ABNF for literal is: literal = '{' number ['+'] '}' CRLF *CHAR8, where the optional '+' distinguishes non-synchronizing from synchronizing literals and number represents the count of CHAR8 octets that follow.