我可以在响应 FETCH 命令时打乱电子邮件的顺序吗?

May I shuffle the order of the e-mails in a response for a FETCH command?

如果客户端使用一系列序列号执行 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 响应部分找不到任何关于响应顺序的内容。

据我了解,不是。顺序必须是有序的。 [请参阅下面的评论 - 因为规范提到了存储,而不是订单检索。]

2.3.1.1. Unique Identifier (UID) Message Attribute

A 32-bit value assigned to each message, which when used with the
unique identifier validity value (see below) forms a 64-bit value
that MUST NOT refer to any other message in the mailbox or any
subsequent mailbox with the same name forever. Unique identifiers
are assigned in a strictly ascending fashion in the mailbox; as each
message is added to the mailbox it is assigned a higher UID than the
message(s) which were added previously. Unlike message sequence
numbers, unique identifiers are not necessarily contiguous.

由于这些是序号,结果必须是连续的。

第 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://www.rfc-editor.org/rfc/rfc3501

您可以根据需要重新订购。 Paurian 引述段落适用于 UID 分配,不适用于报告。

它在实践中也是安全的:Symantec 的 IMAP 代理(我忘了它的名字,但它的工作是扫描顽皮的附件并向 IMAP 客户端呈现一个经过净化的世界视图)发送 fetch 响应不可预测的顺序,并且主要开发人员不知道由此产生的任何问题。