1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
|
<pre>Network Working Group A. Gulbrandsen
Request for Comments: 5530 Oryx Mail Systems GmbH
Category: Standards Track May 2009
<span class="h1">IMAP Response Codes</span>
Status of This Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (<a href="http://trustee.ietf.org/license-info">http://trustee.ietf.org/license-info</a>).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Abstract
IMAP responses consist of a response type (OK, NO, BAD), an optional
machine-readable response code, and a human-readable text.
This document collects and documents a variety of machine-readable
response codes, for better interoperation and error reporting.
<span class="grey">Gulbrandsen Standards Track [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc5530">RFC 5530</a> IMAP Response Codes May 2009</span>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
<a href="./rfc3501#section-7.1">Section 7.1 of [RFC3501]</a> defines a number of response codes that can
help tell an IMAP client why a command failed. However, experience
has shown that more codes are useful. For example, it is useful for
a client to know that an authentication attempt failed because of a
server problem as opposed to a password problem.
Currently, many IMAP servers use English-language, human-readable
text to describe these errors, and a few IMAP clients attempt to
translate this text into the user's language.
This document names a variety of errors as response codes. It is
based on errors that have been checked and reported on in some IMAP
server implementations, and on the needs of some IMAP clients.
This document doesn't require any servers to test for these errors or
any clients to test for these names. It only names errors for better
reporting and handling.
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. Conventions Used in This Document</span>
Formal syntax is defined by [<a href="./rfc5234" title=""Augmented BNF for Syntax Specifications: ABNF"">RFC5234</a>] as modified by [<a href="./rfc3501" title=""INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1"">RFC3501</a>].
Example lines prefaced by "C:" are sent by the client and ones
prefaced by "S:" by the server. "[...]" means elision.
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. Response Codes</span>
This section defines all the new response codes. Each definition is
followed by one or more examples.
UNAVAILABLE
Temporary failure because a subsystem is down. For example, an
IMAP server that uses a Lightweight Directory Access Protocol
(LDAP) or Radius server for authentication might use this
response code when the LDAP/Radius server is down.
C: a LOGIN "fred" "foo"
S: a NO [UNAVAILABLE] User's backend down for maintenance
AUTHENTICATIONFAILED
Authentication failed for some reason on which the server is
unwilling to elaborate. Typically, this includes "unknown
user" and "bad password".
<span class="grey">Gulbrandsen Standards Track [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc5530">RFC 5530</a> IMAP Response Codes May 2009</span>
This is the same as not sending any response code, except that
when a client sees AUTHENTICATIONFAILED, it knows that the
problem wasn't, e.g., UNAVAILABLE, so there's no point in
trying the same login/password again later.
C: b LOGIN "fred" "foo"
S: b NO [AUTHENTICATIONFAILED] Authentication failed
AUTHORIZATIONFAILED
Authentication succeeded in using the authentication identity,
but the server cannot or will not allow the authentication
identity to act as the requested authorization identity. This
is only applicable when the authentication and authorization
identities are different.
C: c1 AUTHENTICATE PLAIN
[...]
S: c1 NO [AUTHORIZATIONFAILED] No such authorization-ID
C: c2 AUTHENTICATE PLAIN
[...]
S: c2 NO [AUTHORIZATIONFAILED] Authenticator is not an admin
EXPIRED
Either authentication succeeded or the server no longer had the
necessary data; either way, access is no longer permitted using
that passphrase. The client or user should get a new
passphrase.
C: d login "fred" "foo"
S: d NO [EXPIRED] That password isn't valid any more
PRIVACYREQUIRED
The operation is not permitted due to a lack of privacy. If
Transport Layer Security (TLS) is not in use, the client could
try STARTTLS (see <a href="./rfc3501#section-6.2.1">Section 6.2.1 of [RFC3501]</a>) and then repeat
the operation.
C: d login "fred" "foo"
S: d NO [PRIVACYREQUIRED] Connection offers no privacy
C: d select inbox
S: d NO [PRIVACYREQUIRED] Connection offers no privacy
<span class="grey">Gulbrandsen Standards Track [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc5530">RFC 5530</a> IMAP Response Codes May 2009</span>
CONTACTADMIN
The user should contact the system administrator or support
desk.
C: e login "fred" "foo"
S: e OK [CONTACTADMIN]
NOPERM
The access control system (e.g., Access Control List (ACL), see
[<a href="./rfc4314" title=""IMAP4 Access Control List (ACL) Extension"">RFC4314</a>]) does not permit this user to carry out an operation,
such as selecting or creating a mailbox.
C: f select "/archive/projects/experiment-iv"
S: f NO [NOPERM] Access denied
INUSE
An operation has not been carried out because it involves
sawing off a branch someone else is sitting on. Someone else
may be holding an exclusive lock needed for this operation, or
the operation may involve deleting a resource someone else is
using, typically a mailbox.
The operation may succeed if the client tries again later.
C: g delete "/archive/projects/experiment-iv"
S: g NO [INUSE] Mailbox in use
EXPUNGEISSUED
Someone else has issued an EXPUNGE for the same mailbox. The
client may want to issue NOOP soon. [<a href="./rfc2180" title=""IMAP4 Multi-Accessed Mailbox Practice"">RFC2180</a>] discusses this
subject in depth.
C: h search from fred@example.com
S: * SEARCH 1 2 3 5 8 13 21 42
S: h OK [EXPUNGEISSUED] Search completed
CORRUPTION
The server discovered that some relevant data (e.g., the
mailbox) are corrupt. This response code does not include any
information about what's corrupt, but the server can write that
to its logfiles.
C: i select "/archive/projects/experiment-iv"
S: i NO [CORRUPTION] Cannot open mailbox
<span class="grey">Gulbrandsen Standards Track [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc5530">RFC 5530</a> IMAP Response Codes May 2009</span>
SERVERBUG
The server encountered a bug in itself or violated one of its
own invariants.
C: j select "/archive/projects/experiment-iv"
S: j NO [SERVERBUG] This should not happen
CLIENTBUG
The server has detected a client bug. This can accompany all
of OK, NO, and BAD, depending on what the client bug is.
C: k1 select "/archive/projects/experiment-iv"
[...]
S: k1 OK [READ-ONLY] Done
C: k2 status "/archive/projects/experiment-iv" (messages)
[...]
S: k2 OK [CLIENTBUG] Done
CANNOT
The operation violates some invariant of the server and can
never succeed.
C: l create "///////"
S: l NO [CANNOT] Adjacent slashes are not supported
LIMIT
The operation ran up against an implementation limit of some
kind, such as the number of flags on a single message or the
number of flags used in a mailbox.
C: m STORE 42 FLAGS f1 f2 f3 f4 f5 ... f250
S: m NO [LIMIT] At most 32 flags in one mailbox supported
OVERQUOTA
The user would be over quota after the operation. (The user
may or may not be over quota already.)
Note that if the server sends OVERQUOTA but doesn't support the
IMAP QUOTA extension defined by [<a href="./rfc2087" title=""IMAP4 QUOTA extension"">RFC2087</a>], then there is a
quota, but the client cannot find out what the quota is.
C: n1 uid copy 1:* oldmail
S: n1 NO [OVERQUOTA] Sorry
C: n2 uid copy 1:* oldmail
S: n2 OK [OVERQUOTA] You are now over your soft quota
<span class="grey">Gulbrandsen Standards Track [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc5530">RFC 5530</a> IMAP Response Codes May 2009</span>
ALREADYEXISTS
The operation attempts to create something that already exists,
such as when the CREATE or RENAME directories attempt to create
a mailbox and there is already one of that name.
C: o RENAME this that
S: o NO [ALREADYEXISTS] Mailbox "that" already exists
NONEXISTENT
The operation attempts to delete something that does not exist.
Similar to ALREADYEXISTS.
C: p RENAME this that
S: p NO [NONEXISTENT] No such mailbox
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. Formal Syntax</span>
The following syntax specification uses the Augmented Backus-Naur
Form (ABNF) notation as specified in [<a href="./rfc5234" title=""Augmented BNF for Syntax Specifications: ABNF"">RFC5234</a>]. [<a href="./rfc3501" title=""INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1"">RFC3501</a>] defines
the non-terminal "resp-text-code".
Except as noted otherwise, all alphabetic characters are case-
insensitive. The use of upper or lowercase characters to define
token strings is for editorial clarity only.
resp-text-code =/ "UNAVAILABLE" / "AUTHENTICATIONFAILED" /
"AUTHORIZATIONFAILED" / "EXPIRED" /
"PRIVACYREQUIRED" / "CONTACTADMIN" / "NOPERM" /
"INUSE" / "EXPUNGEISSUED" / "CORRUPTION" /
"SERVERBUG" / "CLIENTBUG" / "CANNOT" /
"LIMIT" / "OVERQUOTA" / "ALREADYEXISTS" /
"NONEXISTENT"
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. Security Considerations</span>
Revealing information about a passphrase to unauthenticated IMAP
clients causes bad karma.
Response codes are easier to parse than human-readable text. This
can amplify the consequences of an information leak. For example,
selecting a mailbox can fail because the mailbox doesn't exist,
because the user doesn't have the "l" right (right to know the
mailbox exists) or "r" right (right to read the mailbox). If the
server sent different responses in the first two cases in the past,
only malevolent clients would discover it. With response codes it's
possible, perhaps probable, that benevolent clients will forward the
<span class="grey">Gulbrandsen Standards Track [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc5530">RFC 5530</a> IMAP Response Codes May 2009</span>
leaked information to the user. Server authors are encouraged to be
particularly careful with the NOPERM and authentication-related
responses.
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. IANA Considerations</span>
The IANA has created the IMAP Response Codes registry. The registry
has been populated with the following codes:
NEWNAME <a href="./rfc2060">RFC 2060</a> (obsolete)
REFERRAL <a href="./rfc2221">RFC 2221</a>
ALERT <a href="./rfc3501">RFC 3501</a>
BADCHARSET <a href="./rfc3501">RFC 3501</a>
PARSE <a href="./rfc3501">RFC 3501</a>
PERMANENTFLAGS <a href="./rfc3501">RFC 3501</a>
READ-ONLY <a href="./rfc3501">RFC 3501</a>
READ-WRITE <a href="./rfc3501">RFC 3501</a>
TRYCREATE <a href="./rfc3501">RFC 3501</a>
UIDNEXT <a href="./rfc3501">RFC 3501</a>
UIDVALIDITY <a href="./rfc3501">RFC 3501</a>
UNSEEN <a href="./rfc3501">RFC 3501</a>
UNKNOWN-CTE <a href="./rfc3516">RFC 3516</a>
UIDNOTSTICKY <a href="./rfc4315">RFC 4315</a>
APPENDUID <a href="./rfc4315">RFC 4315</a>
COPYUID <a href="./rfc4315">RFC 4315</a>
URLMECH <a href="./rfc4467">RFC 4467</a>
TOOBIG <a href="./rfc4469">RFC 4469</a>
BADURL <a href="./rfc4469">RFC 4469</a>
HIGHESTMODSEQ <a href="./rfc4551">RFC 4551</a>
NOMODSEQ <a href="./rfc4551">RFC 4551</a>
MODIFIED <a href="./rfc4551">RFC 4551</a>
COMPRESSIONACTIVE <a href="./rfc4978">RFC 4978</a>
CLOSED <a href="./rfc5162">RFC 5162</a>
NOTSAVED <a href="./rfc5182">RFC 5182</a>
BADCOMPARATOR <a href="./rfc5255">RFC 5255</a>
ANNOTATE <a href="./rfc5257">RFC 5257</a>
ANNOTATIONS <a href="./rfc5257">RFC 5257</a>
TEMPFAIL <a href="./rfc5259">RFC 5259</a>
MAXCONVERTMESSAGES <a href="./rfc5259">RFC 5259</a>
MAXCONVERTPARTS <a href="./rfc5259">RFC 5259</a>
NOUPDATE <a href="./rfc5267">RFC 5267</a>
METADATA <a href="./rfc5464">RFC 5464</a>
NOTIFICATIONOVERFLOW <a href="./rfc5465">RFC 5465</a>
BADEVENT <a href="./rfc5465">RFC 5465</a>
UNDEFINED-FILTER <a href="./rfc5466">RFC 5466</a>
UNAVAILABLE <a href="./rfc5530">RFC 5530</a>
AUTHENTICATIONFAILED <a href="./rfc5530">RFC 5530</a>
AUTHORIZATIONFAILED <a href="./rfc5530">RFC 5530</a>
<span class="grey">Gulbrandsen Standards Track [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc5530">RFC 5530</a> IMAP Response Codes May 2009</span>
EXPIRED <a href="./rfc5530">RFC 5530</a>
PRIVACYREQUIRED <a href="./rfc5530">RFC 5530</a>
CONTACTADMIN <a href="./rfc5530">RFC 5530</a>
NOPERM <a href="./rfc5530">RFC 5530</a>
INUSE <a href="./rfc5530">RFC 5530</a>
EXPUNGEISSUED <a href="./rfc5530">RFC 5530</a>
CORRUPTION <a href="./rfc5530">RFC 5530</a>
SERVERBUG <a href="./rfc5530">RFC 5530</a>
CLIENTBUG <a href="./rfc5530">RFC 5530</a>
CANNOT <a href="./rfc5530">RFC 5530</a>
LIMIT <a href="./rfc5530">RFC 5530</a>
OVERQUOTA <a href="./rfc5530">RFC 5530</a>
ALREADYEXISTS <a href="./rfc5530">RFC 5530</a>
NONEXISTENT <a href="./rfc5530">RFC 5530</a>
The new registry can be extended by sending a registration request to
IANA. IANA will forward this request to a Designated Expert,
appointed by the responsible IESG Area Director, CCing it to the IMAP
Extensions mailing list at <ietf-imapext@imc.org> (or a successor
designated by the Area Director). After either allowing 30 days for
community input on the IMAP Extensions mailing list or a successful
IETF Last Call, the expert will determine the appropriateness of the
registration request and either approve or disapprove the request by
sending a notice of the decision to the requestor, CCing the IMAP
Extensions mailing list and IANA. A denial notice must be justified
by an explanation, and, in cases where it is possible, concrete
suggestions on how the request can be modified so as to become
acceptable should be provided.
For each response code, the registry contains a list of relevant RFCs
that describe (or extend) the response code and an optional response
code status description, such as "obsolete" or "reserved to prevent
collision with deployed software". (Note that in the latter case,
the RFC number can be missing.) Presence of the response code status
description means that the corresponding response code is NOT
RECOMMENDED for widespread use.
The intention is that any future allocation will be accompanied by a
published RFC (including direct submissions to the RFC Editor). But
in order to allow for the allocation of values prior to the RFC being
approved for publication, the Designated Expert can approve
allocations once it seems clear that an RFC will be published, for
example, before requesting IETF LC for the document.
The Designated Expert can also approve registrations for response
codes used in deployed software when no RFC exists. Such
registrations must be marked as "reserved to prevent collision with
deployed software".
<span class="grey">Gulbrandsen Standards Track [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc5530">RFC 5530</a> IMAP Response Codes May 2009</span>
Response code registrations may not be deleted; response codes that
are no longer believed appropriate for use (for example, if there is
a problem with the syntax of said response code or if the
specification describing it was moved to Historic) should be marked
"obsolete" in the registry, clearly marking the lists published by
IANA.
<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>. Acknowledgements</span>
Peter Coates, Mark Crispin, Philip Guenther, Alexey Melnikov, Ken
Murchison, Chris Newman, Timo Sirainen, Philip Van Hoof, Dale
Wiggins, and Sarah Wilkin helped with this document.
<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>. References</span>
<span class="h3"><a class="selflink" id="section-8.1" href="#section-8.1">8.1</a>. Normative References</span>
[<a id="ref-RFC3501">RFC3501</a>] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
4rev1", <a href="./rfc3501">RFC 3501</a>, March 2003.
[<a id="ref-RFC5234">RFC5234</a>] Crocker, D., Ed., and P. Overell, "Augmented BNF for
Syntax Specifications: ABNF", STD 68, <a href="./rfc5234">RFC 5234</a>, January
2008.
<span class="h2"><a class="selflink" id="section-9" href="#section-9">9</a>. Informative References</span>
[<a id="ref-RFC2087">RFC2087</a>] Myers, J., "IMAP4 QUOTA extension", <a href="./rfc2087">RFC 2087</a>, January
1997.
[<a id="ref-RFC2180">RFC2180</a>] Gahrns, M., "IMAP4 Multi-Accessed Mailbox Practice", <a href="./rfc2180">RFC</a>
<a href="./rfc2180">2180</a>, July 1997.
[<a id="ref-RFC4314">RFC4314</a>] Melnikov, A., "IMAP4 Access Control List (ACL) Extension",
<a href="./rfc4314">RFC 4314</a>, December 2005.
Author's Address
Arnt Gulbrandsen
Oryx Mail Systems GmbH
Schweppermannstr. 8
D-81671 Muenchen
Germany
Fax: +49 89 4502 9758
EMail: arnt@oryx.com
Gulbrandsen Standards Track [Page 9]
</pre>
|
