Skip to main content

7. Server Responses (服务器响应)

服务器响应有三种形式: 状态响应 (Status Responses), 服务器数据 (Server Data) 和命令继续请求 (Command Continuation Request). 服务器响应中包含的信息 (在下面的响应描述中由 "Contents:" 标识) 是按功能而非语法描述的. 服务器响应的精确语法在正式语法 (Formal Syntax) 章节中描述.

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

状态响应可以是标记的或未标记的. 标记的状态响应指示客户端命令的完成结果 (OK, NO 或 BAD 状态), 并且具有与命令匹配的标记.

某些状态响应和所有服务器数据都是未标记的. 未标记响应由标记 "*" 而不是标记指示. 未标记状态响应指示服务器问候, 或不指示命令完成的服务器状态 (例如, 即将发生的系统关闭警报). 出于历史原因, 未标记服务器数据响应也称为 "未请求数据 (Unsolicited Data)", 尽管严格来说, 只有单方面的服务器数据才是真正的 "未请求".

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

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

单方面未标记服务器数据的一个示例发生在 IMAP 连接处于已选择状态时. 在已选择状态下, 服务器作为命令执行的一部分检查邮箱中的新消息. 通常, 这是每个命令执行的一部分; 因此, NOOP 命令足以检查新消息. 如果找到新消息, 服务器会发送反映邮箱新大小的未标记 EXISTS 和 RECENT 响应. 提供对同一邮箱的多个同时访问的服务器实现也应该 (SHOULD) 发送适当的单方面未标记 FETCH 和 EXPUNGE 响应, 如果另一个代理更改了任何消息标志的状态或清除了任何消息.

命令继续请求响应使用标记 "+" 而不是标记. 这些响应由服务器发送以指示接受不完整的客户端命令并准备好接收命令的其余部分.

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

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

状态响应可以 (MAY) 包含一个可选的 "响应代码 (Response Code)". 响应代码由方括号内的数据组成, 形式为原子, 可能后跟一个空格和参数. 响应代码包含超出 OK/NO/BAD 条件的客户端软件的附加信息或状态代码, 并且在客户端可以根据附加信息采取特定操作时定义.

当前定义的响应代码有:

ALERT​

包含人类可读文本的特殊警报, 必须 (MUST) 以引起用户注意消息的方式呈现给用户.

BADCHARSET​

可选地后跟一个括号括起来的字符集列表. 搜索失败, 因为此实现不支持给定的字符集. 如果给出了可选的字符集列表, 则此列表列出了此实现支持的字符集.

CAPABILITY​

后跟一个能力列表. 这可以出现在初始 OK 或 PREAUTH 响应中以传输初始能力列表. 如果客户端识别此响应, 这使得客户端不必发送单独的 CAPABILITY 命令.

PARSE​

人类可读文本表示在解析邮箱中消息的 [RFC-2822] 标头或 [MIME-IMB] 标头时出错.

PERMANENTFLAGS​

后跟一个括号括起来的标志列表, 指示客户端可以永久更改哪些已知标志. FLAGS 未标记响应中的任何标志, 但不在 PERMANENTFLAGS 列表中的标志, 都不能永久设置. 如果客户端尝试 STORE 不在 PERMANENTFLAGS 列表中的标志, 服务器将忽略更改或仅为当前会话的其余部分存储状态更改. PERMANENTFLAGS 列表还可以包含特殊标志 \*, 这表示可以通过尝试在邮箱中存储这些标志来创建新关键字.

READ-ONLY​

邮箱以只读方式选择, 或其在选择时的访问权限已从读写更改为只读.

READ-WRITE​

邮箱以读写方式选择, 或其在选择时的访问权限已从只读更改为读写.

TRYCREATE​

APPEND 或 COPY 尝试失败, 因为目标邮箱不存在 (而不是其他原因). 这是对客户端的提示, 如果首先通过 CREATE 命令创建邮箱, 操作可以成功.

UIDNEXT​

后跟一个十进制数, 指示下一个唯一标识符值. 有关更多信息, 请参阅第 2.3.1.1 节.

UIDVALIDITY​

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

UNSEEN​

后跟一个十进制数, 指示第一个未设置 \Seen 标志的消息的编号.

由特定客户端或服务器实现定义的其他响应代码应该 (SHOULD) 以 "X" 为前缀, 直到它们被添加到本协议的修订版中. 客户端实现应该 (SHOULD) 忽略它们无法识别的响应代码.

7.1.1. OK Response (OK 响应)​

Contents (内容): OPTIONAL response code, human-readable text (可选的响应代码, 人类可读文本)

OK 响应指示来自服务器的信息消息. 当标记时, 它指示关联命令的成功完成. 人类可读文本可以 (MAY) 作为信息消息呈现给用户. 未标记形式指示仅供信息的消息; 信息的性质可以 (MAY) 由响应代码指示.

未标记形式也用作连接启动时三种可能问候之一. 它指示连接尚未经过认证, 并且需要 LOGIN 命令.

示例:

S: * OK IMAP4rev1 server ready
C: A001 LOGIN fred blurdybloop
S: * OK [ALERT] System shutdown in 10 minutes
S: A001 OK LOGIN Completed

7.1.2. NO Response (NO 响应)​

Contents (内容): OPTIONAL response code, human-readable text (可选的响应代码, 人类可读文本)

NO 响应指示来自服务器的操作错误消息. 当标记时, 它指示关联命令的不成功完成. 未标记形式指示警告; 命令仍然可以成功完成. 人类可读文本描述了条件.

示例:

C: A222 COPY 1:2 owatagusiam
S: * NO Disk is 98% full, please delete unnecessary data
S: A222 OK COPY completed
C: A223 COPY 3:200 blurdybloop
S: * NO Disk is 98% full, please delete unnecessary data
S: * NO Disk is 99% full, please delete unnecessary data
S: A223 NO COPY failed: disk is full

7.1.3. BAD Response (BAD 响应)​

Contents (内容): OPTIONAL response code, human-readable text (可选的响应代码, 人类可读文本)

BAD 响应指示来自服务器的错误消息. 当标记时, 它报告客户端命令中的协议级错误; 标记指示导致错误的命令. 未标记形式指示无法确定关联命令的协议级错误; 它还可以指示内部服务器故障. 人类可读文本描述了条件.

示例:

C: ...very long command line...
S: * BAD Command line too long
C: ...empty line...
S: * BAD Empty command line
C: A443 EXPUNGE
S: * BAD Disk crash, attempting salvage to a new disk!
S: * OK Salvage successful, no data lost
S: A443 OK Expunge completed

7.1.4. PREAUTH Response (PREAUTH 响应)​

Contents (内容): OPTIONAL response code, human-readable text (可选的响应代码, 人类可读文本)

PREAUTH 响应始终是未标记的, 并且是连接启动时三种可能问候之一. 它指示连接已通过外部方式进行了认证; 因此不需要 LOGIN 命令.

示例:

S: * PREAUTH IMAP4rev1 server logged in as Smith

7.1.5. BYE Response (BYE 响应)​

Contents (内容): OPTIONAL response code, human-readable text (可选的响应代码, 人类可读文本)

BYE 响应始终是未标记的, 并指示服务器即将关闭连接. 人类可读文本可以 (MAY) 由客户端在状态报告中显示给用户. BYE 响应在以下四种情况之一下发送:

  1. 作为正常注销序列的一部分. 服务器将在向 LOGOUT 命令发送标记的 OK 响应后关闭连接.

  2. 作为紧急关闭公告. 服务器立即关闭连接.

  3. 作为不活动自动注销的公告. 服务器立即关闭连接.

  4. 作为连接启动时三种可能问候之一, 指示服务器不愿意接受来自此客户端的连接. 服务器立即关闭连接.

正常 LOGOUT 序列中发生的 BYE (第一种情况) 与因故障发生的 BYE (其他三种情况) 之间的区别在于, 在故障情况下连接立即关闭. 在所有情况下, 客户端都应该 (SHOULD) 继续从服务器读取响应数据, 直到连接关闭; 这将确保读取和处理任何挂起的未标记或完成响应.

示例:

S: * BYE Autologout; idle for too long

7.2. Server Responses - Server and Mailbox Status (服务器响应 - 服务器和邮箱状态)​

这些响应始终是未标记的. 这是服务器和邮箱状态数据从服务器传输到客户端的方式. 这些响应中的许多通常来自具有相同名称的命令.

7.2.1. CAPABILITY Response (CAPABILITY 响应)​

Contents (内容): capability listing (能力列表)

CAPABILITY 响应作为 CAPABILITY 命令的结果发生. 能力列表包含服务器支持的能力名称的空格分隔列表. 能力列表必须 (MUST) 包含原子 "IMAP4rev1".

此外, 客户端和服务器实现必须 (MUST) 实现 STARTTLS, LOGINDISABLED 和 AUTH=PLAIN (在 [IMAP-TLS] 中描述) 能力. 有关重要信息, 请参阅安全考虑 (Security Considerations) 章节.

以 "AUTH=" 开头的能力名称表示服务器支持该特定认证机制.

LOGINDISABLED 能力表示 LOGIN 命令被禁用, 并且即使用户名和密码有效, 服务器也会使用标记的 NO 响应来响应任何使用 LOGIN 命令的尝试. IMAP 客户端在服务器宣告 LOGINDISABLED 能力时不得 (MUST NOT) 发出 LOGIN 命令.

其他能力名称表示服务器支持 IMAP4rev1 协议的扩展, 修订或修正. 在客户端发出使用相关能力的命令之前, 服务器响应必须 (MUST) 符合本文档.

能力名称必须 (MUST) 以 "X" 开头, 或者是在 IANA 注册的标准或标准跟踪 IMAP4rev1 扩展, 修订或修正. 服务器不得 (MUST NOT) 提供未注册或非标准能力名称, 除非此类名称以 "X" 为前缀.

客户端实现不应该 (SHOULD NOT) 要求除 "IMAP4rev1" 以外的任何能力名称, 并且必须 (MUST) 忽略任何未知的能力名称.

服务器可以 (MAY) 自动发送能力, 方法是在初始 PREAUTH 或 OK 响应中使用 CAPABILITY 响应代码, 以及在成功认证的标记 OK 响应中发送更新的 CAPABILITY 响应代码. 如果客户端识别这些自动能力, 则无需发送单独的 CAPABILITY 命令.

示例:

S: * CAPABILITY IMAP4rev1 STARTTLS AUTH=GSSAPI XPIG-LATIN

7.2.2. LIST Response (LIST 响应)​

Contents (内容): name attributes, hierarchy delimiter, name (名称属性, 层次分隔符, 名称)

LIST 响应作为 LIST 命令的结果发生. 它返回与 LIST 规范匹配的单个名称. 单个 LIST 命令可以有多个 LIST 响应.

定义了四个名称属性:

\Noinferiors

  • 在此名称下不可能存在任何子级层次结构; 现在不存在子级, 将来也不能创建.

\Noselect

  • 无法将此名称用作可选择的邮箱.

\Marked

  • 服务器已将邮箱标记为 "有趣"; 邮箱可能包含自上次选择邮箱以来添加的消息.

\Unmarked

  • 自上次选择邮箱以来, 邮箱不包含任何其他消息.

如果服务器确定邮箱是否 "有趣" 不可行, 或者名称是 \Noselect 名称, 则服务器不应该 (SHOULD NOT) 发送 \Marked 或 \Unmarked.

层次分隔符是用于在邮箱名称中分隔层次级别的字符. 客户端可以使用它来创建子邮箱, 以及搜索更高或更低级别的命名层次结构. 顶级层次结构节点的所有子级必须 (MUST) 使用相同的分隔符字符. NIL 层次分隔符意味着不存在层次结构; 名称是 "扁平" 名称.

名称表示明确的从左到右层次结构, 并且必须 (MUST) 对用作 LIST 和 LSUB 命令中的引用有效. 除非指示了 \Noselect, 否则名称还必须 (MUST) 对接受邮箱名称的命令 (如 SELECT) 作为参数有效.

示例:

S: * LIST (\Noselect) "/" ~/Mail/foo

7.2.3. LSUB Response (LSUB 响应)​

Contents (内容): name attributes, hierarchy delimiter, name (名称属性, 层次分隔符, 名称)

LSUB 响应作为 LSUB 命令的结果发生. 它返回与 LSUB 规范匹配的单个名称. 单个 LSUB 命令可以有多个 LSUB 响应. 数据格式与 LIST 响应相同.

示例:

S: * LSUB () "." #news.comp.mail.misc

7.2.4. STATUS Response (STATUS 响应)​

Contents (内容): name, status parenthesized list (名称, 状态括号列表)

STATUS 响应作为 STATUS 命令的结果发生. 它返回与 STATUS 规范匹配的邮箱名称和请求的邮箱状态信息.

示例:

S: * STATUS blurdybloop (MESSAGES 231 UIDNEXT 44292)

7.2.5. SEARCH Response (SEARCH 响应)​

Contents (内容): zero or more numbers (零个或多个数字)

SEARCH 响应作为 SEARCH 或 UID SEARCH 命令的结果发生. 这些数字指的是与搜索条件匹配的那些消息. 对于 SEARCH, 这些是消息序列号; 对于 UID SEARCH, 这些是唯一标识符. 每个数字由空格分隔.

示例:

S: * SEARCH 2 3 6

7.2.6. FLAGS Response (FLAGS 响应)​

Contents (内容): flag parenthesized list (标志括号列表)

FLAGS 响应作为 SELECT 或 EXAMINE 命令的结果发生. 标志括号列表标识适用于此邮箱的标志 (至少是系统定义的标志). 除了系统标志之外, 还可以存在其他标志, 具体取决于服务器实现.

来自 FLAGS 响应的更新必须 (MUST) 由客户端记录.

示例:

S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)

7.3. Server Responses - Mailbox Size (服务器响应 - 邮箱大小)​

这些响应始终是未标记的. 这是邮箱大小变化从服务器传输到客户端的方式. 紧跟在 "*" 标记后面的是表示消息计数的数字.

7.3.1. EXISTS Response (EXISTS 响应)​

Contents (内容): none (无)

EXISTS 响应报告邮箱中的消息数量. 此响应作为 SELECT 或 EXAMINE 命令的结果发生, 以及邮箱大小发生变化时 (例如, 新消息).

来自 EXISTS 响应的更新必须 (MUST) 由客户端记录.

示例:

S: * 23 EXISTS

7.3.2. RECENT Response (RECENT 响应)​

Contents (内容): none (无)

RECENT 响应报告设置了 \Recent 标志的消息数量. 此响应作为 SELECT 或 EXAMINE 命令的结果发生, 以及邮箱大小发生变化时 (例如, 新消息).

注意: 不能保证最近消息的消息序列号将是邮箱中最高 n 个消息的连续范围 (其中 n 是 RECENT 响应报告的值). 这种情况不成立的示例包括: 多个客户端打开同一邮箱 (第一个被通知的会话将看到它是最近的, 其他会话可能会看到它不是最近的), 以及当邮箱被非 IMAP 代理重新排序时.

识别最近消息的唯一可靠方法是查看消息标志以查看哪些设置了 \Recent 标志, 或执行 SEARCH RECENT.

来自 RECENT 响应的更新必须 (MUST) 由客户端记录.

示例:

S: * 5 RECENT

7.4. Server Responses - Message Status (服务器响应 - 消息状态)​

这些响应始终是未标记的. 这是消息数据从服务器传输到客户端的方式, 通常作为具有相同名称的命令的结果. 紧跟在 "*" 标记后面的是表示消息序列号的数字.

7.4.1. EXPUNGE Response (EXPUNGE 响应)​

Contents (内容): none (无)

EXPUNGE 响应报告指定的消息序列号已从邮箱中永久删除. 邮箱中每个后续消息的消息序列号立即递减 1, 并且此递减反映在后续响应中的消息序列号中 (包括其他未标记的 EXPUNGE 响应).

EXPUNGE 响应还递减邮箱中的消息数量; 不需要发送带有新值的 EXISTS 响应.

由于立即递减规则, 出现在一组连续 EXPUNGE 响应中的消息序列号取决于是从较低数字到较高数字删除消息, 还是从较高数字到较低数字删除消息. 例如, 如果清除 9 条消息邮箱中的最后 5 条消息, "从低到高" 服务器将为消息序列号 5 发送五个未标记的 EXPUNGE 响应, 而 "从高到低" 服务器将为消息序列号 9, 8, 7, 6 和 5 发送连续的未标记 EXPUNGE 响应.

当没有命令正在进行时, 或在响应 FETCH, STORE 或 SEARCH 命令时, 不得 (MUST NOT) 发送 EXPUNGE 响应. 此规则是防止客户端和服务器之间消息序列号失去同步所必需的. 在完整命令被接收之前, 命令不 "正在进行"; 特别是, 在命令继续协商期间, 命令不 "正在进行".

注意: UID FETCH, UID STORE 和 UID SEARCH 是与 FETCH, STORE 和 SEARCH 不同的命令. 在 UID 命令期间可以 (MAY) 发送 EXPUNGE 响应.

来自 EXPUNGE 响应的更新必须 (MUST) 由客户端记录.

示例:

S: * 44 EXPUNGE

7.4.2. FETCH Response (FETCH 响应)​

Contents (内容): message data (消息数据)

FETCH 响应向客户端返回有关消息的数据. 数据是括号中的数据项名称及其值的配对. 此响应作为 FETCH 或 STORE 命令的结果发生, 以及由单方面服务器决定 (例如, 标志更新).

当前的数据项有:

BODY

  • 没有扩展数据的 BODYSTRUCTURE 形式.

BODY[<section>]<<origin octet>>

  • 表示指定部分的正文内容的字符串. 客户端应该 (SHOULD) 根据内容传输编码, 正文类型和子类型来解释字符串.

如果指定了起始八位字节, 则此字符串是整个正文内容的子字符串, 从该起始八位字节开始. 这意味着 BODY[]<0> 可以 (MAY) 被截断, 但 BODY[] 永远不会被截断.

注意: 除非客户端通过 FETCH BODY[<section>]<<partial>> 数据项明确请求, 否则服务器不得 (MUST NOT) 在 FETCH 响应中使用起始八位字节工具.

如果 [CHARSET] 标识符是此部分的正文参数括号列表的一部分, 则允许 8 位文本数据. 请注意, 标头 (部分说明符 HEADER 或 MIME, 或 MESSAGE/RFC822 部分的标头部分) 必须 (MUST) 是 7 位; 标头中不允许 8 位字符. 还要注意, 标头和正文之间的 [RFC-2822] 分隔空行不受标头行子集化的影响; 空行始终作为标头数据的一部分包含在内, 除非消息没有正文且没有空行的情况.

诸如二进制数据之类的非文本数据必须 (MUST) 在发送到客户端之前传输编码为文本形式, 例如 BASE64. 要派生原始二进制数据, 客户端必须 (MUST) 解码传输编码的字符串.

BODYSTRUCTURE

  • 描述消息的 [MIME-IMB] 正文结构的括号列表. 这是由服务器通过解析 [MIME-IMB] 标头字段来计算的, 并根据需要对各种字段进行默认设置.

例如, 一个 48 行 2279 八位字节的简单文本消息可以具有正文结构: ("TEXT" "PLAIN" ("CHARSET" "US-ASCII") NIL NIL "7BIT" 2279 48)

多个部分由括号嵌套指示. 括号列表的第一个元素不是正文类型, 而是一个或多个嵌套正文结构的序列. 括号列表的第二个元素是多部分子类型 (mixed, digest, parallel, alternative 等).

例如, 由文本和 BASE64 编码文本附件组成的两部分消息可以具有正文结构:

(("TEXT" "PLAIN" ("CHARSET" "US-ASCII") NIL NIL "7BIT" 1152 23)
 ("TEXT" "PLAIN" ("CHARSET" "US-ASCII" "NAME" "cc.diff")
  "<[email protected]>" "Compiler diff"
  "BASE64" 4554 73) "MIXED")

扩展数据跟在多部分子类型之后. BODY 获取从不返回扩展数据, 但可以使用 BODYSTRUCTURE 获取返回. 扩展数据 (如果存在) 必须 (MUST) 按定义的顺序排列. 多部分正文部分的扩展数据按以下顺序排列:

正文参数括号列表 (body parameter parenthesized list)

  • 如 [MIME-IMB] 中定义的属性/值对的括号列表 [例如, ("foo" "bar" "baz" "rag"), 其中 "bar" 是 "foo" 的值, "rag" 是 "baz" 的值].

正文配置 (body disposition)

  • 括号列表, 由配置类型字符串组成, 后跟如 [DISPOSITION] 中定义的配置属性/值对的括号列表.

正文语言 (body language)

  • 如 [LANGUAGE-TAGS] 中定义的给出正文语言值的字符串或括号列表.

正文位置 (body location)

  • 如 [LOCATION] 中定义的给出正文内容 URI 的字符串列表.

任何后续的扩展数据尚未在此版本的协议中定义. 此类扩展数据可以由零个或多个 NIL, 字符串, 数字或潜在嵌套的此类数据的括号列表组成. 执行 BODYSTRUCTURE 获取的客户端实现必须 (MUST) 准备好接受此类扩展数据. 服务器实现不得 (MUST NOT) 发送此类扩展数据, 直到它已被此协议的修订版定义.

非多部分正文部分的基本字段按以下顺序排列:

正文类型 (body type)

  • 如 [MIME-IMB] 中定义的给出内容媒体类型名称的字符串.

正文子类型 (body subtype)

  • 如 [MIME-IMB] 中定义的给出内容子类型名称的字符串.

正文参数括号列表 (body parameter parenthesized list)

  • 如 [MIME-IMB] 中定义的属性/值对的括号列表.

正文 ID (body id)

  • 如 [MIME-IMB] 中定义的给出内容 ID 的字符串.

正文描述 (body description)

  • 如 [MIME-IMB] 中定义的给出内容描述的字符串.

正文编码 (body encoding)

  • 如 [MIME-IMB] 中定义的给出内容传输编码的字符串.

正文大小 (body size)

  • 给出正文大小 (以八位字节为单位) 的数字. 请注意, 此大小是其传输编码中的大小, 而不是任何解码后的结果大小.

类型为 MESSAGE 且子类型为 RFC822 的正文类型在基本字段之后立即包含封装消息的信封结构, 正文结构和文本行大小.

类型为 TEXT 的正文类型在基本字段之后立即包含正文的文本行大小. 请注意, 此大小是其内容传输编码中的大小, 而不是任何解码后的结果大小.

扩展数据跟在基本字段和上面列出的特定于类型的字段之后. BODY 获取从不返回扩展数据, 但可以使用 BODYSTRUCTURE 获取返回. 扩展数据 (如果存在) 必须 (MUST) 按定义的顺序排列.

非多部分正文部分的扩展数据按以下顺序排列:

正文 MD5 (body MD5)

  • 如 [MD5] 中定义的给出正文 MD5 值的字符串.

正文配置 (body disposition)

  • 与多部分正文部分的正文配置具有相同内容和功能的括号列表.

正文语言 (body language)

  • 如 [LANGUAGE-TAGS] 中定义的给出正文语言值的字符串或括号列表.

正文位置 (body location)

  • 如 [LOCATION] 中定义的给出正文内容 URI 的字符串列表.

任何后续的扩展数据尚未在此版本的协议中定义, 将如上述多部分扩展数据中所述.

ENVELOPE

  • 描述消息信封结构的括号列表. 这是由服务器通过将 [RFC-2822] 标头解析为组成部分, 并根据需要对各种字段进行默认设置来计算的.

信封结构的字段按以下顺序排列: date, subject, from, sender, reply-to, to, cc, bcc, in-reply-to 和 message-id. date, subject, in-reply-to 和 message-id 字段是字符串. from, sender, reply-to, to, cc 和 bcc 字段是地址结构的括号列表.

地址结构是描述电子邮件地址的括号列表. 地址结构的字段按以下顺序排列: personal name, [SMTP] at-domain-list (源路由), mailbox name 和 host name.

[RFC-2822] 组语法由特殊形式的地址结构指示, 其中主机名字段为 NIL. 如果邮箱名称字段也为 NIL, 则这是组结束标记 (RFC 822 语法中的分号). 如果邮箱名称字段为非 NIL, 则这是组开始标记, 邮箱名称字段保存组名短语.

如果 [RFC-2822] 标头中缺少 Date, Subject, In-Reply-To 和 Message-ID 标头行, 则信封的相应成员为 NIL; 如果这些标头行存在但为空, 则信封的相应成员为空字符串.

注意: 某些服务器可能会在 "存在但为空" 的情况下返回 NIL 信封成员. 客户端应该 (SHOULD) 将 NIL 和空字符串视为相同.

注意: [RFC-2822] 要求所有消息都具有有效的 Date 标头. 因此, 信封中的 date 成员不能为 NIL 或空字符串.

注意: [RFC-2822] 要求 In-Reply-To 和 Message-ID 标头 (如果存在) 具有非空内容. 因此, 信封中的 in-reply-to 和 message-id 成员不能为空字符串.

如果 [RFC-2822] 标头中缺少 From, To, cc 和 bcc 标头行, 或存在但为空, 则信封的相应成员为 NIL.

如果 [RFC-2822] 标头中缺少 Sender 或 Reply-To 行, 或存在但为空, 则服务器将信封的相应成员设置为与 from 成员相同的值 (客户端不应该知道要这样做).

注意: [RFC-2822] 要求所有消息都具有有效的 From 标头. 因此, 信封中的 from, sender 和 reply-to 成员不能为 NIL.

FLAGS

  • 为此消息设置的标志的括号列表.

INTERNALDATE

  • 表示消息内部日期的字符串.

RFC822

  • 等效于 BODY[].

RFC822.HEADER

  • 等效于 BODY[HEADER]. 请注意, 这不会导致设置 \Seen, 因为 RFC822.HEADER 响应数据作为 RFC822.HEADER 的 FETCH 的结果发生. BODY[HEADER] 响应数据作为 BODY[HEADER] 的 FETCH (设置 \Seen) 或 BODY.PEEK[HEADER] (不设置 \Seen) 的结果发生.

RFC822.SIZE

  • 表示消息的 [RFC-2822] 大小的数字.

RFC822.TEXT

  • 等效于 BODY[TEXT].

UID

  • 表示消息的唯一标识符的数字.

示例:

S: * 23 FETCH (FLAGS (\Seen) RFC822.SIZE 44827)

7.5. Server Responses - Command Continuation Request (服务器响应 - 命令继续请求)​

命令继续请求响应由 "+" 标记而不是标记指示. 这种形式的响应指示服务器已准备好接受来自客户端的命令的继续. 此响应的其余部分是一行文本.

此响应在 AUTHENTICATE 命令中用于将服务器数据传输到客户端, 并请求其他客户端数据. 如果任何命令的参数是字面量, 也会使用此响应.

除非服务器指示它是预期的, 否则不允许客户端发送字面量的八位字节. 这允许服务器逐行处理命令和拒绝错误. 命令的其余部分 (包括终止命令的 CRLF) 跟在字面量的八位字节之后. 如果有任何其他命令参数, 则字面量八位字节后跟一个空格和这些参数.

示例:

C: A001 LOGIN {11}
S: + Ready for additional command text
C: FRED FOOBAR {7}
S: + Ready for additional command text
C: fat man
S: A001 OK LOGIN completed
C: A044 BLURDYBLOOP {102856}
S: A044 BAD No such command as "BLURDYBLOOP"

（第7章 Server Responses 翻译完成）

Last updated on