rfc1730.txt

<VC++网络游戏建摸与实现>源代码

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


              INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4



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 4 (IMAP4) allows a
   client to access and manipulate electronic mail messages on a server.
   IMAP4 permits manipulation of remote message folders, called
   "mailboxes", in a way that is functionally equivalent to local
   mailboxes.  IMAP4 also provides the capability for an offline client
   to resynchronize with the server (see also [IMAP-DISC]).

   IMAP4 includes operations for creating, deleting, and renaming
   mailboxes; checking for new messages; permanently removing messages;
   setting and clearing flags; RFC 822 and MIME parsing; searching; and
   selective fetching of message attributes, texts, and portions
   thereof.  Messages in IMAP4 are accessed by the use of numbers.
   These numbers are either message sequence numbers (relative position
   from 1 to the number of messages in the mailbox) or unique
   identifiers (immutable, strictly ascending values assigned to each
   message, but which are not necessarily contiguous).

   IMAP4 supports a single server.  A mechanism for supporting multiple
   IMAP4 servers is discussed in [IMSP].

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

   IMAP4 is designed to be upwards compatible from the [IMAP2] protocol.
   Compatibility issues are discussed in [IMAP-COMPAT].






Crispin                                                         [Page i]

RFC 1730                         IMAP4                     December 1994





Table of Contents



IMAP4 Protocol Specification ......................................    1
1.      Organization of this Document .............................    1
1.1.    How to Read This Document .................................    1
1.2.    Conventions Used in this Document .........................    1
2.      Protocol Overview .........................................    1
2.1.    Link Level ................................................    1
2.2.    Commands and Responses ....................................    1
2.2.1.  Client Protocol Sender and Server Protocol Receiver .......    2
2.2.2.  Server Protocol Sender and Client Protocol Receiver .......    2
3.      State and Flow Diagram ....................................    4
3.1.    Non-Authenticated State ...................................    4
3.2.    Authenticated State .......................................    4
3.3.    Selected State ............................................    4
3.4.    Logout State ..............................................    4
4.      Data Formats ..............................................    6
4.1.    Atom ......................................................    6
4.2.    Number ....................................................    6
4.3.    String ....................................................    6
4.3.1.  8-bit and Binary Strings ..................................    7
4.4.    Parenthesized List ........................................    7
4.5.    NIL .......................................................    7
5.      Operational Considerations ................................    8
5.1.    Mailbox Naming ............................................    8
5.2.    Mailbox Size and Message Status Updates ...................    8
5.3.    Response when no Command in Progress ......................    8
5.4.    Autologout Timer ..........................................    9
5.5.    Multiple Commands in Progress .............................    9
6.      Client Commands ...........................................   10
6.1.    Client Commands - Any State ...............................   10
6.1.1.  CAPABILITY Command ........................................   10
6.1.2.  NOOP Command ..............................................   11
6.1.3.  LOGOUT Command ............................................   11
6.2.    Client Commands - Non-Authenticated State .................   12
6.2.1.  AUTHENTICATE Command ......................................   12
6.2.2.  LOGIN Command .............................................   14
6.3.    Client Commands - Authenticated State .....................   14
6.3.1.  SELECT Command ............................................   15
6.3.2.  EXAMINE Command ...........................................   16
6.3.3.  CREATE Command ............................................   17
6.3.4.  DELETE Command ............................................   18
6.3.5.  RENAME Command ............................................   18



Crispin                                                        [Page ii]

RFC 1730                         IMAP4                     December 1994


6.3.6.  SUBSCRIBE Command .........................................   19
6.3.7.  UNSUBSCRIBE Command .......................................   19
6.3.8.  LIST Command ..............................................   20
6.3.9.  LSUB Command ..............................................   22
6.3.10. APPEND Command ............................................   22
6.4.    Client Commands - Selected State ..........................   23
6.4.1.  CHECK Command .............................................   23
6.4.2.  CLOSE Command .............................................   24
6.4.3.  EXPUNGE Command ...........................................   25
6.4.4.  SEARCH Command ............................................   25
6.4.5.  FETCH Command .............................................   29
6.4.6.  PARTIAL Command ...........................................   32
6.4.7.  STORE Command .............................................   33
6.4.8.  COPY Command ..............................................   34
6.4.9.  UID Command ...............................................   35
6.5.    Client Commands - Experimental/Expansion ..................   37
6.5.1.  X<atom> Command ...........................................   37
7.      Server Responses ..........................................   38
7.1.    Server Responses - Status Responses .......................   39
7.1.1.  OK Response ...............................................   40
7.1.2.  NO Response ...............................................   40
7.1.3.  BAD Response ..............................................   41
7.1.4.  PREAUTH Response ..........................................   41
7.1.5.  BYE Response ..............................................   41
7.2.    Server Responses - Server and Mailbox Status ..............   42
7.2.1.  CAPABILITY Response .......................................   42
7.2.2.  LIST Response .............................................   43
7.2.3.  LSUB Response .............................................   44
7.2.4.  SEARCH Response ...........................................   44
7.2.5.  FLAGS Response ............................................   44
7.3.    Server Responses - Message Status .........................   45
7.3.1.  EXISTS Response ...........................................   45
7.3.2.  RECENT Response ...........................................   45
7.3.3.  EXPUNGE Response ..........................................   45
7.3.4.  FETCH Response ............................................   46
7.3.5.  Obsolete Responses ........................................   51
7.4.    Server Responses - Command Continuation Request ...........   51
8.      Sample IMAP4 session ......................................   52
9.      Formal Syntax .............................................   53
10.     Author's Note .............................................   64
11.     Security Considerations ...................................   64
12.     Author's Address ..........................................   64
Appendices ........................................................   65
A.      Obsolete Commands .........................................   65
A.6.3.OBS.1.    FIND ALL.MAILBOXES Command ........................   65
A.6.3.OBS.2.    FIND MAILBOXES Command ............................   65
A.6.3.OBS.3.    SUBSCRIBE MAILBOX Command .........................   66
A.6.3.OBS.4.    UNSUBSCRIBE MAILBOX Command .......................   66



Crispin                                                       [Page iii]

RFC 1730                         IMAP4                     December 1994


B.      Obsolete Responses ........................................   68
B.7.2.OBS.1.    MAILBOX Response ..................................   68
B.7.3.OBS.1.    COPY Response .....................................   68
B.7.3.OBS.2.    STORE Response ....................................   69
C.      References ................................................   70
E.      IMAP4 Keyword Index .......................................   71













































Crispin                                                        [Page iv]

RFC 1730                         IMAP4                     December 1994


IMAP4 Protocol Specification

1.      Organization of this Document

1.1.    How to Read This Document

   This document is written from the point of view of the implementor of
   an IMAP4 client or server.  Beyond the protocol overview in section
   2, it is not optimized for someone trying to understand the operation
   of the protocol.  The material in sections 3 through 5 provides the
   general context and definitions with which IMAP4 operates.

   Sections 6, 7, and 9 describe the IMAP commands, responses, and
   syntax, respectively.  The relationships among these are such that it
   is almost impossible to understand any of them separately.  In
   particular, one should not attempt to deduce command syntax from the
   command section alone; one should instead refer to the formal syntax
   section.


1.2.    Conventions Used in this Document

   In examples, "C:" and "S:" indicate lines sent by the client and
   server respectively.


2.      Protocol Overview

2.1.    Link Level

   The IMAP4 protocol assumes a reliable data stream such as provided by
   TCP.  When TCP is used, an IMAP4 server listens on port 143.


2.2.    Commands and Responses

   An IMAP4 session consists of the establishment of a client/server
   connection, an initial greeting from the server, and client/server
   interactions.  These client/server interactions consist of a client
   command, server data, and a server completion result response.

   All interactions transmitted by client and server are in the form of
   lines; that is, strings that end with a CRLF.  The protocol receiver
   of an IMAP4 client or server is either reading a line, or is reading
   a sequence of octets with a known count followed by a line.






Crispin                                                         [Page 1]

RFC 1730                         IMAP4                     December 1994


2.2.1.  Client Protocol Sender and Server Protocol Receiver

   The client command begins an operation.  Each client command is
   prefixed with a identifier (typically a short alphanumeric string,
   e.g. A0001, A0002, etc.) called a "tag".  A different tag is
   generated by the client for each command.

   There are two cases in which a line from the client does not
   represent a complete command.  In one case, a command argument is
   quoted with an octet count (see the description of literal in String
   under Data Formats); in the other case, the command arguments require
   server feedback (see the AUTHENTICATE command).  In either case, the
   server sends a command continuation request response if it is ready
   for the octets (if appropriate) and the remainder of the command.
   This response is prefixed with the token "+".

        Note: If, instead, the server detected an error in the
        command, it sends a BAD completion response with tag
        matching the command (as described below) to reject the
        command and prevent the client from sending any more of the
        command.

        It is also possible for the server to send a completion
        response for some other command (if multiple commands are
        in progress), or untagged data.  In either case, the
        command continuation request is still pending; the client
        takes the appropriate action for the response, and reads
        another response from the server.

   The protocol receiver of an IMAP4 server reads a command line from
   the client, parses the command and its arguments, and transmits
   server data and a server command completion result response.


2.2.2.  Server Protocol Sender and Client Protocol Receiver

   Data transmitted by the server to the client and status responses
   that do not indicate command completion are prefixed with the token
   "*", and are called untagged responses.

   Server data may be sent as a result of a client command, or may be
   sent unilaterally by the server.  There is no syntactic difference
   between server data that resulted from a specific command and server
   data that were sent unilaterally.

   The server completion result response indicates the success or
   failure of the operation.  It is tagged with the same tag as the
   client command which began the operation.  Thus, if more than one



Crispin                                                         [Page 2]

RFC 1730                         IMAP4                     December 1994


   command is in progress, the tag in a server completion response
   identifies the command to which the response applies.  There are
   three possible server completion responses: OK (indicating success),
   NO (indicating failure), or BAD (indicating protocol error such as
   unrecognized command or command syntax error).

   The protocol receiver of an IMAP4 client reads a response line from
   the server.  It then takes action on the response based upon the
   first token of the response, which may be a tag, a "*", or a "+".  As
   described above.

   A client MUST be prepared to accept any server response at all times.
   This includes server data that it may not have requested.  Server
   data SHOULD be recorded, so that the client can reference its
   recorded copy rather than sending a command to the server to request
   the data.  In the case of certain server data, recording the data is
   mandatory.

   This topic is discussed in greater detail in the Server Responses
   section.