序列号更改时的 IMAP 获取命令竞争条件答案

【问题标题】：IMAP fetch command race condition on sequence number change序列号更改时的 IMAP 获取命令竞争条件
【发布时间】：2014-06-10 03:41:06
【问题描述】：

我正在尝试通过RFC 3501 确定当您从序列号获取时会发生什么，但是 CREATE 或 EXPUNGE 命令出现在响应之前。例如

> C: t fetch 32 rfc822.size
> S: * 32 FETCH (RFC822.SIZE 4085)

很简单，但是呢：

> C: t fetch 32 rfc822.size
> S: * 12 EXPUNGE
> S: * 32 EXISTS
> S: * 31 FETCH (RFC822.SIZE 4085)

31 是指新的序列号，还是 fetch 中引用的序列号？

【问题讨论】：

tools.ietf.org/html/rfc2180 你可能很感兴趣。

标签： email imap

【解决方案1】：

RFC 3501 的第 7.4.1 节特别包含这种语言：

  An EXPUNGE response MUST NOT be sent when no command is in
  progress, nor while responding to a FETCH, STORE, or SEARCH
  command.  This rule is necessary to prevent a loss of
  synchronization of message sequence numbers between client and
  server.  A command is not "in progress" until the complete command
  has been received; in particular, a command is not "in progress"
  during the negotiation of command continuation.

这特别禁止示例。它不能单方面发送（“不能在没有命令正在进行时发送”），也不能作为对 FETCH 的响应发送（“也不能在响应 FETCH、STORE 或 SEARCH 命令时发送”）。

另请参阅 5.5，其中包含有关多个命令正在进行时的竞争条件的一些信息。禁止客户端在其他类型的命令正在进行时发送普通的 FETCH、STORE 或 SEARCH，反之亦然。

【讨论】：

【解决方案2】：

您的答案应该很明显 - 对于删除后响应中的 31 来引用“当前”序列号 31 消息以外的其他内容，这意味着 IMAP 服务器正在维护每个命令点的序列号索引-时间。显然，IMAP 协议不需要在服务器上进行此类工作。

进一步注意，严格来说，未标记的响应与 fetch 命令无关；该关联只是一个建议。

【讨论】：

此外，规范明确禁止 EXPUNGE 响应以返回任何使用序列号的命令，因此不应出现此示例。
@Max 不会作为回报，这将是在发送 fetch 之后和收到响应之前偶然发送的未经请求的响应。
虽然没有严格禁止，除非您处于空闲状态，否则 IMAP 服务器不会发送未经请求的响应，除非命令正在进行（因此存在 NOOP 命令）。 RFC 3501 中的反竞争条件语言似乎禁止发送完全未经请求的 EXPUNGE。
他的第二种情况也没有意义：他专门要求消息 32，它不会发送 31 响应。就像你说的那样，要这样做，它必须记住客户要求 32，发送 EXPUNGE，将请求重新编号为 31，然后发送。这太荒谬了。
@Max 这是合法的。 IMAP 协议很可笑。