POP→IMAP移行後、古いメールが今日の日付になる原因

月曜の朝によくある光景

POP3からIMAPにアカウントを切り替えた。設定自体は簡単で、ホスティング会社のガイドに従えばスムーズに終わった。ところが受信トレイを開いた瞬間、何かがおかしい。2019年や2021年のメール、去年のアーカイブ...全部が同じ日付を表示している。今日の日付を。しかも時刻まで数秒しか違わない。

これはメールクライアントのバグではありません。タイムゾーンの問題でもありません。IMAPプロトコルの仕様通りの動作で、ローカルに保存されたメールをサーバーに転送する際には必ずこの問題が起きます。

POP3とIMAP：根本的に異なるメールの保存方式

なぜこの問題が発生するのかを理解するには、まずPOP3の仕組みを把握する必要があります。IMAPとは根本的に異なります。

POP3では、サーバーは一時的な受け取り箱にすぎません。Outlookや Thunderbird、Apple Mailといったクライアントがサーバーに接続してメールをダウンロードし、サーバー上からは削除します（設定によっては残す場合もあります）。その後、メールは完全にローカルに存在します。Outlookなら.pstファイル、Thunderbirdならローカルプロファイル、ハードディスク上のデータベースという形で。

IMAPはその逆です。メールはサーバー上に保存され、クライアントはそのリモートデータを表示するだけです。だからこそ、すべてのデバイス間でシームレスに同期できます。

問題は、この2つの間を移行するときに発生します。つまり、ローカルに保存されたPOPのメールをIMAPサーバーにアップロードする瞬間に。

IMAP APPEND：すべての原因となるコマンド

メールクライアントがローカルのメッセージをIMAPサーバーに転送する際、IMAP APPENDというコマンドを使います。このコマンドはサーバーに「このメッセージを指定のフォルダに保存してください」と伝えるものです。

サーバーはメッセージを受け取り、保存し、タイムスタンプを割り当てます。このタイムスタンプがINTERNALDATEです。IMAPの中心的なメタデータで、メッセージがサーバーに保存された時刻を示します。そしてデフォルトでは、APPENDコマンドで明示的に日付を指定しない限り、サーバーは現在時刻を使います。

つまり、メッセージのヘッダーに2018年の日付が含まれていても、誰かが「このメールは2018年のものです」とサーバーに伝えなければ、サーバーは「今転送されてきた」と判断して、今日のINTERNALDATEを割り当てます。

（実は、メールの生ヘッダーを見たことがある方なら、Date:という行が複数のReceived:行の中に埋まっているのを見たことがあるかと思います。RFC 2822で定義されたこのDate:フィールドに本来の送信日時が含まれています。ただし、IMAP INTERNALDATEはサーバー側に保存された別のメタデータであり、メッセージ本体とは無関係です。）

IMAP同士の移行とどう違うのか

BitTitan、CloudM、imapsyncなどを使った通常のIMAP間移行では、問題の性質が少し異なります。移行ツールがあるサーバーから別のサーバーにメッセージをコピーする場合、理論的にはAPPENDコマンドを通じて元のINTERNALDATEを宛先サーバーに伝えることができます。その場合の問題は、一部のツールが移行日時を含むReceived:ヘッダーを追加してしまい、Outlookなどのクライアントで日付表示がおかしくなることです。

今回のケースでは、出発点が完全なローカルデータです。コピー元のINTERNALDATEが存在しません。.pstファイルやThunderbirdのプロファイルは、独自のプロプライエタリ形式で独自の内部メタデータとともにメッセージを保存しています。メールクライアントがこれらのメッセージを読み込んでIMAPサーバーに転送する際、メッセージの内容からAPPENDコマンドを再構築します。そして多くの場合、明示的な日付は渡されません。

結果として、IMAPサーバーは数分の間に数百件または数千件のメッセージを受け取り、すべてに同じ時間帯のINTERNALDATEを割り当てます。今という時間を。

だからこそ、この問題はすべてのデバイスに瞬時に広がります。スマートフォン、タブレット、サブのパソコン...全部が同じIMAPサーバーに接続して、まったく同じ状態を見ることになります。クライアント側での修正は不可能です。

クライアントごとに何が表示されるのか

メールクライアントによって挙動が異なります。多くのIT管理者が後から気づくポイントです。

Outlook（特に2023年から2024年にかけてのアップデート以降）は「受信日時」の列にサーバーのINTERNALDATEを使用します。そのため表示されるのは元の送信日時ではなく、アップロードした日時です。Outlook固有のこの挙動については、Outlook：IMAP移行後の受信日付と送信日付の違いが参考になります。

Gmail / Google WorkspaceとThunderbirdは少し複雑な挙動を示します。Gmailの場合、メッセージヘッダーのDate:フィールドを表示に使うことがあり、一見問題ないように見えます...ところが日付で並べ替えようとすると、順番が完全にバラバラになっています。

Apple Mailは通常、ヘッダーのDate:フィールドから日付を取得して表示しますが、並べ替えや検索の内部処理ではINTERNALDATEが使われます。そのため、視覚的には正しい日付に「見える」のに、並べ替え機能が正常に動作しないという状況になります。Apple Mailの挙動の詳細は、Apple Mail：移行後のメール日付が間違っている場合をご覧ください。

良いニュース：元の日付は消えていない

各メールのDate:ヘッダー（本来の送信日時が含まれているもの）は、一切変更されていません。メッセージの中にそのまま残っています。メールを開いて詳細を確認すると、そこに表示されているものがそれです。

IMAPサーバーが「壊した」のは、メッセージ外部のメタデータであるINTERNALDATEだけです。メッセージ本体は無傷です。

これが修正を可能にする根拠です。同時に、しばらく問題に気づかない理由でもあります。メールを1通ずつ開いて見ると正しく見えるのです。受信トレイを日付順に並べたときに初めて異変に気づきます。2019年のメールが最新メールとして一番上に並び、しかも全部同じ日付になっている。

規模の問題：3通と3,000通では話が違う

「削除して、今度は正しく再インポートすればいいんじゃないか」と思うかもしれません。5通や10通のテストメールなら、確かにそれで済みます。ところが、ネストされたフォルダ、大きな添付ファイル、S/MIME署名付きメール、2015年まで遡るスレッドが混在する8,000件のメールボックスとなると、話は別です。

50通のテストバッチで動いた自作スクリプトが、本番のメールボックスで重複メールを生成したり、添付ファイルを失ったり、スレッドを壊したりすることは十分あり得ます。APIクォータの管理、ネットワークタイムアウト、MIMEの構造が特殊なメッセージ...専門でないツールが対応していないエッジケースはいくらでもあります。

途中で何かがおかしくなったら？バックアップとロールバックの仕組みがなければ、データを失っても取り戻す手段がありません。

大量移行を扱う管理者にはよく知られた問題です。なぜ日付が壊れるかを理解することと、15,000件のメールを1通も欠かさず正確に修正することは、まったく別の話です。さまざまなアプローチとその限界については、移行後のメール日付は修正できるのか？で詳しく解説しています。

Redate.ioがこのケースをどう処理するか

リデイト（Redate.io）は、まさにこのような状況のために設計されています。独自の解析エンジンが、POPからIMAPへの移行、IMAPサーバー間の移行、ローカルアーカイブの手動アップロードを問わず、INTERNALDATEとメッセージヘッダーの日付が一致していないメールを検出します。

多段階の解析パイプラインが各メッセージのヘッダーチェーンを精査し、RFC準拠の検証を行い、メッセージの内容を一切変更せずに日付メタデータを再構築します。テキストも、添付ファイルも、MIME構造も、デジタル署名も、そのままです。修正された各メールは、確定前に個別に検証されます。

オリジナルのメールは30日間、目に見えるバックアップフォルダに保持されます。何か気になることがあれば、復元できます。

最初のスキャンは無料です。Redate.ioがメールボックスを解析し、影響を受けているメールを特定して、何かを決める前に正確な件数をお知らせします。見えない状態でコミットする必要はありません。

Redate.ioはGoogle Workspace（ドメイン委任）、Microsoft 365（Azure AD）、または直接IMAPを通じてメールボックスに接続します。ローカルへのインストールは不要で、.pstファイルを手動で操作する必要もありません。

複数のメールボックスを管理する管理者で、この種のケースの実例を知りたい方は、MSPがクライアントのメール日付問題を修正する方法も参考になります。また、POP/IMAP切り替え時に独自の挙動を示すThunderbirdについての詳細は、Thunderbird移行後の日付表示エラーを修正する方法をご覧ください。

これから移行する場合：問題を未然に防ぐには

まだローカルアーカイブをIMAPサーバーにアップロードしていない場合、または組織内で他のPOPアカウントの移行を予定している場合は、以下の点を念頭に置いてください。

• お使いのメールクライアントがAPPENDコマンドで日付を明示的に渡すことをサポートしているか確認してください。たとえばThunderbirdは、このポイントについてバージョンによって挙動が異なっていました。
• まず検証用アカウントで、古いメール、添付ファイル付きのメール、署名付きメールを含む50〜100通の代表的なメッセージでテストしてください。複数のクライアントで表示される日付を確認しましょう。
• エンドユーザーが移行後のメールボックスで作業を始める前に、日付の修正を計画してください。稼働中のメールボックスで日付を修正するのは、移行直後の空のメールボックスよりも複雑です。
• 移行前後のメール件数を記録してください。サイレントなデータ消失を検出する唯一の手段です。

移行前後に確認すべき項目の完全なチェックリストは、メール移行チェックリスト：日付トラブルを防ぐ方法で網羅しています。

POP→IMAP移行後、古いメールが今日の日付になっていませんか？ Redate.ioで無料スキャンを実行して、問題の規模を確認し、メッセージの内容を一切変えずに日付メタデータを修正してください。