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

imapsyncはIMAP間のメールボックス移行で最も信頼されているツールです。フォルダマッピング、フラグ保持、差分同期など、多くの代替ツールを上回る機能を持っています。しかし、移行先がGmailの場合、日付保持が経験豊富なシステム管理者でも驚くほど不安定になります。

--syncinternaldatesフラグがこの問題を解決するはずです。このフラグはimapsyncに対して、APPEND時に移行元メッセージのINTERNALDATEを移行先サーバーに渡すよう指示します。標準的なIMAPサーバーでは機能します。Gmailでは? 常にうまくいくとは限りません。GmailのIMAP実装は、受信メッセージを独自の内部処理パイプライン(スパムフィルタリング、セキュリティスキャン、コンテンツインデックス化)に通します。この処理中に、Gmailが要求されたINTERNALDATEを上書きし、アップロードタイムスタンプを代わりに付与する場合があります。さらに、「gmailapi.google.com」やIMAPゲートウェイ識別子を含むReceivedヘッダーもアップロード日付で追加されます。

腹立たしいのは、これがすべてのメッセージに起きるわけではないことです。移行されたメールボックスの一部のメールは正しいINTERNALDATEを取得し、他のメールはアップロード日を取得します。明確なパターンはありません。2018年のメッセージが問題なくても、同じ日の隣のメッセージには移行日が付与されているということがあります。結果として、フォルダや時期にランダムに散らばる30〜70%のメールの日付が間違ったメールボックスができあがります。

11,000通の移行メールのうち4,200通が間違った受信日を表示し、残りの6,800通は問題ないという状況を、コンプライアンス担当者にどう説明しますか。パターンを見つけるのは至難の業です。

GmailのWebインターフェースは実は問題を隠してしまいます。Gmail WebはINTERNALDATEではなくDateヘッダー値を表示するため、影響を受けたほとんどのメールがブラウザでは正常に見えます。これは危険な偽の安心感を生み出します。移行管理者がGmail Webを確認し、正しい日付を確認してチケットをクローズするのです。

その後、ユーザーがOutlook、Apple Mail、Thunderbirdを新しいGmailアカウントに接続し始めます。これらのクライアントは日付列にIMAP INTERNALDATEを読み取ります。突然、一部のメールは移行日を表示し、他のメールは正しい日付を表示します。Gmail Webとデスクトップクライアント間の不一致が混乱したサポートチケットを生み出します。サーバー側のIMAP検索コマンド(SEARCH SINCE、SEARCH BEFORE)はINTERNALDATEを参照し、不完全または不正確な結果を返します。IMAP経由でアーカイブするサードパーティのバックアップツールは破損した日付を恒久的に記録します。Google VaultやWorkspaceコンプライアンスツールは日付ベースのホールドにINTERNALDATEを参照する場合があり、法的証拠開示に影響する可能性があります。Redate.ioの移行ツールシグネチャに対するパターンマッチングが、日付破損を示す特定のGmail Receivedヘッダーを特定し、すべてのラベル、スター、既読/未読状態を保持しながら影響を受けたすべてのメッセージに日付メタデータの補正を適用します。