rfc3501_en.htm

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

invalid as a non-waiting<BR>command sequence, depending upon whether or not the 
second UID<BR>SEARCH contains message sequence numbers.<BR><BR>6. Client 
Commands<BR><BR>IMAP4rev1 commands are described in this section. Commands 
are<BR>organized by the state in which the command is permitted. 
Commands<BR>which are permitted in multiple states are listed in the 
minimum<BR>permitted state (for example, commands valid in authenticated 
and<BR>selected state are listed in the authenticated state 
commands).<BR><BR>Command arguments, identified by "Arguments:" in the 
command<BR>descriptions below, are described by function, not by syntax. 
The<BR>precise syntax of command arguments is described in the Formal 
Syntax<BR>section.<BR><BR>Some commands cause specific server responses to be 
returned; these<BR>are identified by "Responses:" in the command descriptions 
below.<BR>See the response descriptions in the Responses section 
for<BR>information on these responses, and the Formal Syntax section for 
the<BR>precise syntax of these responses. It is possible for server data 
to<BR>be transmitted as a result of any command. Thus, commands that do<BR>not 
specifically require server data specify "no specific responses<BR>for this 
command" instead of "none".<BR><BR>The "Result:" in the command description 
refers to the possible<BR>tagged status responses to a command, and any special 
interpretation<BR>of these status responses.<BR><BR>The state of a connection is 
only changed by successful commands<BR>which are documented as changing state. A 
rejected command (BAD<BR>response) never changes the state of the connection or 
of the<BR>selected mailbox. A failed command (NO response) generally does 
not<BR>change the state of the connection or of the selected mailbox; 
the<BR>exception being the SELECT and EXAMINE commands.<BR><BR>6.1. Client 
Commands - Any State<BR><BR>The following commands are valid in any state: 
CAPABILITY, NOOP, and<BR>LOGOUT.<BR><BR>6.1.1. CAPABILITY 
Command<BR><BR>Arguments: none<BR><BR>Responses: REQUIRED untagged response: 
CAPABILITY<BR><BR>Result: OK - capability completed<BR>BAD - command unknown or 
arguments invalid<BR><BR>The CAPABILITY command requests a listing of 
capabilities that the<BR>server supports. The server MUST send a single 
untagged<BR>CAPABILITY response with "IMAP4rev1" as one of the 
listed<BR>capabilities before the (tagged) OK response.<BR><BR>A capability name 
which begins with "AUTH=" indicates that the<BR>server supports that particular 
authentication mechanism. All<BR>such names are, by definition, part of this 
specification. For<BR>example, the authorization capability for an 
experimental<BR>"blurdybloop" authenticator would be "AUTH=XBLURDYBLOOP" and 
not<BR>"XAUTH=BLURDYBLOOP" or "XAUTH=XBLURDYBLOOP".<BR><BR>Other capability 
names refer to extensions, revisions, or<BR>amendments to this specification. 
See the documentation of the<BR>CAPABILITY response for additional information. 
No capabilities,<BR>beyond the base IMAP4rev1 set defined in this specification, 
are<BR>enabled without explicit client action to invoke the 
capability.<BR><BR>Client and server implementations MUST implement the 
STARTTLS,<BR>LOGINDISABLED, and AUTH=PLAIN (described in 
[IMAP-TLS])<BR>capabilities. See the Security Considerations section 
for<BR>important information.<BR><BR>See the section entitled "Client Commands 
-<BR>Experimental/Expansion" for information about the form of site 
or<BR>implementation-specific capabilities.<BR><BR>Example: C: abcd 
CAPABILITY<BR>S: * CAPABILITY IMAP4rev1 STARTTLS 
AUTH=GSSAPI<BR>LOGINDISABLED<BR>S: abcd OK CAPABILITY completed<BR>C: efgh 
STARTTLS<BR>S: efgh OK STARTLS completed<BR>&lt;TLS negotiation, further 
commands are under [TLS] layer&gt;<BR>C: ijkl CAPABILITY<BR>S: * CAPABILITY 
IMAP4rev1 AUTH=GSSAPI AUTH=PLAIN<BR>S: ijkl OK CAPABILITY 
completed<BR><BR>6.1.2. NOOP Command<BR><BR>Arguments: none<BR><BR>Responses: no 
specific responses for this command (but see below)<BR><BR>Result: OK - noop 
completed<BR>BAD - command unknown or arguments invalid<BR><BR>The NOOP command 
always succeeds. It does nothing.<BR><BR>Since any command can return a status 
update as untagged data, the<BR>NOOP command can be used as a periodic poll for 
new messages or<BR>message status updates during a period of inactivity (this is 
the<BR>preferred method to do this). The NOOP command can also be used<BR>to 
reset any inactivity autologout timer on the server.<BR><BR>Example: C: a002 
NOOP<BR>S: a002 OK NOOP completed<BR>. . .<BR>C: a047 NOOP<BR>S: * 22 
EXPUNGE<BR>S: * 23 EXISTS<BR>S: * 3 RECENT<BR>S: * 14 FETCH (FLAGS (/Seen 
/Deleted))<BR>S: a047 OK NOOP completed<BR><BR>6.1.3. LOGOUT 
Command<BR><BR>Arguments: none<BR><BR>Responses: REQUIRED untagged response: 
BYE<BR><BR>Result: OK - logout completed<BR>BAD - command unknown or arguments 
invalid<BR><BR>The LOGOUT command informs the server that the client is done 
with<BR>the connection. The server MUST send a BYE untagged response<BR>before 
the (tagged) OK response, and then close the 
network<BR>connection.<BR><BR>Example: C: A023 LOGOUT<BR>S: * BYE IMAP4rev1 
Server logging out<BR>S: A023 OK LOGOUT completed<BR>(Server and client then 
close the connection)<BR><BR>6.2. Client Commands - Not Authenticated 
State<BR><BR>In the not authenticated state, the AUTHENTICATE or LOGIN 
command<BR>establishes authentication and enters the authenticated state. 
The<BR>AUTHENTICATE command provides a general mechanism for a variety 
of<BR>authentication techniques, privacy protection, and integrity<BR>checking; 
whereas the LOGIN command uses a traditional user name and<BR>plaintext password 
pair and has no means of establishing privacy<BR>protection or integrity 
checking.<BR><BR>The STARTTLS command is an alternate form of establishing 
session<BR>privacy protection and integrity checking, but does not 
establish<BR>authentication or enter the authenticated state.<BR><BR>Server 
implementations MAY allow access to certain mailboxes without<BR>establishing 
authentication. This can be done by means of the<BR>ANONYMOUS [SASL] 
authenticator described in [ANONYMOUS]. An older<BR>convention is a LOGIN 
command using the userid "anonymous"; in this<BR>case, a password is required 
although the server may choose to accept<BR>any password. The restrictions 
placed on anonymous users are<BR>implementation-dependent.<BR><BR>Once 
authenticated (including as anonymous), it is not possible to<BR>re-enter not 
authenticated state.<BR><BR>In addition to the universal commands (CAPABILITY, 
NOOP, and LOGOUT),<BR>the following commands are valid in the not authenticated 
state:<BR>STARTTLS, AUTHENTICATE and LOGIN. See the Security 
Considerations<BR>section for important information about these 
commands.<BR><BR>6.2.1. STARTTLS Command<BR><BR>Arguments: 
none<BR><BR>Responses: no specific response for this command<BR><BR>Result: OK - 
starttls completed, begin TLS negotiation<BR>BAD - command unknown or arguments 
invalid<BR><BR>A [TLS] negotiation begins immediately after the CRLF at the 
end<BR>of the tagged OK response from the server. Once a client issues 
a<BR>STARTTLS command, it MUST NOT issue further commands until a<BR>server 
response is seen and the [TLS] negotiation is complete.<BR><BR>The server 
remains in the non-authenticated state, even if client<BR>credentials are 
supplied during the [TLS] negotiation. This does<BR>not preclude an 
authentication mechanism such as EXTERNAL (defined<BR>in [SASL]) from using 
client identity determined by the [TLS]<BR>negotiation.<BR><BR>Once [TLS] has 
been started, the client MUST discard cached<BR>information about server 
capabilities and SHOULD re-issue the<BR>CAPABILITY command. This is necessary to 
protect against man-in-<BR>the-middle attacks which alter the capabilities list 
prior to<BR>STARTTLS. The server MAY advertise different capabilities 
after<BR>STARTTLS.<BR><BR>Example: C: a001 CAPABILITY<BR>S: * CAPABILITY 
IMAP4rev1 STARTTLS LOGINDISABLED<BR>S: a001 OK CAPABILITY completed<BR>C: a002 
STARTTLS<BR>S: a002 OK Begin TLS negotiation now<BR>&lt;TLS negotiation, further 
commands are under [TLS] layer&gt;<BR>C: a003 CAPABILITY<BR>S: * CAPABILITY 
IMAP4rev1 AUTH=PLAIN<BR>S: a003 OK CAPABILITY completed<BR>C: a004 LOGIN joe 
password<BR>S: a004 OK LOGIN completed<BR><BR>6.2.2. AUTHENTICATE 
Command<BR><BR>Arguments: authentication mechanism name<BR><BR>Responses: 
continuation data can be requested<BR><BR>Result: OK - authenticate completed, 
now in authenticated state<BR>NO - authenticate failure: unsupported 
authentication<BR>mechanism, credentials rejected<BR>BAD - command unknown or 
arguments invalid,<BR>authentication exchange cancelled<BR><BR>The AUTHENTICATE 
command indicates a [SASL] authentication<BR>mechanism to the server. If the 
server supports the requested<BR>authentication mechanism, it performs an 
authentication protocol<BR>exchange to authenticate and identify the client. It 
MAY also<BR>negotiate an OPTIONAL security layer for subsequent 
protocol<BR>interactions. If the requested authentication mechanism is 
not<BR>supported, the server SHOULD reject the AUTHENTICATE command 
by<BR>sending a tagged NO response.<BR><BR>The AUTHENTICATE command does not 
support the optional "initial<BR>response" feature of [SASL]. Section 5.1 of 
[SASL] specifies how<BR>to handle an authentication mechanism which uses an 
initial<BR>response.<BR><BR>The service name specified by this protocol's 
profile of [SASL] is<BR>"imap".<BR><BR>The authentication protocol exchange 
consists of a series of<BR>server challenges and client responses that are 
specific to the<BR>authentication mechanism. A server challenge consists of 
a<BR>command continuation request response with the "+" token followed<BR>by a 
BASE64 encoded string. The client response consists of a<BR>single line 
consisting of a BASE64 encoded string. If the client<BR>wishes to cancel an 
authentication exchange, it issues a line<BR>consisting of a single "*". If the 
server receives such a<BR>response, it MUST reject the AUTHENTICATE command by 
sending a<BR>tagged BAD response.<BR><BR>If a security layer is negotiated 
through the [SASL]<BR>authentication exchange, it takes effect immediately 
following the<BR>CRLF that concludes the authentication exchange for the 
client,<BR>and the CRLF of the tagged OK response for the server.<BR><BR>While 
client and server implementations MUST implement the<BR>AUTHENTICATE command 
itself, it is not required to implement any<BR>authentication mechanisms other 
than the PLAIN mechanism described<BR><BR>in [IMAP-TLS]. Also, an authentication 
mechanism is not required<BR>to support any security layers.<BR><BR>Note: a 
server implementation MUST implement a<BR>configuration in which it does NOT 
permit any plaintext<BR>password mechanisms, unless either the STARTTLS 
command<BR>has been negotiated or some other mechanism that<BR>protects the 
session from password snooping has been<BR>provided. Server sites SHOULD NOT use 
any configuration<BR>which permits a plaintext password mechanism 
without<BR>such a protection mechanism against password snooping.<BR>Client and 
server implementations SHOULD implement<BR>additional [SASL] mechanisms that do 
not use plaintext<BR>passwords, such the GSSAPI mechanism described in 
[SASL]<BR>and/or the [DIGEST-MD5] mechanism.<BR><BR>Servers and clients can 
support multiple authentication<BR>mechanisms. The server SHOULD list its 
supported authentication<BR>mechanisms in the response to the CAPABILITY command 
so that the<BR>client knows which authentication mechanisms to use.<BR><BR>A 
server MAY include a CAPABILITY response code in the tagged OK<BR>response of a 
successful AUTHENTICATE command in order to send<BR>capabilities automatically. 
It is unnecessary for a client to<BR>send a separate CAPABILITY command if it 
recognizes these<BR>automatic capabilities. This should only be done if a 
security<BR>layer was not negotiated by the AUTHENTICATE command, because 
the<BR>tagged OK response as part of an AUTHENTICATE command is not<BR>protected 
by encryption/integrity checking. [SASL] requires the<BR>client to re-issue a 
CAPABILITY command in this case.<BR><BR>If an AUTHENTICATE command fails with a 
NO response, the client<BR>MAY try another authentication mechanism by issuing 
another<BR>AUTHENTICATE command. It MAY also attempt to authenticate by<BR>using 
the LOGIN command (see section 6.2.3 for more detail). In<BR>other words, the 
client MAY request authentication types in<BR>decreasing order of preference, 
with the LOGIN command as a last<BR>resort.<BR><BR>The authorization identity 
passed from the client to the server<BR>during the authentication exchange is 
interpreted by the server as<BR>the user name whose privileges the client is 
requesting.<BR><BR>Example: S: * OK IMAP4rev1 Server<BR>C: A001 AUTHENTICATE 
GSSAPI<BR>S: +<BR>C: 
YIIB+wYJKoZIhvcSAQICAQBuggHqMIIB5qADAgEFoQMCAQ6iBw<BR>MFACAAAACjggEmYYIBIjCCAR6gAwIBBaESGxB1Lndhc2hpbmd0<BR>b24uZWR1oi0wK6ADAgEDoSQwIhsEaW1hcBsac2hpdmFtcy5jYW<BR>Mud2FzaGluZ3Rvbi5lZHWjgdMwgdCgAwIBAaEDAgEDooHDBIHA<BR>cS1GSa5b+fXnPZNmXB9SjL8Ollj2SKyb+3S0iXMljen/