7Internet Engineering Task Force (IETF) A. Melnikov, Ed.
8Request for Comments: 7888 Isode Ltd
9Obsoletes: 2088 May 2016
10Category: Standards Track
14 IMAP4 Non-synchronizing Literals
18 The Internet Message Access Protocol (RFC 3501) contains the
19 "literal" syntactic construct for communicating strings. When
20 sending a literal from client to server, IMAP requires the client to
21 wait for the server to send a command continuation request between
22 sending the octet count and the string data. This document specifies
23 an alternate form of literal that does not require this network round
26 This document specifies 2 IMAP extensions: LITERAL+ and LITERAL-.
27 LITERAL+ allows the alternate form of literals in all IMAP commands.
28 LITERAL- is the same as LITERAL+, but it disallows the alternate form
29 of literals unless they are 4096 bytes or less.
31 This document obsoletes RFC 2088.
35 This is an Internet Standards Track document.
37 This document is a product of the Internet Engineering Task Force
38 (IETF). It represents the consensus of the IETF community. It has
39 received public review and has been approved for publication by the
40 Internet Engineering Steering Group (IESG). Further information on
41 Internet Standards is available in Section 2 of RFC 5741.
43 Information about the current status of this document, any errata,
44 and how to provide feedback on it may be obtained at
45 http://www.rfc-editor.org/info/rfc7888.
58Melnikov Standards Track [Page 1]
60RFC 7888 IMAP4 Non-synchronizing Literals May 2016
65 Copyright (c) 2016 IETF Trust and the persons identified as the
66 document authors. All rights reserved.
68 This document is subject to BCP 78 and the IETF Trust's Legal
69 Provisions Relating to IETF Documents
70 (http://trustee.ietf.org/license-info) in effect on the date of
71 publication of this document. Please review these documents
72 carefully, as they describe your rights and restrictions with respect
73 to this document. Code Components extracted from this document must
74 include Simplified BSD License text as described in Section 4.e of
75 the Trust Legal Provisions and are provided without warranty as
76 described in the Simplified BSD License.
78 This document may contain material from IETF Documents or IETF
79 Contributions published or made publicly available before November
80 10, 2008. The person(s) controlling the copyright in some of this
81 material may not have granted the IETF Trust the right to allow
82 modifications of such material outside the IETF Standards Process.
83 Without obtaining an adequate license from the person(s) controlling
84 the copyright in such materials, this document may not be modified
85 outside the IETF Standards Process, and derivative works of it may
86 not be created outside the IETF Standards Process, except to format
87 it for publication as an RFC or to translate it into languages other
92 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
93 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3
94 3. Specification . . . . . . . . . . . . . . . . . . . . . . . . 3
95 4. Considerations on When to Use and Not to Use Synchronizing
96 Literals . . . . . . . . . . . . . . . . . . . . . . . . . . 5
97 5. LITERAL- Capability . . . . . . . . . . . . . . . . . . . . . 5
98 6. Interaction with BINARY Extension . . . . . . . . . . . . . . 6
99 7. Interaction with MULTIAPPEND Extension . . . . . . . . . . . 6
100 8. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 6
101 9. Security Considerations . . . . . . . . . . . . . . . . . . . 7
102 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
103 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
104 11.1. Normative References . . . . . . . . . . . . . . . . . . 7
105 11.2. Informative References . . . . . . . . . . . . . . . . . 8
106 Appendix A. Changes since RFC 2088 . . . . . . . . . . . . . . . 9
107 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 9
108 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9
114Melnikov Standards Track [Page 2]
116RFC 7888 IMAP4 Non-synchronizing Literals May 2016
121 The Internet Message Access Protocol [RFC3501] contains the "literal"
122 syntactic construct for communicating strings. When sending a
123 literal from client to server, IMAP requires the client to wait for
124 the server to send a command continuation request between sending the
125 octet count and the string data. This document specifies an
126 alternate form of literal that does not require this network round
129 This document specifies 2 IMAP extensions: LITERAL+ and LITERAL-.
130 LITERAL+ allows the alternate form of literals (called "non-
131 synchronized literals" below) in all IMAP commands. LITERAL- is the
132 same as LITERAL+, but it disallows the alternate form of literals
133 unless they are 4096 bytes or less.
137 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
138 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
139 document are to be interpreted as described in [RFC2119].
141 In examples, "C:" and "S:" indicate lines sent by the client and
142 server, respectively. If a single "C:" or "S:" label applies to
143 multiple lines, then the line breaks between those lines are for
144 editorial clarity only and are not part of the actual protocol
149 The non-synchronizing literal is added as an alternate form of
150 literal, and it may appear in communication from client to server
151 instead of the IMAP [RFC3501] form of literal. The IMAP form of
152 literal, used in communication from client to server, is referred to
153 as a synchronizing literal. The non-synchronizing literal form MUST
154 NOT be sent from server to client.
156 Non-synchronizing literals may be used with any IMAP server
157 implementation that returns "LITERAL+" or "LITERAL-" as one of the
158 supported capabilities to the CAPABILITY command. If the server does
159 not advertise either of the above capabilities, the client can only
160 use synchronizing literals. The difference between LITERAL+ and
161 LITERAL- extensions is explained in Section 5.
163 The non-synchronizing literal is distinguished from the original
164 synchronizing literal by having a plus ('+') between the octet count
165 and the closing brace ('}'). The server does not generate a command
170Melnikov Standards Track [Page 3]
172RFC 7888 IMAP4 Non-synchronizing Literals May 2016
175 continuation request in response to a non-synchronizing literal, and
176 clients are not required to wait before sending the octets of a non-
177 synchronizing literal.
179 The protocol receiver of an IMAP server MUST check the end of every
180 received line (a sequence of octets that ends with a CRLF) for an
181 open brace ('{') followed by an octet count, a plus ('+'), and a
182 close brace ('}') immediately preceding the CRLF. This sequence (if
183 found by the receiver) is the octet count of a non-synchronizing
184 literal, and the server MUST treat the specified number of following
185 octets and the following line (as defined in [RFC3501]) as part of
188 It's important to note that the literal is not delimited by CRLF. It
189 ends after the number of bytes specified by the octet count, and the
190 current command continues from there. There might be a CRLF
191 immediately after; it ends the command. Or, there might be more
192 octets, specifying other command parameters, before the CRLF. If a
193 SP (space) character is needed between parameters, it's important
194 that the SP appear after the literal, in its appropriate place.
196 A server MAY still process commands and reject errors on a line-by-
197 line basis, as long as it checks for non-synchronizing literals at
198 the end of each line.
205 S: A001 OK LOGIN completed
207 This is semantically equivalent to this version that uses quoted
208 strings instead of literals:
210 C: A001 LOGIN "FRED FOOBAR" "fat man"
211 S: A001 OK LOGIN completed
213 Note that the space after FOOBAR in the first version corresponds
214 to the space between the two quoted strings in the second.
226Melnikov Standards Track [Page 4]
228RFC 7888 IMAP4 Non-synchronizing Literals May 2016
2314. Considerations on When to Use and Not to Use Synchronizing Literals
233 Understanding of this section is important for both client and server
234 developers of this IMAP extension.
236 While non-synchronizing literals have clear advantages for clients,
237 such as simplicity of use, they might be more difficult to handle on
238 the server side. When a client uses a non-synchronizing literal that
239 is too big for the server to accept, a server implementation that is
240 compliant with LITERAL+ has to make a choice between a couple non-
243 1. Read the number of bytes specified in the non-synchronizing
244 literal and reject the command that included the literal anyway.
245 (The server is allowed to send the tagged BAD/NO response before
246 reading the whole non-synchronizing literal.) This is quite
247 wasteful of bandwidth if the literal is large.
250 the literal (possibly accompanied by an ALERT response code in
251 another response) and close the connection. This will force the
252 client to reconnect or report the error to the user. In the
253 latter case, the error is unlikely to be understandable to the
254 user. Additionally, some naive clients are known to blindly
255 reconnect in this case and repeat the operation that caused the
256 problem, introducing an infinite loop.
258 The problem described above is most common when using the APPEND
259 command, because most commands don't need to send lots of data from
260 the client to the server. Some server implementations impose limits
261 on literals (both synchronizing and non-synchronizing) accepted from
262 clients in order to defend against denial-of-service attacks.
263 Implementations can generally impose much lower limits on literal
264 sizes for all commands other than APPEND. In order to address
265 literal size issue in APPEND, this document introduces a new
266 extension LITERAL-, described in Section 5.
268 The situation can also be improved by implementing support for the
269 APPENDLIMIT extension [RFC7889], which allows a server to advertise
270 its APPEND limit, so that well-behaved clients can check it and avoid
271 uploading big messages in the first place.
2735. LITERAL- Capability
275 The LITERAL- extension is almost identical to LITERAL+, with one
276 exception: when LITERAL- is advertised, non-synchronizing literals
277 used in any command MUST NOT be larger than 4096 bytes. Any literal
278 larger than 4096 bytes MUST be sent as a synchronizing literal as
282Melnikov Standards Track [Page 5]
284RFC 7888 IMAP4 Non-synchronizing Literals May 2016
287 specified in RFC 3501. A server that is compliant with LITERAL- and
288 encounters a non-synchronizing literal larger than 4096 bytes
289 proceeds as described in Section 4. If responding to an APPEND
290 command, the tagged BAD response MUST contain the TOOBIG response
291 code [RFC4469]. If responding with an untagged BYE response, it
292 SHOULD include the TOOBIG response code. Note that the form of the
293 non-synchronizing literal does not change: it still uses the "+" in
294 the literal itself, even if the applicable extension is LITERAL-.
296 Because LITERAL- is a more restricted version of LITERAL+, IMAP
297 servers MUST NOT advertise both of these capabilities at the same
298 time. (A server implementation can choose to have a configuration
299 option to indicate which one to advertise.)
3016. Interaction with BINARY Extension
303 [RFC4466] updated the non-terminal "literal8" defined in [RFC3516] to
304 allow for non-synchronizing literals if both BINARY [RFC3516] and
305 LITERAL+ extensions are supported by the server.
307 This document also allows use of this extended "literal8" syntax when
308 both BINARY [RFC3516] and LITERAL- extensions are supported by the
3117. Interaction with MULTIAPPEND Extension
313 [RFC3502] describes MULTIAPPEND extension and how it can be used with
314 LITERAL+. The LITERAL- extension can be used with the MULTIAPPEND
315 extension in the same way.
319 The following syntax specification uses the Augmented Backus-Naur
320 Form (ABNF) notation as specified in [ABNF].
322 Non-terminals referenced but not defined below are as defined by
325 literal = "{" number ["+"] "}" CRLF *CHAR8
326 ; Number represents the number of CHAR8 octets
328 CHAR8 = <defined in RFC 3501>
338Melnikov Standards Track [Page 6]
340RFC 7888 IMAP4 Non-synchronizing Literals May 2016
3439. Security Considerations
345 Use of non-synchronizing literals can consume extra resources (e.g.
346 memory) on IMAP servers and can be used for denial-of-service
347 attacks. The LITERAL- extension partially improved this situation.
349 This document doesn't raise any security concerns beyond those raised
35210. IANA Considerations
354 IMAP4 capabilities are registered by publishing a Standards Track or
355 IESG-approved Experimental RFC. The registry is currently located at
356 <http://www.iana.org/assignments/imap-capabilities>.
358 IANA has updated the above registry so that the reference for
359 "LITERAL+" points to this document.
361 IANA has added the "LITERAL-" capability to the above registry, with
362 this document as the reference.
36611.1. Normative References
368 [ABNF] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
369 Specifications: ABNF", STD 68, RFC 5234,
370 DOI 10.17487/RFC5234, January 2008,
371 <http://www.rfc-editor.org/info/rfc5234>.
373 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
374 Requirement Levels", BCP 14, RFC 2119,
375 DOI 10.17487/RFC2119, March 1997,
376 <http://www.rfc-editor.org/info/rfc2119>.
378 [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
379 4rev1", RFC 3501, DOI 10.17487/RFC3501, March 2003,
380 <http://www.rfc-editor.org/info/rfc3501>.
382 [RFC3516] Nerenberg, L., "IMAP4 Binary Content Extension", RFC 3516,
383 DOI 10.17487/RFC3516, April 2003,
384 <http://www.rfc-editor.org/info/rfc3516>.
386 [RFC4466] Melnikov, A. and C. Daboo, "Collected Extensions to IMAP4
387 ABNF", RFC 4466, DOI 10.17487/RFC4466, April 2006,
388 <http://www.rfc-editor.org/info/rfc4466>.
394Melnikov Standards Track [Page 7]
396RFC 7888 IMAP4 Non-synchronizing Literals May 2016
399 [RFC4469] Resnick, P., "Internet Message Access Protocol (IMAP)
400 CATENATE Extension", RFC 4469, DOI 10.17487/RFC4469, April
401 2006, <http://www.rfc-editor.org/info/rfc4469>.
40311.2. Informative References
405 [RFC3502] Crispin, M., "Internet Message Access Protocol (IMAP) -
406 MULTIAPPEND Extension", RFC 3502, DOI 10.17487/RFC3502,
407 March 2003, <http://www.rfc-editor.org/info/rfc3502>.
409 [RFC7889] SrimushnamBoovaraghamoorthy, J. and N. Bisht, "The IMAP
410 APPENDLIMIT Extension", RFC 7889, DOI 10.17487/RFC7889,
411 May 2016, <http://www.rfc-editor.org/info/rfc7889>.
450Melnikov Standards Track [Page 8]
452RFC 7888 IMAP4 Non-synchronizing Literals May 2016
455Appendix A. Changes since RFC 2088
457 Added IANA registration.
459 Updated references. Also updated considerations about interactions
462 Added implementation considerations based on the IMAP mailing list
465 Added description of a new capability: LITERAL-.
469 John G. Myers edited the original LITERAL+ extension.
471 Valuable comments, both in agreement and in dissent, were received
472 from Dave Cridland, Michael M. Slusarz, Arnt Gulbrandsen, Jayantheesh
473 SrimushnamBoovaraghamoorthy, Jamie Nicolson, Barry Leiba, and SM.
477 Alexey Melnikov (editor)
480 Hampton, Middlesex TW12 2NP
483 Email: Alexey.Melnikov@isode.com
506Melnikov Standards Track [Page 9]