Skip to main content

1. 如何阅读本文档 (How to Read This Document)

1.1 本文档的组织结构 (Organization of This Document)​

本文档从 IMAP4rev2 客户端或服务器实现者的角度编写. 除了第2节中的协议概述之外，本文档并非为试图理解协议操作的人员优化. 第3、4和5节中的材料提供了 IMAP4rev2 运行的一般上下文和定义.

第6、7和9节分别描述了 IMAP 命令 (Commands)、响应 (Responses) 和语法 (Syntax). 这些部分之间的关系使得几乎不可能单独理解其中任何一个. 特别是，不要试图仅从命令章节推断命令语法，而应参考"正式语法" (Formal Syntax) (第9节).

1.2 本文档使用的约定 (Conventions Used in This Document)​

"约定" (Conventions) 是基本原则或程序. 本节将注明文档约定.

在示例中，"C:" 和 "S:" 分别表示由客户端 (Client) 和服务器 (Server) 发送的行. 请注意，每行都包含终止符 CRLF.

本文档中的关键词 "MUST"、"MUST NOT"、"REQUIRED"、"SHALL"、"SHALL NOT"、"SHOULD"、"SHOULD NOT"、"RECOMMENDED"、"NOT RECOMMENDED"、"MAY" 和 "OPTIONAL" 应按照 BCP 14 [RFC2119] [RFC8174] 中的描述进行解释，且仅当它们以全部大写形式出现时（如此处所示）才如此解释.

关键词翻译对照：

  • MUST = 必须
  • MUST NOT = 禁止
  • REQUIRED = 必需
  • SHALL = 应
  • SHALL NOT = 不应
  • SHOULD = 应该
  • SHOULD NOT = 不应该
  • RECOMMENDED = 推荐
  • NOT RECOMMENDED = 不推荐
  • MAY = 可以
  • OPTIONAL = 可选

单词 "can" (不是 "may") 用于指代可能的情况或场景，而不是协议的可选功能.

"User" (用户) 用于指代人类用户，而 "client" (客户端) 指代用户运行的软件.

"Connection" (连接) 指从网络连接的初始建立到终止为止的整个客户端/服务器交互序列.

"Session" (会话) 指从选择邮箱 (SELECT 或 EXAMINE 命令) 到选择结束 (SELECT 或 EXAMINE 另一个邮箱、CLOSE 命令、UNSELECT 命令或连接终止) 的客户端/服务器交互序列.

术语 "Implicit TLS" (隐式 TLS) 指的是在特定 TCP 端口上建立 TCP 连接时自动协商 TLS，该端口由服务器专门用于 TLS 连接. 术语 "Implicit TLS" 旨在与 IMAP 中使用的 STARTTLS 命令形成对比，后者由客户端和服务器在已建立的明文 TCP 连接上显式协商 TLS.

除非另有说明，字符采用 8 位 UTF-8 编码 (其中 7 位 US-ASCII 是其子集). 其他字符集使用 "CHARSET" 指示，如 [MIME-IMT] 中所述并在 [CHARSET] 中定义. CHARSET 除了定义字符集之外，还具有重要的附加语义，详细信息请参考这些文档.

IMAP 中有几个协议约定 (Protocol Conventions). 这些约定涉及规范中并非严格属于 IMAP 协议一部分但反映了普遍接受的实践的方面. 实现需要了解这些约定，并避免冲突，无论是否实现该约定. 例如，"&" 不得用作层次分隔符 (Hierarchy Delimiter)，因为它与邮箱国际命名约定 (Mailbox International Naming Convention) 冲突，邮箱名称中 "&" 的其他用法也会受到影响.

1.3 实现者特别注意事项 (Special Notes to Implementors)​

强烈建议 IMAP 协议的实现者结合本文档阅读 IMAP 实现建议文档 [IMAP-IMPLEMENTATION]，以帮助理解本协议的复杂性以及如何最好地构建可互操作的产品.

IMAP4rev2 设计为从 IMAP4rev1 [RFC3501]、IMAP2 [IMAP2] 和未发布的 IMAP2bis [IMAP2BIS] 协议向上兼容. IMAP4rev2 在很大程度上与 RFC 3501 中描述的 IMAP4rev1 协议以及 [RFC1730] 中描述的 IMAP4 协议兼容，例外情况是 [RFC1730] 和 [RFC3501] 中添加的某些功能被证明存在问题，随后被移除或被更好的替代方案取代. 在 IMAP4rev2 的演进过程中，早期协议中的某些方面已经过时. 附录 A 和 E 以及 [IMAP-OBSOLETE] 中描述了当 IMAP4rev2 实现与早期实现一起使用时可能遇到的过时命令、响应和数据格式. IMAP4rev2 支持 63 位消息部分和消息大小. IMAP4rev2 与 BINARY 和 LIST-EXTENDED IMAP 扩展的兼容性分别在附录 B 和 C 中描述.

与 IMAP2bis (早期协议最常见的变体) 的其他兼容性问题在 [IMAP-COMPAT] 中讨论. 关于与 [IMAP2] 的罕见 (并且被认为已灭绝) 变体的兼容性问题的完整讨论在 [IMAP-HISTORICAL] 中，该文档主要具有历史意义.

IMAP 最初是为较旧的 [RFC822] 标准开发的，因此，IMAP 中的 "RFC822.SIZE" 获取项包含了 [RFC822] 格式的含义. [RFC5322] 更新了消息格式，但保持了与 [RFC822] 的向后兼容性，因此 IMAP 中 "RFC822.SIZE" 获取项的行为没有改变. 为避免混淆，强烈建议实现者参考 [RFC5322] 而不是 [RFC822].

Last updated on