logo资料库

IMAP_RFC3501 中文版.pdf

发布时间：2022-06-13 发布人：admin 分类：说明书 资料大小：0.79M 资料格式：pdf 举报 版权申诉
第1页 / 共66页
第2页 / 共66页
第3页 / 共66页
第4页 / 共66页
第5页 / 共66页
第6页 / 共66页
第7页 / 共66页
第8页 / 共66页
资料共66页，剩余部分请下载后查看
    IMAP 协议 RFC3501 中文文档 因特网邮件访问协议，版本 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. 服务器端的协议发送和客户端的协议接收 那些没有标识命令完成的、被服务器传送至客户端的数据和状态响应，用―*‖作为前缀，并 称为非标签化的响应。 服务器数据可能被作为客户端命令的结果发送，或者可能被服务器单方面发送。源于特定命 令的服务器数据，和单方面发送的服务器数据，二者之间没有语法上的差异。 服务器完成结果响应表示操作的成功或者失败。它具有与开始操作的客户端命令一样的标 签。然而，如果有多于一个的命令在行进中，服务器完成响应的 标签将标识该响应适用的 命令。可能的服务器完成响应有三种：OK（表示成功），NO（表示失败），或者 BAD（表 示协议错误，如：未知命令，或者命令语法 错误）。 服务器应当严格遵照本文档的语法大纲。任何带有协议语法错误，包括（但不限于）少了、 多了空格或者参数，都应该被拒绝，并且服务器应当给客户端一个 BAD 服务器完成响应。 IMAP4rev1 客户端的协议接收端从服务器读取一条响应行。它可以根据响应的第一个标 记――可以是标签，一个―*‖，或者一个―+‖，做出动作作为响应。 客户端必须一直准备着接收任何服务器响应，包括非请求的服务器数据。服务器数据应当存 储下来，以便客户端可以参照它存储的副本，而不是发送命令至服务器去请求数据。某些服 务器数据则必须存储下来。 这个主题在服务器响应一节中有更细节的讨论。 2.3. 邮件属性 除了邮件文本，每个邮件都有一些与其相关的属性。这些属性可以被单独收回，或者与其它 属性、或者邮件文本组合。
    2.3.1. 邮件号 IMAP4rev1 的邮件通过两个数值中的一个访问：唯一标识符，或者邮件序列号。 2.3.1.1. 唯一标识符（UID）的邮件属性 分配给每一个邮件的 32 位值，和唯一标识符的值（见下）形成一个 64 位的值，这个值永 远不能指向这个邮箱中的其它任何邮件，或者它后面的同名邮 箱。分配时，邮箱中的唯一 标识符严格地按升序排列；每个邮件添加至邮箱时，它将被派予一个比它先加进来的邮件的 唯一标识符更大的唯一标识符。与邮件序列号 不同，唯一标识符可以是不连续的。 在其会话存活期，一个邮件的唯一标识符不能改变，也不应该在不同的会话间改变。唯一标 识符在不同会话间的改变必须使用下面谈到的唯一标识符校验 机制审查。永久唯一标识符 要求客户端刷新其状态，以区别于与服务器的前面一个会话（例如：无连接，或者离线访问 的客户端）；这将在[IMAP-DISC] 进一步地讨论。 与每个邮箱关联，有两个值维护着唯一标识符的指针：后续唯一标识符的值，和当前唯一标 识符的值。 后续唯一标识符的值，是以后分配给这个邮箱中的新邮件的预留值。若非当前唯一标识符的 值也改变了（见下），后续唯一标识符的值必须具有以下两个 特点。第一，若非新的邮件 被加进邮箱，后续唯一标识符的值不能改变；第二，一旦新的邮件被加进邮箱，后续唯一标 识符必须改变，即使这些新的邮件随后被删除 了。 注意：后续唯一标识符，是被用来提供这样一种手段，即客户端判断从上一次确认它的值后， 是否有新的邮件被发送到邮箱。并不一定任何邮件都有唯一标识符。客户端只能推测，一旦 它获得后续唯一标识符，此后到达的邮件的唯一标识符大于等于这个值。 当邮箱被选中时，唯一标识符的值将通过一个非标签化的 OK 响应的唯一标识符校验响应码 发送。如果早先会话的唯一标识符不能永存于这个会话中，则唯一标识符的值必须大于早先 会话的唯一标识符。 注意：理想情况下，唯一标识符可以一直永存。尽管本文档承认，不能永存的情况在特定服 务器环境下是不可避免的，但我们极力鼓励避免这个问题的邮件存储实现技术。例如： 1）邮箱中的唯一标识符必须永远严格按升序排序。如果物理邮件存储被非 IMAP 代理刷新， 则邮箱中的唯一标识符应当刷新，因为这种刷新（非 IMAP 代理刷新）导致旧的唯一标识符 不再严格按升序排序了。 2）如果邮件存储没有唯一标识符的存储机制，那么它必须在每个会话刷新唯一标识符，并 且每个会话必须具有一个唯一标识符校验值。 3）如果一个邮箱被删除，并且之后一个新的同名邮箱被创建，服务器必须保持区别于之前 邮箱的唯一标识符的记录，或者分配给新邮箱一个新的唯一标 识符校验码。在这里，一个 好的唯一标识符校验码，是代表邮箱创建日期或者时间的 32 位数。使用一个常数，如 1, 是没问题的，但这只是在这样前提下――确保 唯一标识符永远不再被使用，即使一个邮箱 被删除（或者重命名），及一个新的同名邮箱不久被创建。 4）邮箱名、唯一标识符校验码、唯一标识符，三者的联合必须永远指向服务器上的一个固 定邮件。特别的，实际日期、[RFC-2822]大小、邮 戳、主体结构及邮件文本（RFC822、 RFC822.HEADER、RFC822.TEXT、及所有 BODY[…]获取数据项）必须永不改变。这并 不包 括邮件号、及可以通过一个 STORE 命令设置的属性（例如，FLAGS）。 2.3.1.2. 邮件序列号的邮件属性 邮箱中，从 1 到邮件总数的一个相对位置。这个位置必须是按升序排序了的唯一标识符。 每当新的邮件被加进来，它就被分配一个比它加进来之前该邮箱中的邮件总数大 1 的邮件 序列号。
    在会话存活期，邮件序列号可以重新分配。例如，当一个邮件被从邮箱中永久删除，其后的 所有邮件的邮件序列号就减小。邮箱的邮件总数也减小。类似的，一个新加进来的邮件将被 分配一个邮件序列号――之前被删除了的其它邮件所持有的邮件序列号。 邮件序列号，不仅可以用于通过邮箱的相对位置访问邮件，还可以用于数学运算。例如，如 果接收到一个非标签化的―11 EXISTS‖，且之前接 收了一个非标签化的―8 EXISTS‖，那么， 已经有邮件序列号为 9、10、11 的三个新邮件到达。另外一个例子，如果一个有 523 个邮 件的邮箱中的邮 件 287 的唯一标识符是 12345，那么，实际上，该邮箱中，有 286 条邮件 的唯一标识符小于 12345,有 236 个邮件的唯一标识符大于 12345. 2.3.2. 标记的邮件属性 与邮件相关联的一个 0 串或者已命名的符号串。向该串中新增时，设置一个标记，从该串 中删除时，清除该标志。IMAP4rev1 中有两种标记。两种标记的实例都可以是永久化的， 或者会话化的。 系统标记是指在本文档中预告确定的。所有的系统标记以―/‖开头。一些系统标记（/Deleted 和/Seen）在其它地方的描述中有特殊的语义。目前定义的系统标记有： /Seen 邮件已读 /Answered 邮件已回复 /Flagged 邮件标记为紧急或者特别注意。 /Deleted 邮件为删除状态。 /Draft 邮件未写完（标记为草稿状态）。 /Recent 邮件是新到达邮箱的。这个会话是关于这个邮件的第一个会话；如果这个会话是可读写的， 后续会话将看不见这个邮件的/Recent 设置符。客户端不能修改该标记。 一个会话，如果不能判断它是不是关于一个邮件的第一个会话，那么就应当考虑这个邮件是 新的。 如果多个连接同时选中了同一个邮箱，哪个连接会看到带有/Recent 设置符的、新到达的邮 件，哪个连接会看到没有/Recent 设置符的邮件，这还没有定义。 关键词是由服务器实现体定义的。关键词并不以―/‖开头。服务器可以允许客户端定义新邮箱 中的关键词（更多信息参看 PERMANENTFLAGS 响应码的描述）。 一个标记可以是永久的，或者会话化的（标记的生命周期为某个会话）。对于永久标记，客 户端可以增加，或者从邮件标记集中永久删除；即，当前和后续会话将可以看见永久标记集 中的任何变化。对会话标记的改变只在其会话内是可视的。 注意：/Recent 系统标记是会话标记的一个特例。/Recent 不能在一个 STORE 或者 APPENT 命令中作为一个变量，也不能被改变。 2.3.3. 实际日期的邮件属性 服务器上邮件的实际日期和时间。它是反映何时接收到邮件的日期和时间，而不是 [RFC-2822]头部中的日期和时间。按照 SMTP 的定义，通 过 SMTP 发送的邮件，其实际 日期和时间反映的是这个邮件的最后发送日期和时间。通过 IMAP4rev1 的 APPEND 命令
    发送的邮件，其实际日期和时间 反映的是 APPEND 命令描述中所指定的。其它情形下， 实际日期和时间遵照实现体的定义。 2.3.4. [RFC-2822]大小的邮件属性 同于[RFC-2822]版中的表述，即邮件中的字节串的长度。 2.3.5. 信封结构的邮件属性 [RFC-2822]邮件头部的一个语法表示。注意，IMAP 信封结构与 SMTP 的不同。 2.3.6. 主体结构的邮件属性 [MIME-IMB]邮件主体结构信息的解析表示。 2.4. 邮件文本 IMAP4rev1 允许获取邮件的全部[RFC-2822]文本，也允许获取它的一部分。特别的，获取 [RFC-2822]邮件头部、[RFC-2822]邮件主体、一个[MIME-IMB]主体部分、或者一个 [MIME-IMB]头部，也是可以的。 3. 状态和流程图 一旦客户端和服务器间的连接建立完成，一个 IMAP4rev1 连接就会处于 4 种状态中的某一 种。初始状态在服务器的欢迎中标识。大多数命令只在 特定的状态中才是正确的。当连接 处于不适当的状态时，客户端尝试一个不适当的命令引发协议错误，服务器将以一个 BAD 或者 NO（取决于服务器的实现体）命 令完成结果响应。 3.1. 未认证状态 在未认证状态下，大多数命令在得到许可前，客户端必须提供认证证书。若非连接已经是预 认证了的，一个连接开始时，就进入了未认证状态。 3.2. 认证状态 在认证状态下，客户端是认证了的，它必须先于影响邮件的命令被许可前，选择一个邮箱以 访问。当一个预认证连接开始，被认可的认证证书已经提供，选择一个邮箱发生错误后，或 者一个成功的 CLOSE 命令后，就进入了认证状态。 3.3. 选中状态 在一个选中状态，一个邮箱被选中以访问。当一个邮箱被成功选中时，就进入了这个状态。 3.4. 注销状态 在注销状态下，连接正在被终止。一个客户端请求（通过 LOGOUT 命令），或者客户端、 服务器的单方面动作，都会导致进入这个状态。 如果客户端请求注销状态，服务器必须在关闭连接前发送 LOGOUT 命令的一个非标签化 BYE 响应和一个标签化 OK 响应；客户端在关闭连接前，必须读取这个 LOGOUT 命令的标 签化 OK 响应至。 在没有发送一个包含原因的、非标签化 BYE 响应的情况下，一个服务器不能单方面关闭连 接。一个客户端不应单方面关闭连接，而应当发出一个 LOGOUT 命令。如果服务器发现客 户端单方面关闭了连接，服务器可以忽略这个非标签化 BYE 响应，并简单地关闭它的连接。
    分享到：
    赞 收藏

    相关推荐

    资料库

    课程资源

    共收录17145份资料，累计13个分类，关注成员有19位，主要包括：PHP,网络管理,网页制作,Java,.Net,数据库,3G/移动开发,C/C++,游戏开发,嵌入式,讲义,软件测试,专业指导

    热门标签

    PHP 网络管理 网页制作 Java .Net 数据库 3G/移动开发 C/C++ 游戏开发 嵌入式 讲义 软件测试 专业指导

    最新资料