rfc3501_en.htm

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

MAY<BR>transmit 8-bit or multi-octet characters in literals, but SHOULD do<BR>so 
only when the [CHARSET] is identified.<BR><BR>Although a BINARY body encoding is 
defined, unencoded binary strings<BR>are not permitted. A "binary string" is any 
string with NUL<BR>characters. Implementations MUST encode binary data into a 
textual<BR>form, such as BASE64, before transmitting the data. A string with 
an<BR>excessive amount of CTL characters MAY also be considered to 
be<BR>binary.<BR><BR>4.4. Parenthesized List<BR><BR>Data structures are 
represented as a "parenthesized list"; a sequence<BR>of data items, delimited by 
space, and bounded at each end by<BR>parentheses. A parenthesized list can 
contain other parenthesized<BR>lists, using multiple levels of parentheses to 
indicate nesting.<BR><BR>The empty list is represented as () -- a parenthesized 
list with no<BR>members.<BR><BR>4.5. NIL<BR><BR>The special form "NIL" 
represents the non-existence of a particular<BR>data item that is represented as 
a string or parenthesized list, as<BR>distinct from the empty string "" or the 
empty parenthesized list ().<BR><BR>Note: NIL is never used for any data item 
which takes the<BR>form of an atom. For example, a mailbox name of "NIL" is 
a<BR>mailbox named NIL as opposed to a non-existent mailbox<BR>name. This is 
because mailbox uses "astring" syntax which<BR>is an atom or a string. 
Conversely, an addr-name of NIL is<BR>a non-existent personal name, because 
addr-name uses<BR>"nstring" syntax which is NIL or a string, but never 
an<BR>atom.<BR><BR>5. Operational Considerations<BR><BR>The following rules are 
listed here to ensure that all IMAP4rev1<BR>implementations interoperate 
properly.<BR><BR>5.1. Mailbox Naming<BR><BR>Mailbox names are 7-bit. Client 
implementations MUST NOT attempt to<BR>create 8-bit mailbox names, and SHOULD 
interpret any 8-bit mailbox<BR>names returned by LIST or LSUB as UTF-8. Server 
implementations<BR>SHOULD prohibit the creation of 8-bit mailbox names, and 
SHOULD NOT<BR>return 8-bit mailbox names in LIST or LSUB. See section 5.1.3 
for<BR>more information on how to represent non-ASCII mailbox 
names.<BR><BR>Note: 8-bit mailbox names were undefined in earlier<BR>versions of 
this protocol. Some sites used a local 8-bit<BR>character set to represent 
non-ASCII mailbox names. Such<BR>usage is not interoperable, and is now formally 
deprecated.<BR><BR>The case-insensitive mailbox name INBOX is a special name 
reserved to<BR>mean "the primary mailbox for this user on this server". 
The<BR>interpretation of all other names is implementation-dependent.<BR><BR>In 
particular, this specification takes no position on case<BR>sensitivity in 
non-INBOX mailbox names. Some server implementations<BR>are fully 
case-sensitive; others preserve case of a newly-created<BR>name but otherwise 
are case-insensitive; and yet others coerce names<BR>to a particular case. 
Client implementations MUST interact with any<BR>of these. If a server 
implementation interprets non-INBOX mailbox<BR>names as case-insensitive, it 
MUST treat names using the<BR>international naming convention specially as 
described in section<BR>5.1.3.<BR><BR>There are certain client considerations 
when creating a new mailbox<BR>name:<BR><BR>1) Any character which is one of the 
atom-specials (see the Formal<BR>Syntax) will require that the mailbox name be 
represented as a<BR>quoted string or literal.<BR><BR>2) CTL and other 
non-graphic characters are difficult to represent<BR>in a user interface and are 
best avoided.<BR><BR>3) Although the list-wildcard characters ("%" and "*") are 
valid<BR>in a mailbox name, it is difficult to use such mailbox names<BR>with 
the LIST and LSUB commands due to the conflict with<BR>wildcard 
interpretation.<BR><BR>4) Usually, a character (determined by the server 
implementation)<BR>is reserved to delimit levels of hierarchy.<BR><BR>5) Two 
characters, "#" and "&amp;", have meanings by convention, and<BR>should be 
avoided except when used in that convention.<BR><BR>5.1.1. Mailbox Hierarchy 
Naming<BR><BR>If it is desired to export hierarchical mailbox names, mailbox 
names<BR>MUST be left-to-right hierarchical using a single character 
to<BR>separate levels of hierarchy. The same hierarchy separator character<BR>is 
used for all levels of hierarchy within a single name.<BR><BR>5.1.2. Mailbox 
Namespace Naming Convention<BR><BR>By convention, the first hierarchical element 
of any mailbox name<BR>which begins with "#" identifies the "namespace" of the 
remainder of<BR>the name. This makes it possible to disambiguate between 
different<BR>types of mailbox stores, each of which have their own 
namespaces.<BR><BR>For example, implementations which offer access to 
USENET<BR>newsgroups MAY use the "#news" namespace to partition the<BR>USENET 
newsgroup namespace from that of other mailboxes.<BR>Thus, the comp.mail.misc 
newsgroup would have a mailbox<BR>name of "#news.comp.mail.misc", and the 
name<BR>"comp.mail.misc" can refer to a different object (e.g., a<BR>user's 
private mailbox).<BR><BR>5.1.3. Mailbox International Naming 
Convention<BR><BR>By convention, international mailbox names in IMAP4rev1 are 
specified<BR>using a modified version of the UTF-7 encoding described in 
[UTF-7].<BR>Modified UTF-7 may also be usable in servers that implement 
an<BR>earlier version of this protocol.<BR><BR>In modified UTF-7, printable 
US-ASCII characters, except for "&amp;",<BR>represent themselves; that is, 
characters with octet values 0x20-0x25<BR>and 0x27-0x7e. The character "&amp;" 
(0x26) is represented by the<BR>two-octet sequence "&amp;-".<BR><BR>All other 
characters (octet values 0x00-0x1f and 0x7f-0xff) are<BR>represented in modified 
BASE64, with a further modification from<BR>[UTF-7] that "," is used instead of 
"/". Modified BASE64 MUST NOT be<BR>used to represent any printing US-ASCII 
character which can represent<BR>itself.<BR><BR>"&amp;" is used to shift to 
modified BASE64 and "-" to shift back to<BR>US-ASCII. There is no implicit shift 
from BASE64 to US-ASCII, and<BR>null shifts ("-&amp;" while in BASE64; note that 
"&amp;-" while in US-ASCII<BR>means "&amp;") are not permitted. However, all 
names start in US-ASCII,<BR>and MUST end in US-ASCII; that is, a name that ends 
with a non-ASCII<BR>ISO-10646 character MUST end with a "-").<BR><BR>The purpose 
of these modifications is to correct the following<BR>problems with 
UTF-7:<BR><BR>1) UTF-7 uses the "+" character for shifting; this conflicts 
with<BR>the common use of "+" in mailbox names, in particular 
USENET<BR>newsgroup names.<BR><BR>2) UTF-7's encoding is BASE64 which uses the 
"/" character; this<BR>conflicts with the use of "/" as a popular hierarchy 
delimiter.<BR><BR>3) UTF-7 prohibits the unencoded usage of "/"; this conflicts 
with<BR>the use of "/" as a popular hierarchy delimiter.<BR><BR>4) UTF-7 
prohibits the unencoded usage of "~"; this conflicts with<BR>the use of "~" in 
some servers as a home directory indicator.<BR><BR>5) UTF-7 permits multiple 
alternate forms to represent the same<BR>string; in particular, printable 
US-ASCII characters can be<BR>represented in encoded form.<BR><BR>Although 
modified UTF-7 is a convention, it establishes certain<BR>requirements on server 
handling of any mailbox name with an<BR>embedded "&amp;" character. In 
particular, server implementations<BR>MUST preserve the exact form of the 
modified BASE64 portion of a<BR>modified UTF-7 name and treat that text as 
case-sensitive, even if<BR>names are otherwise case-insensitive or 
case-folded.<BR><BR>Server implementations SHOULD verify that any mailbox name 
with an<BR>embedded "&amp;" character, used as an argument to CREATE, is: in 
the<BR>correctly modified UTF-7 syntax, has no superfluous shifts, and<BR>has no 
encoding in modified BASE64 of any printing US-ASCII<BR>character which can 
represent itself. However, client<BR>implementations MUST NOT depend upon the 
server doing this, and<BR>SHOULD NOT attempt to create a mailbox name with an 
embedded "&amp;"<BR>character unless it complies with the modified UTF-7 
syntax.<BR><BR>Server implementations which export a mail store that does 
not<BR>follow the modified UTF-7 convention MUST convert to modified<BR>UTF-7 
any mailbox name that contains either non-ASCII characters<BR>or the "&amp;" 
character.<BR><BR>For example, here is a mailbox name which mixes 
English,<BR>Chinese, and Japanese 
text:<BR>~peter/mail/&amp;U,BTFw-/&amp;ZeVnLIqe-<BR><BR>For example, the string 
"&amp;Jjo!" is not a valid mailbox<BR>name because it does not contain a shift 
to US-ASCII<BR>before the "!". The correct form is "&amp;Jjo-!". The<BR>string 
"&amp;U,BTFw-&amp;ZeVnLIqe-" is not permitted because it<BR>contains a 
superfluous shift. The correct form is<BR>"&amp;U,BTF2XlZyyKng-".<BR><BR>5.2. 
Mailbox Size and Message Status Updates<BR><BR>At any time, a server can send 
data that the client did not request.<BR>Sometimes, such behavior is REQUIRED. 
For example, agents other than<BR>the server MAY add messages to the mailbox 
(e.g., new message<BR>delivery), change the flags of the messages in the mailbox 
(e.g.,<BR>simultaneous access to the same mailbox by multiple agents), or 
even<BR>remove messages from the mailbox. A server MUST send mailbox 
size<BR>updates automatically if a mailbox size change is observed during 
the<BR>processing of a command. A server SHOULD send message flag 
updates<BR>automatically, without requiring the client to request such 
updates<BR>explicitly.<BR><BR>Special rules exist for server notification of a 
client about the<BR>removal of messages to prevent synchronization errors; see 
the<BR>description of the EXPUNGE response for more detail. In particular,<BR>it 
is NOT permitted to send an EXISTS response that would reduce the<BR>number of 
messages in the mailbox; only the EXPUNGE response can 
do<BR>this.<BR><BR>Regardless of what implementation decisions a client makes 
on<BR>remembering data from the server, a client implementation MUST 
record<BR>mailbox size updates. It MUST NOT assume that any command after 
the<BR>initial mailbox selection will return the size of the 
mailbox.<BR><BR>5.3. Response when no Command in Progress<BR><BR>Server 
implementations are permitted to send an untagged response<BR>(except for 
EXPUNGE) while there is no command in progress. Server<BR>implementations that 
send such responses MUST deal with flow control<BR>considerations. Specifically, 
they MUST either (1) verify that the<BR>size of the data does not exceed the 
underlying transport's available<BR>window size, or (2) use non-blocking 
writes.<BR><BR>5.4. Autologout Timer<BR><BR>If a server has an inactivity 
autologout timer, the duration of that<BR>timer MUST be at least 30 minutes. The 
receipt of ANY command from<BR>the client during that interval SHOULD suffice to 
reset the<BR>autologout timer.<BR><BR>5.5. Multiple Commands in 
Progress<BR><BR>The client MAY send another command without waiting for 
the<BR>completion result response of a command, subject to ambiguity 
rules<BR>(see below) and flow control constraints on the underlying 
data<BR>stream. Similarly, a server MAY begin processing another 
command<BR>before processing the current command to completion, subject 
to<BR>ambiguity rules. However, any command continuation request 
responses<BR>and command continuations MUST be negotiated before any 
subsequent<BR>command is initiated.<BR><BR>The exception is if an ambiguity 
would result because of a command<BR>that would affect the results of other 
commands. Clients MUST NOT<BR>send multiple commands without waiting if an 
ambiguity would result.<BR>If the server detects a possible ambiguity, it MUST 
execute commands<BR>to completion in the order given by the client.<BR><BR>The 
most obvious example of ambiguity is when a command would affect<BR>the results 
of another command, e.g., a FETCH of a message's flags<BR>and a STORE of that 
same message's flags.<BR><BR>A non-obvious ambiguity occurs with commands that 
permit an untagged<BR>EXPUNGE response (commands other than FETCH, STORE, and 
SEARCH),<BR>since an untagged EXPUNGE response can invalidate sequence numbers 
in<BR>a subsequent command. This is not a problem for FETCH, STORE, or<BR>SEARCH 
commands because servers are prohibited from sending EXPUNGE<BR>responses while 
any of those commands are in progress. Therefore, if<BR>the client sends any 
command other than FETCH, STORE, or SEARCH, it<BR>MUST wait for the completion 
result response before sending a command<BR>with message sequence 
numbers.<BR><BR>Note: UID FETCH, UID STORE, and UID SEARCH are 
different<BR>commands from FETCH, STORE, and SEARCH. If the client<BR>sends a 
UID command, it must wait for a completion result<BR>response before sending a 
command with message sequence<BR>numbers.<BR><BR>For example, the following 
non-waiting command sequences are invalid:<BR><BR>FETCH + NOOP + STORE<BR>STORE 
+ COPY + FETCH<BR>COPY + COPY<BR>CHECK + FETCH<BR><BR>The following are examples 
of valid non-waiting command sequences:<BR><BR>FETCH + STORE + SEARCH + 
CHECK<BR>STORE + COPY + EXPUNGE<BR><BR>UID SEARCH + UID SEARCH may be valid or