Thunderbird移行後の日付表示エラーを修正する方法

Thunderbirdのメール日付処理方法

Mozilla Thunderbirdは最も人気のある無料メールクライアントの1つで、Outlookの代替としてオープンソースを好む個人や組織に広く使用されています。Thunderbirdの日付表示方法は他のメールクライアントより柔軟ですが、これが移行時の日付問題が発生した際には利点でもあり、混乱の原因にもなります。

Thunderbirdの2つの日付列

Thunderbirdは「日付(Date)」と「受信日時(Received)」という2つの日付値を区別します。「日付」列はRFC 2822のDateヘッダーの値、つまり送信者が設定したタイムスタンプを表示します。「受信日時」列は、IMAPサーバーのメタデータ(INTERNALDATE)とメッセージ内のReceivedヘッダーから導かれた日付を表示します。

Thunderbirdはデフォルトで「日付」列(送信日)を表示します。つまり、移行直後はDateヘッダーが保持されているため、Thunderbirdユーザーは日付の問題に気づかないことがあります。しかし「受信日時」列はすべてのメールについて移行日を表示します。表示を「受信日時」列に変更していたり、受信日でソートしているユーザーは、間違った日付を目にすることになります。

「受信順」ソートと「日付」ソートの違い

Thunderbirdには別々のソートオプションがあります。「日付」(Dateヘッダーでソート)と「受信順」(受信タイムスタンプでソート)です。「日付」でソートすると正しい時系列になります。一方「受信順」でソートすると、移行されたメールがすべて移行日にまとめられ、時系列が崩れてしまいます。

多くのユーザーは、これらが異なるソートオプションであることに気づいていません。

Thunderbirdの「日付」列は本当の解決にならない理由

検索にも影響が出る

Thunderbirdの検索は日付範囲で絞り込むことができます。例えば「2024年1月に受信したメール」を検索すると、Thunderbirdはサーバー上の受信日時メタデータを使用し、Dateヘッダーは使用しません。移行後は、この検索で2024年1月のメールが1件も表示されず、代わりに移行日のメールがすべて表示されてしまいます。特定の四半期の請求書を探す会計担当者や、案件期間中のやり取りを集める弁護士など、日付範囲で頻繁に検索するユーザーにとっては、メールボックスが実質的に使えない状態になります。

メッセージフィルターと保存済み検索

Thunderbirdのメッセージフィルターは日付条件に基づいて動作します。「受信日時」や「経過日数」を参照するフィルターは、移行後に誤作動します。日付条件を使う保存済み検索(仮想フォルダ)も同様に影響を受けます。

同じアカウントを使う他のIMAPクライアント

Thunderbirdユーザーが「日付」列に切り替えたとしても、根本的な問題はサーバー上に残っています。同じメールボックスにOutlookやApple Mail、モバイルアプリ、Webメールなど他の手段でアクセスすると、間違った日付が表示されます。この問題はクライアント側ではなく、サーバー側にあるのです。

Thunderbirdでヘッダーを確認する方法

Thunderbirdのヘッダー表示機能を使う

Thunderbirdではメールヘッダーを簡単に確認できます。対象のメールを開き、「表示」から「メッセージのソース」を選択します(またはCtrl+Uを押します)。これでメッセージ全体の生データが表示されます。「表示」から「ヘッダー」、「すべて」を選ぶと、展開されたヘッダー表示も確認できます。

移行時に追加されたReceivedヘッダーを見分ける

生のメッセージソースでは、上部にある「Received」ヘッダーを確認します。最も上にあるReceivedヘッダーが最後に追加されたもので、移行後であればこれは移行ツールが追加したヘッダーです。通常、移行日と一致するタイムスタンプが含まれており、移行ツール名が明示されている場合もあります(例えばBitTitanの場合は「mx.migrationwiz.com」、CloudMの場合は「cloudm.io」、GSMMOの場合は「gmailapi.google.com」など)。

この移行ヘッダーの下には、元のReceivedヘッダーがそのまま残っています。元のDateヘッダーも保持されています。つまり正しい日付情報はまだ存在しており、あとはそれを復元するだけなのです。

クライアント側の対処法が効かない理由

問題はサーバー側にある

Thunderbirdの設定を変更するだけの対処法は、あくまでクライアント側の変更であり、Thunderbirdの画面表示にしか影響しません。サーバー上の実際のメールデータには、依然として移行時のReceivedヘッダーが含まれています。つまり、他のデバイスやクライアントでは間違った日付が表示され、サーバー側検索は誤った結果を返し、コンプライアンスやアーカイブツールも間違った日付を取得し、バックアップツールも誤った日付を記録してしまいます。永続的な解決策は、サーバー自体のデータを修正することだけです。

Thunderbirdのアドオンでは解決できない

Thunderbirdの拡張機能システムは強力ですが、どのアドオンもIMAPサーバー上のメールヘッダーを変更することはできません。アドオンでローカルの日付表示を変える程度のことは可能かもしれませんが、それはその特定のパソコン上のThunderbirdにしか影響しません。では、実際の解決策は何でしょうか。

サーバーレベルでThunderbirdの日付を修正する

Redate.ioによる修正の仕組み

Redate.io(リデイト)はメールサーバー(Google Workspace、Microsoft 365、あるいはZimbraやZohoを含む任意のIMAPサーバー)に接続し、サーバー上で影響を受けた各メールを直接修正します。

Redate.ioの独自の修正エンジンは、日付の異常を手がかりに影響を受けたメッセージのヘッダーチェーン全体を解析します。特定の移行ツールに依存しないため、どの移行ツールを使った場合でも検出できます。多段階の解析プロセスでは、DIYのアプローチでは対処が難しいケース、例えばS/MIME署名付きメッセージ、PGP暗号化されたコンテンツ、入れ子構造のマルチパート、非ASCIIヘッダー、Content-Transfer-Encodingのばらつきなどにも対応します。修正後には整合性検証が行われ、すべてのメッセージが正常な状態であることを確認します。元のメッセージは削除されず、メールボックス内の可視のバックアップフォルダに移動され、クライアントが削除するまでそこに残ります。

修正が完了すると、Thunderbirdはサーバーと同期し、修正済みの日付を取得します。「日付」列と「受信日時」列の両方が正しい値を表示するようになります。日付範囲での検索も正しく機能し、受信日に基づくフィルターや保存済み検索も期待通りに動作します。

自分でスクリプトを書いて対応することはできるでしょうか。もちろん可能です。しかし、8000件の修正済みメールすべてで添付ファイルが正常か、スレッド構造が保持されているか、MIME構造が有効かをどのように検証するのでしょうか。この検証こそが、DIYのアプローチが破綻する部分です。

Thunderbirdで修正結果を確認する

Redate.ioによる修正が完了したら、フォルダ一覧でアカウントを右クリックし、「登録」を選択してダイアログを閉じるか、フォルダを圧縮することで、Thunderbirdに強制的に再同期させます。Thunderbirdはサーバーから更新されたメッセージヘッダーをダウンロードします。「受信日時」列には、元の受信日が表示されるはずです。

よくあるThunderbird移行のシナリオ

移行ツールとしてThunderbirdを使う場合

よくあるシナリオの1つは、Thunderbird自体を移行ツールとして使うケースです。管理者がThunderbird上で移行元と移行先のIMAPアカウントを両方設定し、あるアカウントから別のアカウントへメールをドラッグして移動します。この方法でも「メールは移動できる」という意味では機能しますが、移行先のサーバーはコピーされたすべてのメッセージにReceivedヘッダーを追加し、コピーした日付を記録してしまいます。詳しくはThunderbirdでの手動IMAPコピーによる日付修正ガイドを参照してください。

サーバー側での移行後のThunderbird

移行がサーバーレベルで行われる場合(BitTitan、CloudM、imapsyncなどのツールを使用)、Thunderbirdユーザーも他のIMAPクライアントと同様に影響を受けます。移行日は「受信日時」列に表示され、「日付」列は正しいままの場合があります。Thunderbirdは2つの日付列を持つため問題が見えにくくなることがあるので、管理者は特にThunderbirdでの日付確認を行うべきです。

Thunderbirdで移行後に間違った日付が表示されていますか? Redate.ioで無料スキャンを開始すると、影響を受けたメールを特定し、すべてのメールクライアントで正しい日付を復元できます。