ありがとうございます。
会社でリモートデスクトップ環境で運用しているのですが、
ひとつのファイルが極端に大きくなると、プロファイルを配置しているファイルサーバーのメモリ消費の問題や、
コンパクト発生によるディスク負荷の問題が大きくなりmboxからmaildirに移行しました。

メールサーバー側の容量が無制限ならimapという選択肢もあるのですが、
現状は上限があるため、pop3でローカルに保存するようにしています。
メールのデータが増えすぎて、ファイルサーバーの負荷も高いのですが、
メールデータをメンテナンスする時の運用負荷もすごく高くなってしまっています[img]https://forums.mozillazine.jp/images/smilies/icon_cry.gif[/img]
巨大なフォルダを運用したいというよりは、メールの整理をしないで良い状態にしたいというのが本音です。

Webメールに移行するか、メールアーカイブシステムの導入も検討しているのですが、
コストの問題もあり、すぐには移行できないという状況です。

Maildir関係のメタバグの [url=https://bugzilla.mozilla.org/show_bug.cgi?id=859011]bug 859011[/url] を開いたものです。

一言でいうと、まだ開発途中の新機能ですから、ユーザー同士の助け合いの為のフォーラムは不適切であり、自力でBugzillaにバグを開いて問題をきちんと報告してデベロッパーに修正のコードを作ってもらう必要があります。

メタバグのBug 859011に掲載されているバグの大半が解決して、もういいだろう、と、甘く見て、一度、Maildirに設定するUIをリリース版に入れてしまい、安易にMaildirに設定してしまったユーザーからの問題報告が相次ぎ、それであわてて次のリリースでそのUI
を殺した、という経緯があります。

ある環境で、Maildirでフォルダーの修復が同時に発生した時、2000メールフォルダーまでならば仮想メモリーが足りるが、4000メールフォルダーあたりになると、おそらくOOMでクラッシュ、というような現象に聞こえます。
単純に「メモリーリーク」というのでは無くて、使い終えたファイルハンドル用のメモリーの開放速度よりも、新たなファイルハンドルの要求の速度の方が大きい、といったことのような気がします。
ABCというフォルダーで、中にnnnメールがあれば、
最低限、ABC.msf、ABC(ディレクトリー)、curディレクトリーの下のnnn個のメールデータファイル、のオープン・クローズが入ります。
4000フォルダーあれば、4000 x nnn 個のファイルハンドルが使われます。
そして、ファイルハンドル用のメモリーは、ファイルハンドルの使用をやめた（クローズした）からといって、直ぐに解放されるわけではない。

Maildirの利点は、
(A)４GBの制限がない、
(B)コンパクト(フォルダーの圧縮)が発生しない。
IMAPのOfflineStoreでは、とっくの昔に、4GBの制限は無くなっていてますし、BerkleyStoreでも、52か53か55あたりで4GBの制限がなくなるはずだから、単に、4GBだけの為にMaildirを使う、という必然性は、無くなっています。
IMAPの場合、無理矢理(B)にしてしまったものだから、コンパクトの時にexpungeを送る、という道が閉ざされてしまい、ある場面においては、使い物にならない、という大問題があるのですが、いつまで経っても改善してくれない。

そんな巨大なメールフォルダーを沢山作るのが趣味でなければ、
全てのアカウントがPOP3で、IMAPがらみのいやらしいこともなさそうですし、
(A) 全てのメールフォルダーを、BerkleyStoreに戻す。
(B) どうしてもMaildirが必要な場合は、ダミーのPOPアカウントを作り、それを「疑似ローカルフォルダアカウント」として使い、巨大なフォルダーでコンパクトが発生してほしくないものだけをその下に置く。
といった、運用の工夫をした方が、利口だと思います。
関連づけられたアイデンティティ(差出人情報)を持たない、という、「ローカルフォルダー」という特殊な疑似アカウントよりも、アカウントの削除なども可能な、ダミーサーバーのPOP3アカウントの方が、管理しやすいと思います。
他のアカウント⇒ローカル専用アカウント、の一方通行にして、
そのローカル専用アカウントの中だけで、数少ない巨大なメールフォルダーでメールデータを管理する、
といった感じにして、
各POP3アカウントは単なるメールのダウンローダーとして使う、というふうにすれば、
各POP3アカウントにおける巨大なBerkleyStoreのメールフォルダーファイルを避けられます。

メッセージフィルター、タグ、検索フォルダー、ビュー(絞り込み)などを上手に使えば、べらぼうな数のメッセージフォルダー、というようなのは、避けられます。
また、berkleyStoreならば、10万メールであろうが１ファイルで済むわけですし、メール数が少ない・ファイルサイズが小さいメールフォルダーならばコンパクトによる影響は非常に少ないですし、適材適所、という考えた方もあります。

ご参考までに。
、

<環　境>
バージョン: 52.2.1
ユーザーエージェント: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1
プロトコル：pop3
保存形式：maildir
クラッシュレポート： https://crash-stats.mozilla.com/report/index/bp-344a0b61-13dd-412f-8714-4e45f0170901

お世話になります。
受信したメールが、しばらくするとフォルダ一覧に表示されなくなる問題が頻繁に発生しており、
フォルダの修復をしたのですが、フォルダ件数が4000件ほどあると、
修復が終わらず、Thunderbirdがクラッシュします。

タスクでメモリの状態を観察しながら修復をかけると、
Thunderbirdのメモリ使用量がどんどん増えていき、1.7GBに達すると動作が不安定になり、
Thunderbirdを閉じたときにクラッシュレポートが表示されます。
2000件程度のフォルダなら修復が終了しますが、修復中に増加したメモリが開放されず、
複数のフォルダを続けて修復すると、件数が少ない場合であっても、同様にクラッシュします。

なお、フォルダ一覧に表示されなくなったメールは、修復が成功すると表示されます。

回避方法はないでしょうか？
よろしくお願いいたします。