datatracker.ietf.org
Sign in
Version 5.9.0, 2014-12-18
Report a bug

IMAP Response Codes
RFC 5530

Document type: RFC - Proposed Standard (May 2009; No errata)
Was draft-gulbrandsen-imap-response-codes (individual in app area)
Document stream: IETF
Last updated: 2013-03-02
Other versions: plain text, pdf, html

IETF State: (None)
Consensus: Unknown
Document shepherd: No shepherd assigned

IESG State: RFC 5530 (Proposed Standard)
Responsible AD: Chris Newman
Send notices to: arnt@oryx.com, draft-gulbrandsen-imap-response-codes@tools.ietf.org, alexey.melnikov@isode.com

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

[include full document text]