Thunderbirdでの手動IMAPコピーによる日付破損の修正

Thunderbirdでは、IMAPアカウント間のメール移行が驚くほど簡単にできます。両方のアカウントを追加し、メッセージを選択して右クリック、「コピー先」。完了。ただし、移行先サーバーの日付が間違ってしまいます。Thunderbirdはこのことを警告しません。

Thunderbirdが移行先IMAPサーバーにメッセージをアップロードする際、元のINTERNALDATEを指定せずにAPPENDコマンドを発行します。移行先サーバーはそのような場合にあらゆるIMAPサーバーが行うことを実行します。アップロードタイムスタンプをINTERNALDATEとして記録し、現在の日付で独自のReceivedヘッダーを追加します。メール本文内の元のDateヘッダーはそのまま残りますが、サーバーレベルのメタデータは恒久的に上書きされます。

ここからが紛らわしい部分です。Thunderbirdのデフォルトカラムレイアウトは「日付」列を表示しますが、これはまだ正しいDateヘッダーから読み取ります。つまり、8,000件のメッセージをコピーした直後、Thunderbirdを見ると何も問題ないように見えます。日付は正常に表示されています。問題は解決? と思うでしょう。

実はそうではありません。サーバー側のINTERNALDATEが破損しています。そのINTERNALDATEは他のすべてのメールクライアントが使用するものです。同じアカウントにOutlookを接続すると、すべてのメールに移行日が表示されます。Apple Mailを開いても同じ問題です。Thunderbird自体でも「受信日時」列を追加すると、本当の被害が明らかになります。サーバー側のIMAP検索コマンド(SEARCH SINCE、SEARCH BEFORE)はDateヘッダーではなくINTERNALDATEを参照します。メール履歴はプロトコルレベルで無言のうちに壊れており、Thunderbirdのデフォルトビューがそれを隠しているだけです。

Thunderbirdのデフォルト設定では、視覚的な被害は最小限です。「日付」列はまだ正しく見えます。しかし「受信日時」列を有効にすると、破損が明白になります。コピーされたすべてのメッセージがコピー日を表示します。受信日時によるサーバー側ソートは意味不明な時系列を生み出します。Thunderbirdのクイックフィルタバーは、日付範囲でフィルタリングする際にサーバーにINTERNALDATEでクエリを実行するため、コピーされたメッセージに対して不正確な結果を返します。

本当の危険はThunderbirdを超えて及びます。同じIMAPアカウントに接続する他のクライアント(Outlook、Apple Mail、モバイルメールアプリ)は、デフォルトで間違った日付を表示します。IMAP経由でアーカイブするバックアップツールは破損したINTERNALDATEを記録します。受信日をトリガーとするThunderbirdのメッセージフィルタはINTERNALDATEを使用するため、メッセージの振り分けを誤る可能性があります。Redate.ioのヘッダーチェーン解析と日付メタデータ再構築プロセスはサーバー自体のINTERNALDATEを修正するため、その後接続するすべてのクライアント(Thunderbird、Outlook、モバイルアプリ、バックアップツール)が追加の設定なしで正しい日付を表示するようになります。