Wind さんが書きました:
macで別のメーラーを使用していましたが、クラッシュしてしまったため、Thunderbirdにこの度乗り換え作業中です。
ということは、そのアカウントは、その別のメーラーではクラッシュが起こってしまうような異常な状態であった、ということも、充分にあり得ますよね。
Thundebirdでアカウントを設定した、というのは、別のメーラーではクラッシュしてしまうような問題をひき起こしたそのアカウントなのですか?
Wind さんが書きました:
アカウント設定を行い、いざメール受信をしても画面上はメールが入ってこず、
受信ボタンを押すと、
「受信トレイ フォルダが満杯のため、これ以上メッセージを保存できません。メッセージを保存する領域を空けるには、古くて不要なメッセージを削除するか、フォルダを最適化してください。」
と表示がされました。
大量のメールを受信していることは予想がつくのですが、
画面上に何も表示されないため、
フォルダの振り分けもできず、最適化の対処も行えずにいます。
サーバーのタイプとか設定情報とか、各種の重要な情報などに関する説明などは一切なくて、エラーメッセージしか記載がないので、全て推測でしかないのですが、
雰囲気とエラーメッセージからはPOP3のように思えますし、設定は正しくできていて、受信ボタンを押せばサーバーに接続してサーバーと何らかのやり取りをしている、ということは確かに思えます。
NSPRログ(pop3ログ)をとって、どのようなやり取りが行われたかを見るのが、余計なことを無暗矢鱈にせずに済む方法でしょう。
Bug 402793 のUser Storyをよく読み、そこからポイントされている文書をよく読み、NSPRログをとる。
多分pop3だから、NSPR_LOG_MODULES=timestamp,pop3:5
テキストエディターでログファイルを見ると、
ログインの後、LISTでメッセージ番号とメールサイズ、UIDLでメッセージ番号とUIDLを入手していて、
両方で、全部のメールに対して、(メッセージ番号、UIDLの値、メールサイズ)の情報を得ていることがわかります。
pop3:5だとダウンロードしたメールデータのログもとられてログ量が大きくなりますが、今回は、メールのダウンロード(RETRをだす)が行われないケースですから、大したログ量ではないでしょう。
(pop3のコマンドについては自分でグーグル検索をしてください)
サーバーに残す設定で既にダウンロードしてある場合には、popstate.datファイルに(UIDLの値=Keep)のように記録しておき、そのUIDLの値のメールについては次回はダウンロードしないようにしています。
しかし、今回は最初のアクセスのようですから、popstate.datにはまだ何も書かれていない状態で、全てのメールをダウンロードしようとし、
従って、全てのメールサイズの合計が4GBのファイルサイズ制限以内に収まるかのチェックをするはずです。
現時点で、全てのメールサイズの合計が4GBのサイズ制限以内に収まるのですか?