IMAP Response Codes
RFC 5530

Document Type RFC - Proposed Standard (May 2009; No errata)
Was draft-gulbrandsen-imap-response-codes (individual in app area)
Author Arnt Gulbrandsen 
Last updated 2018-12-20
Stream IETF
Formats plain text html pdf htmlized bibtex
Stream WG state (None)
Document shepherd No shepherd assigned
IESG IESG state RFC 5530 (Proposed Standard)
Action Holders
Consensus Boilerplate Unknown
Telechat date
Responsible AD Chris Newman
Send notices to
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 (
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.


   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.

         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

         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

         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.

         S: c1 NO [AUTHORIZATIONFAILED] No such authorization-ID

         S: c2 NO [AUTHORIZATIONFAILED] Authenticator is not an admin

         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

         C: d login "fred" "foo"
         S: d NO [EXPIRED] That password isn't valid any more

         The operation is not permitted due to a lack of privacy.  If
         Transport Layer Security (TLS) is not in use, the client could
Show full document text