Outlookプロファイル再作成でメール日付が変わる理由

日付を壊す「定番の修復手順」

Outlookが同期しなくなったとユーザーから連絡が来る。メールが届かない、送信済みフォルダが更新されない、くるくると読み込みが続く。担当技術者はプロファイルの破損と診断し、OSTファイルを削除してOutlookプロファイルをゼロから再作成する。結果、Outlookが再接続し、メールが戻り、すべて正常に動いているように見える。

翌朝ユーザーがメールボックスを開くまでは。8年分のメールが同じ日付を表示している。今日の日付を。

これは失敗したIMAP移行とまったく同じ症状だ。そして原因も同じだ。

技術的に何が起きているか

プロファイルの再作成がなぜこの結果を引き起こすのかを理解するには、多くの技術者がよく知らない区別に立ち返る必要がある。メールのDate:ヘッダーとIMAPのINTERNALDATEの違いだ。

すべてのメールはRFC 2822ヘッダーの中にDate:フィールドを持っており、そのメッセージがいつ送信されたかを示している。このフィールドは送信者のメールクライアントが送信時に書き込み、その後すべてのサーバーを経由してあなたのメールボックスに届くまで変更されることはない。2019年3月14日09時32分に送信されたメールは、その後何が起きても常に同じDate:フィールドを持ち続ける。

IMAPのINTERNALDATEはまったく別のものだ。これはメッセージの内容とは独立した、メールサーバーが管理するメタデータだ。そのメッセージがメールボックスに「投入された」日時を示す。通常の状況では、SMTPでメールが届くとサーバーは受信日時をINTERNALDATEとして記録する。2019年3月14日に受信したメールなら、INTERNALDATEも送信日時と一致する。

Outlookはデフォルトで、メッセージ自身のDate:フィールドではなく、IMAPサーバーから送られてくるINTERNALDATEに基づいてメールを並べ替えて表示する。（ちなみに、Outlookでメールのプロパティを開いて生のヘッダーを見ようとしたことがある人なら、それが決して気軽に読めるものではないことは分かるだろう。）

OSTファイルの削除が引き起こすこと

OutlookがIMAPアカウントを使用する場合、ローカルデータベースを維持する。OSTファイル（Offline Storage Table）だ。このファイルはサーバーに保存されているメールのローカルミラーで、メタデータ、既読状態、カテゴリなどを含む。

OSTファイルを削除するということは、このローカルミラーを消去することだ。OutlookはIMAPサーバーからすべてを再ダウンロードしなければならない。

問題はここにある。OutlookがIMAPでメッセージを再ダウンロードする際、コンテンツを取得するためにFETCHコマンドを使う。しかしFETCH INTERNALDATEコマンドを使ってIMAPの元の日付を取得・保持するとは限らない。一部の設定やOutlookバージョンでは、クライアントがサーバー上に保存されているINTERNALDATEではなく、メッセージを再ダウンロードした日時を使ってローカルインデックスを再構築する。

こうして、メールボックス内のすべてのメールが再読み込みした日の日付になってしまう。

すべてのOutlookバージョンが同じ挙動をするわけではない

正確に言うと、この問題はすべてのバージョンのOutlookで同様に発生するわけではない。だからこそ診断が複雑になる。

IMAPモードのOutlook 2016および2019には、キャッシュ削除後のインデックス再構築が誤動作するという文書化された挙動がある。2023年末から段階的に展開されているWebベースの新しいOutlookはキャッシュの扱いが異なり、結果がばらつく場合がある。ExchangeモードまたはMicrosoft 365のアカウントとして設定されたOutlook経由のExchangeは、MAPI/ExchangeプロトコルがIMAPとは異なる同期方法を使うため、この特定の問題にさらされにくい。

しかし、クラシックOutlookでIMAPアカウントを使っているユーザーがいて、技術者がOSTファイルを削除またはプロファイルを再作成した場合、リスクは現実のものだ。

本当の移行との見分け方

プロファイル再作成の後に「日付がおかしい」というチケットを受け取ったIT管理者は、移行の問題だと誤解することがある。2つのケースの見分け方を説明する。

IMAP移行のケース

IMAP移行（BitTitan、CloudM、imapsyncなど）の場合、移行ツールはあるサーバーから別のサーバーへメールをコピーする。コピーされた各メッセージに対して、IMAP APPENDコマンドで宛先サーバーに新しいエントリが作成される。ツールがこのコマンドで元のINTERNALDATEを明示的に指定しない場合、宛先サーバーは現在時刻をINTERNALDATEとして記録する。さらに一部のツールは移行日時を持つReceived:ヘッダーを追加するため、特定のクライアントでは問題が悪化する。このメカニズムの詳細はIMAP INTERNALDATEと日付がおかしくなる仕組みの記事で解説している。

プロファイル再作成のケース

このケースでは、メールは同じサーバー上に元のINTERNALDATEのままある。サーバー側では何も変わっていない。問題はOutlookのローカルキャッシュが誤った日付で再構築されたことだけだ。見た目の症状は同じ（すべてのメールが最近の同じ日付を表示している）が、原因が異なる。

確認するには、ウェブメール（Gmail、Outlook.com、またはホスティング会社のウェブメールインターフェース）からメールボックスにアクセスする。ウェブメールで表示される日付が正しければ、問題はOutlookのローカル環境だけにある。ウェブメールでも日付がおかしければ、問題はサーバー側にある（移行またはサーバー上のINTERNALDATEの変更）。

元の日付が復元可能な理由

良いニュースがある。移行であれプロファイル再作成であれ、元の日付は失われていない。

RFC 2822のDate:ヘッダーはメッセージの一部だ。本文や添付ファイルと同様に不変だ。2017年に送信されたメールの生テキストには次のような行がある：

Date: Mon, 12 Jun 2017 14:23:41 +0200

この行はサーバーに保存されているメッセージの中に存在する。変更されていない。Outlookが（誤って）表示しているのは、メッセージのコンテンツとは外部にあるメタデータだ。

これが修正を可能にしている。リデイト（Redate.io）の修正エンジンは各メッセージのヘッダーチェーンを解析して本来の日付を抽出し、メッセージのコンテンツを変更することなくメタデータへの的確な修正を行う。Outlookが参照するINTERNALDATEは、メッセージ内に常に存在するこの確かな情報から再構築される。

「クリーンな再作成」という落とし穴

ユーザーの同期問題を解決したとする。Outlookは再び動き、新しいメールも届くようになった。チケットをクローズする。

3日後、そのユーザーから再び連絡が来る。去年のサプライヤーからのメールを探しているのだが、Outlookでは2023年のメールがすべて「昨日」受信したように表示されている。何も見つからない。自動アーカイブが最近のメールを古いものとして処理してしまったかもしれない。上司から2022年9月のメールのやり取りを証拠として提出するよう求められている。

このシナリオは実際によく起きる。技術者が仕事を怠ったからではなく、Outlookのこの挙動が標準的なトラブルシューティングガイドに目立つ形で記載されていないからだ。

何も解決しない「偽りの解決策」

Outlookで「受信日時」の代わりに「送信日時」でメールを並べ替えるのが、ユーザーが最初に試すことだ。うまくいくように見える...しばらくは。送信日時での並べ替えは一部のフォルダーでしか使えず、表示を変更すると消えてしまい、他のアプリ（モバイル、ウェブメール、自動振り分けルール）は引き続き誤ったINTERNALDATEを使い続ける。

送信日時での並べ替えは解決策ではない。症状を隠す絆創膏にすぎず、根本的な問題には触れていない。詳細は送信日ソートは解決策ではないの記事で説明している。

もう一度プロファイルを再作成する？Outlookのキャッシュ再構築の挙動が変わらない限り、何も変わらない。

PSTにエクスポートして再インポートする？注意が必要だ。日付がおかしくなったOutlookからPSTをエクスポートすると、おかしくなったメタデータごとエクスポートされる。PSTファイルには誤った日付が入ってしまう。そのファイルを再インポートしても何も修正されないどころか、日付が矛盾した重複メッセージが作成されて状況が悪化する可能性がある。このテーマはPSTインポート後にメール日付が今日になる原因の記事で別途扱っている。

このケースでRedate.ioが行うこと

問題がIMAP移行から来ていようとOutlookプロファイルの再作成から来ていようと、サーバー側の結果は似ている。日付メタデータが実際のコンテンツと一致していないメールが存在している。

Redate.ioはメールボックス（Google Workspace、Microsoft 365、または直接IMAP）に直接接続し、メタデータが正しくないメッセージを特定するためにすべてのメッセージをスキャンし、多段階分析パイプラインを適用して各メールを個別に修正する。すべての修正は検証される。元のメッセージは、目に見えるバックアップフォルダーに保持され、ユーザーが自分で削除するまで残り続ける。

このプロセスは自作スクリプトが必ず失敗するエッジケースに対処する。S/MIME署名付きメッセージ、ヘッダー内の非ASCIIエンコーディング（RFC 2047）を持つメール、複雑なマルチパート構造、非標準または不正形式のタイムゾーンを持つDate:ヘッダーなどだ。開発用メールボックスの50件のテストメールで正常に動作するスクリプトが、本番環境の2,000件のメッセージを取り返しのつかない形で破損させることがある。バックアップなしにメッセージを置き換えてしまったら、IMAPにはネイティブなロールバック機能は存在しない。

Outlookに特有のケースについては、Outlookでの手動IMAPコピーによる日付破損の修正のページで、メールボックスを接続してスキャンを開始するための手順を詳しく説明している。

次回の作業時に問題を防ぐために

技術者やIT管理者としてOutlookプロファイルに定期的に対応する場合、いくつかの習慣でこの状況を避けられる。

OSTファイルを削除したりプロファイルを再作成したりする前に、ウェブメールで表示されている日付を確認する。正しければ、チケットにその旨を記録しておく。再作成後、再度ウェブメールにアクセスし、Outlookで表示される日付と比較する。ずれがあればすぐに問題が特定でき、ユーザーが3日後に気づく前に対処できる。

計画的な移行については、メール移行チェックリスト：日付トラブルを防ぐ方法に、作業前後に行うべき確認事項が一覧になっている。

Outlookのプロファイルを再作成したら、メールボックスの日付がすべて変わってしまいましたか？ Redate.ioで無料スキャンを開始して、影響を受けたメールを特定し、メッセージのコンテンツに触れることなくメタデータを修正してください。