使用 imap_tools（或 imaplib），如何通过重复获取整个 imap 数据库来同步 imap 更改而不是轮询？

Question

由于周围有几个类似的问题，我想非常准确。

编辑：让我们专注于对从一个文件夹移动到另一个文件夹的任何 email 消息进行动态反应。

典型的 imap 客户端应用程序仅获取自上次同步以来 imap 数据库中的更改。 如果您的 email 客户端每次运行时都必须获取每个 email，那将需要很长时间。

不幸的是，我的 imap_tools 应用程序每次运行时都必须获取（仅标题）整个 imap 数据库。 为了动态检测变化，我必须反复轮询整组消息。 显然，这不是一个合理的设计。

imap_tools（或底层 imaplib）是否提供同步机制？

不是使用“seen”标志。 那是用于指示人是否已经阅读了消息，并且也不是特定于特定客户端的。

依靠 uid 并不完全是因为我想检测用户是否已删除或将邮件从一个文件夹移动到另一个文件夹。

Answer 1

你可以：

• 对限制数据集使用搜索参数：date_gte、date_lt、new...
• 如果您存储某些内容，请依赖标头中的 message-id
• 使用mailbox.move作为可靠的“标记”消息而不是标志
• 计算味精 hash

一切都取决于你的任务。

据我所知，IMAP 中没有“同步”，有 IDLE，但 imap_tools 做不到。

Answer 2

IMAP 的核心是一种旧的且效率不高的协议，因为设计并不专注于同步。 Kundrát称其为Cache Filing Protocol ：服务器是事实的唯一来源，客户端的工作是向用户显示此内容，并且通常尽可能多地缓存此内容。

在基线 IMAP 中，这通常意味着连接到服务器，并询问和缓存客户端希望显示的尽可能多的信息。 消息、标题、标志、可能是正文、可能是附件的数量。

它还假设客户端在使用时具有大部分稳定的网络连接，大多数桌面模式客户端都是如此。 同步所有数据后，服务器可以主动向您unsolicited responses ：当有EXISTS进入时存在； 更新EXPUNGE时STORE ，删除消息时删除。 除非响应允许的用户命令，否则服务器通常不会发送这些。 老客户经常使用NOOP ，或者可能为此使用CHECK 。

如果您失去连接，客户端将重新连接并刷新其缓存。 由于关于消息的唯一可变因素是它们的存在和标志，这通常相当快：客户端通常会为所有消息请求所有标志。 从那里它可以快速更新其缓存。 应用标志。 获取它发现的新 UID 的标头，删除它没有收到的 UID 的缓存版本。

当一个文件夹有数万条消息时，这确实开始崩溃，您会发现客户端此时在某些服务器上的启动/同步速度开始非常慢，并且开始使用相当多的数据。

IMAP 作为一种协议不能跨文件夹跟踪邮件。 每个文件夹的 state 是完全独立的。 如果它被移动，则相当于从一个文件夹中删除并添加到另一个文件夹。 桌面客户端通常会维护一个连接池，以便一次查看多个文件夹。 您可以将启发式方法应用于缓存消息以尝试检测文件夹移动（例如，标题和元数据的选择），但它并不完美。

---

如您所见，一旦您的邮箱超过几百条消息，其中的大部分效率都非常低，因此有很多扩展可以提高缓存效率。

UIDPLUS (RFC4315) 几乎无处不在。 这要求服务器在更多命令中支持 UID，并且几乎是任何缓存模式客户端都需要的，因为在涉及删除时消息序列号是不可靠的。

IDLE (RFC 2177) 相当普遍，但并非无处不在。 客户端可以发出一个IDLE命令，这会告诉服务器它随时准备好接受那些未经请求的更新。 这意味着客户端不必每隔几分钟使用NOOP命令轮询一次。

CONDSTORE (RFC 4551) 在大多数 unix 类型的服务器和一些商业服务器上。 除其他外，它将序列号与标志更改相关联。 这允许标志重新同步步骤仅从它知道的最新序列号中获取更改。 但是，它无助于检测已删除的消息，并且仍然需要UID SEARCH ALL才能在断开连接后找到这些消息。

QRESYNC (RFC5162) 为已删除消息提供重新同步数据。 不幸的是，这是一个非常罕见的扩展，在大型商业服务器上几乎不存在。

NOTIFY (RFC5465) 几乎无处可去。 它应该像一个超级IDLE，可以同时监控多个邮箱。

Gmail Extensions当然是 Gmail 特定的。 除其他外，它将永久标识符与每条消息（X-GM-MSGID）相关联，这确实允许跨文件夹可靠地跟踪它。 它还提供“所有邮件”文件夹和标签，这意味着您可以通过同步所有邮件文件夹来同步整个帐户。 与其他服务器一样，当收到数万条消息时，这确实开始导致带宽效率低下。

---

根据我参与开发几个强调带宽效率和响应能力的移动 email 客户端的经验，即使在处理 IMAP 的所有问题时，客户端也会显得非常响应。 IDLE可用于尝试保持收件箱同步。 如果你不能这样做，你可以通过只保持最近一周的消息完全同步来隐藏很多卡顿，并减少同步 rest 的频率（UID SEARCH SINCE 在这里很有帮助）。 用户通常只查看收件箱的末尾，并且通常只关心收到的新消息。

一般来说，镜像消息的移动实际上只是被检测为删除和添加，它只是互联网连接和服务器非常快，而且需要几百毫秒的东西对用户来说可能是即时的。 如果发生任何优化，它是启发式的。 我认为 Thunderbird 可以有一个可以打开的协议日志。 如果你真的很好奇它在做什么，打开它并移动一条消息，看看它做了什么。