]>

jgm+@cmu.edu

Isode Ltd

5 Castle Business Village 36 Station Road Hampton Middlesex TW12 2BX UK Alexey.Melnikov@isode.com

IMAP LITERAL+ LITERAL- APPENDLIMIT The Internet Message Access Protocol (RFC 3501) contains the "literal" syntactic construct for communicating strings. When sending a literal from client to server, IMAP requires the client to wait for the server to send a command continuation request between sending the octet count and the string data. This document specifies an alternate form of literal which does not require this network round trip. This document specifies 2 IMAP extensions: LITERAL+ and LITERAL-. The former allows the alternate form of literals in all IMAP command. The latter is the same as LITERAL+, but disallow the alternate form in IMAP APPEND.

The non-synchronizing literal is added an alternate form of literal, and may appear in communication from client to server instead of the IMAP form of literal. The IMAP form of literal, used in communication from client to server, is referred to as a synchronizing literal. The non-synchronizing literal form MUST NOT be sent from server to client. Non-synchronizing literals may be used with any IMAP server implementation which returns "LITERAL+" or "LITERAL-" as one of the supported capabilities to the CAPABILITY command. If the server does not advertise either of the above capabilities, the client must use synchronizing literals instead. The difference between "LITERAL+" and "LITERAL-" extensions is explained in . The non-synchronizing literal is distinguished from the original synchronizing literal by having a plus ('+') between the octet count and the closing brace ('}'). The server does not generate a command continuation request in response to a non-synchronizing literal, and clients are not required to wait before sending the octets of a non- synchronizing literal. The protocol receiver of an IMAP server must check the end of every received line for an open brace ('{') followed by an octet count, a plus ('+'), and a close brace ('}') immediately preceeding the CRLF. If it finds this sequence, it is the octet count of a non- synchronizing literal and the server MUST treat the specified number of following octets and the following line as part of the same command. 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. Example:

C: A001 LOGIN {11+} C: FRED FOOBAR {7+} C: fat man S: A001 OK LOGIN completed

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in . In examples, "C:" and "S:" indicate lines sent by the client and server respectively. If a single "C:" or "S:" label applies to multiple lines, then the line breaks between those lines are for editorial clarity only and are not part of the actual protocol exchange.

This section is important to understand for both client and server developers of this IMAP extension. While non-synchronizing literals have clear advantages for clients, such as simplicity of use, they might be more difficilt to handle on the server side. When a non synchronizing literal is used by a client which is too big for the server to accept, a compliant LITERAL+ server implementation has to make a choice between several non optimal choices: Read the number of bytes specified in the non synchronizing literal and reject the command that included the literal anyway. (The server is allowed to send the tagged BAD/NO response before reading the whole non synchronizing literal.) This is quite wasteful on bandwidth if the literal size is big. Send the untagged BYE response explaining the reason for rejecting the literal and close the connection. This will force the client to reconnect or report the error to the user. In the latter case the error is unlikely to be understandable to the user. Additionally, some naive clients are known to blindly reconnect in this case and repeat the operation that caused the problem. Possibly also send the ALERT response code? The situation can be improved by implementing support for the APPENDLIMIT extension , which allows a server to advertise its APPEND limit, so that well behaved clients can check it and avoid uploading big messages in the first place. The problem described above is most common when using the APPEND command, because most of commands don't need to send lots of data from the client to the server. Some server implementations impose limits on literal (both synchronizing and non synchronizing) accepted from clients in order to protect from Denial Of Service attacks. Implementations can generally impose much lower limits on literal sizes for all commands other than APPEND. In order to address literal size issue in APPEND, this document introduces a new extension "LITERAL-", described in .

"LITERAL-" extension is almost identical to "LITERAL+", with one exception: when "LITERAL-" is advertised, non synchronizing literals used in APPEND (and extensions to APPEND such as MULTIAPPEND and CATENATE ) MUST NOT be bigger than 4096 bytes. When any literal used in APPEND is larger than 4096, RFC 3501 synchronizing literals MUST be used instead. A "LITERAL-" compliant server which encounters a non synchronizing literal in APPEND larget than 4096 bytes MUST reject such APPEND command with a tagged BAD response. Because "LITERAL-" is a more restricted version of "LITERAL+", IMAP servers MUST NOT advertise both of these capabilities at the same time. (A server implementation can choose to have a configuration option to pick which one to advertise.)

RFC 4466 updated the non-terminal "literal8" defined in to allow for non-synchronizing literals if both and "LITERAL+" (or "LITERAL-") extensions are supported by the server.

The following syntax specification uses the Augmented Backus-Naur Form (ABNF) notation as specified in . Non-terminals referenced but not defined below are as defined by .

literal = "{" number ["+"] "}" CRLF *CHAR8 ; Number represents the number of CHAR8 octets CHAR8 = <defined in RFC 3501> literal8 = <defined in RFC 4466>

This document doesn't raise any new security concerns not already raised by .

IMAP4 capabilities are registered by publishing a standards track or IESG approved experimental RFC. The registry is currently located at:

http://www.iana.org/assignments/imap-capabilities

This document requests that IANA updated the above registry to include the entry for LITERAL+ capability pointing to this document. This document also requests that IANA adds "LITERAL-" capability pointing to this document to the above registry.

Reference draft-jayantheesh-imap-appendlimit-extension which allows advertising limits for the APPEND command.

TBD

Internet technical specifications often need to define a formal syntax. Over the years, a modified version of Backus-Naur Form (BNF), called Augmented BNF (ABNF), has been popular among many Internet specifications. The current specification documents ABNF. It balances compactness and simplicity with reasonable representational power. The differences between standard BNF and ABNF involve naming rules, repetition, alternatives, order-independence, and value ranges. This specification also supplies additional rule definitions and encoding for a core lexical analyzer of the type common to several Internet specifications. [STANDARDS TRACK] &rfc2119; &rfc3501; &rfc3516; &rfc4466; &rfc3502; &rfc4469; This memo defines an extension to the IMAP service whereby a server can advertise its capability, to support maximum mail upload size using CAPABILITY, SELECT/EXAMINE and LIST command.

Added IANA registration. Updated references. Also updated considerations about interactions of IMAP extensions. Additional implementation considerations based on the IMAP mailing list discussions. LITERAL- capability description.