Internet Message Access Protocol RFC 2060

Network Working Group                                        M. Crispin
Request for Comments: 2060                     University of Washington
Obsoletes: 1730                                           December 1996
Category: Standards Track

            INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1

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.

Abstract

   The Internet Message Access Protocol, Version 4rev1 (IMAP4rev1)
   allows a client to access and manipulate electronic mail messages on
   a server.  IMAP4rev1 permits manipulation of remote message folders,
   called "mailboxes", in a way that is functionally equivalent to local
   mailboxes.  IMAP4rev1 also provides the capability for an offline
   client to resynchronize with the server (see also [IMAP-DISC]).

   IMAP4rev1 includes operations for creating, deleting, and renaming
   mailboxes; checking for new messages; permanently removing messages;
   setting and clearing flags; [RFC-822] and [MIME-IMB] parsing;
   searching; and selective fetching of message attributes, texts, and
   portions thereof.  Messages in IMAP4rev1 are accessed by the use of
   numbers.  These numbers are either message sequence numbers or unique
   identifiers.

   IMAP4rev1 supports a single server.  A mechanism for accessing
   configuration information to support multiple IMAP4rev1 servers is
   discussed in [ACAP].

   IMAP4rev1 does not specify a means of posting mail; this function is
   handled by a mail transfer protocol such as [SMTP].

   IMAP4rev1 is designed to be upwards compatible from the [IMAP2] and
   unpublished IMAP2bis protocols.  In the course of the evolution of
   IMAP4rev1, some aspects in the earlier protocol have become obsolete.
   Obsolete commands, responses, and data formats which an IMAP4rev1
   implementation may encounter when used with an earlier implementation
   are described in [IMAP-OBSOLETE].

   Other compatibility issues with IMAP2bis, the most common variant of
   the earlier protocol, are discussed in [IMAP-COMPAT].  A full
   discussion of compatibility issues with rare (and presumed extinct)
   variants of [IMAP2] is in [IMAP-HISTORICAL]; this document is
   primarily of historical interest.

Table of Contents

1. How to Read This Document 
1.1. Organization of This Document 
1.2. Conventions Used in This Document 
2. Protocol Overview 
2.1. Link Level 
2.2. Commands and Responses 
2.2.1. Client Protocol Sender and Server Protocol Receiver 
2.2.2. Server Protocol Sender and Client Protocol Receiver 
2.3. Message Attributes 
2.3.1. Message Numbers 
2.3.1.1. Unique Identifier (UID) Message Attribute 
2.3.1.2. Message Sequence Number Message Attribute 
2.3.2. Flags Message Attribute 
2.3.3. Internal Date Message Attribute 
2.3.4. [RFC-822] Size Message Attribute 
2.3.5. Envelope Structure Message Attribute 
2.3.6. Body Structure Message Attribute 
2.4. Message Texts 
3. State and Flow Diagram 
3.1. Non-Authenticated State 
3.2. Authenticated State 
3.3. Selected State 
3.4. Logout State 
4. Data Formats 
4.1. Atom 
4.2. Number 
4.3. String 
4.3.1. 8-bit and Binary Strings 
4.4. Parenthesized List 
4.5. NIL 
5. Operational Considerations 
5.1. Mailbox Naming 
5.1.1. Mailbox Hierarchy Naming 
5.1.2. Mailbox Namespace Naming Convention 
5.1.3. Mailbox International Naming Convention 
5.2. Mailbox Size and Message Status Updates 
5.3. Response when no Command in Progress 
5.4. Autologout Timer 
5.5. Multiple Commands in Progress 

6. Client Commands 
6.1. Client Commands - Any State 
6.1.1. CAPABILITY Command 
6.1.2. NOOP Command 
6.1.3. LOGOUT Command 
6.2. Client Commands - Non-Authenticated State 
6.2.1. AUTHENTICATE Command 
6.2.2. LOGIN Command 
6.3. Client Commands - Authenticated State 
6.3.1. SELECT Command 
6.3.2. EXAMINE Command 
6.3.3. CREATE Command 
6.3.4. DELETE Command 
6.3.5. RENAME Command 
6.3.6. SUBSCRIBE Command 
6.3.7. UNSUBSCRIBE Command 
6.3.8. LIST Command 
6.3.9. LSUB Command 
6.3.10. STATUS Command 
6.3.11. APPEND Command 
6.4. Client Commands - Selected State 
6.4.1. CHECK Command 
6.4.2. CLOSE Command 
6.4.3. EXPUNGE Command 
6.4.4. SEARCH Command 
6.4.5. FETCH Command 
6.4.6. STORE Command 
6.4.7. COPY Command 
6.4.8. UID Command 
6.5. Client Commands - Experimental/Expansion 
6.5.1. X Command 
7. Server Responses 
7.1. Server Responses - Status Responses 
7.1.1. OK Response 
7.1.2. NO Response 
7.1.3. BAD Response 
7.1.4. PREAUTH Response 
7.1.5. BYE Response 
7.2. Server Responses - Server and Mailbox Status 
7.2.1. CAPABILITY Response 
7.2.2. LIST Response 
7.2.3. LSUB Response 
7.2.4 STATUS Response 
7.2.5. SEARCH Response 
7.2.6. FLAGS Response 
7.3. Server Responses - Mailbox Size 
7.3.1. EXISTS Response 
7.3.2. RECENT Response 

7.4. Server Responses - Message Status 
7.4.1. EXPUNGE Response 
7.4.2. FETCH Response 
7.5. Server Responses - Command Continuation Request 
8. Sample IMAP4rev1 connection 
9. Formal Syntax 
10. Author's Note 
11. Security Considerations 
12. Author's Address 
A. References 
B. Changes from RFC 1730