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

GSMMO(Google Workspace Migration for Microsoft Outlook)は、PSTファイルまたはOutlookプロファイルからGmail APIを通じてメールを直接Gmailにアップロードします。このアップロード中に、Gmailは各メッセージのアップロードタイムスタンプをINTERNALDATEとして記録します。メール本文内の元のDateヘッダーは保持されますが、サーバーレベルの日付メタデータは移行日で上書きされます。

これが紛らわしい状況を生み出します。GmailのWebインターフェースはメール本文のDateヘッダーを表示に読み取るため、ほとんどのメールがブラウザでは正しい日付で表示されます。すべてが問題ないように見えます。しかし、その裏側では、Googleのサーバーに保存されているIMAP INTERNALDATEが間違っています。これが問題になるのは、誰かがIMAPクライアント(Outlook、Thunderbird、Apple Mail)経由でそのメールボックスにアクセスした時、またはバックアップツール、コンプライアンスシステム、アーカイブソリューションがIMAP経由でメールボックスを照会した時です。

GSMMOは通常、Googleの公式移行ドキュメントに従ってMicrosoft OutlookからGoogle Workspaceに移行するエンドユーザーによって使用されます。これらのユーザーは主にGmail Webインターフェースを使用するため、数週間から数か月間問題に気づかないこともあります。そしてある日、コンプライアンスチームがGoogle Vaultで日付ベースの検索を実行したり、IT部門がMailStoreでアーカイブを設定したり、ユーザーがIMAP経由でGmailに接続したOutlookをインストールしたりします。突然、40,000通のメールがすべて半年前の同じ日付を表示します。その頃には移行は遠い過去の出来事で、根本原因の診断がパズルになります。

Gmail Webユーザーにとって、視覚的な影響は一見わずかです。ブラウザでは日付が正しく見えます。しかし、破損したINTERNALDATEは表面下に潜む時限爆弾です。GmailのIMAP SEARCH DATEコマンドはINTERNALDATEを使用するため、メールボックスに対して日付検索を行うIMAPベースのツールはすべて不正確な結果を得ます。MailStore、Veeam、IMAP経由でGmailをアーカイブするカスタムスクリプトなどのバックアップツールは、間違った日付を記録します。それらのバックアップは恒久的に不正確になります。

すべて同じ受信日を共有する50,000通のメールをソートしようとしたことがありますか? それがGSMMO移行済みメールボックスに接続するすべてのIMAPクライアントが経験することです。Outlook、Apple Mail、ThunderbirdはすべてINTERNALDATEをソートと表示に使用します。Google Takeoutのエクスポートもファイル名とメタデータにINTERNALDATEを参照する場合があり、混乱したアーカイブ構造を作成します。Google Vaultのコンプライアンス検索も、INTERNALDATEが実際のメール日付と一致しない場合に誤解を招く結果を返す可能性があります。

Redate.ioは、GSMMOの移行シグネチャを特定する多段階ヘッダー解析パイプラインでサーバーレベルの日付メタデータ再構築を行うことでこの問題を解決します。プロセスはすべてのメッセージ本文、ラベル、添付ファイルを保持しながら、日付メタデータのみを修正します。各メッセージは処理後に個別検証されます。