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 [email protected]
        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 <[email protected]> (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: [email protected]






Gulbrandsen                 Standards Track                     [Page 9]


You are viewing proxied material from gopher.fnord.one. The copyright of proxied material belongs to its original authors. Any comments or complaints in relation to proxied material should be directed to the original authors of the content concerned. Please see the disclaimer for more details.