★今日の課題★
Thunderbirdで受信が途中で止まるメールがある。
途中で受信が止まる
今回の事象は説明が難しいです。
あるメールアカウントに対して、例えば1,000通のメールが届くとします。
その内の995通は正常に届きますが、5通に関係してトラブルが発生します。
確率で言えば0.5%、200通に1通の確率です。
下図の例で言うと、1000通の受信途中、ある段階までは正常に動作して受信ボックスにメールが貯まっていきます。
ところが、ある1通のメールで動きが止まり、放置しておくとメール受信が終わった状態になりますが、全件受信はできていません。


受信が終わったかのように見えて、まだ終わっていないからと『受信』ボタンを押して追加で取得しようとすると、下図のように『アカウント xxx@xxx は処理中です。受信処理が終了するまでしばらくお待ちください。』というメッセージボックスが表示されます。

このあとはどうなるかというと、Thunderbirdを閉じるまで何も変わりません。
いわゆる強制終了が必要です。
受信できているが、受信記録がない?
前述の状態になってThunderbirdを再起動しても、まったく無意味です。
受信ボタンを押すと受信処理は開始しますが、同じメッセージで引っ掛かります。
ある件数までは受信済なので、残っているメールの1通目で停止してしまいます。
ただし、この再起動した時点で、問題となっているメールは受信ボックスに入っています。
すなわち、前回の受信処理でThunderbirdの受信ボックスにメッセージは届いていますが、まだ受信完了とはなっていない体裁です。
同じメッセージが悪さする
そこで、最初からやり直してみました。
Thunderbirdのファイル類が入っているフォルダから『popstate.dat』を開き、中に記録されているすべてのデータを削除しました。
ヘッダーにある『POP3 State File』や『This is a generated file! Do not edit.』も気にせず削除します。
これにより、Thunderbirdがメールサーバと交信する際に、受信済のメールはありませんという信号を送りますので、サーバにある全件の受信を開始します。
今回のケースでは1,000件用意しているので、1,000件の受信を開始します。
そうすると、また同じメッセージの所でスタックします。
『popstate.dat』の在る場所ですが、Thunderbirdのアカウント設定で『サーバ設定』のタブを開くと最下段に『メッセージの保存先』というものがあり、そこに記載されています。
デフォルトだとCドライブの奥の方にありますが、筆者はDドライブに受信用フォルダを設けていますので下図のような位置にあります。

popstate.datにウソの書き込み!?
ウソではないのですが、Thunderbirdではなく私が勝手に受信済みだと書き込みました。
下図の例で言うと、受信ボックスには『X-UIDL』というものが『UID12493』というメッセージがありますが、『popstate.dat』のファイルの最後の受信メッセージは数字が1つ少ない『UID13492』です。
そこで、『UID13492』の下に1行加えて『UID13493』と書いてみました。


この『UID』とはユニーク識別子、メールサーバに収められているメッセージ1つずつに個別の記号が付与されます。
Thunderbirdで受信メッセージのUIDを確認するためには、メニューバーの『表示(V)』から『ヘッダー(H)』を選び、選択肢から『すべて(A)』を選ぶと、メッセージと一緒に表示されます。
このヘッダー表示を『すべて』にしておくと、メールの返信などでもヘッダーが引用文に表示されてしまうので、普段は『標準(N)』にしてくと良いと思います。

popstate.datの書込は姑息的回避策
手動で1行足された『popstate.dat』ですが、その状態でThunderbirdを起動して、受信してみると上手くいきました。
なぜ、その1通がスタックさせるのかわからないのですが、スタックさせる原因のメールを受信済みだと見せかける(実際には受信済)ことで、この問題を回避できました。
小さな失敗
ここにたどり着くまでに何度も失敗をしたので、受信ボックスには同じメッセージが複数ありました。
どれもメールサーバ上でのユニークID(UID)は同じなので『popstate.dat』では1行足せば処理されてしまいますが、Thunderbirdローカルの話では複数の同じメッセージが存在することになります。
ここで1つ確認できることとして、受信ボックスに入ったメールは即座にフィルターで仕分けされて、『Dammy』という別フォルダに移動するように設定していますが、それが実行されずに受信フォルダに残ったままになっているということです。
すなわち、フィルタ処理の手前でスタックしていることになります。

メッセージ自体は普通
今回、1,000通のメッセージはすべて発信源が同じ、文面もだいたい同じです。
自作したソフトから仮想人物として適当な名前で送信しているので返信先はありませんが、送信元も宛先も同じアドレスです。
すなわち、自分宛てのメールを自分で作成した1,000通です。
スタックさせるメッセージに特徴はありません。他のメッセージとよく似ています。
受信したことにしてしまえば、Thunderbirdでの表示にエラーが出るようなことはありません。
ウェブメールは正常
ブラウザからメッセージを確認できるウェブメールでは、まったく問題なく閲覧できています。
1,000通のすべてに問題がありません。
3,000通になっても問題ありません。
POP3も正常
同じメールを、別のシステムでPOP3受信しましたが、そちらでも1,000通だろうが3,000通だろうが関係なく受信できています。
再現性あるスタックメッセージ
メールサーバにはメッセージが残った状態で、Thunderbirdの『popstate.dat』を空にして、再びThunderbirdで受信してみました。
すると、先ほど問題があったメッセージで再び引っ掛かります。
『popstate.dat』を開いてみて見れば、やはりUIDが記録されていません。
姑息的作戦も再現性
別なメッセージでも姑息的な対処法は奏功しました。
先ほどは『UID12493』というメッセージでしたが、下図の例で言うと、受信ボックスには『UID13330』というメッセージがあります。
そして『popstate.dat』のファイルの最後の受信メッセージは数字が1つ少ない『UID13329』です。
そこで、『UID13329』の下に1行加えて『UID13330』と書いてみました。
これで受信すると、上手くいきます。


受信速度を変えても同じ
Thunderbirdではメッセージを受信する毎に『popstate.dat』にUIDを書き込みます。
1通ごとに実行される処理に何らかの問題があるのであれば、その問題が書き込み速度と関係しているのであれば、と思ったので通信速度を遅くしてみました。
光回線の100Mbpsを200kbpsまで500分の1まで落としているので、受信にかかる時間は相当に延長しました。
ただし、スタックする箇所は同じでした。
断定できませんが、『popstate.dat』への書き込みエラーではなく、そもそも違う問題が潜んでいると思います。


タイムアウト設定変更も同じ
Thunderbirdの『ツール』メニューから『設定』を選び、『一般』タブの一番下まで行くと『設定エディター...(C)』があります。
それを開いて『mailnews.tcptimeout』と入力するとタイムアウトの時間設定ができます。
これを色々といじってみましたが、特に変化はありませんでした。
そもそも tcptimeout が何の設定なのか、よくわかっていませんので、標準設定に戻しました。



Updateしても同じ
このときの最新版は Version 102.2.2 でした。
Windows7以降の64bit版に適用されるバージョンですので、使用環境には合っています。
再インストールしても同じ
以前、Thunderbirdのトラブルがあったときは、筆者がWindows10の64bitに、32bit版のThunderbirdをインストールしていたことが原因だったことがあります。
そのときは入替で解決しました。
そこで、今回は64bit版をアンインストールして、再び64bit版をインストールしてみました。
再インストール前に下記のフォルダも削除してみました。
[C:\Users\****\AppData\Roaming\Thunderbird]
その結果、何も変わりませんでした。
ここまででわかったこと
事実を並べると、メールサーバには1,000通のメールが存在し、それをウェブメールで閲覧すると1通目から1,000通目まですべて読める。
さらに、別のシステムでローカルコンピュータにPOP3接続でメールを受信しても、1通目から1,000通目まで滞りなく受信できる。
Thunderbirdに限って言えば、1,000通に5通くらいの確率で受信中にスタックするメールがある。
そのメールは受信できていないように見えるが、Thunderbirdを再起動してみると受信ボックスに届いている。
その届いているメールは普通に読めるものである。壊れていない。
そのメールのUIDは『popstate.dat』には記録されていないので、Thunderbirdからメールサーバへは未受信として連絡される。
未受信のまま再度チャレンジすると、またスタックする。
ところが『popstate.dat』にスタックするメッセージのUIDを書き込んで受信済としてやると、そのあとのメッセージは順調に受信できる。
ただし、また問題のあるメッセージに当たれば、同じ事が繰り返される。
この、姑息的手段により1,000通の受信を終えてしまうと、どれがスタックするメッセージなのかわからないように、すべてが普通のメッセージ(メール)として扱える。
おそらく、受信した旨を『popstate.dat』に書き込む際に何らかの問題が起きている。
その原因も、解決策もわからない。

半分は解決、そして未解決
今回は姑息的手段により、とりあえずメールを受信するということについては解決しました。
しかしながら、根本的解決には至っていないので、いつでも再発します。実際に、再発しています。
解決策が見つかったら、またご案内いたします。
最後までお読みいただき、ありがとうございました。


「Thunderbirdで受信困難例 中途半端な途中停止 ~今日の課題~」への6件の返信
初めまして、同様の現象が今月から始まり困っていました。今日初めてググってみたらこのサイトにたどり着きました。Thunderbirdはもう10年以上使っていますが初めてのことです。1時間ほど経過すると自然に治ってしまうこともありますが、確実なのはWindowsの再起動でした。今のところこれが確実で一番早い回復です。
貴重な情報ありがとうございます。
当方は再起動も再インストールも有効でない感じでしたので、この現象にはいくつかの異なる要因があるのかもしれないと思いました。
いずれにしても受信の工程の1つに問題が起きて、スタックするということには変わらないと思いますので、また現象が起きたら謎解きしてみたいと思いました。
初めまして。
102.0へのアップデートにおいて「新しい Javascript による NNTP 実装を既定で有効化。」が行われているようです。
弊社でもThunderbirdを使用しており、メールスタック現象がかなり増えておりました。
解決策としては、設定エディタにて、[mailnews.pop3.jsmodule]→falseにする。とすると以前のPOP3の処理に戻すことができます。
根本的なバグの回避にはなっていませんが、現状このようにするしかなさそうです。
ちなみにベータ版では修正されているとの噂です。
貴重な情報をありがとうございます。
海外のサイトで『Setting mailnews.pop3.jsmodule to false solved the problem.』という記述を見かけましたが、日本語版でも修正できるのか懐疑的で、試していませんでした。試してみたいと思います。
同様の事象が私も発生しましたが、こちらの書き込みを拝見させて頂いたおかげで無事受信するようになりました。
取り急ぎお礼申し上げます。
まだ事象が発生しているようですが、改修できたようで良かったです。お役に立てたようであれば、記事を書いた甲斐があります。わざわざ御礼のメッセージをありがとうございました。