跳到主要内容

8. IMAP4rev1 连接示例

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

     扩展数据跟在基本字段和上面列出的类型特定字段之后. 扩展数据绝不会随 BODY 获取返回, 但可以随 BODYSTRUCTURE 获取返回. 若存在扩展数据, 它们 MUST 按定义的顺序出现.

     非多部分 (non-multipart) 正文部分的扩展数据按以下顺序排列:

     body MD5
        一个字符串, 给出 [MD5] 中定义的正文 MD5 值.

RFC 3501 IMAPv4 March 2003

     body disposition
        一个带括号的列表, 其内容和功能与多部分正文部分的 body disposition 相同.

     body language
        一个字符串或带括号的列表, 给出 [LANGUAGE-TAGS] 中定义的正文语言值.

     body location
        一个字符串列表, 给出 [LOCATION] 中定义的正文内容 URI.

     后续任何扩展数据在本协议版本中尚未定义, 将按上文 multipart extension data 中的描述处理.

  ENVELOPE
     一个带括号的列表, 描述消息的信封结构 (envelope structure). 它由服务器通过将 [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 字段是带括号的地址结构列表.

     地址结构 (address structure) 是一个带括号的列表, 描述一个电子邮件地址. 地址结构中的字段按以下顺序排列: 个人名称, [SMTP] at-domain-list (source route), 邮箱名称, 主机名.

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

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

RFC 3501 IMAPv4 March 2003

        注意: 一些服务器在"存在但为空"的情况下可能返回 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
     为此消息设置的标志 (flags) 的带括号列表.

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

  RFC822
     等价于 BODY[].

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

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

RFC 3501 IMAPv4 March 2003

  RFC822.TEXT
     等价于 BODY[TEXT].

  UID
     表示消息唯一标识符 (unique identifier) 的数字.

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

7.5. 服务器响应 - 命令继续请求​

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

此响应用于 AUTHENTICATE 命令, 以向客户端传输服务器数据并请求额外的客户端数据. 如果任何命令的某个参数是字面量 (literal), 也会使用此响应.

除非服务器表示期望接收, 否则客户端不得发送字面量的八位字节. 这允许服务器逐行处理命令并拒绝错误. 命令的其余部分, 包括终止命令的 CRLF, 跟在字面量八位字节之后. 如果还有其他命令参数, 字面量八位字节之后会跟一个空格和这些参数.

Example: 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"

最后于 更新