Question

如果客户端使用一系列序列号执行FETCH，服务器响应是否必须按递增的顺序编号顺序给出每个电子邮件？

RFC3501包含以下FETCH命令示例。

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

以下示例是否代表兼容服务器？

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

关于响应顺序，我在FETCH请求和FETCH响应部分找不到任何内容。

Answer 1

根据我的理解，不可以。序列必须按顺序排列。 [见下面的评论 - 因为规格提到存储，而不是检索订单。]

2.3.1.1。唯一标识符（UID）消息属性

分配给每条消息的32位值，与
用于时   唯一标识符有效性值（见下文）形成64位值
  不得引用邮箱中的任何其他邮件或任何其他信息   永远具有相同名称的后续邮箱。唯一标识符
  在邮箱中以严格提升的方式分配;如每个   消息被添加到邮箱，它被分配了比B1更高的UID   先前添加的消息。 与消息序列不同   数字，唯一标识符不一定是连续的。

由于这些是序列号，因此结果必须是连续的。

Articld 6.4.8。意味着没有UID前缀的FETCH表示序列搜索而不是范围表达式中的唯一标识符：

  ... the UID command (variant) takes a SEARCH command with
  SEARCH command arguments.  The interpretation of the arguments is
  the same as with SEARCH; however, the numbers returned in a SEARCH
  response for a UID SEARCH command are unique identifiers instead

来源：https://tools.ietf.org/html/rfc3501

Answer 2

您可以根据需要重新排序。 Paurian引用段落适用于UID分配，而不适用于报告。

在实践中它也是安全的：赛门铁克的IMAP代理（我忘了它的名字，但它的工作是扫描顽皮的附件并向IMAP客户端提供世界的视图）以不可预测的顺序发送fetch个响应，主要开发者知道没有问题。

我是否可以在响应FETCH命令时改变电子邮件的顺序？

2 个答案: