    Network Working Group                                     A. Gulbrandsen
    Request for Comments: 5530                        Oryx Mail Systems GmbH
    Category: Standards Track                                       May 2009

                              IMAP Response Codes

    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 BCP 78 and the IETF Trust's Legal
       Provisions Relating to IETF Documents in effect on the date of
       publication of this document (http://trustee.ietf.org/license-info).
       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.

    Gulbrandsen                 Standards Track                     [Page 1]

    RFC 5530                  IMAP Response Codes                   May 2009

    1.  Introduction

       Section 7.1 of [RFC3501] 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.

    2.  Conventions Used in This Document

       Formal syntax is defined by [RFC5234] as modified by [RFC3501].

       Example lines prefaced by "C:" are sent by the client and ones
       prefaced by "S:" by the server.  "[...]" means elision.

    3.  Response Codes

       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".

    Gulbrandsen                 Standards Track                     [Page 2]

    RFC 5530                  IMAP Response Codes                   May 2009

             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 Section 6.2.1 of [RFC3501]) 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

    Gulbrandsen                 Standards Track                     [Page 3]

    RFC 5530                  IMAP Response Codes                   May 2009

       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
             [RFC4314]) 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.  [RFC2180] 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

    Gulbrandsen                 Standards Track                     [Page 4]

    RFC 5530                  IMAP Response Codes                   May 2009

       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 [RFC2087], 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

    Gulbrandsen                 Standards Track                     [Page 5]

    RFC 5530                  IMAP Response Codes                   May 2009

       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

    4.  Formal Syntax

       The following syntax specification uses the Augmented Backus-Naur
       Form (ABNF) notation as specified in [RFC5234].  [RFC3501] 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"

    5.  Security Considerations

       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

    Gulbrandsen                 Standards Track                     [Page 6]

    RFC 5530                  IMAP Response Codes                   May 2009

       leaked information to the user.  Server authors are encouraged to be
       particularly careful with the NOPERM and authentication-related
       responses.

    6.  IANA Considerations

       The IANA has created the IMAP Response Codes registry.  The registry
       has been populated with the following codes:

          NEWNAME              RFC 2060 (obsolete)
          REFERRAL             RFC 2221
          ALERT                RFC 3501
          BADCHARSET           RFC 3501
          PARSE                RFC 3501
          PERMANENTFLAGS       RFC 3501
          READ-ONLY            RFC 3501
          READ-WRITE           RFC 3501
          TRYCREATE            RFC 3501
          UIDNEXT              RFC 3501
          UIDVALIDITY          RFC 3501
          UNSEEN               RFC 3501
          UNKNOWN-CTE          RFC 3516
          UIDNOTSTICKY         RFC 4315
          APPENDUID            RFC 4315
          COPYUID              RFC 4315
          URLMECH              RFC 4467
          TOOBIG               RFC 4469
          BADURL               RFC 4469
          HIGHESTMODSEQ        RFC 4551
          NOMODSEQ             RFC 4551
          MODIFIED             RFC 4551
          COMPRESSIONACTIVE    RFC 4978
          CLOSED               RFC 5162
          NOTSAVED             RFC 5182
          BADCOMPARATOR        RFC 5255
          ANNOTATE             RFC 5257
          ANNOTATIONS          RFC 5257
          TEMPFAIL             RFC 5259
          MAXCONVERTMESSAGES   RFC 5259
          MAXCONVERTPARTS      RFC 5259
          NOUPDATE             RFC 5267
          METADATA             RFC 5464
          NOTIFICATIONOVERFLOW RFC 5465
          BADEVENT             RFC 5465
          UNDEFINED-FILTER     RFC 5466
          UNAVAILABLE          RFC 5530
          AUTHENTICATIONFAILED RFC 5530
          AUTHORIZATIONFAILED  RFC 5530

    Gulbrandsen                 Standards Track                     [Page 7]

    RFC 5530                  IMAP Response Codes                   May 2009

          EXPIRED              RFC 5530
          PRIVACYREQUIRED      RFC 5530
          CONTACTADMIN         RFC 5530
          NOPERM               RFC 5530
          INUSE                RFC 5530
          EXPUNGEISSUED        RFC 5530
          CORRUPTION           RFC 5530
          SERVERBUG            RFC 5530
          CLIENTBUG            RFC 5530
          CANNOT               RFC 5530
          LIMIT                RFC 5530
          OVERQUOTA            RFC 5530
          ALREADYEXISTS        RFC 5530
          NONEXISTENT          RFC 5530

       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".

    Gulbrandsen                 Standards Track                     [Page 8]

    RFC 5530                  IMAP Response Codes                   May 2009

       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.

    7.  Acknowledgements

       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.

    8.  References

    8.1.  Normative References

       [RFC3501]  Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
                  4rev1", RFC 3501, March 2003.

       [RFC5234]  Crocker, D., Ed., and P. Overell, "Augmented BNF for
                  Syntax Specifications: ABNF", STD 68, RFC 5234, January
                  2008.

    9.  Informative References

       [RFC2087]  Myers, J., "IMAP4 QUOTA extension", RFC 2087, January
                  1997.

       [RFC2180]  Gahrns, M., "IMAP4 Multi-Accessed Mailbox Practice", RFC
                  2180, July 1997.

       [RFC4314]  Melnikov, A., "IMAP4 Access Control List (ACL) Extension",
                  RFC 4314, 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]