RFC3501（imp4协议）中文版
因特网邮件访问协议，版本4rev1（IMAP4rev1）允许一个客户端访问和操作在一个服务器上的电子邮件。IMAP4rev1允许，以一 种功能上等效于本地文件夹的方式，操作邮箱（远程邮件文件夹）。IMAP4rev1也提供这样一个功能，一个离线客户端与服务器异步（交互）。
IMAP4rev1包括以下操作：创建、删除、及重命名邮箱，检查新邮件，永久删除邮件，设置和清除标记，RFC2822及RFC2045解 析，检索，及选择性的获取邮件属性，文本，及其中的一部分。IMAP4rev1中的邮件通过使用数字访问。这些数字或者是邮件序列号，或者是唯一标识符。
IMAP4rev1支持单个服务器。访问注册信息以支持多个IMAP4rev1服务器的机制在RFC2244中讨论。
IMAP4rev1不详述邮递邮件的方法；该职责由如RFC2821的某种邮件传输协议完成。 目录
１. 如何阅读本文 5 １.1. 本文的结构 5 1.2 本文用到的约定语 5
1.3. 实现者需要特别注意的地方 6 2. 协议概述 6 2.1. 链路层 6 2.2. 命令及响应 6
2.2.1. 客户端的协议发送和服务器端的协议接收 7 2.2.2. 服务器端的协议发送和客户端的协议接收 7 2.3. 邮件属性 8 2.3.1. 邮件号 8
2.3.1.1. 唯一标识符（UID）的邮件属性 8 2.3.1.2. 邮件序列号的邮件属性 9 2.3.2. 标记的邮件属性 9
2.3.3. 实际日期的邮件属性 11
2.3.4. [RFC-2822]大小的邮件属性 11 2.3.5. 信封结构的邮件属性 11 2.3.6. 主体结构的邮件属性 11 2.4. 邮件文本 11 3. 状态和流程图 11 3.1. 未认证状态 12 3.2. 认证状态 12 3.3. 选中状态 12 3.4. 注销状态 12 4. 数据格式 14 4.1. 原语 14 4.2. 数字 14 4.3. 字符串 14
4.3.1. 字节及二进制字符串 14
4.4. 圆括符列表 15 4.5. NIL 15
5. 操作的考虑 15 5.1. 邮箱命名 15
5.1.1. 邮箱层级命名 16
5.1.2. 邮箱命名空间的约定 16 5.1.3. 邮箱的国际命名约定 16 5.2. 邮箱大小和邮件状态更新 17 5.3. 没有命令在行进中的响应 18 5.4. 自动注销计时器 18 5.5. 多个命令在行进中 18 6. 客户端命令 19
6.1. 客户端命令－任意状态 19 6.1.1. CAPABILITY命令 20 6.1.2. NOOP命令 20 6.1.3. LOGOUT命令 21
6.2. 客户端命令－未认证状态 21 6.2.1. STARTTLS命令 22 6.2.2. AUTHENTICATE命令 23 6.2.3. LOGIN 命令 25
6.3. 客户端命令－认证状态 25 6.3.1. SEELCT命令 25 6.3.2. EXAMINE命令 27 6.3.3. CREATE命令 28 6.3.4. DELETE命令 29 6.3.5. RENAME命令 30 6.3.6. SUBSCRIBE命令 31 6.3.7. UNSUBSCRIBE命令 32 6.3.8. LIST命令 32 6.3.9. LSUB命令 34 6.3.10. STATUS命令 35 6.3.11. APPEND命令 36
6.4. 客户端命令－被选中状态 37 6.4.1. CHECK命令 38 6.4.2. CLOSE命令 38 6.4.3. EXPUNGE命令 38 6.4.4. SEARCH命令 39 6.4.5. FETCH命令 43 6.4.6. STORE命令 47 6.4.7. COPY命令 48 6.4.8. UID命令 48
6.5. 客户端命令－试验/扩展 50 6.5.1. X命令 50 7.服务器响应 50
7.1. 服务器响应－状态响应 51 7.1.1. OK 响应 53 7.1.2. NO响应 53 7.1.4. PREAUTH响应 54 7.1.5. BYE响应 54
7.2. 服务器响应－服务器和邮箱状态 54 7.2.1. CAPABILITY响应 54 7.2.2. LIST响应 55 7.2.3. LSUB响应 56 7.2.4. STATUS响应 56 7.2.5. SEARCH响应 56 7.2.6. FLAGS响应 57
7.3. 服务器响应－邮箱大小 57 7.3.1. EXISTS响应 57 7.3.2. RECENT响应 57
7.4. 服务器响应－邮件状态 58 7.4.1. EXPUNGE响应 58 7.4.2. FETCH响应 59
7.5. 服务器响应－命令连续请求 63 8. IMAP4rev1连接例子 64 9. 正式语法 65 10. 作者的说明 79 11. 安全考虑 79
11.1. STARTTLS安全考虑 79 11.2. 其它安全考虑 80 12. IANA考虑 81 附录 81
A. 标准参考 81 C.关键词索引 92 作者地址 97 感谢 98
IMAP４rev１协议规范
１. 如何阅读本文
１.1. 本文的结构
本文是基于一个IMAP4rev1客户端或者服务器的视点写的。第２章超出了本协议的范畴，对某些人而言，试图理解本协议的操作是不现实的。第３到第５章提供了IMAP4rev1操作的总体脉络和概念。
第６、７、９章分别描述了IMAP的命令、响应和语法。三者之间的联系如此紧密，甚至于我们几乎不可能独立地理解它们。特别的，不要试图单单从命令块推论命令语法，相反的，要参考正式语法。
1.2 本文用到的约定语
约定语用来描述基本的原理或者过程。本节将列出本文档的约定语。 例如，“C:”和“S:”分别表示由客户端和服务器发出的信息行。 “MUST”、“MUST NOT”、“REQUIRE”、“SHALL”、“SHALL NOT”、“SHOULD”、“SHOULD NOT”、“MAY”，及“OPTIONAL”这些基本的词，在本文中解释为[关键词]。
“can”（或者“may”）用来指出某种可能情况和条件，而不是该协议的任意一种功能。
“User”用来表示一个自然人，而“client”则用来表示用户运行的软件。 “Connection”表示从网络连接初始建立直至其结束的过程中，客户端、服务器间的整个、一连串的交互。
“Session”表示从选中一个邮箱（SELECT或者EXAMINE命令）直至选中结束（CLOSE命令，或者连接终止，另一个邮箱的SELECT或者EXAMINE命令）的过程中，客户端、服务器间的一连串交互。 没有特别说明时，字符串当作7位的US－ASCII处理。其它的字符集用“CHARSET”标识，与[MIME－IMT]中描述的、[CHARSET]中定义的是一样的。除了定义字符集，CHARSETs还有其它重要的语义，更多细节参考相关文档。
IMAP中有一些协议约定语。它们涉及到协议说明的某些方面，严格讲，这些方面不属于IMAP协议的部分，但是它们反映了被普遍认可的实践经 验。协议的实现体需要考虑这些约定语，并避免冲突，不管实现这些约定语与否。例如，“&”不应该用作等级定义符――因为这与邮箱的网络命名约定冲 突，而邮箱名称中“&”的其它使用则无碍。
1.3. 实现者需要特别注意的地方
强烈建议IMAP协议的实现者阅读与本文相关的[IMAP实现]的推荐文章，以利于理解这个协议的难点，及如何最好地创建一个有效沟通的产品。
IMAP4rev1设计成从[IMAP2]和未发布的IMAP2bis协议向上兼容。IMAP4rev1很好地兼容了RFC1730中描述的 IMAP4协议；RFC1730中增加的、有异常的、被证实有问题的那些功能后来被删减了。在IMAP4rev1的发展历程中，早期的协议中某些方面遭到 了废弃。[IMAP－OBSOLETE]中，描述了IMAP4rev1实现者使用早期的协议实现时，可能遇到的、废弃了的命令、响应及数据格式。 [IMAP-COMPAT]讨论了与IMAP2bis的其它兼容问题，与早期的协议的最一般性的差异。[IMAP－HISTORICAL]全面讨论了与[IMAP2]因罕见（被擅自主张者去除了）差异而产生的兼容问题；本文是历史关注的源头。
IMAP起初是为旧的[RFC-822]标准发展的，因此一些项目在它们的名称中把“RFC822”包含进来。除了RFC822.SIZE,还 有更先进的取代；例如， RFC822.HEADER在新版中是BODY.PEEK[HEADER]。在所有案例中，“RFC822”应该解释为升级的 [RFC-822]标准的参考。
2. 协议概述
2.1. 链路层
IMAP4rev1协议假定了类似TCP提供的可靠数据流。使用TCP时，IMAP4rev1服务器监听143端口。
2.2. 命令及响应
一次IMAP4rev1连接的组成有：一次客户端、服务器的网络连接的建立，服务器的初始欢迎，以及客户端、服务器的交互。这些客户端、服务器的交互由客户端命令、服务器数据和服务器的完成结果响应组成。
传送于客户端和服务器间的所有交互都是以行的形式，即，以一个CRLF为结束标志的字符串。一个IMAP4rev1客户端或者服务器的协议接收端要么是按行读取，要么是以一个已知的数值n，每次读取n个字节的串。
2.2.1. 客户端的协议发送和服务器端的协议接收
客户端命令引发操作。每个客户端命令以一个标识作为前缀（典型的有字母、数字构成的短字符串，如：A0001，A0002，等等）――它称为“标签”。客户端为每个命令生成不同的“标签”。
客户端必须严格遵守本说明中的语法大纲。发送缺损的命令，或者多余的空格、变量都属于语法错误。
客户端没有描述一个完整的命令，有两种情形。一种是，一个命令参数被以一个字节数引用（参看Data Formats下的String的原义描 述）；另一种是，命令参数要求服务器的反馈（参看AUTHENTICATE命令）。这再者中的任何一种情形下，服务器发送命令以不停地请求响应――如果为 字节串（如果适当）和剩余命令准备就绪。响应用“+”作为前缀。
注意：而如果服务器发现命令的一个错误，它就发送一个带有匹配于命令（如下所描述的）的标签的BAD完整响应，以拒绝该命令，避免客户端再发送更多的命令。
服务器对一些其它的命令（如果多个命令相继发生）、或者非标签化的数据，请求发送完整的响应，这也是可能的。在两者中的任何一种情形下，连续的 请求命令仍然是悬而不决的；客户端对响应采取相应的动作，并读取服务器的其它响应。所有情形下，客户端必须在初始化一个新的命令前发送一个完整命令（包括 接收所有连续请求响应命令）
IMAP4rev1服务器端的协议接收端，从客户端读取命令行，解析该命令行及其参数，并传送服务器数据及一个服务器命令完成结果的响应。
2.2.2. 服务器端的协议发送和客户端的协议接收
那些没有标识命令完成的、被服务器传送至客户端的数据和状态响应，用“*”作为前缀，并称为非标签化的响应。