7. 服务器响应 (Server Responses)

与列表中的某个名称匹配的那些头部字段; 类似地, HEADER.FIELDS.NOT 返回的子集只包含 field-name 不匹配的头部字段. 字段匹配不区分大小写, 但除此之外必须精确匹配. 取子集不会排除头部和正文之间的 [RFC-2822] 分隔空行; 除非消息没有正文也没有空行, 否则该空行会包含在所有头部获取结果中.

MIME 部分说明符指此部分的 [MIME-IMB] 头部.

TEXT 部分说明符指消息的文本正文, 省略 [RFC-2822] 头部.

下面是一个复杂消息及其若干部分说明符的示例:

   HEADER     (消息的 [RFC-2822] 头部)
   TEXT       (消息的 [RFC-2822] 文本正文) MULTIPART/MIXED
        TEXT/PLAIN
        APPLICATION/OCTET-STREAM
        MESSAGE/RFC822
HEADER   (消息的 [RFC-2822] 头部)
TEXT     (消息的 [RFC-2822] 文本正文) MULTIPART/MIXED
1        TEXT/PLAIN
2        APPLICATION/OCTET-STREAM
        MULTIPART/MIXED
1        IMAGE/GIF
1.MIME   (IMAGE/GIF 的 [MIME-IMB] 头部)
2        MESSAGE/RFC822
2.HEADER (消息的 [RFC-2822] 头部)
2.TEXT   (消息的 [RFC-2822] 文本正文) MULTIPART/MIXED
2.1      TEXT/PLAIN
2.2      MULTIPART/ALTERNATIVE
2.2.1    TEXT/PLAIN
2.2.2    TEXT/RICHTEXT

可以获取指定文本的子字符串. 这通过在部分说明符后附加一个左尖括号 ("<"), 所需第一个八位字节的八位字节位置, 一个句点, 所需的最大八位字节数, 以及一个右尖括号 (">") 来完成. 如果起始八位字节超过文本末尾, 则返回空字符串.

任何试图读取超过文本末尾的部分获取都会按适当方式截断. 即使发生了这种截断, 从八位字节 0 开始的部分获取也会作为部分获取返回.

注意: 这意味着对于一个 1500 八位字节的消息, BODY[]<0.2048> 将返回带有大小为 1500 的 literal 的 BODY[]<0>, 而不是 BODY[].

注意: HEADER.FIELDS 或 HEADER.FIELDS.NOT 部分说明符的子字符串获取是在对头部取子集之后计算的.

\Seen 标志会被隐式设置; 如果这导致标志发生改变, 则应该将这些标志作为 FETCH 响应的一部分包含在内.

BODY.PEEK[<section>]<<partial>> : BODY[<section>] 的另一种形式, 不会隐式设置 \Seen 标志.

BODYSTRUCTURE : 消息的 [MIME-IMB] 正文结构. 这是服务器通过解析 [RFC-2822] 头部和 [MIME-IMB] 头部中的 [MIME-IMB] 头部字段计算出来的.

ENVELOPE : 消息的信封结构. 这是服务器通过将 [RFC-2822] 头部解析为各组成部分, 并按需为各种字段提供默认值而计算出来的.

FLAGS : 为此消息设置的标志.

INTERNALDATE : 消息的内部日期.

RFC822 : 在功能上等同于 BODY[], 区别在于生成的未加标签 FETCH 数据的语法不同, 返回的是 RFC822.

RFC822.HEADER : 在功能上等同于 BODY.PEEK[HEADER], 区别在于生成的未加标签 FETCH 数据的语法不同, 返回的是 RFC822.HEADER.

RFC822.SIZE : 消息的 [RFC-2822] 大小.

RFC822.TEXT : 在功能上等同于 BODY[TEXT], 区别在于生成的未加标签 FETCH 数据的语法不同, 返回的是 RFC822.TEXT.

UID : 消息的唯一标识符.

Example: C: A654 FETCH 2:4 (FLAGS BODY[HEADER.FIELDS (DATE FROM)]) S: * 2 FETCH .... S: * 3 FETCH .... S: * 4 FETCH .... S: A654 OK FETCH completed

6.4.6. STORE 命令 (STORE Command)

Arguments: sequence set message data item name value for message data item

Responses: 未加标签响应: FETCH

Result: OK - store completed NO - store 错误: 无法存储该数据 BAD - 命令未知或参数无效

STORE 命令会改变邮箱中与消息关联的数据. 通常, STORE 将通过未加标签 FETCH 响应返回该数据的更新值. 数据项名称中的 ".SILENT" 后缀会阻止未加标签 FETCH, 并且服务器应该假定客户端已经自行确定更新后的值, 或者并不关心更新后的值.

注意: 无论是否使用了 ".SILENT" 后缀, 如果观察到来自外部来源的消息标志变更, 服务器应该发送未加标签 FETCH 响应. 其意图是使标志状态在不存在竞争条件的情况下是确定的.

当前定义的可存储数据项如下:

FLAGS <flag list> : 用参数替换消息的标志 (\Recent 除外). 这些标志的新值会像执行了对这些标志的 FETCH 一样被返回.

FLAGS.SILENT <flag list> : 等同于 FLAGS, 但不返回新值.

+FLAGS <flag list> : 将参数添加到消息的标志中. 这些标志的新值会像执行了对这些标志的 FETCH 一样被返回.

+FLAGS.SILENT <flag list> : 等同于 +FLAGS, 但不返回新值.

-FLAGS <flag list> : 从消息的标志中移除参数. 这些标志的新值会像执行了对这些标志的 FETCH 一样被返回.

-FLAGS.SILENT <flag list> : 等同于 -FLAGS, 但不返回新值.

Example: C: A003 STORE 2:4 +FLAGS (\Deleted) S: * 2 FETCH (FLAGS (\Deleted \Seen)) S: * 3 FETCH (FLAGS (\Deleted)) S: * 4 FETCH (FLAGS (\Deleted \Flagged \Seen)) S: A003 OK STORE completed

6.4.7. COPY 命令 (COPY Command)

Arguments: sequence set mailbox name

Responses: 此命令无特定响应

Result: OK - copy completed NO - copy 错误: 无法将这些消息复制到该 name BAD - 命令未知或参数无效

COPY 命令将指定消息复制到指定目标邮箱的末尾. 在副本中, 消息的标志和内部日期应该保留, 并且应该设置 Recent 标志.

如果目标邮箱不存在, 服务器应该返回错误. 它不应该自动创建该邮箱. 除非确定无法创建目标邮箱, 否则服务器必须发送 response code "[TRYCREATE]" 作为带标签 NO 响应文本的前缀. 这会向客户端提示: 它可以尝试 CREATE 命令, 并在 CREATE 成功后重试 COPY.

如果 COPY 命令因任何原因未成功, 服务器实现必须将目标邮箱恢复到 COPY 尝试之前的状态.

Example: C: A003 COPY 2:4 MEETING S: A003 OK COPY completed

6.4.8. UID 命令 (UID Command)

Arguments: command name command arguments

Responses: 未加标签响应: FETCH, SEARCH

Result: OK - UID command completed NO - UID 命令错误 BAD - 命令未知或参数无效

UID 命令有两种形式. 第一种形式以 COPY, FETCH, 或 STORE 命令及其对应参数作为参数. 但是, sequence set 参数中的数字是唯一标识符, 而不是消息序列号 (message sequence number). 允许使用 sequence set 范围, 但不能保证唯一标识符是连续的.

不存在的唯一标识符会被忽略, 且不会生成任何错误消息. 因此, UID FETCH 命令可能在没有任何数据的情况下返回 OK, 或者 UID COPY 或 UID STORE 可能在未执行任何操作的情况下返回 OK.

在第二种形式中, UID 命令采用 SEARCH 命令及 SEARCH 命令参数. 参数的解释方式与 SEARCH 相同; 但是, 对于 UID SEARCH 命令, SEARCH 响应中返回的数字是唯一标识符, 而不是消息序列号. 例如, 命令 UID SEARCH 1:100 UID 443:557 返回与两个 sequence set 的交集对应的唯一标识符, 即消息序列号范围 1:100 与 UID 范围 443:557 的交集.

注意: 在上面的示例中, 出现了 UID 范围 443:557. 关于不存在的唯一标识符会被忽略且不会产生任何错误消息的相同说明在这里同样适用. 因此, 即使 UID 443 和 557 都不存在, 此范围也是有效的, 并且会包含现有的 UID 495.

还要注意, UID 范围 559:* 始终包含邮箱中最后一条消息的 UID, 即使 559 高于任何已分配的 UID 值也是如此. 这是因为范围的内容独立于范围端点的顺序. 因此, 除非邮箱为空, 否则任何以 * 作为其中一个端点的 UID 范围都表示至少一条消息 (具有最高编号 UID 的消息).

在未加标签 FETCH 响应中, "*" 后面的数字始终是消息序列号, 而不是唯一标识符, 即使该响应是 UID 命令响应也是如此. 但是, 无论是否在 FETCH 中将 UID 指定为消息数据项, 服务器实现都必须将 UID 消息数据项隐式包含为由 UID 命令导致的任何 FETCH 响应的一部分.

注意: 将 UID 消息数据项包含为 FETCH 响应一部分的规则主要适用于 UID FETCH 和 UID STORE 命令, 包括未将 UID 作为消息数据项包含的 UID FETCH 命令. 虽然其他 UID 命令不太可能导致未加标签 FETCH, 但此规则同样适用于这些命令.

Example: C: A999 UID FETCH 4827313:4828442 FLAGS S: * 23 FETCH (FLAGS (\Seen) UID 4827313) S: * 24 FETCH (FLAGS (\Seen) UID 4827943) S: * 25 FETCH (FLAGS (\Seen) UID 4828442) S: A999 OK UID FETCH completed

6.5. 客户端命令 - 实验/扩展 (Client Commands - Experimental/Expansion)

6.5.1. X`<atom>` 命令 (X`<atom>` Command)

Arguments: 由实现定义

Responses: 由实现定义

Result: OK - command completed NO - 失败 BAD - 命令未知或参数无效

任何以 X 为前缀的命令都是实验命令. 不属于本规范, 本规范的标准或标准跟踪修订版, 或 IESG 批准的实验协议的命令, 必须使用 X 前缀.

实验命令发出的任何新增未加标签响应也必须以 X 为前缀. 除非客户端通过发出关联的实验命令请求了此类响应, 否则服务器实现不得发送任何此类未加标签响应.

Example: C: a441 CAPABILITY S: * CAPABILITY IMAP4rev1 XPIG-LATIN S: a441 OK CAPABILITY completed C: A442 XPIG-LATIN S: * XPIG-LATIN ow-nay eaking-spay ig-pay atin-lay S: A442 OK XPIG-LATIN ompleted-cay

```
 服务器响应 (Server Responses)
```

服务器响应有三种形式: 状态响应 (status responses), 服务器数据 (server data), 以及命令继续请求 (command continuation request). 在下面响应描述中以 "Contents:" 标识的服务器响应所包含的信息, 是按功能而非按语法描述的. 服务器响应的精确语法在正式语法 (Formal Syntax) 章节中描述.

客户端必须随时准备接受任何响应.

状态响应可以是带标签 (tagged) 或未加标签 (untagged) 的. 带标签状态响应表示客户端命令的完成结果 (OK, NO, 或 BAD 状态), 并带有与该命令匹配的 tag.

某些状态响应以及所有服务器数据都是未加标签的. 未加标签响应由 token "*" 而不是 tag 指示. 未加标签状态响应表示服务器问候语, 或者不表示命令完成的服务器状态 (例如, 即将发生的系统关闭警报). 出于历史原因, 未加标签服务器数据响应也称为 "unsolicited data", 但严格来说, 只有单方面服务器数据才真正是 "unsolicited".

某些服务器数据在收到时必须由客户端记录; 这会在该数据的描述中注明. 这些数据传递关键信息, 会影响后续所有命令和响应的解释 (例如, 反映消息创建或销毁的更新).

其他服务器数据应该被记录以供以后参考; 如果客户端不需要记录该数据, 或记录该数据没有明显目的 (例如, 没有 SEARCH 命令正在进行时收到 SEARCH 响应), 则该数据应该被忽略.

当 IMAP 连接处于 selected 状态时, 会出现单方面未加标签服务器数据的一个示例. 在 selected 状态下, 服务器会在命令执行过程中检查邮箱中是否有新消息. 通常, 这是每个命令执行过程的一部分; 因此, NOOP 命令足以检查新消息. 如果有新

7.1. 服务器响应 - 状态响应 (Server Responses - Status Responses)

状态响应包括 OK, NO, BAD, PREAUTH 和 BYE. OK, NO 和 BAD 可以是带标签或未加标签的. PREAUTH 和 BYE 始终是未加标签的.

状态响应可以包含一个可选的 "response code". response code 由方括号内的数据组成, 形式为 atom, 后面可以跟一个空格和参数. 除 OK/NO/BAD 条件之外, response code 还为客户端软件包含附加信息或状态码; 当客户端可以基于附加信息采取特定操作时, 会定义 response code.

RFC 3501 IMAPv4 March 2003

当前定义的 response codes 如下:

ALERT : 人类可读文本包含一个特殊警报, 必须以能够引起用户注意的方式呈现给用户.

BADCHARSET : 可选地后跟一个用括号括起的 charsets 列表. SEARCH 失败, 因为给定 charset 不受此实现支持. 如果给出了可选 charsets 列表, 则该列表列出此实现支持的 charsets.

CAPABILITY : 后跟一个 capabilities 列表. 这可以出现在初始 OK 或 PREAUTH 响应中, 用于传输初始 capabilities 列表. 如果客户端识别此响应, 就无需发送单独的 CAPABILITY 命令.

PARSE : 人类可读文本表示解析 mailbox 中某条消息的 [RFC-2822] 头部或 [MIME-IMB] 头部时发生错误.

PERMANENTFLAGS : 后跟一个用括号括起的 flags 列表, 指示客户端可以永久更改哪些已知 flags. 出现在 FLAGS 未加标签响应中但不在 PERMANENTFLAGS 列表中的任何 flags, 都不能被永久设置. 如果客户端尝试 STORE 一个不在 PERMANENTFLAGS 列表中的 flag, 服务器将忽略该更改, 或者仅在当前会话的剩余期间存储该状态更改. PERMANENTFLAGS 列表还可以包含特殊 flag *, 它表示可以通过尝试将这些 flags 存入 mailbox 来创建新的 keywords.

RFC 3501 IMAPv4 March 2003

READ-ONLY : mailbox 以只读方式被选中, 或者其在 selected 状态下的访问权限已从读写变为只读.

READ-WRITE : mailbox 以读写方式被选中, 或者其在 selected 状态下的访问权限已从只读变为读写.

TRYCREATE : APPEND 或 COPY 尝试失败, 因为目标 mailbox 不存在 (而不是其他原因). 这是给客户端的提示: 如果先由 CREATE 命令创建 mailbox, 该操作就可以成功.

UIDNEXT : 后跟一个十进制数字, 指示下一个唯一标识符值. 更多信息请参见第 2.3.1.1 节.

UIDVALIDITY : 后跟一个十进制数字, 指示唯一标识符有效性值. 更多信息请参见第 2.3.1.1 节.

UNSEEN : 后跟一个十进制数字, 指示第一条未设置 \Seen flag 的消息编号.

由特定客户端或服务器实现定义的其他 response codes, 在加入本协议的修订版之前应该以 "X" 为前缀. 客户端实现应该忽略无法识别的 response codes.