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

CloudM Migrate(旧Cloud Migrator)は、Gmail APIを使用してメールをGoogle Workspaceにアップロードします。アップロード時に、Gmailはメッセージの挿入タイムスタンプをINTERNALDATEとして記録します。メール本文内の元のDateヘッダーは移行後も残ります。しかし、IMAPクライアントがメッセージの受信日を判定するために読み取るINTERNALDATEは、移行日で恒久的に上書きされます。

CloudM移行で特にわかりにくいのは、Gmailでの二重表示の挙動です。GmailのWebインターフェースはDateヘッダーを読み取って表示するため、ブラウザではメールの日付が完全に正しく見えます。同じメールボックスをIMAP経由でOutlookで開くと、すべてのメールに移行日が表示されます。Apple Mail、Thunderbird、モバイルIMAPクライアントも同様です。Gmail Webだけを使っている人には問題が見えないため、診断が困難で、軽視されがちです。

「移行は正常に完了しました。日付も正しく表示されています。」CloudMコンソールはそう表示します。Gmailもそう表示します。しかし、ユーザーの60%はOutlookで接続しており、彼らにとっては14か月分のメール履歴が1日に圧縮されてしまったのです。

Google管理コンソール(管理 > アプリ > Google Workspace Marketplaceアプリ > CloudM Migrate)のCloudM管理画面では、この問題はフラグ付けされません。エラーも警告も、INTERNALDATEの破損に言及する移行後レポートもありません。ユーザーからの苦情が出て初めて表面化する、見えないデータ品質の問題です。

影響は、ユーザーがどのようにメールボックスにアクセスするかに完全に依存します。Gmail Web? 正常に見えます。IMAP経由のOutlook、Apple Mail、Thunderbird? すべてのメールの受信列に移行日が表示されます。この不整合は混乱したサポートチケットを生み出し、技術に詳しくないユーザーへの説明を難しくします。

表示の問題以上に、INTERNALDATEの破損はコンプライアンスとバックアップのインフラにまで及びます。Google Vaultは特定の保持および法的ホールド操作でINTERNALDATEを参照するため、日付ベースのeDiscovery検索の精度が損なわれる可能性があります。IMAP経由で接続するサードパーティのバックアップツール(Veeam、Spanning、Backupify)は移行日をメッセージの日付としてアーカイブし、復元が必要になるまで発見されない恒久的な不正確さをバックアップ記録に生み出します。

Redate.ioは、ヘッダーチェーン解析と日付メタデータの再構築により、CloudMが挿入した移行アーティファクトのみを対象として修正します。Gmail Webの表示(すでに正しく表示されていた部分)はそのままです。IMAPクライアント、Google Vault、バックアップツールのすべてが元の日付を読み取るようになります。各メッセージは処理前後に個別検証され、データ損失ゼロが保証されます。