eM Client：PSTまたはThunderbird移行後の日付エラー

症状：すべてのメールが同じ日付になっている

eM ClientへのPSTインポートを完了したか、Thunderbirdから新しいメールボックスに移行したばかりです。インポートはエラーなく完了したように見えます。ところが受信トレイを開くと、何かがおかしい。数百件、場合によっては数千件のメールが、すべてインポートした日の日付を表示しています。2019年のメールが昨日届いたように見える。3年前に締結した契約が、今朝受信したかのように表示されている。

最初の自然な反応は、eM Clientのせいにすることです。設定が間違っている、並び替えの列がおかしい、表示バグかもしれない...。設定画面を開いて、「受信日時」と「送信日時」を切り替えてみる。何かが変わりますが、問題の本質は解決しません。

なぜなら、問題はeM Clientの中にないからです。問題はサーバー側のメタデータにあります。

真の原因：インポート時に上書きされるIMAP INTERNALDATE

何が起きているかを理解するには、IMAPプロトコルがメールをどのように保存するかを一段深く見る必要があります。

IMAPサーバー上の各メッセージには、2種類の日付があります：

• Date:ヘッダー（RFC 2822で定義）：送信者がメッセージを送信した時点でメッセージに書き込んだ日付です。メッセージ本体に埋め込まれており、理論上は変更されません。
• INTERNALDATE：メッセージ外部のサーバーメタデータで、メッセージがメールボックスに格納された日時を表します。メールクライアントがメールの並び替えや表示に優先的に使用するのは、この値です。

PSTのインポートやThunderbirdからの移行を行う際、インポートツール（eM Client本体のモジュールであれ、サードパーティ製ツールであれ、手動のIMAPコピーであれ）は、メッセージを移行先IMAPサーバーに格納します。このとき、ツールが格納のタイミングで元のINTERNALDATEを明示的に保持しなければ、サーバーは自動的に現在の日時、つまりインポートした日時をINTERNALDATEとして割り当てます。

結果：2017年からアーカイブされていた8,000件のメールが、すべて移行した日に「受信した」としてタイムスタンプされます。

（実は、eM Clientの「ソースを表示」でメールの生のヘッダーを見たことがある方は気づいているはずですが、元のDate:ヘッダーは常にそこにあり、無傷のまま残っています。これは、問題がメッセージ自体ではなくサーバーのINTERNALDATEにあることを示す証拠です。）

並び替え列を変えても意味がない理由

混乱の原因は、あまり知られていない区別にあります。eM Clientでも、OutlookでもThunderbirdでも、通常2種類の日付列が存在します：

• 「受信日時」（または「着信日時」）：サーバーのINTERNALDATEに基づく。
• 「日付」または「送信日時」：メッセージのDate:ヘッダーに基づく。

多くの管理者はこれを発見して解決策を見つけたと思います。「送信日時」に切り替えれば、eM Client上では見た目の問題が消えます。しかし、それは正確ではありません。

正確に言うと、eM Clientで送信日時順に並び替えても、同じメールボックスにアクセスしている他のすべてのクライアントやインターフェースでは問題が残ります。ユーザーがOWA、デスクトップのOutlook、モバイルのGmailアプリ、またはIMAPで設定された他のクライアントからメールを確認すると、インポートの日付が表示されます。eM Clientの並び替え設定は、eM Clientにしか適用されず、サーバー側に保存されたメタデータには影響しません。

さらに、Microsoft 365やGoogle Workspaceのネイティブウェブビューは、INTERNALDATEで並び替えを行います。クライアント側からこの動作を変えることはできません。

送信日時順の並び替えは解決策ではありません。根本的な問題を直さずに隠す応急処置にすぎません。

PSTインポートの特殊事情

PSTファイルのインポートは別途説明が必要です。PST（Personal Storage Table）はMicrosoftの独自形式で、メール、連絡先、カレンダーをローカルに保存します。eM ClientにPSTをインポートする場合、2つのシナリオが考えられます：

• IMAPアカウントへのローカルインポート：eM ClientがPSTを読み取り、メッセージを移行先IMAPサーバーにプッシュします。格納時に日付が保持されなければ、INTERNALDATEは上書きされます。これが最も一般的なケースで、日付が破損する場面です。
• ローカルフォルダーへのインポート：メッセージがサーバーを経由せずマシン上に残ります。このコンテキストではINTERNALDATEは存在せず、eM ClientはメッセージのDate:を表示できます。日付の問題は少ないですが、実用性も限られます。

Thunderbirdの場合も状況は似ています。eM Client組み込みのインポート機能（Thunderbirdのプロファイルを読み取る）を使う場合も、mboxフォルダーをIMAPでコピーした場合も、メッセージはINTERNALDATEの保持を保証されずにサーバーへ再格納されます。そして、日付の明示的な指示なしにメッセージを受け取ったサーバーは、受信した時刻で必ずタイムスタンプを付けます。

影響を受けるプラットフォーム

問題はIMAPプロトコルの標準的な動作に起因するため、移行先プラットフォームを問わず同じように発生します：

• Microsoft 365 / Exchange Online：明示的な日付パラメーターを指定したIMAP APPENDコマンドを使用しないインポートでは、INTERNALDATEが上書きされます。オンプレミスのExchangeからの移行でも同様です。
• Google Workspace：同じ動作です。eM Clientやサードパーティツールでインポートされたメールは、GmailおよびAdmin Console上でインポート日が表示されます。
• 一般的なIMAPホスティング（OVH、Infomaniak、Ionos、さくらのメールボックスなど）：APPENDでメッセージを受信する際に日付の特別処理はありません。INTERNALDATEは格納した時刻になります。

あるクライアントは、Exchange 2013からMicrosoft 365へ約100ほどのメールボックスを移行した後に問い合わせてきました。一部のVIPアカウントの移行ツールとしてeM Clientを使用した結果、MigrationWiz経由で適切に移行されたメールボックスは正常でしたが、eM Clientを経由したメールボックスはすべてインポート日付になっていたとのこと。該当ユーザーが喜ばなかったのは言うまでもありません。

自作スクリプトで簡単に解決できない理由

技術的には、IMAPプロトコルを理解している人なら、INTERNALDATEを修正するスクリプトを書けると考えるかもしれません。元のDate:ヘッダーは各メッセージの中に無傷で残っています。それを読み取ってサーバーのメタデータを再構築すればいいだけでは？

理論上はそうです。実際には、地雷原です。

まず、本番メールボックスではエッジケースがすぐに積み重なります。S/MIME電子署名されたメッセージは、構造への操作に特に敏感です。PGP暗号化メッセージも同様です。添付ファイルが大きいメール、非標準のMIME境界、通常でないContent-Transfer-Encodingのエンコードを持つメールは、処理が厳密でなければ静かに壊れてしまいます。テスト用の50件で動くスクリプトが、6年分のアーカイブを含む20,000件のメールボックスで確実に機能するとは限りません。

次に、APIクォータの管理があります。Microsoft 365のGraph APIやEWSでのレート制限は、8,000件の修正バッチを深夜3時に処理する際に管理が必要です。しかし自動では管理できません。監視なしで動くスクリプトが、3,741番目のメッセージで429 Too Many Requestsエラーに遭遇した場合、処理を続けるかもしれないし、止まるかもしれない。どのメッセージが処理済みかを正確に把握するのは困難です。

そして何より：処理後に各メールが無傷であることをどうやって確認しますか？ 自作スクリプトには通常、個別の検証メカニズムがありません。Redate.ioは各メッセージに対してこれを自動的に実行します。

Redate.ioで日付を根本から修正する

リデイト（Redate.io）は、問題が存在する場所、つまりメールクライアントのレベルではなくサーバーのメタデータのレベルで問題に対処します。

プロセスは無料のスキャンフェーズから始まります。Redate.ioは対象のメールボックスに接続し（Microsoft 365はAzure AD経由、Google Workspaceはドメイン委任経由、一般的なホスティングはダイレクトIMAP経由）、日付メタデータがメッセージの内容と一致しないメールを特定します。料金が発生する前に結果を確認できます。

修正には独自のエンジンを使用し、各メッセージの完全なヘッダーチェーンを分析します。数百種類の既知のインポートツールのシグネチャ（eM Client、Thunderbird、PSTインポートの固有の動作を含む）に対してパターンマッチングを適用し、メッセージの内容、添付ファイル、MIME構造を変更することなく、日付メタデータを標的を絞って再構築します。

修正された各メールは個別に検証されます。元のメッセージは30日間、目に見えるバックアップフォルダーに保存されます。これは自作スクリプトがデフォルトでは絶対に行わないことです。

料金はシンプルです：修正するメール数に基づいた、メールボックスごとの一括払い。サブスクリプションも継続費用もありません。詳細については開始ページをご覧ください。

次の移行の前に確認すべきこと

移行を計画していて、この問題を事前に避けたい場合、確認ポイントはシンプルです：使用するツールは、移行先サーバーへのメッセージ格納時にINTERNALDATEを明示的に保持しますか？

Microsoft 365へのPSTインポートの場合、Microsoftが認定したツール（ネイティブモードのMigrationWizやExchange Onlineの移行ツールなど）は通常この保持に対応しています。eM ClientやThunderbirdを使った手動インポートでは、それが保証されることはほとんどありません。本番メールボックスでインポートを開始する前に、ツールのドキュメントを確認してください。

適切なメール移行チェックリストには、必ずいくつかのメールボックスのサンプルに対する移行後の日付確認が含まれます。さらに詳しく知りたい場合は、メール移行チェックリストでこの点を詳しく解説しています。

クライアントの移行を定期的に担当している管理者向けには、MSPがクライアントのメール日付問題を修正する方法とIMAP INTERNALDATEの仕組みと日付が壊れる理由の記事が、問題のより全体的な視点を提供しています。

eM Clientでのインポート後にメールの日付が壊れていますか？ Redate.ioで無料スキャンを実行して、何をすべきか判断する前に問題の範囲を把握しましょう。