Google WorkspaceでのCloudM移行による日付破損の修正

CloudM Migrateは、特にExchange環境からGoogle Workspaceへのメールボックス移行で最も広く使われているツールの一つです。移行中、CloudMはGmail APIを通じて各メッセージをアップロードします。問題は、Googleのメール基盤がアップロードされたすべてのメッセージに対して、移行が行われた正確な瞬間のタイムスタンプを持つReceivedヘッダーを追加することです。メールが元々送信または受信された日付ではありません。

ここからが不思議な点です。GmailのWebインターフェースは表示目的で元のDateヘッダーを読み取るため、ブラウザではメールの日付が完全に正しく見えます。しかし、すべてのIMAPクライアント(Outlook、Apple Mail、Thunderbird)はINTERNALDATE値を読み取ります。その値は移行のタイムスタンプを反映しています。つまり、ユーザーの半数はまったく問題がないと報告し、残りの半数はすべてのメールが同じ日付を表示していると主張する、分裂した現実が生まれます。

これがITヘルプデスクのチケットにどう影響するか考えてみてください。管理者がブラウザでGmailを開くと正しい日付が表示され、「再現できない」としてチケットをクローズします。一方、Outlookユーザーは47,000通のメールがすべて3月15日の日付になっている画面を見つめています。Gmail WebとIMAPクライアント間のこの不一致は、CloudMからGoogle Workspaceへの移行の診断を特に困難にし、解決が数週間遅れることも珍しくありません。

影響は混乱するユーザーの問題にとどまりません。Google Workspaceの管理ツールは、ポリシー適用にINTERNALDATEを参照します。Google管理コンソールで設定された保持ポリシー、Google Vaultの法的ホールド、IMAP経由で接続するサードパーティのDLPソリューション、これらすべてが実際の日付ではなく移行タイムスタンプに基づいて動作します。3年間の保持ポリシーで削除されるべき2019年のメールが、Google Workspaceでは先月届いたと認識されているのです。

規制産業(医療、金融、法律)の組織にとって、これは単なる不便ではありません。正確なメール日付範囲に依存するコンプライアンス監査が信頼できない結果を生み出します。そして、この問題は永続します。自動修正はなく、有効期限もなく、自己修復もしません。影響を受けたすべてのGoogle Workspaceメールボックスに接続するすべてのIMAPクライアントが、基盤となるメタデータがサーバーレベルで修正されるまで、間違った日付を表示し続けます。