Network Working Group B. Leiba
Request for Comments: 2683 IBM T.J. Watson Research Center
Category: Informational September 1999
Network Working Group B. Leiba
Request for Comments: 2683 IBM T.J. Watson Research Center
Category: Informational September 1999
IMAP4 Implementation Recommendations
IMAP4实施建议
Status of this Memo
本备忘录的状况
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (1999). All Rights Reserved.
版权所有（C）互联网协会（1999年）。版权所有。
The IMAP4 specification [RFC-2060] describes a rich protocol for use in building clients and servers for storage, retrieval, and manipulation of electronic mail. Because the protocol is so rich and has so many implementation choices, there are often trade-offs that must be made and issues that must be considered when designing such clients and servers. This document attempts to outline these issues and to make recommendations in order to make the end products as interoperable as possible.
IMAP4规范[RFC-2060]描述了一种用于构建用于存储、检索和处理电子邮件的客户端和服务器的丰富协议。由于该协议非常丰富，并且有很多实现选择，因此在设计此类客户端和服务器时，通常必须进行权衡，并考虑一些问题。本文档试图概述这些问题并提出建议，以使最终产品尽可能具有互操作性。
In examples, "C:" indicates lines sent by a client that is connected to a server. "S:" indicates lines sent by the server to the client.
在示例中，“C:”表示连接到服务器的客户端发送的线路。“S:”表示服务器发送到客户端的行。
The words "must", "must not", "should", "should not", and "may" are used with specific meaning in this document; since their meaning is somewhat different from that specified in RFC 2119, we do not put them in all caps here. Their meaning is as follows:
“必须”、“不得”、“应该”、“不应该”和“可以”等词语在本文件中具有特定含义；由于它们的含义与RFC 2119中规定的含义有所不同，因此我们在此不将它们放在所有大写字母中。其含义如下：
must -- This word means that the action described is necessary to ensure interoperability. The recommendation should not be ignored. must not -- This phrase means that the action described will be almost certain to hurt interoperability. The recommendation should not be ignored.
必须——这个词意味着所描述的操作是确保互操作性所必需的。这项建议不应被忽视。绝不能——这个短语意味着所描述的操作几乎肯定会损害互操作性。这项建议不应被忽视。
should -- This word means that the action described is strongly recommended and will enhance interoperability or usability. The recommendation should not be ignored without careful consideration. should not -- This phrase means that the action described is strongly recommended against, and might hurt interoperability or usability. The recommendation should not be ignored without careful consideration. may -- This word means that the action described is an acceptable implementation choice. No specific recommendation is implied; this word is used to point out a choice that might not be obvious, or to let implementors know what choices have been made by existing implementations.
应该——这个词的意思是强烈推荐所描述的操作，并将增强互操作性或可用性。未经认真考虑，不应忽视这项建议。不应该——这个短语意味着强烈建议不要执行所描述的操作，并且可能会损害互操作性或可用性。未经认真考虑，不应忽视这项建议。may——这个词意味着所描述的操作是可接受的实现选择。没有暗示具体建议；这个词用来指出一个可能不明显的选择，或者让实现者知道现有实现已经做出了哪些选择。
This section describes the issues related to access to servers and server resources. Concerns here include data sharing and maintenance of client/server connections.
本节介绍与访问服务器和服务器资源相关的问题。这里关注的问题包括数据共享和客户机/服务器连接的维护。
One strong point of IMAP4 is that, unlike POP3, it allows for multiple simultaneous access to a single mailbox. A user can, thus, read mail from a client at home while the client in the office is still connected; or the help desk staff can all work out of the same inbox, all seeing the same pool of questions. An important point about this capability, though is that NO SERVER IS GUARANTEED TO SUPPORT THIS. If you are selecting an IMAP server and this facility is important to you, be sure that the server you choose to install, in the configuration you choose to use, supports it.
IMAP4的一个优点是，与POP3不同，它允许对单个邮箱进行多个同时访问。因此，当办公室中的客户机仍然连接时，用户可以从家中的客户机读取邮件；或者，服务台的工作人员都可以在同一个收件箱中工作，都可以看到相同的问题库。不过，关于此功能的一个重要方面是，没有任何服务器保证支持此功能。如果您选择的是IMAP服务器，并且此功能对您很重要，请确保您选择安装的服务器在您选择使用的配置中支持此功能。
If you are designing a client, you must not assume that you can access the same mailbox more than once at a time. That means
如果正在设计客户端，则不能假定一次可以多次访问同一邮箱。这意味着
1. you must handle gracefully the failure of a SELECT command if the server refuses the second SELECT, 2. you must handle reasonably the severing of your connection (see "Severed Connections", below) if the server chooses to allow the second SELECT by forcing the first off, 3. you must avoid making multiple connections to the same mailbox in your own client (for load balancing or other such reasons), and 4. you must avoid using the STATUS command on a mailbox that you have selected (with some server implementations the STATUS command has the same problems with multiple access as do the SELECT and
1. 如果服务器拒绝第二次选择，则必须优雅地处理SELECT命令的失败，2。如果服务器选择通过强制关闭第一个选项来允许第二个选项，则必须合理地处理连接的断开（请参阅下面的“断开的连接”），3。您必须避免在自己的客户端中多次连接到同一邮箱（出于负载平衡或其他类似原因），以及4。必须避免在已选择的邮箱上使用STATUS命令（在某些服务器实现中，STATUS命令与SELECT和and命令具有相同的多址访问问题）
EXAMINE commands).
检查命令）。
A further note about STATUS: The STATUS command is sometimes used to check a non-selected mailbox for new mail. This mechanism must not be used to check for new mail in the selected mailbox; section 5.2 of [RFC-2060] specifically forbids this in its last paragraph. Further, since STATUS takes a mailbox name it is an independent operation, not operating on the selected mailbox. Because of this, the information it returns is not necessarily in synchronization with the selected mailbox state.
关于STATUS的进一步说明：STATUS命令有时用于检查未选择的邮箱中是否有新邮件。此机制不得用于检查所选邮箱中的新邮件；[RFC-2060]第5.2节在最后一段中明确禁止这样做。此外，由于STATUS采用邮箱名称，因此它是一个独立的操作，而不是对所选邮箱进行操作。因此，它返回的信息不一定与所选邮箱状态同步。
The client/server connection may be severed for one of three reasons: the client severs the connection, the server severs the connection, or the connection is severed by outside forces beyond the control of the client and the server (a telephone line drops, for example). Clients and servers must both deal with these situations.
客户机/服务器连接可能由于以下三种原因之一而被切断：客户机切断连接、服务器切断连接，或者连接被客户机和服务器无法控制的外力切断（例如，电话线掉线）。客户端和服务器都必须处理这些情况。
When the client wants to sever a connection, it's usually because it has finished the work it needed to do on that connection. The client should send a LOGOUT command, wait for the tagged response, and then close the socket. But note that, while this is what's intended in the protocol design, there isn't universal agreement here. Some contend that sending the LOGOUT and waiting for the two responses (untagged BYE and tagged OK) is wasteful and unnecessary, and that the client can simply close the socket. The server should interpret the closed socket as a log out by the client. The counterargument is that it's useful from the standpoint of cleanup, problem determination, and the like, to have an explicit client log out, because otherwise there is no way for the server to tell the difference between "closed socket because of log out" and "closed socket because communication was disrupted". If there is a client/server interaction problem, a client which routinely terminates a session by breaking the connection without a LOGOUT will make it much more difficult to determine the problem.
当客户端想要断开连接时，通常是因为它已经完成了在该连接上所需的工作。客户端应该发送一个注销命令，等待标记的响应，然后关闭套接字。但是请注意，虽然这是协议设计的初衷，但这里并没有达成一致意见。一些人认为，发送注销并等待两个响应（未标记的BYE和标记的OK）是浪费和不必要的，客户端可以简单地关闭套接字。服务器应将关闭的套接字解释为客户端注销。相反的论点是，从清理、问题确定等角度来看，显式客户端注销是有用的，因为否则服务器无法区分“由于注销而关闭的套接字”和“由于通信中断而关闭的套接字”。如果存在客户机/服务器交互问题，如果客户机经常通过断开连接而不注销来终止会话，那么确定问题将变得更加困难。
Because of this disagreement, server designers must be aware that some clients might close the socket without sending a LOGOUT. In any case, whether or not a LOGOUT was sent, the server should not implicitly expunge any messages from the selected mailbox. If a client wants the server to do so, it must send a CLOSE or EXPUNGE command explicitly.
由于这种不一致，服务器设计者必须意识到一些客户端可能会在不发送注销的情况下关闭套接字。在任何情况下，无论是否发送了注销，服务器都不应从所选邮箱中隐式删除任何邮件。如果客户端希望服务器执行此操作，则必须显式发送CLOSE或EXPUNGE命令。
When the server wants to sever a connection it's usually due to an inactivity timeout or is because a situation has arisen that has changed the state of the mail store in a way that the server can not communicate to the client. The server should send an untagged BYE
当服务器想要断开连接时，通常是由于不活动超时，或者是由于出现了某种情况，改变了邮件存储的状态，导致服务器无法与客户端通信。服务器应该发送一个未标记的BYE
response to the client and then close the socket. Sending an untagged BYE response before severing allows the server to send a human-readable explanation of the problem to the client, which the client may then log, display to the user, or both (see section 7.1.5 of [RFC-2060]).
响应客户端，然后关闭套接字。在断开之前发送未标记的BYE响应允许服务器向客户端发送问题的可读解释，然后客户端可以记录、向用户显示或同时显示（参见[RFC-2060]第7.1.5节）。
Regarding inactivity timeouts, there is some controversy. Unlike POP, for which the design is for a client to connect, retrieve mail, and log out, IMAP's design encourages long-lived (and mostly inactive) client/server sessions. As the number of users grows, this can use up a lot of server resources, especially with clients that are designed to maintain sessions for mailboxes that the user has finished accessing. To alleviate this, a server may implement an inactivity timeout, unilaterally closing a session (after first sending an untagged BYE, as noted above). Some server operators have reported dramatic improvements in server performance after doing this. As specified in [RFC-2060], if such a timeout is done it must not be until at least 30 minutes of inactivity. The reason for this specification is to prevent clients from sending commands (such as NOOP) to the server at frequent intervals simply to avert a too-early timeout. If the client knows that the server may not time out the session for at least 30 minutes, then the client need not poll at intervals more frequent than, say, 25 minutes.
关于不活动超时，存在一些争议。与POP不同，它的设计是让客户端连接、检索邮件和注销，IMAP的设计鼓励长时间（大部分是非活动的）客户端/服务器会话。随着用户数量的增长，这可能会占用大量服务器资源，特别是对于设计用于维护用户已完成访问的邮箱会话的客户端。为了缓解这种情况，服务器可能会实现非活动超时，单方面关闭会话（在第一次发送未标记的BYE之后，如上所述）。一些服务器运营商报告说，这样做后，服务器性能有了显著提高。按照[RFC-2060]中的规定，如果超时，则在至少30分钟不活动之前不得超时。此规范的原因是为了防止客户端频繁地向服务器发送命令（如NOOP），以避免过早超时。如果客户机知道服务器可能至少30分钟没有超时会话，那么客户机不需要以超过（比如）25分钟的间隔进行轮询。
IMAP4 has many features that allow for scalability, as mail stores become larger and more numerous. Large numbers of users, mailboxes, and messages, and very large messages require thought to handle efficiently. This document will not address the administrative issues involved in large numbers of users, but we will look at the other items.
随着邮件存储变得越来越大和越来越多，IMAP4具有许多允许扩展的功能。大量的用户、邮箱和消息，以及非常大的消息都需要考虑如何有效地处理。本文档不会涉及大量用户所涉及的管理问题，但我们将研究其他项目。
There are three situations when a client can make a request that will result in a very large response - too large for the client reasonably to deal with: there are a great many mailboxes available, there are a great many messages in the selected mailbox, or there is a very large message part. The danger here is that the end user will be stuck waiting while the server sends (and the client processes) an enormous response. In all of these cases there are things a client can do to reduce that danger.
有三种情况下，客户端可以发出一个请求，该请求将导致非常大的响应—太大，客户端无法合理处理：有大量可用邮箱，选定邮箱中有大量邮件，或者邮件部分非常大。这里的危险在于，当服务器发送（和客户机处理）一个巨大的响应时，最终用户将无法等待。在所有这些情况下，客户都可以做一些事情来减少这种危险。
There is also the case where a client can flood a server, by sending an arbitratily long command. We'll discuss that issue, too, in this section.
还有一种情况是，客户机可以通过发送仲裁长的命令来淹没服务器。在本节中，我们也将讨论这个问题。
Some servers present Usenet newsgroups to IMAP users. Newsgroups, and other such hierarchical mailbox structures, can be very numerous but may have only a few entries at the top level of hierarchy. Also, some servers are built against mail stores that can, unbeknownst to the server, have circular hierarchies - that is, it's possible for "a/b/c/d" to resolve to the same file structure as "a", which would then mean that "a/b/c/d/b" is the same as "a/b", and the hierarchy will never end. The LIST response in this case will be unlimited.
一些服务器向IMAP用户提供Usenet新闻组。新闻组和其他类似的层次邮箱结构可能非常多，但在层次结构的顶层可能只有几个条目。此外，有些服务器是针对邮件存储构建的，在服务器不知道的情况下，邮件存储可以具有循环层次结构——也就是说，“a/b/c/d”可以解析为与“a”相同的文件结构，这意味着“a/b/c/d/b”与“a/b”相同，层次结构永远不会结束。在这种情况下，列表响应将是无限的。
Clients that will have trouble with this are those that use
有问题的客户端是那些使用
C: 001 LIST "" *
C:001列表“”*
to determine the mailbox list. Because of this, clients should not use an unqualified "*" that way in the LIST command. A safer approach is to list each level of hierarchy individually, allowing the user to traverse the tree one limb at a time, thus:
以确定邮箱列表。因此，客户端不应在LIST命令中以这种方式使用非限定的“*”。更安全的方法是单独列出层次结构的每个级别，允许用户一次遍历一根树枝，因此：
C: 001 LIST "" %
S: * LIST () "/" Banana
S: * LIST ...etc...
S: 001 OK done
C: 001 LIST "" %
S: * LIST () "/" Banana
S: * LIST ...etc...
S: 001 OK done
and then
然后
C: 002 LIST "" Banana/%
S: * LIST () "/" Banana/Apple
S: * LIST ...etc...
S: 002 OK done
C: 002 LIST "" Banana/%
S: * LIST () "/" Banana/Apple
S: * LIST ...etc...
S: 002 OK done
Using this technique the client's user interface can give the user full flexibility without choking on the voluminous reply to "LIST *".
使用这种技术，客户机的用户界面可以为用户提供充分的灵活性，而不会因大量回复“LIST*”而感到窒息。
Of course, it is still possible that the reply to
当然，仍然有可能
C: 005 LIST "" alt.fan.celebrity.%
C:005列出“另类名人”
may be thousands of entries long, and there is, unfortunately, nothing the client can do to protect itself from that. This has not yet been a notable problem.
可能有数千个条目，不幸的是，客户端无法保护自己不受此影响。这还不是一个值得注意的问题。
Servers that may export circular hierarchies (any server that directly presents a UNIX file system, for instance) should limit the hierarchy depth to prevent unlimited LIST responses. A suggested depth limit is 20 hierarchy levels.
可能导出循环层次结构的服务器（例如，直接呈现UNIX文件系统的任何服务器）应限制层次结构的深度，以防止无限的列表响应。建议的深度限制为20个层次。
When a client selects a mailbox, it is given a count, in the untagged EXISTS response, of the messages in the mailbox. This number can be very large. In such a case it might be unwise to use
当客户端选择邮箱时，会在Untaged EXISTS响应中为其提供邮箱中邮件的计数。这个数字可能非常大。在这种情况下，使用
C: 004 FETCH 1:* ALL
C: 004 FETCH 1:* ALL
to populate the user's view of the mailbox. One good method to avoid problems with this is to batch the requests, thus:
以填充用户的邮箱视图。避免此问题的一个好方法是批处理请求，因此：
C: 004 FETCH 1:50 ALL
S: * 1 FETCH ...etc...
S: 004 OK done
C: 005 FETCH 51:100 ALL
S: * 51 FETCH ...etc...
S: 005 OK done
C: 006 FETCH 101:150 ALL
...etc...
C: 004 FETCH 1:50 ALL
S: * 1 FETCH ...etc...
S: 004 OK done
C: 005 FETCH 51:100 ALL
S: * 51 FETCH ...etc...
S: 005 OK done
C: 006 FETCH 101:150 ALL
...etc...
Using this method, another command, such as "FETCH 6 BODY[1]" can be inserted as necessary, and the client will not have its access to the server blocked by a storm of FETCH replies. (Such a method could be reversed to fetch the LAST 50 messages first, then the 50 prior to that, and so on.)
使用此方法，可以根据需要插入另一个命令，如“FETCH 6 BODY[1]”，客户端对服务器的访问不会因大量的FETCH回复而受阻。（这种方法可以反过来先获取最后50条消息，然后再获取之前的50条消息，依此类推。）
As a smart extension of this, a well designed client, prepared for very large mailboxes, will not automatically fetch data for all messages AT ALL. Rather, the client will populate the user's view only as the user sees it, possibly pre-fetching selected information, and only fetching other information as the user scrolls to it. For example, to select only those messages beginning with the first unseen one:
作为此功能的智能扩展，一个设计良好的客户机（为非常大的邮箱做好准备）根本不会自动获取所有消息的数据。相反，客户端将仅在用户看到时填充用户视图，可能会预取所选信息，并且仅在用户滚动到视图时获取其他信息。例如，要仅选择以第一条未看到的消息开头的消息，请执行以下操作：
C: 003 SELECT INBOX
S: * 10000 EXISTS
S: * 80 RECENT
S: * FLAGS (\Answered \Flagged \Deleted \Draft \Seen)
S: * OK [UIDVALIDITY 824708485] UID validity status
S: * OK [UNSEEN 9921] First unseen message
S: 003 OK [READ-WRITE] SELECT completed
C: 004 FETCH 9921:* ALL
... etc...
C: 003 SELECT INBOX
S: * 10000 EXISTS
S: * 80 RECENT
S: * FLAGS (\Answered \Flagged \Deleted \Draft \Seen)
S: * OK [UIDVALIDITY 824708485] UID validity status
S: * OK [UNSEEN 9921] First unseen message
S: 003 OK [READ-WRITE] SELECT completed
C: 004 FETCH 9921:* ALL
... etc...
If the server does not return an OK [UNSEEN] response, the client may use SEARCH UNSEEN to obtain that value.
如果服务器没有返回OK[UNSEEN]响应，客户端可以使用SEARCH UNSEEN来获取该值。
This mechanism is good as a default presentation method, but only works well if the default message order is acceptable. A client may want to present various sort orders to the user (by subject, by date sent, by sender, and so on) and in that case (lacking a SORT extension on the server side) the client WILL have to retrieve all message descriptors. A client that provides this service should not do it by default and should inform the user of the costs of choosing this option for large mailboxes.
这种机制作为默认的表示方法很好，但只有在默认的消息顺序是可接受的情况下才能很好地工作。客户机可能希望向用户呈现各种排序顺序（按主题、按发送日期、按发件人等），在这种情况下（服务器端缺少排序扩展），客户机将必须检索所有消息描述符。默认情况下，提供此服务的客户端不应这样做，而应通知用户为大型邮箱选择此选项的成本。
The issue here is similar to the one for a list of messages. In the BODYSTRUCTURE response the client knows the size, in bytes, of the body part it plans to fetch. Suppose this is a 70 MB video clip. The client can use partial fetches to retrieve the body part in pieces, avoiding the problem of an uninterruptible 70 MB literal coming back from the server:
这里的问题类似于消息列表的问题。在BODYSTRUCTURE响应中，客户机知道它计划获取的身体部位的大小（以字节为单位）。假设这是一个70 MB的视频剪辑。客户端可以使用部分回迁来检索分段的主体部分，从而避免从服务器返回不间断的70 MB文本的问题：
C: 022 FETCH 3 BODY[1]<0.20000>
S: * 3 FETCH (FLAGS(\Seen) BODY[1]<0> {20000}
S: ...data...)
S: 022 OK done
C: 023 FETCH 3 BODY[1]<20001.20000>
S: * 3 FETCH (BODY[1]<20001> {20000}
S: ...data...)
S: 023 OK done
C: 024 FETCH 3 BODY[1]<40001.20000>
...etc...
C: 022 FETCH 3 BODY[1]<0.20000>
S: * 3 FETCH (FLAGS(\Seen) BODY[1]<0> {20000}
S: ...data...)
S: 022 OK done
C: 023 FETCH 3 BODY[1]<20001.20000>
S: * 3 FETCH (BODY[1]<20001> {20000}
S: ...data...)
S: 023 OK done
C: 024 FETCH 3 BODY[1]<40001.20000>
...etc...
Because FETCH BODYSTRUCTURE is necessary in order to determine the number of body parts, and, thus, whether a message has "attachments", clients often use FETCH FULL as their normal method of populating the user's view of a mailbox. The benefit is that the client can display a paperclip icon or some such indication along with the normal message summary. However, this comes at a significant cost with some server configurations. The parsing needed to generate the FETCH BODYSTRUCTURE response may be time-consuming compared with that needed for FETCH ENVELOPE. The client developer should consider this issue when deciding whether the ability to add a paperclip icon is worth the tradeoff in performance, especially with large mailboxes.
由于FETCH BODYSTRUCTURE对于确定正文部分的数量以及邮件是否具有“附件”是必需的，因此客户端通常使用FETCH FULL作为填充用户邮箱视图的常规方法。这样做的好处是，客户端可以显示一个回形针图标或一些类似的指示以及正常的消息摘要。然而，对于某些服务器配置来说，这是一个巨大的成本。与FETCH信封所需的解析相比，生成FETCH BODYSTRUCTURE响应所需的解析可能比较耗时。客户端开发者应该考虑这个问题，当决定是否添加一个剪纸图标的能力是值得权衡的性能，特别是与大型邮箱。
Some clients, rather than using FETCH BODYSTRUCTURE, use FETCH BODY[] (or the equivalent FETCH RFC822) to retrieve the entire message. They then do the MIME parsing in the client. This may give the client slightly more flexibility in some areas (access, for instance, to header fields that aren't returned in the BODYSTRUCTURE and
有些客户机不使用fetchbodystructure，而是使用fetchbody[]（或等效的fetchrfc822）来检索整个消息。然后，他们在客户端执行MIME解析。这可能会使客户机在某些方面稍有灵活性（例如，访问BODYSTRUCTURE中未返回的头字段和
ENVELOPE responses), but it can cause severe performance problems by forcing the transfer of all body parts when the user might only want to see some of them - a user logged on by modem and reading a small text message with a large ZIP file attached may prefer to read the text only and save the ZIP file for later. Therefore, a client should not normally retrieve entire messages and should retrieve message body parts selectively.
信封响应），但当用户可能只想看到部分身体部位时，它会强制传输所有身体部位，从而导致严重的性能问题-通过调制解调器登录并阅读带有大ZIP文件的小文本消息的用户可能更喜欢只阅读文本并保存ZIP文件以备以后使用。因此，客户端通常不应检索整个消息，而应选择性地检索消息正文部分。
A client can wind up building a very long command line in an effort to try to be efficient about requesting information from a server. This can typically happen when a client builds a message set from selected messages and doesn't recognise that contiguous blocks of messages may be group in a range. Suppose a user selects all 10,000 messages in a large mailbox and then unselects message 287. The client could build that message set as "1:286,288:10000", but a client that doesn't handle that might try to enumerate each message individually and build "1,2,3,4, [and so on] ,9999,10000". Adding that to the fetch command results in a command line that's almost 49,000 octets long, and, clearly, one can construct a command line that's even longer.
客户机最终可能会构建一个很长的命令行，以便在从服务器请求信息时更加高效。当客户机根据选定的消息构建消息集，并且无法识别连续的消息块可能在某个范围内分组时，通常会发生这种情况。假设用户选择一个大邮箱中的所有10000封邮件，然后取消选择邮件287。客户端可以将该消息集构建为“1:286288:10000”，但不处理该消息的客户端可能会尝试单独枚举每条消息，并构建“1,2,3,4[等等]、99991000”。将其添加到fetch命令中会产生一个将近49000个八位字节长的命令行，而且，很明显，可以构造一个更长的命令行。
A client should limit the length of the command lines it generates to approximately 1000 octets (including all quoted strings but not including literals). If the client is unable to group things into ranges so that the command line is within that length, it should split the request into multiple commands. The client should use literals instead of long quoted strings, in order to keep the command length down.
客户端应将其生成的命令行长度限制为大约1000个八位字节（包括所有带引号的字符串，但不包括文字）。如果客户机无法将内容分组到范围中，以便命令行在该长度内，则应将请求拆分为多个命令。客户机应该使用文本而不是长引号字符串，以便降低命令长度。
For its part, a server should allow for a command line of at least 8000 octets. This provides plenty of leeway for accepting reasonable length commands from clients. The server should send a BAD response to a command that does not end within the server's maximum accepted command length.
就服务器而言，它应该允许至少8000个八位字节的命令行。这为从客户端接受合理长度的命令提供了很大的余地。服务器应发送错误的命令响应，该命令的结尾不在服务器可接受的最大命令长度内。
The client isn't the only entity that can get flooded: the end user, too, may need some flood control. The IMAP4 protocol provides such control in the form of subscriptions. Most servers support the SUBSCRIBE, UNSUBSCRIBE, and LSUB commands, and many users choose to narrow down a large list of available mailboxes by subscribing to the ones that they usually want to see. Clients, with this in mind, should give the user a way to see only subscribed mailboxes. A client that never uses the LSUB command takes a significant usability feature away from the user. Of course, the client would not want to hide the LIST command completely; the user needs to have a way to
客户端不是唯一一个可能被淹没的实体：最终用户也可能需要一些洪水控制。IMAP4协议以订阅的形式提供这种控制。大多数服务器支持SUBSCRIBE、UNSUBSCRIBE和LSUB命令，许多用户选择通过订阅他们通常希望看到的邮箱来缩小可用邮箱的大列表。考虑到这一点，客户端应该为用户提供只查看已订阅邮箱的方式。从不使用LSUB命令的客户机会让用户失去一个重要的可用性特性。当然，客户机不希望完全隐藏LIST命令；用户需要有一种方法
choose between LIST and LSUB. The usual way to do this is to provide a setting like "show which mailboxes?: [] all [] subscribed only".
在列表和LSUB之间选择。通常的方法是提供类似“显示哪些邮箱？”：[]仅订阅所有[]的设置。
IMAP SEARCH commands can become particularly troublesome (that is, slow) on mailboxes containing a large number of messages. So let's put a few things in perspective in that regard.
IMAP搜索命令在包含大量邮件的邮箱上可能会变得特别麻烦（即速度慢）。因此，让我们从这个角度来看一些事情。
The flag searches should be fast. The flag searches (ALL, [UN]SEEN, [UN]ANSWERED, [UN]DELETED, [UN]DRAFT, [UN]FLAGGED, NEW, OLD, RECENT) are known to be used by clients for the client's own use (for instance, some clients use "SEARCH UNSEEN" to find unseen mail and "SEARCH DELETED" to warn the user before expunging messages).
标志搜索应该是快速的。标记搜索（所有、[UN]已看到、[UN]已回答、[UN]已删除、[UN]草稿、[UN]已标记、新的、旧的、最近的）已知由客户端用于客户端自身使用（例如，一些客户端使用“搜索未看到”查找未看到的邮件，“搜索已删除”在删除邮件之前警告用户）。
Other searches, particularly the text searches (HEADER, TEXT, BODY) are initiated by the user, rather than by the client itself, and somewhat slower performance can be tolerated, since the user is aware that the search is being done (and is probably aware that it might be time-consuming). A smart server might use dynamic indexing to speed commonly used text searches.
其他搜索，特别是文本搜索（标题、文本、正文）是由用户发起的，而不是由客户端本身发起的，并且可以容忍稍慢的性能，因为用户知道正在进行搜索（并且可能知道这可能很耗时）。智能服务器可以使用动态索引来加速常用的文本搜索。
The client may allow other commands to be sent to the server while a SEARCH is in progress, but at the time of this writing there is little or no server support for parallel processing of multiple commands in the same session (and see "Multiple Accesses of the Same Mailbox" above for a description of the dangers of trying to work around this by doing your SEARCH in another session).
在进行搜索时，客户端可能允许向服务器发送其他命令，但在撰写本文时，服务器很少或根本不支持在同一会话中并行处理多个命令（请参阅“同一邮箱的多个访问”）以上是通过在另一个会话中进行搜索来解决此问题的危险描述）。
Another word about text searches: some servers, built on database back-ends with indexed search capabilities, may return search results that do not match the IMAP spec's "case-insensitive substring" requirements. While these servers are in violation of the protocol, there is little harm in the violation as long as the search results are used only in response to a user's request. Still, developers of such servers should be aware that they ARE violating the protocol, should think carefully about that behaviour, and must be certain that their servers respond accurately to the flag searches for the reasons outlined above.
关于文本搜索的另一个说法：一些服务器构建在具有索引搜索功能的数据库后端上，可能返回与IMAP规范的“不区分大小写的子字符串”要求不匹配的搜索结果。虽然这些服务器违反了协议，但只要搜索结果仅用于响应用户的请求，那么违反协议的危害就很小。尽管如此，此类服务器的开发人员应该意识到他们违反了协议，应该仔细考虑这种行为，并且必须确保他们的服务器基于上述原因准确响应标记搜索。
In addition, servers should support CHARSET UTF-8 [UTF-8] in searches.
此外，服务器应在搜索中支持字符集UTF-8[UTF-8]。
IMAP4 provides ways for a server to tell a client in advance what is and isn't permitted in some circumstances. Clients should use these features to avoid sending requests that a well designed client would know to be invalid. This section explains this in more detail.
IMAP4为服务器提供了在某些情况下提前告知客户机哪些是允许的，哪些是不允许的。客户机应该使用这些功能来避免发送设计良好的客户机知道无效的请求。本节将对此进行更详细的解释。
All IMAP4 clients should use the CAPABILITY command to determine what version of IMAP and what optional features a server supports. The client should not send IMAP4rev1 commands and arguments to a server that does not advertize IMAP4rev1 in its CAPABILITY response. Similarly, the client should not send IMAP4 commands that no longer exist in IMAP4rev1 to a server that does not advertize IMAP4 in its CAPABILITY response. An IMAP4rev1 server is NOT required to support obsolete IMAP4 or IMAP2bis commands (though some do; do not let this fact lull you into thinking that it's valid to send such commands to an IMAP4rev1 server).
所有IMAP4客户端都应该使用CAPABILITY命令来确定服务器支持的IMAP版本和可选功能。客户端不应将IMAP4rev1命令和参数发送到在其功能响应中未播发IMAP4rev1的服务器。类似地，客户端不应将IMAP4rev1中不再存在的IMAP4命令发送到在其功能响应中未播发IMAP4的服务器。IMAP4rev1服务器不需要支持过时的IMAP4或IMAP2bis命令（尽管有些服务器需要支持；不要让这一事实诱使您认为将此类命令发送到IMAP4rev1服务器是有效的）。
A client should not send commands to probe for the existance of certain extensions. All standard and standards-track extensions include CAPABILITY tokens indicating their presense. All private and experimental extensions should do the same, and clients that take advantage of them should use the CAPABILITY response to determine whether they may be used or not.
客户端不应发送命令来探测某些扩展的存在。所有标准和标准跟踪扩展都包含表示其存在的功能标记。所有私有扩展和实验扩展都应该这样做，利用它们的客户端应该使用功能响应来确定是否可以使用它们。
In many cases, the server, in response to a command, will tell the client something about what can and can't be done with a particular mailbox. The client should pay attention to this information and should not try to do things that it's been told it can't do.
在许多情况下，服务器在响应命令时会告诉客户端关于特定邮箱可以做什么和不能做什么的信息。客户应该注意这些信息，不应该尝试做他们被告知不能做的事情。
Examples:
示例：
* Do not try to SELECT a mailbox that has the \Noselect flag set. * Do not try to CREATE a sub-mailbox in a mailbox that has the \Noinferiors flag set. * Do not respond to a failing COPY or APPEND command by trying to CREATE the target mailbox if the server does not respond with a [TRYCREATE] response code. * Do not try to expunge a mailbox that has been selected with the [READ-ONLY] response code.
* 不要尝试选择设置了\n选择标志的邮箱。*请勿尝试在设置了\n Inferiors标志的邮箱中创建子邮箱。*如果服务器未使用[TRYCREATE]响应代码响应，请不要通过尝试创建目标邮箱来响应失败的复制或追加命令。*请勿尝试删除已使用[只读]响应代码选择的邮箱。
We describe here a number of important protocol-related issues, the misunderstanding of which has caused significant interoperability problems in IMAP4 implementations. One general item is that every implementer should be certain to take note of and to understand section 2.2.2 and the preamble to section 7 of the IMAP4rev1 spec [RFC-2060].
我们在这里描述了一些重要的协议相关问题，对这些问题的误解导致了IMAP4实现中的重大互操作性问题。一个普遍的问题是，每个实施者都应该注意并理解IMAP4rev1规范[RFC-2060]第2.2.2节和第7节序言。
We cannot stress enough the importance of adhering strictly to the protocol grammar. The specification of the protocol is quite rigid; do not assume that you can insert blank space for "readability" if none is called for. Keep in mind that there are parsers out there that will crash if there are protocol errors. There are clients that will report every parser burp to the user. And in any case, information that cannot be parsed is information that is lost. Be careful in your protocol generation. And see "A Word About Testing", below.
严格遵守协议语法的重要性怎么强调都不过分。协议的规范相当严格；如果不需要，请不要假设您可以插入空格以实现“可读性”。请记住，如果存在协议错误，有些解析器将崩溃。有些客户端会向用户报告每个解析器打嗝。在任何情况下，无法解析的信息都是丢失的信息。在生成协议时要小心。请参阅下面的“关于测试的一句话”。
In particular, note that the string in the INTERNALDATE response is NOT an RFC-822 date string - that is, it is not in the same format as the first string in the ENVELOPE response. Since most clients will, in fact, accept an RFC-822 date string in the INTERNALDATE response, it's easy to miss this in your interoperability testing. But it will cause a problem with some client, so be sure to generate the correct string for this field.
特别要注意的是，INTERNALDATE响应中的字符串不是RFC-822日期字符串——也就是说，它与信封响应中的第一个字符串格式不同。事实上，由于大多数客户端都会在INTERNALDATE响应中接受RFC-822日期字符串，因此在互操作性测试中很容易忽略这一点。但这会导致某些客户端出现问题，因此请确保为此字段生成正确的字符串。
Certain characters, currently the double-quote and the backslash, may not be sent as-is inside a quoted string. These characters must be preceded by the escape character if they are in a quoted string, or else the string must be sent as a literal. Both clients and servers must handle this, both on output (they must send these characters properly) and on input (they must be able to receive escaped characters in quoted strings). Example:
某些字符（当前为双引号和反斜杠）不能像在带引号的字符串中那样发送。如果这些字符位于带引号的字符串中，则必须在其前面加转义字符，否则该字符串必须作为文本发送。客户端和服务器都必须处理这个问题，无论是在输出端（它们必须正确发送这些字符）还是在输入端（它们必须能够接收带引号的字符串中的转义字符）。例子：
C: 001 LIST "" %
S: * LIST () "" INBOX
S: * LIST () "\\" TEST
S: * LIST () "\\" {12}
S: "My" mailbox
S: 001 OK done
C: 002 LIST "" "\"My\" mailbox\\%"
S: * LIST () "\\" {17}
S: "My" mailbox\Junk
C: 001 LIST "" %
S: * LIST () "" INBOX
S: * LIST () "\\" TEST
S: * LIST () "\\" {12}
S: "My" mailbox
S: 001 OK done
C: 002 LIST "" "\"My\" mailbox\\%"
S: * LIST () "\\" {17}
S: "My" mailbox\Junk
S: 002 OK done
S:002好的
Note that in the example the server sent the hierarchy delimiter as an escaped character in the quoted string and sent the mailbox name containing imbedded double-quotes as a literal. The client used only quoted strings, escaping both the backslash and the double-quote characters.
请注意，在该示例中，服务器将层次分隔符作为带引号的字符串中的转义字符发送，并将包含嵌入双引号的邮箱名称作为文本发送。客户端仅使用带引号的字符串，对反斜杠和双引号字符进行转义。
The CR and LF characters may be sent ONLY in literals; they are not allowed, even if escaped, inside quoted strings.
CR和LF字符只能以文字形式发送；即使转义，也不允许在带引号的字符串中使用它们。
And while we're talking about special characters: the IMAP spec, in the section titled "Mailbox International Naming Convention", describes how to encode mailbox names in modified UTF-7 [UTF-7 and RFC-2060]. Implementations must adhere to this in order to be interoperable in the international market, and servers should validate mailbox names sent by client and reject names that do not conform.
当我们谈论特殊字符时：IMAP规范在标题为“邮箱国际命名约定”的部分中描述了如何在修改的UTF-7[UTF-7和RFC-2060]中对邮箱名称进行编码。实现必须遵守这一点，以便在国际市场上互操作，服务器应验证客户端发送的邮箱名称，并拒绝不一致的名称。
As to special characters in userids and passwords: clients must not restrict what a user may type in for a userid or a password. The formal grammar specifies that these are "astrings", and an astring can be a literal. A literal, in turn can contain any 8-bit character, and clients must allow users to enter all 8-bit characters here, and must pass them, unchanged, to the server (being careful to send them as literals when necessary). In particular, some server configurations use "@" in user names, and some clients do not allow that character to be entered; this creates a severe interoperability problem.
至于用户名和密码中的特殊字符：客户端不能限制用户输入用户名或密码的内容。形式语法规定这些是“astring”，astring可以是文字。文本可以包含任何8位字符，客户端必须允许用户在此处输入所有8位字符，并且必须将它们原封不动地传递给服务器（在必要时小心地将它们作为文本发送）。特别是，有些服务器配置在用户名中使用“@”，有些客户端不允许输入该字符；这造成了严重的互操作性问题。
Servers that support existing back-end mail stores often have no good place to save UIDs for messages. Often the existing mail store will not have the concept of UIDs in the sense that IMAP has: strictly increasing, never re-issued, 32-bit integers. Some servers solve this by storing the UIDs in a place that's accessible to end users, allowing for the possibility that the users will delete them. Others solve it by re-assigning UIDs every time a mailbox is selected.
支持现有后端邮件存储的服务器通常没有保存邮件UID的好位置。通常，现有的邮件存储区不会像IMAP那样具有UID的概念：严格递增，从不重新发布，32位整数。一些服务器通过将UID存储在最终用户可以访问的地方来解决这个问题，允许用户删除它们。其他人则通过在每次选择邮箱时重新分配UID来解决此问题。
The server should maintain UIDs permanently for all messages if it can. If that's not possible, the server must change the UIDVALIDITY value for the mailbox whenever any of the UIDs may have become invalid. Clients must recognize that the UIDVALIDITY has changed and must respond to that condition by throwing away any information that they have saved about UIDs in that mailbox. There have been many problems in this area when clients have failed to do this; in the worst case it will result in loss of mail when a client deletes the
如果可以，服务器应永久维护所有消息的UID。如果不可能，则服务器必须在任何UID无效时更改邮箱的UIDVality值。客户端必须认识到UID的有效性已更改，并且必须通过丢弃他们在该邮箱中保存的有关UID的任何信息来响应该情况。当客户未能做到这一点时，这一领域出现了许多问题；在最坏的情况下，当客户端删除
wrong piece of mail by using a stale UID.
使用过期UID导致邮件错误。
It seems to be a common misunderstanding that "the UIDVALIDITY and the UID, taken together, form a 64-bit identifier that uniquely identifies a message on a server". This is absolutely NOT TRUE. There is no assurance that the UIDVALIDITY values of two mailboxes be different, so the UIDVALIDITY in no way identifies a mailbox. The ONLY purpose of UIDVALIDITY is, as its name indicates, to give the client a way to check the validity of the UIDs it has cached. While it is a valid implementation choice to put these values together to make a 64-bit identifier for the message, the important concept here is that UIDs are not unique between mailboxes; they are only unique WITHIN a given mailbox.
这似乎是一个常见的误解，即“UIDVality和UID一起构成一个64位标识符，唯一地标识服务器上的消息”。这绝对不是事实。无法保证两个邮箱的UIDVALIDITY值不同，因此UIDVALIDITY无法识别邮箱。正如其名称所示，UIDVALIDITY的唯一目的是为客户端提供一种检查其缓存的UID有效性的方法。虽然将这些值放在一起为消息创建64位标识符是一种有效的实现选择，但这里的重要概念是UID在邮箱之间不是唯一的；它们仅在给定邮箱中是唯一的。
Some server implementations have attempted to make UIDs unique across the entire server. This is inadvisable, in that it limits the life of UIDs unnecessarily. The UID is a 32-bit number and will run out in reasonably finite time if it's global across the server. If you assign UIDs sequentially in one mailbox, you will not have to start re-using them until you have had, at one time or another, 2**32 different messages in that mailbox. In the global case, you will have to reuse them once you have had, at one time or another, 2**32 different messages in the entire mail store. Suppose your server has around 8000 users registered (2**13). That gives an average of 2**19 UIDs per user. Suppose each user gets 32 messages (2**5) per day. That gives you 2**14 days (16000+ days = about 45 years) before you run out. That may seem like enough, but multiply the usage just a little (a lot of spam, a lot of mailing list subscriptions, more users) and you limit yourself too much.
一些服务器实现试图使UID在整个服务器上唯一。这是不可取的，因为它不必要地限制了UID的寿命。UID是一个32位的数字，如果它在整个服务器上是全局的，它将在合理的有限时间内用完。如果您在一个邮箱中按顺序分配UID，则在该邮箱中有2**32封不同的邮件之前，您不必重新使用UID。在全局情况下，一旦您在整个邮件存储中有2**32条不同的邮件，您就必须重用它们。假设您的服务器注册了大约8000个用户（2**13）。这使得每个用户的平均UID为2**19。假设每个用户每天收到32条消息（2**5）。这给了你2**14天（16000多天=大约45年）的时间，然后你就用完了。这似乎已经足够了，但使用量只会增加一点点（大量垃圾邮件、大量邮件列表订阅、更多用户），你就限制了自己太多。
What's worse is that if you have to wrap the UIDs, and, thus, you have to change UIDVALIDITY and invalidate the UIDs in the mailbox, you have to do it for EVERY mailbox in the system, since they all share the same UID pool. If you assign UIDs per mailbox and you have a problem, you only have to kill the UIDs for that one mailbox.
更糟糕的是，如果必须包装UID，因此必须更改UID的有效性并使邮箱中的UID无效，则必须对系统中的每个邮箱执行此操作，因为它们都共享相同的UID池。如果您为每个邮箱分配UID，并且遇到问题，则只需删除该邮箱的UID。
Under extreme circumstances (and this is extreme, indeed), the server may have to invalidate UIDs while a mailbox is in use by a client - that is, the UIDs that the client knows about in its active mailbox are no longer valid. In that case, the server must immediately change the UIDVALIDITY and must communicate this to the client. The server may do this by sending an unsolicited UIDVALIDITY message, in the same form as in response to the SELECT command. Clients must be prepared to handle such a message and the possibly coincident failure of the command in process. For example:
在极端情况下（事实上，这是极端情况），当客户端正在使用邮箱时，服务器可能必须使UID无效，也就是说，客户端在其活动邮箱中知道的UID不再有效。在这种情况下，服务器必须立即更改UIDVality，并且必须将此更改传达给客户端。服务器可以通过发送未经请求的UIDVALIDITY消息来实现这一点，其形式与响应SELECT命令的形式相同。客户机必须准备好处理这样的消息以及过程中可能同时发生的命令失败。例如：
C: 032 UID STORE 382 +Flags.silent \Deleted
S: * OK [UIDVALIDITY 12345] New UIDVALIDITY value!
S: 032 NO UID command rejected because UIDVALIDITY changed!
C: ...invalidates local information and re-fetches...
C: 033 FETCH 1:* UID
...etc...
C: 032 UID STORE 382 +Flags.silent \Deleted
S: * OK [UIDVALIDITY 12345] New UIDVALIDITY value!
S: 032 NO UID command rejected because UIDVALIDITY changed!
C: ...invalidates local information and re-fetches...
C: 033 FETCH 1:* UID
...etc...
At the time of the writing of this document, the only server known to do this does so only under the following condition: the client selects INBOX, but there is not yet a physical INBOX file created. Nonetheless, the SELECT succeeds, exporting an empty INBOX with a temporary UIDVALIDITY of 1. While the INBOX remains selected, mail is delivered to the user, which creates the real INBOX file and assigns a permanent UIDVALIDITY (that is likely not to be 1). The server reports the change of UIDVALIDITY, but as there were no messages before, so no UIDs have actually changed, all the client must do is accept the change in UIDVALIDITY.
在编写本文档时，已知唯一执行此操作的服务器仅在以下条件下执行此操作：客户端选择收件箱，但尚未创建物理收件箱文件。尽管如此，选择成功，导出了一个临时UIDVality为1的空收件箱。当收件箱保持选中状态时，邮件将发送给用户，用户将创建真正的收件箱文件并分配永久UIDVality（可能不是1）。服务器报告UIDVality的更改，但由于之前没有消息，因此UID实际上没有更改，因此客户端必须做的就是接受UIDVality中的更改。
Alternatively, a server may force the client to re-select the mailbox, at which time it will obtain a new UIDVALIDITY value. To do this, the server closes this client session (see "Severed Connections" above) and the client then reconnects and gets back in synch. Clients must be prepared for either of these behaviours.
或者，服务器可以强制客户端重新选择邮箱，此时它将获得新的UIDVality值。为此，服务器关闭此客户端会话（请参阅上面的“已断开的连接”），然后客户端重新连接并恢复同步。客户必须为上述任何一种行为做好准备。
We do not know of, nor do we anticipate the future existance of, a server that changes UIDVALIDITY while there are existing messages, but clients must be prepared to handle this eventuality.
我们不知道，也不预期将来会有这样一个服务器，它在存在现有消息时会改变UID的有效性，但客户端必须准备好处理这种情况。
When a client asks for certain information in a FETCH command, the server may return the requested information in any order, not necessarily in the order that it was requested. Further, the server may return the information in separate FETCH responses and may also return information that was not explicitly requested (to reflect to the client changes in the state of the subject message). Some examples:
当客户机在FETCH命令中请求某些信息时，服务器可以按任何顺序返回请求的信息，而不一定按请求的顺序返回。此外，服务器可以在单独的获取响应中返回信息，并且还可以返回未被明确请求的信息（以向客户端反映主题消息状态的变化）。一些例子：
C: 001 FETCH 1 UID FLAGS INTERNALDATE
S: * 5 FETCH (FLAGS (\Deleted))
S: * 1 FETCH (FLAGS (\Seen) INTERNALDATE "..." UID 345)
S: 001 OK done
C: 001 FETCH 1 UID FLAGS INTERNALDATE
S: * 5 FETCH (FLAGS (\Deleted))
S: * 1 FETCH (FLAGS (\Seen) INTERNALDATE "..." UID 345)
S: 001 OK done
(In this case, the responses are in a different order. Also, the server returned a flag update for message 5, which wasn't part of the client's request.)
（在本例中，响应的顺序不同。此外，服务器还返回了消息5的标志更新，这不是客户端请求的一部分。）
C: 002 FETCH 2 UID FLAGS INTERNALDATE
S: * 2 FETCH (INTERNALDATE "...")
S: * 2 FETCH (UID 399)
S: * 2 FETCH (FLAGS ())
S: 002 OK done
C: 002 FETCH 2 UID FLAGS INTERNALDATE
S: * 2 FETCH (INTERNALDATE "...")
S: * 2 FETCH (UID 399)
S: * 2 FETCH (FLAGS ())
S: 002 OK done
(In this case, the responses are in a different order and were returned in separate responses.)
（在本例中，响应的顺序不同，以单独的响应返回。）
C: 003 FETCH 2 BODY[1]
S: * 2 FETCH (FLAGS (\Seen) BODY[1] {14}
S: Hello world!
S: )
S: 003 OK done
C: 003 FETCH 2 BODY[1]
S: * 2 FETCH (FLAGS (\Seen) BODY[1] {14}
S: Hello world!
S: )
S: 003 OK done
(In this case, the FLAGS response was added by the server, since fetching the body part caused the server to set the \Seen flag.)
（在本例中，服务器添加了标志响应，因为获取主体部分会导致服务器设置\Seen标志。）
Because of this characteristic a client must be ready to receive any FETCH response at any time and should use that information to update its local information about the message to which the FETCH response refers. A client must not assume that any FETCH responses will come in any particular order, or even that any will come at all. If after receiving the tagged response for a FETCH command the client finds that it did not get all of the information requested, the client should send a NOOP command to the server to ensure that the server has an opportunity to send any pending EXPUNGE responses to the client (see [RFC-2180]).
由于此特性，客户机必须随时准备好接收任何提取响应，并应使用该信息更新关于提取响应所引用消息的本地信息。客户机不能假设任何获取响应将以任何特定的顺序出现，甚至不能假设任何响应将以任何特定的顺序出现。如果在收到FETCH命令的标记响应后，客户端发现它没有获得请求的所有信息，则客户端应向服务器发送NOOP命令，以确保服务器有机会向客户端发送任何挂起的删除响应（请参阅[RFC-2180]）。
Some back-end mail stores keep the mail in a canonical form, rather than retaining the original MIME format of the messages. This means that the server must reassemble the message to produce a MIME stream when a client does a fetch such as RFC822 or BODY[], requesting the entire message. It also may mean that the server has no convenient way to know the RFC822.SIZE of the message. Often, such a server will actually have to build the MIME stream to compute the size, only to throw the stream away and report the size to the client.
一些后端邮件存储以规范的形式保存邮件，而不是保留邮件的原始MIME格式。这意味着，当客户端执行诸如RFC822或BODY[]之类的获取请求整个消息时，服务器必须重新组装消息以生成MIME流。这也可能意味着服务器无法方便地知道消息的RFC822.1大小。通常，这样的服务器实际上必须构建MIME流来计算大小，而只需丢弃该流并向客户端报告大小。
When this is the case, some servers have chosen to estimate the size, rather than to compute it precisely. Such an estimate allows the client to display an approximate size to the user and to use the estimate in flood control considerations (q.v.), but requires that the client not use the size for things such as allocation of buffers, because those buffers might then be too small to hold the actual MIME stream. Instead, a client should use the size that's returned in the literal when you fetch the data.
在这种情况下，一些服务器会选择估算大小，而不是精确计算大小。这样的估计允许客户端向用户显示近似大小，并在洪水控制考虑（q.v.）中使用估计值，但要求客户端不要将大小用于诸如缓冲区分配之类的事情，因为这些缓冲区可能太小，无法容纳实际的MIME流。相反，客户机应该使用在获取数据时返回的文本大小。
The protocol requires that the RFC822.SIZE value returned by the server be EXACT. Estimating the size is a protocol violation, and server designers must be aware that, despite the performance savings they might realize in using an estimate, this practice will cause some clients to fail in various ways. If possible, the server should compute the RFC822.SIZE for a particular message once, and then save it for later retrieval. If that's not possible, the server must compute the value exactly every time. Incorrect estimates do cause severe interoperability problems with some clients.
协议要求服务器返回的RFC822.SIZE值精确。估计大小违反了协议，服务器设计人员必须意识到，尽管使用估计值可以节省性能，但这种做法会导致一些客户端以各种方式失败。如果可能，服务器应该计算一次特定消息的RFC822.SIZE，然后将其保存以供以后检索。如果不可能，服务器每次都必须精确计算该值。错误的估计确实会导致某些客户端出现严重的互操作性问题。
If the server allows multiple connections to the same mailbox, it is often possible for messages to be expunged in one client unbeknownst to another client. Since the server is not allowed to tell the client about these expunged messages in response to a FETCH command, the server may have to deal with the issue of how to return information about an expunged message. There was extensive discussion about this issue, and the results of that discussion are summarized in [RFC-2180]. See that reference for a detailed explanation and for recommendations.
如果服务器允许多个连接到同一邮箱，则通常可能会在一个客户端中删除邮件，而另一个客户端则不知道。由于服务器不允许在响应FETCH命令时告诉客户端这些已删除的消息，因此服务器可能必须处理如何返回已删除消息的信息的问题。关于这个问题进行了广泛的讨论，讨论的结果总结在[RFC-2180]中。有关详细说明和建议，请参阅该参考资料。
Namespaces are a very muddy area in IMAP4 implementation right now (see [NAMESPACE] for a proposal to clear the water a bit). Until the issue is resolved, the important thing for client developers to understand is that some servers provide access through IMAP to more than just the user's personal mailboxes, and, in fact, the user's personal mailboxes may be "hidden" somewhere in the user's default hierarchy. The client, therefore, should provide a setting wherein the user can specify a prefix to be used when accessing mailboxes. If the user's mailboxes are all in "~/mail/", for instance, then the user can put that string in the prefix. The client would then put the prefix in front of any name pattern in the LIST and LSUB commands:
名称空间目前在IMAP4实现中是一个非常混乱的领域（请参阅[NAMESPACE]，以了解稍微澄清一点的建议）。在问题得到解决之前，客户机开发人员需要了解的重要一点是，有些服务器通过IMAP提供对用户个人邮箱的访问，而不仅仅是用户的个人邮箱，事实上，用户的个人邮箱可能“隐藏”在用户的默认层次结构中的某个位置。因此，客户端应该提供一个设置，用户可以在其中指定访问邮箱时使用的前缀。例如，如果用户的邮箱都在“~/mail/”中，则用户可以将该字符串放在前缀中。然后，客户端会将前缀放在列表和LSUB命令中任何名称模式的前面：
C: 001 LIST "" ~/mail/%
C: 001 LIST "" ~/mail/%
(See also "Reference Names in the LIST Command" below.)
（另请参见下面的“列表命令中的引用名称”。）
It may seem at first that this is part of the namespace issue; it is not, and is only indirectly related to it. A number of clients like to create special-use mailboxes with particular names. Most commonly, clients with a "trash folder" model of message deletion want to create a mailbox with the name "Trash" or "Deleted". Some
乍一看，这似乎是名称空间问题的一部分；它不是，而且只是间接地与之相关。许多客户端喜欢创建具有特定名称的专用邮箱。最常见的情况是，具有“垃圾箱文件夹”邮件删除模式的客户端希望创建一个名为“垃圾箱”或“已删除”的邮箱。一些
clients want to create a "Drafts" mailbox, an "Outbox" mailbox, or a "Sent Mail" mailbox. And so on. There are two major interoperability problems with this practice:
客户端希望创建“草稿”邮箱、“发件箱”邮箱或“已发送邮件”邮箱。等等这种做法存在两个主要的互操作性问题：
1. different clients may use different names for mailboxes with similar functions (such as "Trash" and "Deleted"), or may manage the same mailboxes in different ways, causing problems if a user switches between clients and 2. there is no guarantee that the server will allow the creation of the desired mailbox.
1. 不同的客户端可能对具有类似功能的邮箱使用不同的名称（例如“垃圾箱”和“已删除”），或者可能以不同的方式管理相同的邮箱，如果用户在客户端和2之间切换，则会导致问题。无法保证服务器将允许创建所需的邮箱。
The client developer is, therefore, well advised to consider carefully the creation of any special-use mailboxes on the server, and, further, the client must not require such mailbox creation - that is, if you do decide to do this, you must handle gracefully the failure of the CREATE command and behave reasonably when your special-use mailboxes do not exist and can not be created.
因此，建议客户开发者仔细考虑在服务器上创建任何特殊用途邮箱，并且，客户端不一定需要这样的邮箱创建——也就是说，如果您决定这样做，当特殊用途邮箱不存在且无法创建时，您必须优雅地处理CREATE命令的失败，并合理行事。
In addition, the client developer should provide a convenient way for the user to select the names for any special-use mailboxes, allowing the user to make these names the same in all clients used and to put them where the user wants them.
此外，客户机开发人员应为用户提供一种方便的方式来选择任何特殊用途邮箱的名称，允许用户在所有使用的客户机中使用相同的名称，并将其放置在用户需要的位置。
Many implementers of both clients and servers are confused by the "reference name" on the LIST command. The reference name is intended to be used in much the way a "cd" (change directory) command is used on Unix, PC DOS, Windows, and OS/2 systems. That is, the mailbox name is interpreted in much the same way as a file of that name would be found if one had done a "cd" command into the directory specified by the reference name. For example, in Unix we have the following:
客户机和服务器的许多实现者都被LIST命令上的“reference name”弄糊涂了。参考名称的使用方式与Unix、PC DOS、Windows和OS/2系统上使用“cd”（更改目录）命令的方式大致相同。也就是说，邮箱名称的解释方式与在引用名称指定的目录中执行“cd”命令时找到该名称的文件的解释方式大致相同。例如，在Unix中，我们有以下功能：
> cd /u/jones/junk
> vi banana [file is "/u/jones/junk/banana"]
> vi stuff/banana [file is "/u/jones/junk/stuff/banana"]
> vi /etc/hosts [file is "/etc/hosts"]
> cd /u/jones/junk
> vi banana [file is "/u/jones/junk/banana"]
> vi stuff/banana [file is "/u/jones/junk/stuff/banana"]
> vi /etc/hosts [file is "/etc/hosts"]
In the past, there have been several interoperability problems with this. First, while some IMAP servers are built on Unix or PC file systems, many others are not, and the file system semantics do not make sense in those configurations. Second, while some IMAP servers expose the underlying file system to the clients, others allow access only to the user's personal mailboxes, or to some other limited set of files, making such file-system-like semantics less meaningful. Third, because the IMAP spec leaves the interpretation of the reference name as "implementation-dependent", in the past the various server implementations handled it in vastly differing ways.
在过去，这方面存在一些互操作性问题。首先，虽然一些IMAP服务器构建在Unix或PC文件系统上，但其他许多服务器都不是，并且文件系统语义在这些配置中没有意义。其次，虽然一些IMAP服务器向客户机公开底层文件系统，但其他服务器只允许访问用户的个人邮箱或其他有限的文件集，这使得类似文件系统的语义意义不大。第三，由于IMAP规范将引用名称的解释保留为“依赖于实现”，因此在过去，各种服务器实现以截然不同的方式处理它。
The following recommendations are the result of significant operational experience, and are intended to maximize interoperability.
以下建议是重要运营经验的结果，旨在最大限度地提高互操作性。
Server implementations must implement the reference argument in a way that matches the intended "change directory" operation as closely as possible. As a minimum implementation, the reference argument may be prepended to the mailbox name (while suppressing double delimiters; see the next paragraph). Even servers that do not provide a way to break out of the current hierarchy (see "breakout facility" below) must provide a reasonable implementation of the reference argument, as described here, so that they will interoperate with clients that use it.
服务器实现必须以与预期的“更改目录”操作尽可能接近的方式实现引用参数。作为最低限度的实现，可以在邮箱名称前加上reference参数（同时禁止使用双分隔符；请参见下一段）。即使服务器不提供打破当前层次结构的方法（请参阅下面的“突破工具”），也必须提供引用参数的合理实现，如本文所述，以便它们能够与使用它的客户端进行互操作。
Server implementations that prepend the reference argument to the mailbox name should insert a hierarchy delimiter between them, and must not insert a second if one is already present:
将引用参数前置到邮箱名称的服务器实现应在它们之间插入层次结构分隔符，如果已经存在，则不得插入第二个分隔符：
C: A001 LIST ABC DEF
S: * LIST () "/" ABC/DEF <=== should do this
S: A001 OK done
C: A001 LIST ABC DEF
S: * LIST () "/" ABC/DEF <=== should do this
S: A001 OK done
C: A002 LIST ABC/ /DEF
S: * LIST () "/" ABC//DEF <=== must not do this
S: A002 OK done
C: A002 LIST ABC/ /DEF
S: * LIST () "/" ABC//DEF <=== must not do this
S: A002 OK done
On clients, the reference argument is chiefly used to implement a "breakout facility", wherein the user may directly access a mailbox outside the "current directory" hierarchy. Client implementations should have an operational mode that does not use the reference argument. This is to interoperate with older servers that did not implement the reference argument properly. While it's a good idea to give the user access to a breakout facility, clients that do not intend to do so should not use the reference argument at all.
在客户端上，reference参数主要用于实现“breakout facility”，其中用户可以直接访问“current directory”层次结构之外的邮箱。客户端实现应具有不使用引用参数的操作模式。这是为了与未正确实现引用参数的旧服务器进行互操作。虽然让用户访问突破工具是个好主意，但不打算这样做的客户机根本不应该使用reference参数。
Client implementations should always place a trailing hierarchy delimiter on the reference argument. This is because some servers prepend the reference argument to the mailbox name without inserting a hierarchy delimiter, while others do insert a hierarchy delimiter if one is not already present. A client that puts the delimiter in will work with both varieties of server.
客户机实现应始终在引用参数上放置一个尾部层次结构分隔符。这是因为有些服务器在不插入层次结构分隔符的情况下将引用参数前置到邮箱名称，而其他服务器则在层次结构分隔符不存在的情况下插入层次结构分隔符。放入分隔符的客户端将与这两种类型的服务器一起工作。
Client implementations that implement a breakout facility should allow the user to choose whether or not to use a leading hierarchy delimiter on the mailbox argument. This is because the handling of a leading mailbox hierarchy delimiter also varies from server to server, and even between different mailstores on the same server. In some cases, a leading hierarchy delimiter means "discard the
实现断开功能的客户端实现应允许用户选择是否在邮箱参数上使用前导层次结构分隔符。这是因为对前导邮箱层次结构分隔符的处理也因服务器而异，甚至在同一服务器上的不同邮件存储之间也是如此。在某些情况下，前导层次分隔符表示“放弃
reference argument" (implementing the intended breakout facility), thus:
参考参数“（实施预期的突破设施），因此：
C: A001 LIST ABC/ /DEF
S: * LIST () "/" /DEF
S: A001 OK done
C: A001 LIST ABC/ /DEF
S: * LIST () "/" /DEF
S: A001 OK done
In other cases, however, the two are catenated and the extra hierarchy delimiter is discarded, thus:
但是，在其他情况下，这两个属性是链接的，多余的层次分隔符被丢弃，因此：
C: A001 LIST ABC/ /DEF
S: * LIST () "/" ABC/DEF
S: A001 OK done
C: A001 LIST ABC/ /DEF
S: * LIST () "/" ABC/DEF
S: A001 OK done
Client implementations must not assume that the server supports a breakout facility, but may provide a way for the user to use one if it is available. Any breakout facility should be exported to the user interface. Note that there may be other "breakout" characters besides the hierarchy delimiter (for instance, UNIX filesystem servers are likely to use a leading "~" as well), and that their interpretation is server-dependent.
客户机实现不能假设服务器支持断开功能，但可以为用户提供一种使用断开功能的方法（如果可用）。应将任何中断设施导出到用户界面。请注意，除了层次分隔符之外，可能还有其他“breakout”字符（例如，UNIX文件系统服务器也可能使用前导“~”），并且它们的解释依赖于服务器。
The server's selection of what to use as a mailbox hierarchy delimiter is a difficult one, involving several issues: What characters do users expect to see? What characters can they enter for a hierarchy delimiter if it is desired (or required) that the user enter it? What character can be used for the hierarchy delimiter, noting that the chosen character can not otherwise be used in the mailbox name?
服务器选择用作邮箱层次结构分隔符的内容是一个困难的问题，涉及几个问题：用户希望看到哪些字符？如果用户希望（或要求）输入层次定界符，则可以为其输入哪些字符？请注意，在邮箱名称中不能使用所选字符，层次分隔符可以使用哪个字符？
Because some interfaces show users the hierarchy delimiters or allow users to enter qualified mailbox names containing them, server implementations should use delimiter characters that users generally expect to see as name separators. The most common characters used for this are "/" (as in Unix file names), "\" (as in OS/2 and Windows file names), and "." (as in news groups). There is little to choose among these apart from what users may expect or what is dictated by the underlying file system, if any. One consideration about using "\" is that it's also a special character in the IMAP protocol. While the use of other hierarchy delimiter characters is permissible, A DESIGNER IS WELL ADVISED TO STAY WITH ONE FROM THIS SET unless the server is intended for special purposes only. Implementers might be thinking about using characters such as "-", "_", ";", "&", "#", "@", and "!", but they should be aware of the surprise to the user as well as of the effect on URLs and other external specifications (since some of these characters have special meanings there). Also, a
由于某些界面向用户显示层次分隔符或允许用户输入包含它们的限定邮箱名称，服务器实现应使用用户通常希望看到的分隔符字符作为名称分隔符。最常用的字符是“/”（在Unix文件名中）、“\”（在OS/2和Windows文件名中）和“.”（在新闻组中）。除了用户可能期望的内容或底层文件系统（如果有的话）规定的内容之外，在这些内容中几乎没有什么可供选择的。关于使用“\”的一个考虑因素是，它也是IMAP协议中的一个特殊字符。虽然允许使用其他层次分隔符，但设计师最好使用此集合中的一个，除非服务器仅用于特殊目的。实现者可能会考虑使用诸如“-”、“_“、“；”、“&”、“#”、“@”和“！”之类的字符，但他们应该意识到用户的惊讶以及对URL和其他外部规范的影响（因为其中一些字符有特殊的含义）。还有一个
server that uses "\" (and clients of such a server) must remember to escape that character in quoted strings or to send literals instead. Literals are recommended over escaped characters in quoted strings in order to maintain compatibility with older IMAP versions that did not allow escaped characters in quoted strings (but check the grammar to see where literals are allowed):
使用“\”的服务器（以及此类服务器的客户端）必须记住在带引号的字符串中转义该字符，或者改为发送文本。建议将文字置于带引号字符串中的转义字符之上，以保持与不允许在带引号字符串中使用转义字符的旧IMAP版本的兼容性（但请检查语法以查看允许使用文字的位置）：
C: 001 LIST "" {13}
S: + send literal
C: this\%\%\%\h*
S: * LIST () "\\" {27}
S: this\is\a\mailbox\hierarchy
S: 001 OK LIST complete
C: 001 LIST "" {13}
S: + send literal
C: this\%\%\%\h*
S: * LIST () "\\" {27}
S: this\is\a\mailbox\hierarchy
S: 001 OK LIST complete
In any case, a server should not use normal alpha-numeric characters (such as "X" or "0") as delimiters; a user would be very surprised to find that "EXPENDITURES" actually represented a two-level hierarchy. And a server should not use characters that are non-printable or difficult or impossible to enter on a standard US keyboard. Control characters, box-drawing characters, and characters from non-US alphabets fit into this category. Their use presents interoperability problems that are best avoided.
在任何情况下，服务器都不应使用普通字母数字字符（如“X”或“0”）作为分隔符；用户会非常惊讶地发现“支出”实际上代表了两级层次结构。服务器不应使用无法打印、难以或无法在标准美国键盘上输入的字符。控制字符、方框图字符和来自非美国字母的字符都属于这一类别。它们的使用带来了最好避免的互操作性问题。
The UTF-7 encoding of mailbox names also raises questions about what to do with the hierarchy delimiters in encoded names: do we encode each hierarchy level and separate them with delimiters, or do we encode the fully qualified name, delimiters and all? The answer for IMAP is the former: encode each hierarchy level separately, and insert delimiters between. This makes it particularly important not to use as a hierarchy delimiter a character that might cause confusion with IMAP's modified UTF-7 [UTF-7 and RFC-2060] encoding.
邮箱名称的UTF-7编码还提出了如何处理编码名称中的层次分隔符的问题：我们是对每个层次进行编码并用分隔符分隔它们，还是对完全限定的名称、分隔符和所有内容进行编码？IMAP的答案是前者：分别对每个层次结构级别进行编码，并在它们之间插入分隔符。这使得不使用可能与IMAP修改的UTF-7[UTF-7和RFC-2060]编码混淆的字符作为层次分隔符尤为重要。
To repeat: a server should use "/", "\", or "." as its hierarchy delimiter. The use of any other character is likely to cause problems and is STRONGLY DISCOURAGED.
要重复：服务器应使用“/”、“\”或“.”作为其层次结构分隔符。使用任何其他字符都可能导致问题，因此强烈建议不要使用。
The protocol spec is very clear on the matter of what to do with ALERT response codes, and yet there are many clients that violate it so it needs to be said anyway: "The human-readable text contains a special alert that must be presented to the user in a fashion that calls the user's attention to the message." That should be clear enough, but I'll repeat it here: Clients must present ALERT text clearly to the user.
协议规范非常清楚如何处理警报响应代码，但是有许多客户端违反了它，因此无论如何都需要说：“人类可读的文本包含一个特殊警报，必须以一种唤起用户对消息注意的方式呈现给用户。”这应该足够清楚，但我要在这里重复一遍：客户端必须向用户清晰地显示警报文本。
The protocol does not guarantee that a client may delete a mailbox that is not empty, though on some servers it is permissible and is, in fact, much faster than the alternative or deleting all the messages from the client. If the client chooses to try to take advantage of this possibility it must be prepared to use the other method in the even that the more convenient one fails. Further, a client should not try to delete the mailbox that it has selected, but should first close that mailbox; some servers do not permit the deletion of the selected mailbox.
该协议并不保证客户端可以删除非空的邮箱，尽管在某些服务器上这是允许的，而且实际上比从客户端删除所有邮件的备选方案快得多。如果客户选择尝试利用这种可能性，则必须准备使用另一种方法，即使更方便的方法失败。此外，客户端不应尝试删除其选择的邮箱，而应首先关闭该邮箱；某些服务器不允许删除所选邮箱。
That said, a server should permit the deletion of a non-empty mailbox; there's little reason to pass this work on to the client. Moreover, forbidding this prevents the deletion of a mailbox that for some reason can not be opened or expunged, leading to possible denial-of-service problems.
也就是说，服务器应该允许删除非空邮箱；没有什么理由把这项工作转交给客户。此外，禁止此操作可防止删除因某种原因无法打开或删除的邮箱，从而可能导致拒绝服务问题。
Example:
例子：
[User tells the client to delete mailbox BANANA, which is
currently selected...]
C: 008 CLOSE
S: 008 OK done
C: 009 DELETE BANANA
S: 009 NO Delete failed; mailbox is not empty.
C: 010 SELECT BANANA
S: * ... untagged SELECT responses
S: 010 OK done
C: 011 STORE 1:* +FLAGS.SILENT \DELETED
S: 011 OK done
C: 012 CLOSE
S: 012 OK done
C: 013 DELETE BANANA
S: 013 OK done
[User tells the client to delete mailbox BANANA, which is
currently selected...]
C: 008 CLOSE
S: 008 OK done
C: 009 DELETE BANANA
S: 009 NO Delete failed; mailbox is not empty.
C: 010 SELECT BANANA
S: * ... untagged SELECT responses
S: 010 OK done
C: 011 STORE 1:* +FLAGS.SILENT \DELETED
S: 011 OK done
C: 012 CLOSE
S: 012 OK done
C: 013 DELETE BANANA
S: 013 OK done
Since the whole point of IMAP is interoperability, and since interoperability can not be tested in a vacuum, the final recommendation of this treatise is, "Test against EVERYTHING." Test your client against every server you can get an account on. Test your server with every client you can get your hands on. Many clients make limited test versions available on the Web for the downloading. Many server owners will give serious client developers guest accounts for testing. Contact them and ask. NEVER assume that because your client works with one or two servers, or because your server does fine with one or two clients, you will interoperate well
由于IMAP的全部要点是互操作性，而且互操作性不能在真空中测试，因此本论文的最后一个建议是“针对所有内容进行测试”。针对您可以获得帐户的每台服务器测试您的客户端。用每一台你能接触到的客户机测试你的服务器。许多客户端在Web上提供有限的测试版本供下载。许多服务器所有者会给认真的客户机开发人员提供来宾帐户进行测试。联系他们并询问。永远不要假设因为您的客户机与一个或两个服务器协同工作，或者因为您的服务器与一个或两个客户机协同工作良好，所以您可以很好地进行互操作
in general.
一般来说
In particular, in addition to everything else, be sure to test against the reference implementations: the PINE client, the University of Washington server, and the Cyrus server.
特别是，除了其他一切之外，一定要对参考实现进行测试：Poin客户端、华盛顿大学服务器和赛勒斯服务器。
See the following URLs on the web for more information here:
有关更多信息，请参见web上的以下URL：
IMAP Products and Sources: http://www.imap.org/products.html
IMC MailConnect: http://www.imc.org/imc-mailconnect
IMAP Products and Sources: http://www.imap.org/products.html
IMC MailConnect: http://www.imc.org/imc-mailconnect
This document describes behaviour of clients and servers that use the IMAP4 protocol, and as such, has the same security considerations as described in [RFC-2060].
本文档描述了使用IMAP4协议的客户端和服务器的行为，因此具有与[RFC-2060]中所述相同的安全注意事项。
[RFC-2060] Crispin, M., "Internet Message Access Protocol - Version 4rev1", RFC 2060, December 1996.
[RFC-2060]Crispin，M.，“互联网消息访问协议-版本4rev1”，RFC 2060，1996年12月。
[RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC-2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC-2180] Gahrns, M., "IMAP4 Multi-Accessed Mailbox Practice", RFC 2180, July 1997.
[RFC-2180]Gahrns，M.，“IMAP4多址邮箱实践”，RFC 2180，1997年7月。
[UTF-8] Yergeau, F., " UTF-8, a transformation format of Unicode and ISO 10646", RFC 2044, October 1996.
[UTF-8]Yergeau，F.，“UTF-8，Unicode和ISO10646的转换格式”，RFC 2044，1996年10月。
[UTF-7] Goldsmith, D. and M. Davis, "UTF-7, a Mail-Safe Transformation Format of Unicode", RFC 2152, May 1997.
[UTF-7]Goldsmith，D.和M.Davis，“UTF-7，Unicode的邮件安全转换格式”，RFC 2152，1997年5月。
[NAMESPACE] Gahrns, M. and C. Newman, "IMAP4 Namespace", Work in Progress.
[名称空间]Gahrns，M.和C.Newman，“IMAP4名称空间”，正在进行中。
Barry Leiba IBM T.J. Watson Research Center 30 Saw Mill River Road Hawthorne, NY 10532
Barry Leiba IBM T.J.Watson研究中心，纽约州霍桑市锯木厂河路30号，邮编10532
Phone: 1-914-784-7941 EMail: leiba@watson.ibm.com
电话：1-914-784-7941电子邮件：leiba@watson.ibm.com
Copyright (C) The Internet Society (1999). All Rights Reserved.
版权所有（C）互联网协会（1999年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。