IMAPフォルダー：大きすぎますか？
Thunderbirdの使用からofflineimapとmuttに切り替えました。私のメールボックスには50k以上のメッセージがあります。いくつかの設定を調整した後、muttはこの多くのメッセージに非常に反応します。 notmuchは検索が非常に高速です。ただし、offlineimapがすべてのフォルダを同期するのに数分かかる場合があります。
少し調べたところ、IMAPは非常に大きなフォルダでの使用を意図していないようです。その場合は、フォルダーを小さく保つためにどのようなエマルワークフローを使用する必要がありますか？
すべてのIMAPサーバーが高速であるとは限りませんが、前述のように、効率的なIMAPの実装とセットアップを行うことができます。私は dovecot で運が良かった。ただし、offlineimapは特に遅いプログラムです。小さなテストでは問題なく動作したので、それに切り替えて、メールの設定全体をやり直して、それに依存しました。しかし、メールが多くなるほど遅くなり、最終的にはメールをチェックするたびに失望し始めました。
Notmuchのように完全にオフラインの検索エクスペリエンスが必要な場合は、 muchsync を検討できます。これは、offlineimapと同等の機能ですが、notmuchのインデックスを利用するためにnotmuchに特化しています。 muchsyncは、offlineimapが持つすべてのネットワークラウンドトリップを回避し、notmuchのインデックスデータ構造を効率的に利用するため、最初の同期を実行した後は、offlineimapよりもはるかに高速です。私はofflineimapからそれに切り替えて、とても満足しています。
考慮すべきさらに別の選択肢は isync です。私はisyncの個人的な経験はありませんが、一部の人はそれを気に入っているようです。以前にofflineimapを使用して嫌っていたので、私がmuchsyncに切り替えていなかった場合は、isyncを真剣に調査しています。
「IMAP」と言うと、IMAPサーバーの実装であるuwimapdを参照している可能性があります。その場合は、mboxが2GBを超えないようにする必要があります。つまり、すべてのメールが同じフォルダーにあり、サブフォルダーはカウントされません。
uwimapdを参照していない場合、問題はIMAPではなく、コンピュータとインターネットアップリンクのパフォーマンスにあると思います。したがって：
3か月以内のメールと、進行中のプロジェクトに属するメールのみを保持してください。残りをarchiveフォルダに入れます。 [〜＃〜] inbox [〜＃〜]と同じフォルダ構造をarchiveに作成します。 [〜＃〜] inbox [〜＃〜]で見つからない場合でも、archiveで簡単に検索できます。
IMAP（メールユーザーエージェントが（リモート）メールサーバーに格納されているメールを取得して管理するために使用するクリアテキストプロトコル）は、一度に数千のメールを処理する必要がある場合に問題になります。重要な側面は、「処理する必要がある」です。電子メールの全体的な量とサイズは、IMAP自体には問題ありません。実際に大量のメールを処理する必要がある場合に問題が発生します。
これは、たとえば、2度の同期間で数千のメールの内容やステータス（フラグ付き、未読、優先度、タイムスタンプなど）が変更された場合に発生します。 offlineimapを使用すると、ユースケースによっては、これが実際に発生する可能性があります。ただし、その場合は、より頻繁な同期が役立つ唯一の方法です。
「少し調べたところ、IMAPは非常に大きなフォルダーでの使用を意図していないようです。」
私の意見（および経験）は正反対です。 Imapには非常に高度なサーバー側検索、インデックス作成機能があります。唯一の問題は、ほとんどのメールクライアントがこれをリモートファイル処理プロトコルとして実際に使用していることです。
たとえば、IMAPを使用すると、特定のSMTPヘッダーを持つフォルダー内のメールを検索できます。または、メールの添付ファイルを本文とは別に処理することもできます。しかし、これには代償があります。プロトコルは、私が今まで見た他のどのプロトコルよりもはるかに複雑です。
Imapの真の力は、
実際のIMAPサーバーはメールにインデックスを付けることができます
メールクライアントはimapフォルダーをインテリジェントに処理できます（つまり、imapdをリモートファイルシステムとして使用せず、サーバー側でリモートクエリを使用してそのほとんどを実行します）。
私の唯一の良い経験は、Thunderbird/dovecotとのペアでした。クライアントサイドでは、kmailも比較的大丈夫で、サーバーサイドでもcyrusです。別のシステムは本当に大丈夫ではありません。
Thunderbirdでは、「サーバーで検索」クエリを実行し、仮想フォルダーとして結果を確認できます。また、サーバーサイド検索により、imapdは内部インデックスデータに基づいてキーワードベースの高速検索を行うことができます。
私はofflineimapを知りませんが、muttを知っています。クリーンなcharコンソールアプリは非常に優れており、ほとんどの場合非常に効率的ですが、例外が1つありますが、これはまさにあなたが見つけたものです。
imapsync to Alpine Linux を追加しました。 LinuxのLXCコンテナーで実行できます。 Alpineコンテナのサイズは約5mbです。
昨夜、7GBメールボックスを問題なく新しいmailserverに転送しました。 2.2メッセージ/秒の転送で約3時間かかり、プロセスはRAMの260-280mbを使用しました。 60キャッシュを有効にして5つのメールボックスを同期するには、--useuid秒かかります。