我正在阅读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对我来说并不完全清楚。