rfc3501_en.htm

因特网邮件访问协议－版本4rev1简体中文版。因特网邮件访问协议

as opposed to an optional facility of the<BR>protocol.<BR><BR>"User" is used to 
refer to a human user, whereas "client" refers to<BR>the software being run by 
the user.<BR><BR>"Connection" refers to the entire sequence of 
client/server<BR>interaction from the initial establishment of the network 
connection<BR>until its termination.<BR><BR>"Session" refers to the sequence of 
client/server interaction from<BR>the time that a mailbox is selected (SELECT or 
EXAMINE command) until<BR>the time that selection ends (SELECT or EXAMINE of 
another mailbox,<BR>CLOSE command, or connection termination).<BR><BR>Characters 
are 7-bit US-ASCII unless otherwise specified. Other<BR>character sets are 
indicated using a "CHARSET", as described in<BR>[MIME-IMT] and defined in 
[CHARSET]. CHARSETs have important<BR>additional semantics in addition to 
defining character set; refer to<BR>these documents for more 
detail.<BR><BR>There are several protocol conventions in IMAP. These refer 
to<BR>aspects of the specification which are not strictly part of the 
IMAP<BR>protocol, but reflect generally-accepted practice. 
Implementations<BR>need to be aware of these conventions, and avoid conflicts 
whether or<BR>not they implement the convention. For example, "&amp;" may not be 
used<BR>as a hierarchy delimiter since it conflicts with the 
Mailbox<BR>International Naming Convention, and other uses of "&amp;" in 
mailbox<BR>names are impacted as well.<BR><BR>1.3. Special Notes to 
Implementors<BR><BR>Implementors of the IMAP protocol are strongly encouraged to 
read the<BR>IMAP implementation recommendations document [IMAP-IMPLEMENTATION] 
in<BR>conjunction with this document, to help understand the intricacies 
of<BR>this protocol and how best to build an interoperable 
product.<BR><BR>IMAP4rev1 is designed to be upwards compatible from the [IMAP2] 
and<BR>unpublished IMAP2bis protocols. IMAP4rev1 is largely compatible 
with<BR>the IMAP4 protocol described in <A 
href="http://www.jzdb.cn/Net/xieyi/index.html/rfcs/rfc1730.html"><U><FONT 
color=#0000ff>RFC1730</FONT></U></A>; the exception being in<BR>certain 
facilities added in <A 
href="http://www.jzdb.cn/Net/xieyi/index.html/rfcs/rfc1730.html"><U><FONT 
color=#0000ff>RFC1730</FONT></U></A> that proved problematic and 
were<BR>subsequently removed. In the course of the evolution of 
IMAP4rev1,<BR>some aspects in the earlier protocols have become obsolete. 
Obsolete<BR>commands, responses, and data formats which an 
IMAP4rev1<BR>implementation can encounter when used with an earlier 
implementation<BR>are described in [IMAP-OBSOLETE].<BR><BR>Other compatibility 
issues with IMAP2bis, the most common variant of<BR>the earlier protocol, are 
discussed in [IMAP-COMPAT]. A full<BR>discussion of compatibility issues with 
rare (and presumed extinct)<BR><BR>variants of [IMAP2] is in [IMAP-HISTORICAL]; 
this document is<BR>primarily of historical interest.<BR><BR>IMAP was originally 
developed for the older [<A 
href="http://www.jzdb.cn/Net/xieyi/index.html/rfcs/rfc822.html"><U><FONT 
color=#0000ff>RFC-822</FONT></U></A>] standard, and<BR>as a consequence several 
fetch items in IMAP incorporate "<A 
href="http://www.jzdb.cn/Net/xieyi/index.html/rfcs/rfc822.html"><U><FONT 
color=#0000ff>RFC822</FONT></U></A>" in<BR>their name. With the exception of <A 
href="http://www.jzdb.cn/Net/xieyi/index.html/rfcs/rfc822.html"><U><FONT 
color=#0000ff>RFC822</FONT></U></A>.SIZE, there are more modern<BR>replacements; 
for example, the modern version of <A 
href="http://www.jzdb.cn/Net/xieyi/index.html/rfcs/rfc822.html"><U><FONT 
color=#0000ff>RFC822</FONT></U></A>.HEADER is<BR>BODY.PEEK[HEADER]. In all 
cases, "<A 
href="http://www.jzdb.cn/Net/xieyi/index.html/rfcs/rfc822.html"><U><FONT 
color=#0000ff>RFC822</FONT></U></A>" should be interpreted as a<BR>reference to 
the updated [<A 
href="http://www.jzdb.cn/Net/xieyi/index.html/rfcs/rfc2822.html"><U><FONT 
color=#0000ff>RFC-2822</FONT></U></A>] standard.<BR><BR>2. Protocol 
Overview<BR><BR>2.1. Link Level<BR><BR>The IMAP4rev1 protocol assumes a reliable 
data stream such as that<BR>provided by TCP. When TCP is used, an IMAP4rev1 
server listens on<BR>port 143.<BR><BR>2.2. Commands and Responses<BR><BR>An 
IMAP4rev1 connection consists of the establishment of a<BR>client/server network 
connection, an initial greeting from the<BR>server, and client/server 
interactions. These client/server<BR>interactions consist of a client command, 
server data, and a server<BR>completion result response.<BR><BR>All interactions 
transmitted by client and server are in the form of<BR>lines, that is, strings 
that end with a CRLF. The protocol receiver<BR>of an IMAP4rev1 client or server 
is either reading a line, or is<BR>reading a sequence of octets with a known 
count followed by a line.<BR><BR>2.2.1. Client Protocol Sender and Server 
Protocol Receiver<BR><BR>The client command begins an operation. Each client 
command is<BR>prefixed with an identifier (typically a short alphanumeric 
string,<BR>e.g., A0001, A0002, etc.) called a "tag". A different tag 
is<BR>generated by the client for each command.<BR><BR>Clients MUST follow the 
syntax outlined in this specification<BR>strictly. It is a syntax error to send 
a command with missing or<BR>extraneous spaces or arguments.<BR><BR>There are 
two cases in which a line from the client does not<BR>represent a complete 
command. In one case, a command argument is<BR>quoted with an octet count (see 
the description of literal in String<BR>under Data Formats); in the other case, 
the command arguments require<BR>server feedback (see the AUTHENTICATE command). 
In either case, the<BR><BR>server sends a command continuation request response 
if it is ready<BR>for the octets (if appropriate) and the remainder of the 
command.<BR>This response is prefixed with the token "+".<BR><BR>Note: If 
instead, the server detected an error in the<BR>command, it sends a BAD 
completion response with a tag<BR>matching the command (as described below) to 
reject the<BR>command and prevent the client from sending any more of 
the<BR>command.<BR><BR>It is also possible for the server to send a 
completion<BR>response for some other command (if multiple commands are<BR>in 
progress), or untagged data. In either case, the<BR>command continuation request 
is still pending; the client<BR>takes the appropriate action for the response, 
and reads<BR>another response from the server. In all cases, the client<BR>MUST 
send a complete command (including receiving all<BR>command continuation request 
responses and command<BR>continuations for the command) before initiating a 
new<BR>command.<BR><BR>The protocol receiver of an IMAP4rev1 server reads a 
command line<BR>from the client, parses the command and its arguments, and 
transmits<BR>server data and a server command completion result 
response.<BR><BR>2.2.2. Server Protocol Sender and Client Protocol 
Receiver<BR><BR>Data transmitted by the server to the client and status 
responses<BR>that do not indicate command completion are prefixed with the 
token<BR>"*", and are called untagged responses.<BR><BR>Server data MAY be sent 
as a result of a client command, or MAY be<BR>sent unilaterally by the server. 
There is no syntactic difference<BR>between server data that resulted from a 
specific command and server<BR>data that were sent unilaterally.<BR><BR>The 
server completion result response indicates the success or<BR>failure of the 
operation. It is tagged with the same tag as the<BR>client command which began 
the operation. Thus, if more than one<BR>command is in progress, the tag in a 
server completion response<BR>identifies the command to which the response 
applies. There are<BR>three possible server completion responses: OK (indicating 
success),<BR>NO (indicating failure), or BAD (indicating a protocol error such 
as<BR>unrecognized command or command syntax error).<BR><BR>Servers SHOULD 
enforce the syntax outlined in this specification<BR>strictly. Any client 
command with a protocol syntax error, including<BR>(but not limited to) missing 
or extraneous spaces or arguments,<BR><BR>SHOULD be rejected, and the client 
given a BAD server completion<BR>response.<BR><BR>The protocol receiver of an 
IMAP4rev1 client reads a response line<BR>from the server. It then takes action 
on the response based upon the<BR>first token of the response, which can be a 
tag, a "*", or a "+".<BR><BR>A client MUST be prepared to accept any server 
response at all times.<BR>This includes server data that was not requested. 
Server data SHOULD<BR>be recorded, so that the client can reference its recorded 
copy<BR>rather than sending a command to the server to request the data. 
In<BR>the case of certain server data, the data MUST be recorded.<BR><BR>This 
topic is discussed in greater detail in the Server 
Responses<BR>section.<BR><BR>2.3. Message Attributes<BR><BR>In addition to 
message text, each message has several attributes<BR>associated with it. These 
attributes can be retrieved individually<BR>or in conjunction with other 
attributes or message texts.<BR><BR>2.3.1. Message Numbers<BR><BR>Messages in 
IMAP4rev1 are accessed by one of two numbers; the unique<BR>identifier or the 
message sequence number.<BR><BR>2.3.1.1. Unique Identifier (UID) Message 
Attribute<BR><BR>A 32-bit value assigned to each message, which when used with 
the<BR>unique identifier validity value (see below) forms a 64-bit value<BR>that 
MUST NOT refer to any other message in the mailbox or any<BR>subsequent mailbox 
with the same name forever. Unique identifiers<BR>are assigned in a strictly 
ascending fashion in the mailbox; as each<BR>message is added to the mailbox it 
is assigned a higher UID than the<BR>message(s) which were added previously. 
Unlike message sequence<BR>numbers, unique identifiers are not necessarily 
contiguous.<BR><BR>The unique identifier of a message MUST NOT change during 
the<BR>session, and SHOULD NOT change between sessions. Any change of<BR>unique 
identifiers between sessions MUST be detectable using the<BR>UIDVALIDITY 
mechanism discussed below. Persistent unique identifiers<BR>are required for a 
client to resynchronize its state from a previous<BR>session with the server 
(e.g., disconnected or offline access<BR>clients); this is discussed further in 
[IMAP-DISC].<BR><BR>Associated with every mailbox are two values which aid in 
unique<BR>identifier handling: the next unique identifier value and the 
unique<BR>identifier validity value.<BR><BR>The next unique identifier value is 
the predicted value that will be<BR>assigned to a new message in the mailbox. 
Unless the unique<BR>identifier validity also changes (see below), the next 
unique<BR>identifier value MUST have the following two characteristics. 
First,<BR>the next unique identifier value MUST NOT change unless new 
messages<BR>are added to the mailbox; and second, the next unique 
identifier<BR>value MUST change whenever new messages are added to the 
mailbox,<BR>even if those new messages are subsequently expunged.<BR><BR>Note: 
The next unique identifier value is intended to<BR>provide a means for a client 
to determine whether any<BR>messages have been delivered to the mailbox since 
the<BR>previous time it checked this value. It is not intended to<BR>provide any 
guarantee that any message will have this<BR>unique identifier. A client can 
only assume, at the time<BR>that it obtains the next unique identifier value, 
that<BR>messages arriving after that time will have a UID greater<BR>than or 
equal to that value.<BR><BR>The unique identifier validity value is sent in a 
UIDVALIDITY<BR>response code in an OK untagged response at mailbox selection 
time.<BR>If unique identifiers from an earlier session fail to persist in 
this<BR>session, the unique identifier validity value MUST be greater 
than<BR>the one used in the earlier session.<BR><BR>Note: Ideally, unique 
identifiers SHOULD persist at all<BR>times. Although this specification 
recognizes that failure<BR>to persist can be unavoidable in certain 
server<BR>environments, it STRONGLY ENCOURAGES message store<BR>implementation 
techniques that avoid this problem. For<BR>example:<BR><BR>1) Unique identifiers 
MUST be strictly ascending in the<BR>mailbox at all times. If the physical 
message store is<BR>re-ordered by a non-IMAP agent, this requires that 
the<BR>unique identifiers in the mailbox be regenerated, since<BR>the former 
unique identifiers are no longer strictly<BR>ascending as a result of the 
re-ordering.<BR><BR>2) If the message store has no mechanism to store 
unique<BR>identifiers, it must regenerate unique identifiers at<BR>each session, 
and each session must have a unique<BR>UIDVALIDITY value.<BR><BR>3) If the 
mailbox is deleted and a new mailbox with the<BR>same name is created at a later 
date, the server must<BR>either keep track of unique identifiers from