我正在阅读RFC 7162，尝试弄清楚客户端在与支持CONDSTORE但不支持QRESYNC的服务器进行通信时应该如何表现。
初始连接情况很简单：客户端将其缓存的modseq值与对HIGHESTMODSEQ命令的SELECT响应进行比较，如果它较低，则客户端可以使用{{检索任何更改1}} + FETCH或CHANGEDSINCE + SEARCH。执行此操作后，客户端可以将MODSEQ值存储为邮箱的新缓存modseq值。
但是，如果客户端在选择邮箱时收到未经请求的HIGHESTMODSEQ响应，是否可以从这些更新中的FETCH属性中得出任何可靠的结论？缓存看到的最高MODSEQ值是否安全，或者客户端是否有可能在此过程中丢失对邮箱状态的任何更新？
答案 0 :(得分：2)
这很棘手。
这个问题可能是指RFC7162中的一种语言，它澄清了HIGHESTMODSEQ和MODSEQ是两种不同的野兽，而FETCH MODSEQ可能会在服务器被迫撤回一些EXPUNGE时到达{ {1}} s，可能是因为客户端发送了一个使用MSN的命令（参见3.2节中的motivation）。
在此特定情况下，服务器仅支持CONDSTORE而不支持 QRESYNC，仅使用MODSEQ和HIGHESTMODSEQ用于跟踪元数据更改（例如FLAGS更新）。他们不必须更改消息清除。因此，由于您作为客户端不能使用HIGHESTMODSEQ用于除FLAGS更新之外的任何其他目的，因此可能会因为QRESYNC而导致RFC试图阻止的情况没有任何致命后果。基于此，我看不出客户在看到HIGHESTMODSEQ时只能在CONDSTORE服务器上发现MODSEQ的原因。
你应该在imap-protocol邮件列表上询问并寻求澄清。我也有一个关于如何正确处理这个问题的公开错误，RFC对我来说并不完全清楚。