idnits 2.17.1 draft-gulbrandsen-imap-response-codes-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (December 15, 2008) is 5610 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 3501 (Obsoleted by RFC 9051) -- Obsolete informational reference (is this intentional?): RFC 2087 (Obsoleted by RFC 9208) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Arnt Gulbrandsen 3 Internet-Draft Oryx Mail Systems GmbH 4 Intended Status: Proposed Standard December 15, 2008 6 IMAP Response Codes 7 draft-gulbrandsen-imap-response-codes-07.txt 9 Status of this Memo 11 This Internet-Draft is submitted to IETF in full conformance with the 12 provisions of BCP 78 and BCP 79. 14 Copyright (c) 2008 IETF Trust and the persons identified as the 15 document authors. All rights reserved. 17 This document is subject to BCP 78 and the IETF Trust's Legal 18 Provisions Relating to IETF Documents 19 (http://trustee.ietf.org/license-info) in effect on the date of 20 publication of this document. Please review these documents 21 carefully, as they describe your rights and restrictions with respect 22 to this document. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF), its areas, and its working groups. Note that 26 other groups may also distribute working documents as Internet- 27 Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet- 36 Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html. 39 This Internet-Draft expires in June 2009. 41 Internet-draft December 2008 43 Abstract 45 IMAP responses consist of a response type (OK, NO, BAD), an optional 46 machine-readable response code and a human-readable text. 48 This document collects and documents a variety of machine-readable 49 response codes, for better interoperation and error reporting. 51 1. Conventions Used in This Document 53 Formal syntax is defined by [RFC5234] as modified by [RFC3501]. 55 Example lines prefaced by "C:" are sent by the client and ones 56 prefaced by "S:" by the server. "[...]" means elision. 58 2. Introduction 60 [RFC3501] section 7.1 defines a number of response codes which can 61 help tell an IMAP client why a command failed. However, experience 62 has shown that more codes are useful. For example, it is useful for a 63 client to know that an authentication attempt failed because of a 64 server problem as opposed to a password problem. 66 Currently many IMAP servers use English-language human-readable text 67 to describe these errors, and a few IMAP clients attempt to translate 68 this text into the user's language. 70 This document names a variety of errors as response codes. It is 71 based on errors checked and reported in some IMAP server 72 implementations, and on needs in some IMAP clients. 74 This document doesn't require any servers to test for these errors, 75 or any clients to test for these names. It only names errors for 76 better reporting and handling. 78 [RFC Editor: Please remove this paragraph.] In general, this document 79 aims to do that which is widely considered good, and nothing more. 80 Several controversial and/or complex features were discussed, but 81 just listing the simple and desirable response codes is enough for 82 one document. 84 3. Response Codes 86 This section defines all the new response codes. Each definition is 87 followed by one or more examples. 89 Internet-draft December 2008 91 UNAVAILABLE Temporary failure because a subsystem is down. For 92 example, an IMAP server which uses an LDAP or Radius 93 server for authentication might use this when the 94 LDAP/Radius server is down. 96 C: a LOGIN "fred" "foo" 97 S: a NO [UNAVAILABLE] User's backend down for maintenance 99 AUTHENTICATIONFAILED Authentication failed for some reason which the 100 server is not willing to elaborate. Typically this 101 includes "unknown user" and "bad password". 103 This is the same as not sending any response code, except 104 that when a client sees AUTHENTICATIONFAILED, it knows 105 that the problem wasn't e.g. UNAVAILABLE, so there's no 106 point in trying the same login/password again later. 108 C: b LOGIN "fred" "foo" 109 S: b NO [AUTHENTICATIONFAILED] Authentication failed 111 AUTHORIZATIONFAILED Authentication succeeded, but authorization 112 failed. This is only applicable when the authentication 113 and authorization identities are different. 115 C: c AUTHENTICATE PLAIN 116 [...] 117 S: c NO [AUTHORIZATIONFAILED] No such auth-ID 119 EXPIRED Authentication succeeded or the server didn't have the 120 necessary data any more, but access is no longer 121 permitted using that passphrase. The client or user 122 should get a new passphrase. 124 C: d login "fred" "foo" 125 S: d NO [EXPIRED] That password isn't valid any more 127 PRIVACYREQUIRED The operation is not permitted due to a lack of 128 privacy. If TLS is not in use, the client could try 129 STARTTLS (see [RFC3501] section 6.2.1) and then repeat 130 the operation. 132 C: d login "fred" "foo" 133 S: d NO [PRIVACYREQUIRED] Connection offers no privacy 135 C: d select inbox 136 S: d NO [PRIVACYREQUIRED] Connection offers no privacy 138 Internet-draft December 2008 140 CONTACTADMIN The user should contact the system administrator or 141 support desk. 143 C: e login "fred" "foo" 144 S: e OK [CONTACTADMIN] 146 NOPERM The access control system (e.g. ACL, see [RFC4314]) does 147 not permit this user to carry out an operation, such as 148 selecting or creating a mailbox. 150 C: f select "/archive/projects/experiment-iv" 151 S: f NO [NOPERM] Access denied 153 INUSE An operation has not been carried out because it involves 154 sawing off a branch someone else is sitting on. Someone 155 else may be holding an exclusive lock needed for this 156 operation, or it may involve deleting a resource someone 157 else is using, typically a mailbox. 159 The operation may succeed if the client tries again 160 later. 162 C: g delete "/archive/projects/experiment-iv" 163 S: g NO [INUSE] Mailbox in use 165 EXPUNGEISSUED Someone else has issued an EXPUNGE for the same 166 mailbox. The client may want to issue NOOP soon. 167 [RFC2180] discusses this subject in depth. 169 C: h search from fred@example.com 170 S: * SEARCH 1 2 3 5 8 13 21 42 171 S: h OK [EXPUNGEISSUED] Search completed 173 CORRUPTION The server discovered that some relevant data (e.g. the 174 mailbox) are corrupt. This response code does not include 175 any information about what's corrupt, but the server can 176 write that to its logfiles. 178 C: i select "/archive/projects/experiment-iv" 179 S: i NO [CORRUPTION] Cannot open mailbox 181 SERVERBUG The server encountered a bug in itself or violated one of 182 its own invariants. 184 C: j select "/archive/projects/experiment-iv" 185 S: j NO [SERVERBUG] This should not happen 187 Internet-draft December 2008 189 CLIENTBUG The server has detected a client bug. This can accompany 190 all of OK, NO and BAD, depending on what the client bug 191 is. 193 C: k1 select "/archive/projects/experiment-iv" 194 [...] 195 S: k1 OK [READ-ONLY] Done 196 C: k2 status "/archive/projects/experiment-iv" (messages) 197 [...] 198 S: k2 OK [CLIENTBUG] Done 200 CANNOT The operation violates some invariant of the server and 201 can never succeed. 203 C: l create "///////" 204 S: l NO [CANNOT] Adjacent slashes is not supported 206 LIMIT The operation ran up against an implementation limit of 207 some kind, such as the number of flags on a single 208 message or number of flags used in a mailbox. 210 C: m STORE 42 FLAGS f1 f2 f3 f4 f5 ... f250 211 S: m NO [LIMIT] At most 32 flags in one mailbox supported 213 OVERQUOTA The user is or would be over quota after the operation. 214 (The user may or may not be over quota already.) 216 Note that if the server sends OVERQUOTA but doesn't 217 support the IMAP QUOTA extension defined by [RFC2087], 218 then there is a quota, but the client cannot find out 219 what the quota is. 221 C: n1 uid copy 1:* oldmail 222 S: n1 NO [OVERQUOTA] Sorry 224 C: n2 uid copy 1:* oldmail 225 S: n2 OK [OVERQUOTA] You are now over your soft quota 227 ALREADYEXISTS The operation attempts to create something which 228 already exists, such as when the CREATE or RENAME 229 directories attempt to create a mailbox and there is one 230 of that name. 232 C: o RENAME this that 233 S: o NO [ALREADYEXISTS] Mailbox "that" already exists 235 Internet-draft December 2008 237 NONEXISTENT The operation attempts to delete something which does not 238 exist. Similar to ALREADYEXISTS. 240 C: p RENAME this that 241 S: p NO [NONEXISTENT] No such mailbox 243 4. Formal Syntax 245 The following syntax specification uses the Augmented Backus-Naur 246 Form (ABNF) notation as specified in [RFC5234]. [RFC3501] defines the 247 non-terminal "resp-text-code". 249 Except as noted otherwise, all alphabetic characters are case- 250 insensitive. The use of upper or lower case characters to define 251 token strings is for editorial clarity only. 253 resp-text-code =/ "UNAVAILABLE" / "AUTHENTICATIONFAILED" / 254 "AUTHORIZATIONFAILED" / "EXPIRED" / 255 "PRIVACYREQUIRED" / "CONTACTADMIN" / "NOPERM" / 256 "INUSE" / "EXPUNGEISSUED" / "CORRUPTION" / 257 "SERVERBUG" / "CLIENTBUG" / "CANNOT" / "LIMIT" 258 / "OVERQUOTA" / "ALREADYEXISTS" / "NONEXISTENT" 260 5. Security considerations 262 Revealing information about a passphrase to unauthenticated IMAP 263 clients has bad karma. 265 Response codes are easier to parse than human-readable text. This can 266 amplify the consequences of an information leak. For example, 267 selecting a mailbox can fail because the mailbox doesn't exist, 268 because the user doesn't have the "l" right (right to know the 269 mailbox exists) or "r" (right to read the mailbox). If the server 270 sent different responses in the first two cases in the past, only 271 malevolent clients would discover it. With response codes it's 272 possible, perhaps probable, that benevolent clients forward the 273 leaked information to the user. Server authors are encouraged to be 274 particularly careful with the NOPERM and authentication-related 275 responses. 277 Internet-draft December 2008 279 6. IANA considerations 281 The IANA is requested to create a new registry, tentatively named 282 imap-response-codes, and populate it as follows: 284 REFERRAL RFC 2221 285 ALERT RFC 3501 286 BADCHARSET RFC 3501 287 PARSE RFC 3501 288 PERMANENTFLAGS RFC 3501 289 READ-ONLY RFC 3501 290 READ-WRITE RFC 3501 291 TRYCREATE RFC 3501 292 UIDNEXT RFC 3501 293 UIDVALIDITY RFC 3501 294 UNSEEN RFC 3501 295 UNKNOWN-CTE RFC 3516 296 UIDNOTSTICKY RFC 4315 297 APPENDUID RFC 4315 298 COPYUID RFC 4315 299 URLMECH RFC 4467 300 TOOBIG RFC 4469 301 BADURL RFC 4469 302 HIGHESTMODSEQ RFC 4551 303 NOMODSEQ RFC 4551 304 MODIFIED RFC 4551 305 COMPRESSIONACTIVE RFC 4978 306 CLOSED RFC 5162 307 BADCOMPARATOR RFC 5255 308 ANNOTATE RFC 5257 309 METADATA RFC (draft-daboo-imap-annotatemore-16.txt) 310 UNAVAILABLE RFC (this) 311 AUTHENTICATIONFAILED RFC (this) 312 AUTHORIZATIONFAILED RFC (this) 313 EXPIRED RFC (this) 314 PRIVACYREQUIRED RFC (this) 315 CONTACTADMIN RFC (this) 316 NOPERM RFC (this) 317 INUSE RFC (this) 318 EXPUNGEISSUED RFC (this) 319 CORRUPTION RFC (this) 320 SERVERBUG RFC (this) 321 CLIENTBUG RFC (this) 322 CANNOT RFC (this) 323 LIMIT RFC (this) 324 OVERQUOTA RFC (this) 325 ALREADYEXISTS RFC (this) 326 NONEXISTENT RFC (this) 328 Internet-draft December 2008 330 The RFC editor is requested to delete this entire text, and insert a 331 sentence or two mentioning the registry's URL instead. 333 The new registry should only be extended by publishing an RFC. The 334 IANA may to add placeholders for internet-drafts at its discretion. 336 7. Acknowledgements 338 Peter Coates, Mark Crispin, Philip Guenther, Philip Van Hoof, Alexey 339 Melnikov, Ken Murchison, Chris Newman, Timo Sirainen, Dale Wiggins 340 and Sarah Wilkin helped with this document. 342 8. Normative References 344 [RFC3501] Crispin, "Internet Message Access Protocol - Version 345 4rev1", RFC 3501, University of Washington, June 2003. 347 [RFC5234] Crocker, Overell, "Augmented BNF for Syntax 348 Specifications: ABNF", RFC 5234, Brandenburg 349 Internetworking, THUS plc, January 2008. 351 9. Informative References 353 [RFC2087] Myers, "IMAP4 QUOTA extension", RFC 2087, Carnegie Mellon, 354 January 1997. 356 [RFC2180] Gahrns, "IMAP4 Multi-Accessed Mailbox Practice", RFC 2180, 357 Microsoft, July 1997. 359 [RFC4314] Melnikov, "IMAP4 Access Control List (ACL) Extension", RFC 360 4314, December 2005. 362 10. Author's Address 364 Arnt Gulbrandsen 365 Oryx Mail Systems GmbH 366 Schweppermannstr. 8 367 D-81671 Muenchen 368 Germany 370 Fax: +49 89 4502 9758 372 Email: arnt@oryx.com 374 Internet-draft December 2008 376 (RFC Editor: Please delete everything after this point) 378 Open Issues 380 I took TOOWEAK out since it doesn't seem to have real purpose: "The 381 server requires a stronger authentication mechanism. If the 382 connection is not encrypted, the client could also try the same 383 mechanism via an encrypted connection." But now I remember why it was 384 there: The server may offer e.g. AUTH=CRAM-MD5, but not be able to 385 carry that out for every user. Maybe it should be returned with a 386 better name. I'd like to hear whether anyone actually does this. 388 The name, if any, should reflect that the server cannot carry out 389 this particular mechanism for this particular authentication-id. This 390 may be because it's too weak (a policy decision) or because the 391 server lacks data for this (user,mechanism) combination. 393 Changes since -00 395 - CHILDMAILBOXEXISTS merged into INUSE. 397 - ACCESSDENIED renamed ACL to clarify its scope. 399 - NOBODYPART scheduled for deletion if noone minds. 401 - EXISTS renamed ALREADYEXISTS to avoid confusion with the EXISTS 402 response. Mustn't overload developer brains. (Do unto others.) 404 - Added a security note about how response codes makes some 405 information leaks worse. 407 - A couple of open issues. 409 Changes since -01 411 - Two people independently argued that merging ALREADYEXISTS and 412 NONEXISTENT was bad because of RENAME. Open issue closed. 414 - An example for each response code. 416 - EXPUNGED renamed, see EXISTS above. 418 - EXPUNGEISSUED semantics changed to be 2180-neutral. It should now 419 be equally useful no matter which part of 2180 the server 420 implements. 422 Internet-draft December 2008 424 - CONTACTADMIN vs. ALERT, an open issue. 426 - Added an IANA considerations section registering every (?) response 427 code defined so far. 429 - Added contact details to CONTACTADMIN, by request. 431 - Resolved the CA/SB/C issue: The three responses may be handled 432 similarly by some clients, but they may equally well be handled 433 differently, so they should not be folded. 435 Changes since -02 437 - Removed the contact details for CONTACTADMIN. I think that was 438 creeping featuritis, not likely to be implemented. 440 - Removed NOBODYPART, noone suggested use for it. 442 - Edited CORRUPTION to suggest that detailed information belongs in 443 the server logs. The client/user can bug the admin to look in the 444 log, but expecting users to transmit information is stupid. 446 - Updated the IANA list for 5255 and 5257. 448 Changes since -03 450 - Explained the criteria for inclusion/exclusion better. 452 - Fixed remove/delete typo, fix status type 454 - Better text in the CANNOT example 456 - Instruct the IANA to extend the registry only when an RFC is 457 published 459 Changes since -04 461 - ACL renamed NOPERM on request of Timo. 463 - Added METADATA, which I had overlooked. 465 - Turned ANNOTATE into just ANNOTATE, added METADATA 466 in the same way. 468 Internet-draft December 2008 470 Changes since -05 472 - Fix typo (by rewriting the sentence) 474 Changes since -06 476 - added PRIVACYREQUIRED 478 - Random formatting, since this now close to RFC