横から失礼します。
【行を分割したメールヘッダ】
メールヘッダにおいて、長い一行を複数行に分割する場合(フォールディング)の規定として、2 行目以降の先頭にはスペース(全角は不可)が入ることになっていたように記憶しています。
もともとは、単語をスペース区切りで記述していく欧文の仕様に則ったものだそうですが、2 行目以降の先頭がスペースになっていることで、次行が連続したものであることを判断しているらしいです。
(そこまでやる余裕がありませんでしたが、ネットを探せば RFC などの典拠が見つかるはずです...。)
例えば、Cai さんが提示された
Cai さんが書きました:
コード:
From: =?iso-2022-jp?B?GyRCJF8kOiRbNmQ5VBsoQg==?= <mailnews@e-mail.mizuhobank.co.jp>
Subject: [=?iso-2022-jp?B?GyRCJF8kOiRbJV4lJCVsITwlOCUvJWklVhsoQl0gGyRCRkMbKEI=?=
=?iso-2022-jp?B?GyRCRTUkTiQ0TXhNUSRLJEQkJCRGIUobKEIyMDEzGyRCRy8bKEIx?=
=?iso-2022-jp?B?GyRCN24hSxsoQg==?=
の場合、3 行に分割された Subject の 2 行目と 3 行目の先頭はスペースになっているため、1 行目からつづく以下の 3 行は連続したものとして扱われることがわかります。
一方、noob さんが最初の投稿で提示された
noob さんが書きました:
Subject: [=?iso-2022-jp?B?GyRCJF8kOiRbJV4lJCVsITwlOCUvJWklVhsoQl0gGyRCRkMbKEI=?=
=?iso-2022-jp?B?GyRCRTUkTiQ0TXhNUSRLJEQkJCRGIUobKEIyMDEzGyRCRy8bKEIx?=
=?iso-2022-jp?B?GyRCN24hSxsoQg==?=
の場合、2 行目の先頭にスペースがなく、1 行目で終了していることになってしまうため、1 行目だけがデコードされたような表示になると考えられます。(2 ~ 3 行目は解釈されないデータとして宙に浮く?)
この場合、理屈の上では、スレッドペインだけでなくメッセージペインでも、件名(Subject)の表示は「[みずほマイレージクラブ] 特」だけになると考えられます。
一般的なメッセージソースの解釈ではそうですが、上記だけでは Thunderbird のスレッドペインとメッセージペインで件名(Subject)の表示が異なることの説明としては不十分です。
【Thunderbird のスレッドペインとメッセージペイン】
ご存知だと思いますが、Thunderbird のスレッドペインとメッセージペインでは、読み込んでいるファイルが異なります。
例えば、[受信トレイ] なら、
スレッドペインでは、Inbox.msf を読み込んでいます。
*.msf ファイルは、メッセージの実体の要約ファイルです。
メッセージペインでは、Inbox(拡張子なし)を読み込んでいます。
これは、メッセージの実体ファイルです。
スレッドペインに表示されるメッセージ一覧から任意のひとつを選択すると、msf ファイルの情報から実体ファイルを呼び出してメッセージペインに目的のメッセージが表示されます。
通常、msf ファイルは実体ファイルの変化にともなって適宜更新されますが、もし何らかの事情で実体ファイルからの要約情報の反映に問題が起こっているような場合、ご質問のようにスレッドペインだけで「文字化け」が起こる可能性はありえると思います。
noob さんが書きました:
そこで,文字化けしたメールを見ていると2行目の行末にスペースが4個入っていたので,
行末のスペースを削除すると,スレッドペインも正しく表示されるようになりました.
通常、メールヘッダのフォールディング(とくにエンコードされた文字列の場合)で、行末にそのように多くのスペースが挿入されることは考えにくいのですが、ご提示の状態を意図的に作り出したメッセージソースを Thunderbird に読み込ませてみると、おっしゃるようにスレッドペインでだけ同様のパターンの文字化けが起こりました。(当方の環境:Windows XP SP3 + Thunderbird 17.0.2)
しかし、比較のためにおこなった手持ちのメールクライアント(Sylpheed 、Outlook Express など)での検証では、メッセージ一覧画面でも表示画面でも文字化けは起こりませんでした。
これらの "状況証拠" から推測するかぎりでは、特定パターンのメッセージソースに対して、msf の処理に問題がある可能性が考えられるのではないでしょうか。
そもそも、エンコードされたヘッダ文字列のフォールディングで、途中行の行末に複数のスペースが挿入されていることに疑問がありますが、もし本当にそうだとしたら、その件については送信元に起因する可能性を否定できないと思います。
しかし試した範囲では、Thunderbird 以外のメールクライアントはそのような状態の件名もメッセージ一覧で正常にデコードしていますから、なにかしら Thuderbird 固有の問題があるようにも思われます。
同時に、そのような処理をしてしまう原因が、Thunderbird 本体にあるのか、導入しているアドオンにあるのか、もっと別の要因があるのか、そのあたりはさらに調べてみないと判断できないように思います。
アドオンがらみの点検では、通常はセーフモードで動作チェックをして問題の有無を確認します。
しかし、アドオンが原因で msf ファイルの書き換えに問題が発生していた場合、セーフモードで起動したからといって、異常の起こってしまった msf ファイルが正常に戻るわけではないため、セーフモードだけでは真の原因を見つけられない場合もあると思います。この点は留意しておいたほうがいいかもしれません。
解決策ではありませんが、思い当たることを書き込ませていただきました。的外れだったらすみません。