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
datatracker.ietf.org