508 lines
17 KiB
Plaintext
508 lines
17 KiB
Plaintext
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
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]
|
|||
|
|