rfc3501_en.htm

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

the<BR>previous instance of the mailbox, or it must assign a<BR>new UIDVALIDITY 
value to the new instance of the<BR>mailbox. A good UIDVALIDITY value to use in 
this case<BR>is a 32-bit representation of the creation date/time of<BR>the 
mailbox. It is alright to use a constant such as<BR>1, but only if it guaranteed 
that unique identifiers<BR>will never be reused, even in the case of a 
mailbox<BR>being deleted (or renamed) and a new mailbox by the<BR>same name 
created at some future time.<BR><BR>4) The combination of mailbox name, 
UIDVALIDITY, and UID<BR>must refer to a single immutable message on that 
server<BR>forever. In particular, the internal date, [<A 
href="http://www.jzdb.cn/Net/xieyi/index.html/rfcs/rfc2822.html"><U><FONT 
color=#0000ff>RFC-2822</FONT></U></A>]<BR>size, envelope, body structure, and 
message texts<BR>(<A 
href="http://www.jzdb.cn/Net/xieyi/index.html/rfcs/rfc822.html"><U><FONT 
color=#0000ff>RFC822</FONT></U></A>, <A 
href="http://www.jzdb.cn/Net/xieyi/index.html/rfcs/rfc822.html"><U><FONT 
color=#0000ff>RFC822</FONT></U></A>.HEADER, <A 
href="http://www.jzdb.cn/Net/xieyi/index.html/rfcs/rfc822.html"><U><FONT 
color=#0000ff>RFC822</FONT></U></A>.TEXT, and all BODY[...]<BR>fetch data items) 
must never change. This does not<BR>include message numbers, nor does it include 
attributes<BR>that can be set by a STORE command (e.g., FLAGS).<BR><BR>2.3.1.2. 
Message Sequence Number Message Attribute<BR><BR>A relative position from 1 to 
the number of messages in the mailbox.<BR>This position MUST be ordered by 
ascending unique identifier. As<BR>each new message is added, it is assigned a 
message sequence number<BR>that is 1 higher than the number of messages in the 
mailbox before<BR>that new message was added.<BR><BR>Message sequence numbers 
can be reassigned during the session. For<BR>example, when a message is 
permanently removed (expunged) from the<BR>mailbox, the message sequence number 
for all subsequent messages is<BR>decremented. The number of messages in the 
mailbox is also<BR>decremented. Similarly, a new message can be assigned a 
message<BR>sequence number that was once held by some other message prior to 
an<BR>expunge.<BR><BR>In addition to accessing messages by relative position in 
the<BR>mailbox, message sequence numbers can be used in 
mathematical<BR>calculations. For example, if an untagged "11 EXISTS" is 
received,<BR>and previously an untagged "8 EXISTS" was received, three 
new<BR>messages have arrived with message sequence numbers of 9, 10, and 
11.<BR>Another example, if message 287 in a 523 message mailbox has 
UID<BR>12345, there are exactly 286 messages which have lesser UIDs and 
236<BR>messages which have greater UIDs.<BR><BR>2.3.2. Flags Message 
Attribute<BR><BR>A list of zero or more named tokens associated with the 
message. A<BR>flag is set by its addition to this list, and is cleared by 
its<BR>removal. There are two types of flags in IMAP4rev1. A flag of<BR>either 
type can be permanent or session-only.<BR><BR>A system flag is a flag name that 
is pre-defined in this<BR>specification. All system flags begin with "/". 
Certain system<BR>flags (/Deleted and /Seen) have special semantics 
described<BR>elsewhere. The currently-defined system flags 
are:<BR><BR>/Seen<BR>Message has been read<BR><BR>/Answered<BR>Message has been 
answered<BR><BR>/Flagged<BR>Message is "flagged" for urgent/special 
attention<BR><BR>/Deleted<BR>Message is "deleted" for removal by later 
EXPUNGE<BR><BR>/Draft<BR>Message has not completed composition (marked as a 
draft).<BR><BR>/Recent<BR>Message is "recently" arrived in this mailbox. This 
session<BR>is the first session to have been notified about this<BR>message; if 
the session is read-write, subsequent sessions<BR>will not see /Recent set for 
this message. This flag can not<BR>be altered by the client.<BR><BR>If it is not 
possible to determine whether or not this<BR>session is the first session to be 
notified about a message,<BR>then that message SHOULD be considered 
recent.<BR><BR>If multiple connections have the same mailbox 
selected<BR>simultaneously, it is undefined which of these connections<BR>will 
see newly-arrived messages with /Recent set and which<BR>will see it without 
/Recent set.<BR><BR>A keyword is defined by the server implementation. Keywords 
do not<BR>begin with "/". Servers MAY permit the client to define new 
keywords<BR>in the mailbox (see the description of the PERMANENTFLAGS 
response<BR>code for more information).<BR><BR>A flag can be permanent or 
session-only on a per-flag basis.<BR>Permanent flags are those which the client 
can add or remove from the<BR>message flags permanently; that is, concurrent and 
subsequent<BR>sessions will see any change in permanent flags. Changes to 
session<BR>flags are valid only in that session.<BR><BR>Note: The /Recent system 
flag is a special case of a<BR>session flag. /Recent can not be used as an 
argument in a<BR>STORE or APPEND command, and thus can not be changed 
at<BR>all.<BR><BR>2.3.3. Internal Date Message Attribute<BR><BR>The internal 
date and time of the message on the server. This<BR>is not the date and time in 
the [<A 
href="http://www.jzdb.cn/Net/xieyi/index.html/rfcs/rfc2822.html"><U><FONT 
color=#0000ff>RFC-2822</FONT></U></A>] header, but rather a<BR>date and time 
which reflects when the message was received. In<BR>the case of messages 
delivered via [SMTP], this SHOULD be the<BR>date and time of final delivery of 
the message as defined by<BR>[SMTP]. In the case of messages delivered by the 
IMAP4rev1 COPY<BR>command, this SHOULD be the internal date and time of the 
source<BR>message. In the case of messages delivered by the IMAP4rev1<BR>APPEND 
command, this SHOULD be the date and time as specified in<BR>the APPEND command 
description. All other cases are<BR>implementation defined.<BR><BR>2.3.4. [<A 
href="http://www.jzdb.cn/Net/xieyi/index.html/rfcs/rfc2822.html"><U><FONT 
color=#0000ff>RFC-2822</FONT></U></A>] Size Message Attribute<BR><BR>The number 
of octets in the message, as expressed in [<A 
href="http://www.jzdb.cn/Net/xieyi/index.html/rfcs/rfc2822.html"><U><FONT 
color=#0000ff>RFC-2822</FONT></U></A>]<BR>format.<BR><BR>2.3.5. Envelope 
Structure Message Attribute<BR><BR>A parsed representation of the [<A 
href="http://www.jzdb.cn/Net/xieyi/index.html/rfcs/rfc2822.html"><U><FONT 
color=#0000ff>RFC-2822</FONT></U></A>] header of the message.<BR>Note that the 
IMAP Envelope structure is not the same as an<BR>[SMTP] envelope.<BR><BR>2.3.6. 
Body Structure Message Attribute<BR><BR>A parsed representation of the 
[MIME-IMB] body structure<BR>information of the message.<BR><BR>2.4. Message 
Texts<BR><BR>In addition to being able to fetch the full [<A 
href="http://www.jzdb.cn/Net/xieyi/index.html/rfcs/rfc2822.html"><U><FONT 
color=#0000ff>RFC-2822</FONT></U></A>] text of a<BR>message, IMAP4rev1 permits 
the fetching of portions of the full<BR>message text. Specifically, it is 
possible to fetch the<BR>[<A 
href="http://www.jzdb.cn/Net/xieyi/index.html/rfcs/rfc2822.html"><U><FONT 
color=#0000ff>RFC-2822</FONT></U></A>] message header, [<A 
href="http://www.jzdb.cn/Net/xieyi/index.html/rfcs/rfc2822.html"><U><FONT 
color=#0000ff>RFC-2822</FONT></U></A>] message body, a [MIME-IMB]<BR>body part, 
or a [MIME-IMB] header.<BR><BR>3. State and Flow Diagram<BR><BR>Once the 
connection between client and server is established, an<BR>IMAP4rev1 connection 
is in one of four states. The initial<BR>state is identified in the server 
greeting. Most commands are<BR>only valid in certain states. It is a protocol 
error for the<BR>client to attempt a command while the connection is in 
an<BR>inappropriate state, and the server will respond with a BAD or<BR>NO 
(depending upon server implementation) command completion<BR>result.<BR><BR>3.1. 
Not Authenticated State<BR><BR>In the not authenticated state, the client MUST 
supply<BR>authentication credentials before most commands will be<BR>permitted. 
This state is entered when a connection starts<BR>unless the connection has been 
pre-authenticated.<BR><BR>3.2. Authenticated State<BR><BR>In the authenticated 
state, the client is authenticated and MUST<BR>select a mailbox to access before 
commands that affect messages<BR>will be permitted. This state is entered when 
a<BR>pre-authenticated connection starts, when acceptable<BR>authentication 
credentials have been provided, after an error in<BR>selecting a mailbox, or 
after a successful CLOSE command.<BR><BR>3.3. Selected State<BR><BR>In a 
selected state, a mailbox has been selected to access.<BR>This state is entered 
when a mailbox has been successfully<BR>selected.<BR><BR>3.4. Logout 
State<BR><BR>In the logout state, the connection is being terminated. 
This<BR>state can be entered as a result of a client request (via the<BR>LOGOUT 
command) or by unilateral action on the part of either<BR>the client or 
server.<BR><BR>If the client requests the logout state, the server MUST send 
an<BR>untagged BYE response and a tagged OK response to the LOGOUT<BR>command 
before the server closes the connection; and the client<BR>MUST read the tagged 
OK response to the LOGOUT command before<BR>the client closes the 
connection.<BR><BR>A server MUST NOT unilaterally close the connection 
without<BR>sending an untagged BYE response that contains the reason 
for<BR>having done so. A client SHOULD NOT unilaterally close the<BR>connection, 
and instead SHOULD issue a LOGOUT command. If the<BR>server detects that the 
client has unilaterally closed the<BR>connection, the server MAY omit the 
untagged BYE response and<BR>simply close its 
connection.<BR><BR>+----------------------+<BR>|connection 
established|<BR>+----------------------+<BR>||<BR>//<BR>+--------------------------------------+<BR>| 
server greeting |<BR>+--------------------------------------+<BR>|| (1) || (2) 
|| (3)<BR>// || ||<BR>+-----------------+ || ||<BR>|Not Authenticated| || 
||<BR>+-----------------+ || ||<BR>|| (7) || (4) || ||<BR>|| // // ||<BR>|| 
+----------------+ ||<BR>|| | Authenticated |&lt;=++ ||<BR>|| +----------------+ 
|| ||<BR>|| || (7) || (5) || (6) ||<BR>|| || // || ||<BR>|| || +--------+ || 
||<BR>|| || |Selected|==++ ||<BR>|| || +--------+ ||<BR>|| || || (7) ||<BR>// // 
// //<BR>+--------------------------------------+<BR>| Logout 
|<BR>+--------------------------------------+<BR>||<BR>//<BR>+-------------------------------+<BR>|both 
sides close the connection|<BR>+-------------------------------+<BR><BR>(1) 
connection without pre-authentication (OK greeting)<BR>(2) pre-authenticated 
connection (PREAUTH greeting)<BR>(3) rejected connection (BYE greeting)<BR>(4) 
successful LOGIN or AUTHENTICATE command<BR>(5) successful SELECT or EXAMINE 
command<BR>(6) CLOSE command, or failed SELECT or EXAMINE command<BR>(7) LOGOUT 
command, server shutdown, or connection closed<BR><BR>4. Data 
Formats<BR><BR>IMAP4rev1 uses textual commands and responses. Data 
in<BR>IMAP4rev1 can be in one of several forms: atom, number, 
string,<BR>parenthesized list, or NIL. Note that a particular data item<BR>may 
take more than one form; for example, a data item defined as<BR>using "astring" 
syntax may be either an atom or a string.<BR><BR>4.1. Atom<BR><BR>An atom 
consists of one or more non-special characters.<BR><BR>4.2. Number<BR><BR>A 
number consists of one or more digit characters, and<BR>represents a numeric 
value.<BR><BR>4.3. String<BR><BR>A string is in one of two forms: either literal 
or quoted<BR>string. The literal form is the general form of string. 
The<BR>quoted string form is an alternative that avoids the overhead 
of<BR>processing a literal at the cost of limitations of characters<BR>which may 
be used.<BR><BR>A literal is a sequence of zero or more octets (including CR 
and<BR>LF), prefix-quoted with an octet count in the form of an open<BR>brace 
("{"), the number of octets, close brace ("}"), and CRLF.<BR>In the case of 
literals transmitted from server to client, the<BR>CRLF is immediately followed 
by the octet data. In the case of<BR>literals transmitted from client to server, 
the client MUST wait<BR>to receive a command continuation request (described 
later in<BR>this document) before sending the octet data (and the 
remainder<BR>of the command).<BR><BR>A quoted string is a sequence of zero or 
more 7-bit characters,<BR>excluding CR and LF, with double quote (&lt;"&gt;) 
characters at each<BR>end.<BR><BR>The empty string is represented as either "" 
(a quoted string<BR>with zero characters between double quotes) or as {0} 
followed<BR>by CRLF (a literal with an octet count of 0).<BR><BR>Note: Even if 
the octet count is 0, a client transmitting a<BR>literal MUST wait to receive a 
command continuation request.<BR><BR>4.3.1. 8-bit and Binary 
Strings<BR><BR>8-bit textual and binary mail is supported through the use of 
a<BR>[MIME-IMB] content transfer encoding. IMAP4rev1 implementations