7Network Working Group A. Gulbrandsen
8Request for Comments: 5530 Oryx Mail Systems GmbH
9Category: Standards Track May 2009
16 This document specifies an Internet standards track protocol for the
17 Internet community, and requests discussion and suggestions for
18 improvements. Please refer to the current edition of the "Internet
19 Official Protocol Standards" (STD 1) for the standardization state
20 and status of this protocol. Distribution of this memo is unlimited.
24 Copyright (c) 2009 IETF Trust and the persons identified as the
25 document authors. All rights reserved.
27 This document is subject to BCP 78 and the IETF Trust's Legal
28 Provisions Relating to IETF Documents in effect on the date of
29 publication of this document (http://trustee.ietf.org/license-info).
30 Please review these documents carefully, as they describe your rights
31 and restrictions with respect to this document.
35 IMAP responses consist of a response type (OK, NO, BAD), an optional
36 machine-readable response code, and a human-readable text.
38 This document collects and documents a variety of machine-readable
39 response codes, for better interoperation and error reporting.
58Gulbrandsen Standards Track [Page 1]
60RFC 5530 IMAP Response Codes May 2009
65 Section 7.1 of [RFC3501] defines a number of response codes that can
66 help tell an IMAP client why a command failed. However, experience
67 has shown that more codes are useful. For example, it is useful for
68 a client to know that an authentication attempt failed because of a
69 server problem as opposed to a password problem.
71 Currently, many IMAP servers use English-language, human-readable
72 text to describe these errors, and a few IMAP clients attempt to
73 translate this text into the user's language.
75 This document names a variety of errors as response codes. It is
76 based on errors that have been checked and reported on in some IMAP
77 server implementations, and on the needs of some IMAP clients.
79 This document doesn't require any servers to test for these errors or
80 any clients to test for these names. It only names errors for better
81 reporting and handling.
832. Conventions Used in This Document
85 Formal syntax is defined by [RFC5234] as modified by [RFC3501].
87 Example lines prefaced by "C:" are sent by the client and ones
88 prefaced by "S:" by the server. "[...]" means elision.
92 This section defines all the new response codes. Each definition is
93 followed by one or more examples.
96 Temporary failure because a subsystem is down. For example, an
97 IMAP server that uses a Lightweight Directory Access Protocol
98 (LDAP) or Radius server for authentication might use this
99 response code when the LDAP/Radius server is down.
101 C: a LOGIN "fred" "foo"
102 S: a NO [UNAVAILABLE] User's backend down for maintenance
105 Authentication failed for some reason on which the server is
106 unwilling to elaborate. Typically, this includes "unknown
107 user" and "bad password".
114Gulbrandsen Standards Track [Page 2]
116RFC 5530 IMAP Response Codes May 2009
119 This is the same as not sending any response code, except that
120 when a client sees AUTHENTICATIONFAILED, it knows that the
121 problem wasn't, e.g., UNAVAILABLE, so there's no point in
122 trying the same login/password again later.
124 C: b LOGIN "fred" "foo"
125 S: b NO [AUTHENTICATIONFAILED] Authentication failed
128 Authentication succeeded in using the authentication identity,
129 but the server cannot or will not allow the authentication
130 identity to act as the requested authorization identity. This
131 is only applicable when the authentication and authorization
132 identities are different.
134 C: c1 AUTHENTICATE PLAIN
136 S: c1 NO [AUTHORIZATIONFAILED] No such authorization-ID
138 C: c2 AUTHENTICATE PLAIN
140 S: c2 NO [AUTHORIZATIONFAILED] Authenticator is not an admin
144 Either authentication succeeded or the server no longer had the
145 necessary data; either way, access is no longer permitted using
146 that passphrase. The client or user should get a new
149 C: d login "fred" "foo"
150 S: d NO [EXPIRED] That password isn't valid any more
153 The operation is not permitted due to a lack of privacy. If
154 Transport Layer Security (TLS) is not in use, the client could
155 try STARTTLS (see Section 6.2.1 of [RFC3501]) and then repeat
158 C: d login "fred" "foo"
159 S: d NO [PRIVACYREQUIRED] Connection offers no privacy
162 S: d NO [PRIVACYREQUIRED] Connection offers no privacy
170Gulbrandsen Standards Track [Page 3]
172RFC 5530 IMAP Response Codes May 2009
176 The user should contact the system administrator or support
179 C: e login "fred" "foo"
180 S: e OK [CONTACTADMIN]
183 The access control system (e.g., Access Control List (ACL), see
184 [RFC4314]) does not permit this user to carry out an operation,
185 such as selecting or creating a mailbox.
187 C: f select "/archive/projects/experiment-iv"
188 S: f NO [NOPERM] Access denied
191 An operation has not been carried out because it involves
192 sawing off a branch someone else is sitting on. Someone else
193 may be holding an exclusive lock needed for this operation, or
194 the operation may involve deleting a resource someone else is
195 using, typically a mailbox.
197 The operation may succeed if the client tries again later.
199 C: g delete "/archive/projects/experiment-iv"
200 S: g NO [INUSE] Mailbox in use
203 Someone else has issued an EXPUNGE for the same mailbox. The
204 client may want to issue NOOP soon. [RFC2180] discusses this
207 C: h search from fred@example.com
208 S: * SEARCH 1 2 3 5 8 13 21 42
209 S: h OK [EXPUNGEISSUED] Search completed
212 The server discovered that some relevant data (e.g., the
213 mailbox) are corrupt. This response code does not include any
214 information about what's corrupt, but the server can write that
217 C: i select "/archive/projects/experiment-iv"
218 S: i NO [CORRUPTION] Cannot open mailbox
226Gulbrandsen Standards Track [Page 4]
228RFC 5530 IMAP Response Codes May 2009
232 The server encountered a bug in itself or violated one of its
235 C: j select "/archive/projects/experiment-iv"
236 S: j NO [SERVERBUG] This should not happen
239 The server has detected a client bug. This can accompany all
240 of OK, NO, and BAD, depending on what the client bug is.
242 C: k1 select "/archive/projects/experiment-iv"
244 S: k1 OK [READ-ONLY] Done
245 C: k2 status "/archive/projects/experiment-iv" (messages)
247 S: k2 OK [CLIENTBUG] Done
250 The operation violates some invariant of the server and can
253 C: l create "///////"
254 S: l NO [CANNOT] Adjacent slashes are not supported
257 The operation ran up against an implementation limit of some
258 kind, such as the number of flags on a single message or the
259 number of flags used in a mailbox.
261 C: m STORE 42 FLAGS f1 f2 f3 f4 f5 ... f250
262 S: m NO [LIMIT] At most 32 flags in one mailbox supported
265 The user would be over quota after the operation. (The user
266 may or may not be over quota already.)
268 Note that if the server sends OVERQUOTA but doesn't support the
269 IMAP QUOTA extension defined by [RFC2087], then there is a
270 quota, but the client cannot find out what the quota is.
272 C: n1 uid copy 1:* oldmail
273 S: n1 NO [OVERQUOTA] Sorry
275 C: n2 uid copy 1:* oldmail
276 S: n2 OK [OVERQUOTA] You are now over your soft quota
282Gulbrandsen Standards Track [Page 5]
284RFC 5530 IMAP Response Codes May 2009
288 The operation attempts to create something that already exists,
289 such as when the CREATE or RENAME directories attempt to create
290 a mailbox and there is already one of that name.
292 C: o RENAME this that
293 S: o NO [ALREADYEXISTS] Mailbox "that" already exists
296 The operation attempts to delete something that does not exist.
297 Similar to ALREADYEXISTS.
299 C: p RENAME this that
300 S: p NO [NONEXISTENT] No such mailbox
304 The following syntax specification uses the Augmented Backus-Naur
305 Form (ABNF) notation as specified in [RFC5234]. [RFC3501] defines
306 the non-terminal "resp-text-code".
308 Except as noted otherwise, all alphabetic characters are case-
309 insensitive. The use of upper or lowercase characters to define
310 token strings is for editorial clarity only.
312 resp-text-code =/ "UNAVAILABLE" / "AUTHENTICATIONFAILED" /
313 "AUTHORIZATIONFAILED" / "EXPIRED" /
314 "PRIVACYREQUIRED" / "CONTACTADMIN" / "NOPERM" /
315 "INUSE" / "EXPUNGEISSUED" / "CORRUPTION" /
316 "SERVERBUG" / "CLIENTBUG" / "CANNOT" /
317 "LIMIT" / "OVERQUOTA" / "ALREADYEXISTS" /
3205. Security Considerations
322 Revealing information about a passphrase to unauthenticated IMAP
323 clients causes bad karma.
325 Response codes are easier to parse than human-readable text. This
326 can amplify the consequences of an information leak. For example,
327 selecting a mailbox can fail because the mailbox doesn't exist,
328 because the user doesn't have the "l" right (right to know the
329 mailbox exists) or "r" right (right to read the mailbox). If the
330 server sent different responses in the first two cases in the past,
331 only malevolent clients would discover it. With response codes it's
332 possible, perhaps probable, that benevolent clients will forward the
338Gulbrandsen Standards Track [Page 6]
340RFC 5530 IMAP Response Codes May 2009
343 leaked information to the user. Server authors are encouraged to be
344 particularly careful with the NOPERM and authentication-related
3476. IANA Considerations
349 The IANA has created the IMAP Response Codes registry. The registry
350 has been populated with the following codes:
352 NEWNAME RFC 2060 (obsolete)
357 PERMANENTFLAGS RFC 3501
365 UIDNOTSTICKY RFC 4315
371 HIGHESTMODSEQ RFC 4551
374 COMPRESSIONACTIVE RFC 4978
377 BADCOMPARATOR RFC 5255
381 MAXCONVERTMESSAGES RFC 5259
382 MAXCONVERTPARTS RFC 5259
385 NOTIFICATIONOVERFLOW RFC 5465
387 UNDEFINED-FILTER RFC 5466
389 AUTHENTICATIONFAILED RFC 5530
390 AUTHORIZATIONFAILED RFC 5530
394Gulbrandsen Standards Track [Page 7]
396RFC 5530 IMAP Response Codes May 2009
400 PRIVACYREQUIRED RFC 5530
401 CONTACTADMIN RFC 5530
404 EXPUNGEISSUED RFC 5530
411 ALREADYEXISTS RFC 5530
414 The new registry can be extended by sending a registration request to
415 IANA. IANA will forward this request to a Designated Expert,
416 appointed by the responsible IESG Area Director, CCing it to the IMAP
417 Extensions mailing list at <ietf-imapext@imc.org> (or a successor
418 designated by the Area Director). After either allowing 30 days for
419 community input on the IMAP Extensions mailing list or a successful
420 IETF Last Call, the expert will determine the appropriateness of the
421 registration request and either approve or disapprove the request by
422 sending a notice of the decision to the requestor, CCing the IMAP
423 Extensions mailing list and IANA. A denial notice must be justified
424 by an explanation, and, in cases where it is possible, concrete
425 suggestions on how the request can be modified so as to become
426 acceptable should be provided.
428 For each response code, the registry contains a list of relevant RFCs
429 that describe (or extend) the response code and an optional response
430 code status description, such as "obsolete" or "reserved to prevent
431 collision with deployed software". (Note that in the latter case,
432 the RFC number can be missing.) Presence of the response code status
433 description means that the corresponding response code is NOT
434 RECOMMENDED for widespread use.
436 The intention is that any future allocation will be accompanied by a
437 published RFC (including direct submissions to the RFC Editor). But
438 in order to allow for the allocation of values prior to the RFC being
439 approved for publication, the Designated Expert can approve
440 allocations once it seems clear that an RFC will be published, for
441 example, before requesting IETF LC for the document.
443 The Designated Expert can also approve registrations for response
444 codes used in deployed software when no RFC exists. Such
445 registrations must be marked as "reserved to prevent collision with
450Gulbrandsen Standards Track [Page 8]
452RFC 5530 IMAP Response Codes May 2009
455 Response code registrations may not be deleted; response codes that
456 are no longer believed appropriate for use (for example, if there is
457 a problem with the syntax of said response code or if the
458 specification describing it was moved to Historic) should be marked
459 "obsolete" in the registry, clearly marking the lists published by
464 Peter Coates, Mark Crispin, Philip Guenther, Alexey Melnikov, Ken
465 Murchison, Chris Newman, Timo Sirainen, Philip Van Hoof, Dale
466 Wiggins, and Sarah Wilkin helped with this document.
4708.1. Normative References
472 [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
473 4rev1", RFC 3501, March 2003.
475 [RFC5234] Crocker, D., Ed., and P. Overell, "Augmented BNF for
476 Syntax Specifications: ABNF", STD 68, RFC 5234, January
4799. Informative References
481 [RFC2087] Myers, J., "IMAP4 QUOTA extension", RFC 2087, January
484 [RFC2180] Gahrns, M., "IMAP4 Multi-Accessed Mailbox Practice", RFC
487 [RFC4314] Melnikov, A., "IMAP4 Access Control List (ACL) Extension",
488 RFC 4314, December 2005.
493 Oryx Mail Systems GmbH
498 Fax: +49 89 4502 9758
506Gulbrandsen Standards Track [Page 9]