WDIFF

draft-gulbrandsen-imap-response-codes-07.txt --> rfc5530.txt

Network Working Group Arnt A. Gulbrandsen
Internet-Draft
Request for Comments: 5530 Oryx Mail Systems GmbH
Intended Status: Proposed Standard December 15, 2008
Category: Standards Track May 2009

IMAP Response Codes
draft-gulbrandsen-imap-response-codes-07.txt

Status of this This Memo

This Internet-Draft is submitted document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to IETF in full conformance with the
provisions current edition of BCP 78 the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and BCP 79. status of this protocol. Distribution of this memo is unlimited.

This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.

Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.

Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."

The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-
Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.

This Internet-Draft expires in June 2009.

Gulbrandsen Expires June 2009 [Page 1]

Internet-draft December 2008

Abstract

IMAP responses consist of a response type (OK, NO, BAD), an optional
machine-readable response code 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. 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.

2. Introduction

[RFC3501] section

Section 7.1 of [RFC3501] defines a number of response codes which 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

Currently, many IMAP servers use English-language 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 in of some IMAP clients.

This document doesn't require any servers to test for these errors, errors or
any clients to test for these names. It only names errors for better
reporting and handling.

[RFC Editor: Please remove this paragraph.] In general, this document
aims to do that which

2. Conventions Used in This Document

Formal syntax is widely considered good, and nothing more.
Several controversial and/or complex features were discussed, but
just listing defined by [RFC5234] as modified by [RFC3501].

Example lines prefaced by "C:" are sent by the simple client and desirable response codes is enough for
one document. 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.

Gulbrandsen Expires June 2009 [Page 2]

Internet-draft December 2008

UNAVAILABLE
Temporary failure because a subsystem is down. For example, an
IMAP server which that uses an LDAP 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 not willing
unwilling to elaborate. Typically 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. 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, succeeded in using the authentication identity,
but the server cannot or will not allow the authentication
identity to act as the requested authorization
failed. identity. This
is only applicable when the authentication and authorization
identities are different.

C: c c1 AUTHENTICATE PLAIN
[...]
S: c c1 NO [AUTHORIZATIONFAILED] No such auth-ID

EXPIRED Authentication succeeded or the server didn't have the
necessary data any more, but 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 TLS
Transport Layer Security (TLS) is not in use, the client could
try STARTTLS (see [RFC3501] section 6.2.1) 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 Expires June 2009 Standards Track [Page 3]

Internet-draft December 2008

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. ACL, (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 it
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. (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

Gulbrandsen Expires June 2009 [Page 4]

Internet-draft December 2008

CLIENTBUG
The server has detected a client bug. This can accompany all
of OK, NO 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 is 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 is or 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 which 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

Gulbrandsen Expires June 2009 [Page 5]

Internet-draft December 2008

NONEXISTENT
The operation attempts to delete something which 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 lower case 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 Considerations

Revealing information about a passphrase to unauthenticated IMAP
clients has 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.

Gulbrandsen Expires June 2009 [Page 6]

Internet-draft December 2008

6. IANA considerations Considerations

The IANA is requested to create a new registry, tentatively named
imap-response-codes, and populate it as follows: 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 (draft-daboo-imap-annotatemore-16.txt) 5464
NOTIFICATIONOVERFLOW RFC 5465
BADEVENT RFC 5465
UNDEFINED-FILTER RFC 5466
UNAVAILABLE RFC (this) 5530
AUTHENTICATIONFAILED RFC (this) 5530
AUTHORIZATIONFAILED RFC (this) 5530

Gulbrandsen Standards Track [Page 7]

RFC 5530 IMAP Response Codes May 2009

EXPIRED RFC (this) 5530
PRIVACYREQUIRED RFC (this) 5530
CONTACTADMIN RFC (this) 5530
NOPERM RFC (this) 5530
INUSE RFC (this) 5530
EXPUNGEISSUED RFC (this) 5530
CORRUPTION RFC (this) 5530
SERVERBUG RFC (this) 5530
CLIENTBUG RFC (this) 5530
CANNOT RFC (this) 5530
LIMIT RFC (this) 5530
OVERQUOTA RFC (this) 5530
ALREADYEXISTS RFC (this) 5530
NONEXISTENT RFC (this)

Gulbrandsen Expires June 2009 [Page 7]

Internet-draft December 2008

The RFC editor is requested to delete this entire text, and insert a
sentence or two mentioning the registry's URL instead. 5530

The new registry should only can be extended by publishing an RFC. The sending a registration request to
IANA. IANA may will forward this request to add placeholders for internet-drafts a Designated Expert,
appointed by the responsible IESG Area Director, CCing it to the IMAP
Extensions mailing list at its discretion.

7. Acknowledgements

Peter Coates, Mark Crispin, Philip Guenther, Philip Van Hoof, Alexey
Melnikov, Ken Murchison, Chris Newman, Timo Sirainen, Dale Wiggins <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 Sarah Wilkin helped with this document.

8. Normative References

[RFC3501] Crispin, "Internet Message Access Protocol - Version
4rev1", RFC 3501, University either approve or disapprove the request by
sending a notice of Washington, June 2003.

[RFC5234] Crocker, Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 5234, Brandenburg
Internetworking, THUS plc, January 2008.

9. Informative References

[RFC2087] Myers, "IMAP4 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, Carnegie Mellon, January
1997.

[RFC2180] Gahrns, M., "IMAP4 Multi-Accessed Mailbox Practice", RFC
2180,
Microsoft, July 1997.

[RFC4314] Melnikov, A., "IMAP4 Access Control List (ACL) Extension",
RFC 4314, December 2005.

10.

Author's Address

Arnt Gulbrandsen
Oryx Mail Systems GmbH
Schweppermannstr. 8
D-81671 Muenchen
Germany

Fax: +49 89 4502 9758

Email:
EMail: arnt@oryx.com

Gulbrandsen Expires June 2009 [Page 8]

Internet-draft December 2008

(RFC Editor: Please delete everything after this point)

Open Issues

I took TOOWEAK out since it doesn't seem to have real purpose: "The
server requires a stronger authentication mechanism. If the
connection is not encrypted, the client could also try the same
mechanism via an encrypted connection." But now I remember why it was
there: The server may offer e.g. AUTH=CRAM-MD5, but not be able to
carry that out for every user. Maybe it should be returned with a
better name. I'd like to hear whether anyone actually does this.

The name, if any, should reflect that the server cannot carry out
this particular mechanism for this particular authentication-id. This
may be because it's too weak (a policy decision) or because the
server lacks data for this (user,mechanism) combination.

Changes since -00

- CHILDMAILBOXEXISTS merged into INUSE.

- ACCESSDENIED renamed ACL to clarify its scope.

- NOBODYPART scheduled for deletion if noone minds.

- EXISTS renamed ALREADYEXISTS to avoid confusion with the EXISTS
response. Mustn't overload developer brains. (Do unto others.)

- Added a security note about how response codes makes some
information leaks worse.

- A couple of open issues.

Changes since -01

- Two people independently argued that merging ALREADYEXISTS and
NONEXISTENT was bad because of RENAME. Open issue closed.

- An example for each response code.

- EXPUNGED renamed, see EXISTS above.

- EXPUNGEISSUED semantics changed to be 2180-neutral. It should now
be equally useful no matter which part of 2180 the server
implements.

Gulbrandsen Expires June 2009 Standards Track [Page 9]

Internet-draft December 2008

- CONTACTADMIN vs. ALERT, an open issue.

- Added an IANA considerations section registering every (?) response
code defined so far.

- Added contact details to CONTACTADMIN, by request.

- Resolved the CA/SB/C issue: The three responses may be handled
similarly by some clients, but they may equally well be handled
differently, so they should not be folded.

Changes since -02

- Removed the contact details for CONTACTADMIN. I think that was
creeping featuritis, not likely to be implemented.

- Removed NOBODYPART, noone suggested use for it.

- Edited CORRUPTION to suggest that detailed information belongs in
the server logs. The client/user can bug the admin to look in the
log, but expecting users to transmit information is stupid.

- Updated the IANA list for 5255 and 5257.

Changes since -03

- Explained the criteria for inclusion/exclusion better.

- Fixed remove/delete typo, fix status type

- Better text in the CANNOT example

- Instruct the IANA to extend the registry only when an RFC is
published

Changes since -04

- ACL renamed NOPERM on request of Timo.

- Added METADATA, which I had overlooked.

- Turned ANNOTATE <VARIOUS> into just ANNOTATE, added METADATA
<VARIOUS> in the same way.

Gulbrandsen Expires June 2009 [Page 10]

Internet-draft December 2008

Changes since -05

- Fix typo (by rewriting the sentence)

Changes since -06

- added PRIVACYREQUIRED

- Random formatting, since this now close to RFC

Gulbrandsen Expires June 2009 [Page 11]

----