Exchange IMAPインポート:メール日付がずれる原因

Exchange IMAPインポートとメールの日付

Exchange Onlineはメールボックス内のすべてのメッセージに日付を付け、Outlookはその日付を表示し、並べ替えの基準にします。インターネットから届くメールの場合、それは配信された瞬間の日付です。移行でコピーされたメールの場合は、移行がそのコピーに与えた日付になります。移行が元の日付を引き渡せばその日付になり、引き渡さなければインポートした日の日付になります。

これがExchange IMAPインポート中に日付がおかしくなる原因です。Exchange Onlineは与えられた日付を上書きしません。しかしインポートが各メールの元の日付を引き渡さない場合、7年前のメッセージのコピーは、まるでたった今配信されたかのように、インポート日を受け取ってしまいます。

その結果はどうなるでしょうか。古いIMAPサーバーから4,000件のメールをExchange Onlineにインポートすると、メールは本来の日付ではなくインポート日を表示します。2018年、2020年、2023年のメールが、すべて今日の日付になります。ユーザーは月曜の朝Outlookを開き、同じ日付が並んだメールの壁を目にすることになります。

Exchange管理センターの移行ウィザードの仕組み

Exchange管理センター(EAC)には、IMAPインポート用の移行ウィザードが組み込まれています。これは多くのExchange管理者が最初に使うグラフィカルインターフェースです。[受信者]から[移行]に進んで新しいバッチを作成し、[Exchange Onlineに移行]を選択したうえでソースとしてIMAPを指定し、メールボックスの対応関係を記したCSVをアップロードしてバッチを開始します。

裏側では、EACの移行ウィザードはエンドポイントの種類をIMAPに設定したNew-MigrationBatchを作成します。ExchangeはソースとなるIMAPサーバーに接続し、各メッセージを読み取り、ターゲットのExchange Onlineメールボックスに書き込みます。理屈の上では単純な仕組みです。

しかし、管理者が実際にぶつかる問題はここにあります。Microsoftは移行が各コピーメッセージの日付をどのように設定するかを文書化しておらず、管理者からは、受信した日付ではなく同期した日付でメールが出てくるという報告が上がっています。そのメールボックスに接続するOutlook、OWA、その他すべてのクライアントは、表示と並べ替えにその日付を使います。

2019年の元のDate:ヘッダーはどうなるでしょうか。メッセージヘッダーの中に、そのまま埋もれた状態で残っています。しかしExchangeは受信トレイの並べ替え順にそれを使いません。

Date: Fri, 22 Nov 2019 16:08:33 +0100

PowerShell: New-MailboxImportRequestと同じ問題

コマンドラインを好む管理者は、PSTファイルのインポートにはNew-MailboxImportRequestを、サーバー間の移行にはIMAPエンドポイントを指定したNew-MigrationBatchをよく使います。PowerShellの方が細かく制御できると期待されがちです。実際、いくつかの点ではそのとおりです。ただ日付に関してはそうではありません。

New-MailboxImportRequestはPSTファイルをExchange Onlineメールボックスにインポートします。PSTファイルにはすべてのメッセージの元のタイムスタンプが含まれています。しかしこのPowerShellコマンドレットには、インポートされる各メッセージがどの日付を受け取るかを制御するパラメーターがありません。-PreserveDatesフラグは存在しません(本当に、管理者たちはそういうフラグを探し回っています)。

IMAPエンドポイントを指定したNew-MigrationBatch -SourceEndpointは、グラフィカルインターフェースがないだけで、EACウィザードと同じように動作します。IMAP接続は同じで、日付についての結果も同じです。このコマンドレットには日付範囲でフィルタリングするパラメーター(-StartAfter、-CompleteAfter)やフォルダーを除外するパラメーターはありますが、受信メッセージのタイムスタンプをExchangeがどう扱うかを制御するものはありません。

正確に言うと、これが主に影響するのは表示される日付と並べ替え順です。元のDate:ヘッダーを含むメッセージの内容はそのまま届きます。間違っているのはコピーに付けられた日付だけですが、ユーザーの目に見えるものすべての背後にあるのはその日付です。

直接IMAPインポートとサードパーティツール

ExchangeネイティブのIMAPインポートを使うか、BitTitan MigrationWizやCloudMのようなサードパーティツールを使うかで違いはあるのでしょうか。簡単に言うと、日付の問題はどちらの場合でも発生しますが、理由はわずかに異なります。

ExchangeネイティブのIMAPインポート(EACウィザードまたはPowerShell)では、Exchange自体がソースのIMAPサーバーに接続し、メッセージを取得します。各コピーの日付をどう設定するかはMicrosoft次第で、文書化されていません。

サードパーティツールの場合、移行ツールが中継役を務めます。ソースから読み取り、場合によってはメッセージを変換し、Exchange Onlineに書き込みます。ツールがIMAP経由で書き込むとき、Exchange Onlineはツールが渡した日付をそのまま保持します。ツールが各メールの元の日付を送信すればコピーはそれを保持し、送信しなければコピーは移行日を受け取ります。ツールによっては、中継の際に独自のReceived:ヘッダーを追加するものもあります。

実際的な違いは何でしょうか。残されるヘッダーはツールによって異なるため、修正を一つの固定パターンに頼ることはできません。根本の問題はどちらも同じです。表示されている日付がメールの元の日付ではないという点です。

Exchange Onlineのトランスポートルールが状況を悪化させる理由

経験豊富なExchange管理者でも意表を突かれることがあります。Exchange Onlineには、インポートされたメッセージに対しても発火する可能性があるトランスポートルール(管理センターでは現在「メールフロールール」と呼ばれています)があります。組織にヘッダーを付与したり、免責事項を追加したり、条件に応じてメッセージを変更したりするルールがある場合、それらのルールがインポートされたメールも処理してしまうことがあります。

つまり、2020年のメールに免責事項のフッターが追加されたり、元のメールが送られた当時は存在しなかったコンプライアンスルールによってXヘッダーが付けられたりする可能性があります。日付がおかしくなることが最も目に見える症状ですが、トランスポートルールはさらに予期しない変更を生むこともあります。

インポート中にトランスポートルールを無効にすることはできるのでしょうか。一時的には可能です。しかし、そもそもトランスポートパイプラインが移行されたメッセージを処理するとは想定していないため、ほとんどの管理者はそうしようと思いつきません。何が起きたのかに気づいた頃には、インポートバッチは完了し、 被害はすでに出ています。

間違った日付がExchange環境にとって意味すること

Exchange環境はビジネス環境であることが多いです。法律事務所、金融機関、医療機関、政府機関。これらは間違った日付が多少うっとうしいだけの個人のGmailアカウントとは違います。メールのタイムスタンプが法的、規制上の重要性を持つメールボックスなのです。

Exchangeの訴訟ホールドは日付範囲に基づいてメールを保持します。インポートされたすべてのメールが元の日付ではなくインポート日を表示している場合、ホールドは間違ったメッセージの集合を捕捉してしまいます。「2022年1月から3月までのすべてのやり取り」を検索するeDiscoveryは、それらのメールが今では2026年4月と表示されているため、何も返しません。

保持ポリシーも同じ問題にぶつかります。3年間の保持ポリシーを持つ組織は、実際には2019年のもので保存されるべきメールを、2026年のもの(つまり「新しい」もの)に見えるという理由で誤って削除してしまうかもしれません。あるいは逆に、保持ポリシーのもとで削除されるべきメールが、見かけ上の日付が新しいために残り続けてしまうこともあります。

2025年後半のある事例です。あるMSPが、EACの移行ウィザードを使ってホスト型Exchangeプロバイダーから約200個のメールボックスをMicrosoft 365に移行しました。3週間後、顧客のコンプライアンス担当者は、四半期のメールアーカイブレポートで、アーカイブされたすべてのメッセージが同じ日付になっていることに気づきました。5年分のメールアーカイブ全体が、11月のある一つの火曜日に届いたように見えていたのです。

Exchange IMAPインポート日付の修正

元のDate:ヘッダーはインポートを無傷で通過します。インポートはメッセージ内部の元のRFC 2822ヘッダーを変更しません。この元の日付が修正の基準点になります。

Redate.ioはExchange Onlineメールボックスに接続し(各利用者は自分のMicrosoft アカウントでサインインします)、IMAPインポートによって日付に異常が生じたメッセージをスキャンし、RFC準拠の検証、メッセージ構造の保持、対象を絞ったメタデータの再構成を行う独自の修正エンジンを適用します。Redateはどのツールがインポートを行ったかを知る必要はありません。表示されている日付が元の日付と一致しないメールを見つけるだけです。

修正された各メッセージは、内容の整合性、添付ファイルのチェックサム、フォルダーの配置、スレッドのつながりを含めて個別に検証されます。元のメールは、自分で削除するまで、自分のメールボックス内の見えるバックアップフォルダーに残ります。何かおかしいと感じたら、ロールバックはワンクリックで実行できます。

なぜPowerShellスクリプトで修正しないのでしょうか。Receivedヘッダーの問題を理解すること自体は簡単な部分です。50個のメールボックスにわたる8,000件のメールを、S/MIME署名付きメッセージを損なわず、入れ子になったMIME構造を崩さず、非ASCIIのRFC 2047ヘッダーを台無しにせず、フォルダーの割り当てを失わずに修正すること、これが難しい部分です。本番環境で修正された一つひとつのメッセージが無傷であること、添付ファイルが失われていないこと、スレッドのつながりが壊れていないことを、どうやって検証するのでしょうか。30件のメッセージで動くテストメールボックスで動作したスクリプトも、実際の現場のエッジケースには対応できません。multipart/alternativeのラッパーの中のmultipart/mixed構造に埋め込まれた、42MBの添付ファイルと3つのインライン画像を持つあの契約書はどうでしょう。うまくいくことを祈るしかありません。

プラットフォーム別ガイド

日付の修正はExchange Onlineメールボックスのレベルで適用されますが、利用者は異なるクライアントを通じてメールにアクセスします。それぞれ日付の表示方法が異なります。

• OutlookでExchange IMAPインポート日付を修正する
• OWAでExchange IMAPインポート日付を修正する(Outlook on the Web)

さまざまな移行ツールにわたるMicrosoft 365の日付問題について、より広い文脈をお探しですか。Microsoft 365移行後のメール日付を修正する完全ガイドをご覧ください。

Exchange IMAPインポートで、メールボックスの日付が間違ってしまいましたか? 無料スキャンから始めると、影響を受けたメールの件数と修正費用を、決済情報の入力なしで確認できます。