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

BitTitan MigrationWizは、Gmail APIまたはIMAPを通じてメールをGoogle Workspaceにアップロードします。アップロード時に、Googleのメール基盤はメッセージの挿入タイムスタンプをINTERNALDATEとして記録します。また、BitTitanは移行日付のReceivedヘッダーも追加します。メール本文内の元のDateヘッダーはそのまま残りますが、INTERNALDATEは移行タイムスタンプで上書きされ、元に戻りません。

ところで、Google Workspaceは他のプラットフォームとは異なる挙動を示します。GmailのWebインターフェースはDateヘッダーを読み取って表示するため、ブラウザでメールを見ると日付は正しく見えます。しかし、IMAP INTERNALDATEは移行日に固定されたままです。そのGoogle Workspaceアカウントに接続するIMAPクライアント(Outlook、Thunderbird、Apple Mail)はINTERNALDATEを読み取るため、元の日付ではなく移行日が表示されます。

この結果、非常にやっかいな「二重日付」問題が発生します。同じメールがGmail Webでは正しい日付を、同じアカウントに接続したOutlookでは間違った日付を表示するのです。IT管理者のもとには矛盾した報告が寄せられます。「メールは問題ありません」「メールの日付が全部おかしいです」。どちらのユーザーも正しいのですが、使っているクライアントが違うだけです。

たとえば、MigrationWizを使ってオンプレミスExchangeからGoogle Workspaceに85件のメールボックスを移行したとします。チームの半数はGmail Webインターフェースを使っていて何も問題を感じていません。残りの半数はIMAP経由でOutlookを使っており、ある月曜の朝に85件のサポートチケットが発生します。MigrationWizコンソールやGmail管理パネルでは問題が見えないため、診断に何時間もかかります。

この二重日付問題は、複数のクライアントでメールにアクセスする組織で最も深刻な影響を与えます。Gmail Webは正常に見えます。Outlookは壊れています。Apple Mailも壊れています。モバイルIMAPクライアントも壊れています。問題を隠せるのはWebインターフェースだけです。

しかし、影響は表示だけにとどまりません。Google Vault(法的ホールドやeDiscoveryに使用されるコンプライアンス・アーカイブソリューション)は、特定の操作でINTERNALDATEを参照します。日付ベースの法的証拠開示検索が不正確な結果を返す可能性があります。IMAP経由で接続するサードパーティのバックアップツールは、移行日をメッセージの日付としてアーカイブし、バックアップ記録に恒久的な不正確さを生み出します。Gmail自体のIMAP SEARCH DATEコマンドも、DateヘッダーではなくINTERNALDATEを使用します。

Redate.ioは、多段階のヘッダー解析パイプラインを通じてINTERNALDATEと移行ヘッダーを修正します。メールの本文や添付ファイルには一切触れません。Gmail Web(もともと正しく表示されていた部分)はそのままで、IMAPクライアント、Vault、バックアップツールのすべてが正しい日付を読み取るようになります。移行ツールのシグネチャに対するパターンマッチングにより、BitTitanが挿入したヘッダーのみが対象となります。