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

imapsyncでMicrosoft 365に移行するのは合理的に聞こえます。無料で、スクリプト化でき、ほとんどのシナリオでIMAP間転送を適切に処理します。しかし、Microsoft 365では、たった一つの詳細がメールの日付を決めてしまいます。

Exchange Onlineは、渡された日付をそのまま保持します。imapsyncがIMAP経由でメッセージを書き込むとき、各メールの元の日付も一緒に渡され（--syncinternaldatesはデフォルトで有効です）、コピーはその日付を保持します。ただし、imapsyncが渡すのは、各メッセージについて元のサーバーが保持している日付であって、そのメールが送信された日付ではありません。正常なメールボックスでは、この2つは一致します。しかし、以前に一度移行された、またはバックアップから復元されたメールボックスでは、元のサーバーがその以前の操作の日付を保持している場合があり、imapsyncはそれをそのままコピーします。

これはMicrosoft 365やimapsyncのバグではありません。コピーはそれぞれ、与えられた日付をそのまま忠実に保持します。元のメールの日付がすでに間違っていた場合、500通でも500,000通を移行しても、影響を受けたメールはすべて、受信日ではなくその以前の操作の日付を表示します。

週末に実行した移行で6年分のメール履歴が1つの日付に圧縮されたとIT部長に報告する場面を想像してください。これがimapsyncでMicrosoft 365に移行した後に管理者が直面する現実です。そしてGoogle Workspace(GmailのWebクライアントが問題を隠せる)とは異なり、Microsoft 365はどこでも間違った日付を表示します。Outlookデスクトップ、OWA、Outlookモバイル、Microsoft Search。クライアント側の回避策はありません。

Microsoft 365では、被害は全面的かつ目に見えます。すべてのクライアント(Outlook for Windows、Outlook for Mac、OWA、iOSおよびAndroidのOutlookモバイル)が移行タイムスタンプを表示します。ユーザーは日付でソートできず、時系列でメールを見つけられず、日付範囲でフィルタリングする検索結果を信頼できません。80,000通のメールがすべて「2024年11月12日」を表示するメールボックスは、日常業務にとって実務上使い物にならない状態です。

コンプライアンスへの影響はさらに深刻です。Exchange Online Protection、Microsoft Purview、保持ポリシーのすべてが間違った配信タイムスタンプをインデックス化しています。7年以上経過したメールを削除する保持ポリシーは間違った日付で動作します。つまり、削除に近づいているはずの2018年のメールが、メタデータ上では2024年のものに見えます。GDPR、HIPAA、SEC規制の対象組織は、メール保持が信頼できない場合に実際の規制上のリスクに直面します。そして「2023年第3四半期のすべてのメール」を求める法的ホールド要求が来た場合、間違った日付のためにPurviewは何も返しません。メタデータ上、その期間のメールは存在しないことになっているからです。

Redate.ioはMicrosoft 365に接続し、影響を受けた各メッセージにヘッダーチェーン解析と日付メタデータ再構築プロセスを適用します。どのツールが移行を行ったかを知る必要はなく、表示されている日付が元の日付と一致しないメールを見つけ出します。各メッセージは修正・個別検証され、元のメッセージはバックアップフォルダに保存されます。メールボックスの容量に制限はなく、修正料金はスキャン結果に基づいて事前に表示されます。