我已从使用 Thunderbird 转为使用offlineimap和mutt。我的邮箱有超过 50,000 封邮件。调整一些设置后，mutt对这么多消息的反应非常灵敏。notmuch搜索速度非常快。但offlineimap同步所有文件夹可能需要几分钟时间。
经过一番研究，IMAP 似乎不适用于非常大的文件夹。如果是这样，那么我应该使用什么样的电子邮件工作流程来保持文件夹更小？
答案1
并非所有 IMAP 服务器都很快，但如前所述，可以实现高效的 IMAP 实施和设置。我有相当的运气鸽舍。然而，offlineimap 是一个特别慢的程序。它在小型测试中运行良好，因此我切换到它并重新设置了我的整个电子邮件设置以依赖它。但后来我收到的邮件越多，速度就越慢，直到最后我每次检查电子邮件时都开始失去理智。
如果您想要完全离线的搜索体验并且不太喜欢，您可以考虑多同步，这有点像离线地图，但专门用于 notmuch 以利用 notmuch 的索引。完成初始同步后，muchsync 比 Offlineimap 快得多，因为它避免了 Offlineimap 所具有的所有网络往返，并利用 notmuch 的索引数据结构来提高效率。我从 Offlineimap 切换到它并且非常高兴。
另一个值得考虑的选择是同步。我对 isync 没有个人经验，但有些人似乎喜欢它。以前使用过并且讨厌offlineimap，如果我没有切换到muchsync，我会认真研究isync。
答案2
当您说“IMAP”时，您很可能指的是uwimapdIMAP 服务器的实现。在这种情况下，您需要确保所有 mbox 的大小都不会超过 2GB，即同一文件夹中的所有电子邮件，不包括子文件夹。
如果您不是指uwimapd，我相信您的问题是计算机和互联网上行链路的性能，而不是 IMAP。所以：
仅保留不超过 3 个月的电子邮件以及属于正在进行的项目的电子邮件。将其余部分放入档案文件夹。下创建相同的文件夹结构档案正如你所看到的收件箱。这使得在其中找到东西变得很容易档案，如果你找不到它收件箱。
IMAP 是邮件用户代理用来检索和管理（远程）邮件服务器上存储的电子邮件的明文协议，当它必须同时处理数千封电子邮件时，就会出现问题。关键的一点是“必须处理“。电子邮件的总量和大小本身对于 IMAP 来说不是问题。如果它必须实际处理大量电子邮件，就会出现问题。
例如，如果数千封电子邮件的内容和/或状态（已标记、未读/已读、优先级、时间戳等）在两次同步之间发生更改，就会发生这种情况。当您使用时，offlineimap这确实可能会发生，具体取决于您的用例。但是，在这种情况下，唯一对您有帮助的是更频繁的同步。
答案3
“经过一些研究，IMAP 似乎不适用于非常大的文件夹。”
我的观点（和经验）恰恰相反。 Imap 具有非常复杂的服务器端搜索、索引能力 - 唯一的问题是，大多数邮件客户端实际上将其用作远程文件处理协议。
例如，使用 IMAP 可以在具有给定 SMTP 标头的文件夹中搜索邮件。或者，您可以将邮件的文件附件与其正文分开处理。但这是有代价的：该协议比我见过的任何其他协议都要复杂得多。
只有在以下情况下，imap 的真正威力才会可见：
实际的 IMAP 服务器能够索引您的邮件
并且您的邮件客户端能够智能地处理 imap 文件夹（即不使用 imapd 作为远程文件系统，而是通过服务器端的远程查询来完成大部分工作）。
我唯一的美好经历是雷鸟/鸽舍配对。在客户端，kmail 也相对不错，服务器端也有 cyrus。其他系统确实不太好。
在雷鸟中，您可以进行“在服务器上搜索”查询并以虚拟文件夹的形式查看其结果。服务器端搜索允许 imapd 根据其内部索引数据进行快速、基于关键字的搜索。
我不知道offlineimap，但我知道mutt。干净的字符控制台应用程序非常好，而且大多非常高效，有一个例外，这正是您发现的：它们倾向于避免索引事物并尝试线性事物（尽管非常快）。
答案4
我刚刚添加了imapsync到 Alpine Linux。它可以在LXC任何 Linux 上的容器中运行。 Alpine 集装箱的5mb大小约为。
我昨晚将7GB邮箱转移到新邮箱，没有任何问题。mailserver大约需要 3 小时，每秒传输 2.2 条消息，并且进程使用了260-280mb RAM。60在启用缓存的情况下同步 5 个邮箱需要几秒钟的时间--useuid。