すべてのメールが同じ日付を表示する問題
IMAP移行後、ユーザーがメールボックスを開くと驚くべき光景が広がっています。すべてのメールが全く同じ日付を表示しているのです。元の送受信日の代わりに、移行が実行された日付がすべてのメッセージに表示されます。何年分もの通信が、まるで同じ日に届いたかのように見えてしまいます。
IT管理者にとって、これは悪夢です。サポートチケットが殺到し、ユーザーは日付で何も見つけられず、メールボックスの時系列履歴は事実上破壊されています。
Outlookでの表示
Microsoft Outlookでは、「受信日時」列がすべてのメールで移行日を表示します。2018年に送信されたメッセージも2023年のメッセージも、Outlookは同じ日付、つまり移行ツールがメールボックスを処理した日を表示します。受信トレイ、送信済みアイテム、すべてのフォルダが影響を受けます。日付順の並べ替えに頼っているユーザーのワークフローは完全に壊れてしまいます。
Apple Mailでの表示
macOSとiOSのApple Mailも同様の動作をします。各メッセージの横に表示される日付は、元の日付ではなく移行のタイムスタンプを反映しています。Apple MailはIMAPサーバーのメタデータを使用して表示日付を決定するため、同じ根本原因が同じ可視的結果を生み出します。受信トレイをスクロールすると、同一の日付の壁しか見えません。
Gmail(ウェブインターフェース)での表示
GmailのウェブインターフェースではやY少し状況が異なります。GmailのウェブクライアントはメールのDateヘッダーを使用するため、メッセージが正しい日付で表示される場合があります。しかしIMAP INTERNALDATEは依然として誤ったままで、そのGmailアカウントに接続するIMAPクライアント(Outlook、Thunderbird、Apple Mail)は移行日を表示します。つまり、同じメールボックスがあるクライアントでは正しく見え、別のクライアントでは間違って見えるのです。かなり混乱する状況です。
なぜ発生するのか - 技術的原因
根本原因は、IMAP移行ツールがメールヘッダーをどう処理するか、そしてメールクライアントがどの日付を表示するかをどう決定するかにあります。これを理解するには、IMAPプロトコルとヘッダー構造について簡単に見ておく必要があります。
IMAP移行ツールがヘッダーをどう処理するか
メールがあるサーバーから別のサーバーに移行される際、移行ツールはソースサーバーから生のメッセージをダウンロードし、IMAP APPENDコマンドで宛先サーバーにアップロードします。このプロセス中、IMAPプロトコルは宛先サーバーにReceivedヘッダーの追加を要求します。このヘッダーには、メッセージが新しいサーバーに挿入された時刻、つまり移行日のタイムスタンプが含まれます。
すべてを壊すReceivedヘッダー
メールメッセージには通常、複数のReceivedヘッダーが含まれており、元の配信時にメッセージを処理した各メールサーバーによって追加されます。Outlookなどのクライアントは、チェーンの最上部にある最新のReceivedヘッダーを読み取って「受信日時」を決定します。移行ツールが移行タイムスタンプ付きの新しいReceivedヘッダーを追加すると、それが最新のものとなり、メールクライアントは元の日付の代わりにその日付を表示します。
実は、これは移行ツールやメールクライアントのバグではありません。両者ともIMAPとメールの標準に正しく従っています。問題は、これらの標準が大量移行を想定して設計されていなかったことにあり、IMAP APPENDと日付表示ロジックの相互作用がこの望ましくない結果を生み出すのです。
INTERNALDATE vs Dateヘッダー
IMAPサーバーは各メッセージに対して2つの異なる日付値を保存します。Dateヘッダーはメールメッセージ自体の一部で、メッセージが最初に作成・送信された日時を記録します。INTERNALDATEはIMAPサーバーが保存するメタデータで、メッセージがその特定のサーバーに配信または挿入された日時を表します。
一部の移行ツールはAPPENDコマンド中にINTERNALDATEを設定することで元のINTERNALDATEを保持しようとします。しかしINTERNALDATEが正しく設定されていても、追加されたReceivedヘッダーは、Received日付をINTERNALDATEより優先するクライアントで依然として問題を引き起こします。
どの移行ツールがこの問題を引き起こすか
ほぼすべてのIMAP移行ツールがこの問題を引き起こす可能性があります。問題は特定のツールではなく、IMAPプロトコルに固有のものです。ただし、広く使用されているため、この問題との関連が特に多いツールがあります。
BitTitan MigrationWiz
BitTitan MigrationWizは、MSPやITコンサルタントが使用する最も人気のある商用移行ツールの1つです。MigrationWizは移行プロセス中に「mx.migrationwiz.com」を含むReceivedヘッダーを追加します。このヘッダーがチェーンの最新となり、OutlookやほかのIMAPクライアントで移行日が表示される原因となります。詳細なガイドはOutlookでのBitTitan日付修正、Microsoft 365、Google Workspace、Exchange Onlineをご覧ください。
CloudM Migrate
CloudM Migrate(旧Cloud Migrator)はGoogle Workspace移行で広く使用されています。他のツールと同様、CloudMもIMAP挿入時に独自のReceivedヘッダーを追加します。CloudMで移行されたメールは、Receivedヘッダーに依存するクライアントで移行日を表示します。ガイドはGmailでのCloudM日付修正、Outlook、Google Workspace、Microsoft 365をご覧ください。
imapsync
imapsyncはLinux管理者やホスティング事業者に人気のオープンソースツールです。imapsyncはINTERNALDATEを保持しようとしますが、宛先サーバーはAPPEND操作時にReceivedヘッダーを追加します。imapsyncのFAQはこの制限を認めていますが、移行後に追加されたヘッダーを削除するビルトインの解決策は提供していません。ガイドはOutlookでのimapsync日付修正、Gmail、Microsoft 365、Google Workspaceをご覧ください。
GSMMO(Google Workspace Migration)
Google Workspace Migration for Microsoft Outlook(GSMMO)は、ExchangeやOutlook PSTファイルからGoogle Workspaceへの移行用にGoogleが提供する独自ツールです。GSMMOも同じ日付問題を引き起こす場合があり、特に移行に中間IMAP段階が含まれる場合に発生します。ガイドはOutlookでのGSMMO日付修正、Gmail、Apple Mailをご覧ください。
Exchange管理センター(ネイティブIMAPインポート)
MicrosoftのExchange管理センターにはExchange Online(Microsoft 365)への移行用のネイティブIMAPインポート機能が含まれています。この組み込み移行ツールもインポート中にReceivedヘッダーを追加し、同じ日付表示の問題を引き起こします。ガイドはOutlookでのExchange IMAPインポート日付修正、OWAをご覧ください。
手動IMAPコピー
Thunderbirdなどのクライアントを使用してIMAPサーバー間で手動でメールをコピーした場合でも、この日付問題が発生する可能性があります。メールクライアントがIMAP経由でメッセージをコピーすると、宛先サーバーはそれを新規挿入として扱い、現在のタイムスタンプで独自のReceivedヘッダーを追加します。ガイドはOutlookでの手動IMAPコピー日付修正、Gmail、Thunderbird、Apple Mailをご覧ください。
一般的な回避策がうまくいかない理由
この問題に直面すると、ユーザーや管理者は通常、どれも本当に問題を解決しないことに気付く前に、いくつかのアプローチを試みます。
「送信日で並べ替え」では不十分な理由
最も一般的な提案は、メールクライアントで「受信」日から「送信」日のソートに切り替えることです。確かに表示順序は変わりますが、根本的なデータは修正されません。検索結果は依然として誤った日付を表示します。カレンダー連携、コンプライアンスツール、受信日に依存する自動ワークフローは引き続き正常に機能しません。そしてユーザーはすべてのデバイス、すべてのフォルダでこの設定を変更することを覚えておく必要があります。
再移行 - 高コストでリスクが高い
一部の管理者は、2回目で日付問題を回避できることを期待して移行をやり直すことを検討します。このアプローチは高コスト(メールボックス数に応じて500~5000 EUR)で、時間がかかり、リスクがあります。2回目の移行でも同じReceivedヘッダーの問題が発生し、データ損失のリスクが倍増し、大幅なダウンタイムが必要です。移行ツール自体が根本的に変更されない限り、再移行では日付問題は解決しません。
手動ヘッダー編集にはサーバーアクセスが必要
技術的には、修正には各メールから移行Receivedヘッダーを除去する必要があります。しかし手動で行うには、サーバーへの直接アクセス、メールヘッダー構造の知識、カスタムスクリプトが必要です。10,000通のメールボックスでは、手動編集は非現実的で危険なほどエラーが起きやすいです。S/MIME署名メール、PGP暗号化メッセージ、ネストされたMIME境界を持つマルチパート構造、Content-Transfer-Encodingの問題、非ASCIIヘッダー(RFC 2047)、大容量添付ファイル、それぞれが基本的なスクリプトに不可逆なデータ破壊を引き起こす可能性があります。10,000通の修正済みメールがすべて無傷であることをどう確認しますか? 専用の検証システムなしには確認できません。
本当の解決策 - 元の日付を復元する
正しいアプローチは、各メールのヘッダーチェーンから移行アーティファクトを特定し、すべてのメールクライアントで元の時系列順序を復元するターゲット修正を適用することです。単純なヘッダー編集ではありません。このプロセスには、RFCコンプライアンス検証、メッセージ構造の保持、既知のツールプロファイルのデータベースからの移行シグネチャマッチングが含まれます。
リデイト(Redate.io)による修正方法
Redate.ioはメールボックス(Google Workspace、Microsoft 365、または任意のIMAPサーバー)に接続し、移行ヘッダーの影響を受けたメッセージを特定するために各メールを分析します。分析は無料で、支払い前に正確に何通のメールが影響を受けているかを表示します。
影響を受けた各メールに対して、Redate.ioの独自修正エンジンがメッセージを多段階分析パイプラインに通します。エンジンは、大量の実際のメールデータの処理から構築された数百の既知の移行ツールプロファイルに対してシグネチャマッチングを適用します。エンコーディングの問題、マルチパート構造、インライン添付ファイル、DIYスクリプトがデータを破壊するような数十のエッジケースを処理します(月曜の朝に発見したくない類のものです)。修正された各メールは確定前に整合性検証を受けます。元のメッセージは「Redate.io - Originals」という可視フォルダに移動(削除ではなく)され、30日間保持されます。
結果は? メールがすべてのクライアントで正しい元の日付を表示します。ソートが再び機能します。メールボックスの時系列履歴が復元されます。
よくある質問
移行から数か月後でも日付を修正できますか?
はい。元のDateヘッダーは、移行がいつ行われたかに関係なく、メールメッセージ内に保持されています。Redate.ioは移行後数週間、数か月、さらには数年後でもメールの日付を修正できます。元のメールヘッダーが無傷である限り、修正は機能します。
日付の修正でメールが削除されますか?
いいえ。Redate.ioはメールを削除しません。元のメッセージはメールボックス内の「Redate.io - Originals」という可視フォルダに移動され、30日間アクセス可能な状態で保持されます。修正された各メールは、プロセスの確定前に元のメールと照合して検証されます。あるメッセージの検証が失敗した場合、元のメッセージはそのまま残ります。
共有メールボックスでも機能しますか?
はい。Redate.ioはGoogle WorkspaceとMicrosoft 365の共有メールボックスで機能します。共有メールボックスの場合、接続を承認するために管理者レベルのアクセスが必要です。プロセスは個人のメールボックスと同じで、分析、修正、検証の順で行われます。
正しい日付を復元する準備はできましたか? 無料分析を開始して、各メールボックスで何通のメールが影響を受けているかを確認してください。