CloudM Migrate:メール日付の誤りを修正する方法

誰も警告しないCloudM Migrateの日付問題

CloudM Migrateが作業を完了しました。ダッシュボードには100%完了、全ユーザー移行済み、エラーゼロと表示されています。プロジェクトチケットを閉じて、次のクライアントに移ります。

そして1週間後、IT部長から電話がかかってきます。「受信トレイのすべてのメールに4月2日と表示されているのはなぜですか?」

一部のメールではありません。すべてです。5年分のクライアントとのやり取り、法的文書、人事記録、2020年の発注書、すべてがCloudMが移行を実行した日付を表示しています。メッセージは存在し、内容は無傷で、添付ファイルも問題ありません。しかし、すべてのメールで日付が間違っています。

これはCloudMのバグではありません。CloudM自身のサポートドキュメントがこれを公然と認めています。問題は、移行ツールがメッセージを転送する方法と、宛先メールサーバーが受信メールのメタデータを処理する方法の交差点にあります。しかし、それを知っていても、受信トレイがソート不能になったクライアントの助けにはなりません。

CloudMが実際にメールメッセージを転送する仕組み

CloudM Migrateは、ソースと宛先のプラットフォームにそれぞれのAPIを通じて接続します。Google Workspaceの場合、ドメイン全体の委任を持つサービスアカウント(Google管理コンソールのセキュリティ > APIコントロールで設定)を使用します。Microsoft 365の場合、移行パスに応じてExchange Web ServicesまたはMicrosoft Graph APIを使用します。

CloudMがソースからメッセージを読み取ると、すべてのオリジナルヘッダーとメッセージ本文を含む完全なRFC 2822コンテンツを取得します。オリジナルのDate:ヘッダー(メールが最初に送信されたときに送信者のメールサーバーがスタンプしたもの)はそのまま届きます。メッセージの配送パスを追跡するすべてのオリジナルReceived:ヘッダーも同様です。

問題は宛先側で発生します。CloudMがそのメッセージをターゲットメールボックスに書き込むと、宛先サーバーはそれを新しい配送として扱います。現在の日時を含む新しいReceived:ヘッダーをスタンプし、INTERNALDATE(IMAPがソートに使用するタイムスタンプ)を挿入の瞬間に設定します。

CloudMからMicrosoft 365への移行後のヘッダーチェーンは次のようになります:

Received: from cloudm-migrate.processing.cloudm.io
    by outlook.office365.com; Wed, 02 Apr 2026 08:14:52 +0000
Received: from mail.original-company.com
    by smtp.original-company.com; Mon, 23 Sep 2019 14:07:11 +0200

2019年のヘッダーはそこにあります。オリジナルのDate:ヘッダーはまだ2019年9月23日と言っています。しかしOutlookは表示順序を決定するために最新のReceived:ヘッダーを読み取り、それは今2026年4月2日と言っています。

CloudMの"Strip Received Headers"設定

CloudMはこの問題に対処する設定を提供しています。宛先プラットフォームの詳細設定、メッセージオプションの下に、"Strip Received Headers"トグルがあります。有効にすると、CloudMはメッセージを挿入する前にreceivedヘッダーを削除し、メールのDate:ヘッダーと一致する単一のヘッダーに置き換えます。

すべてを解決するように聞こえますね。実はそうでもありません。

まず、移行を実行する前にこの設定について知っている必要があります。ほとんどの管理者は移行完了後に日付の問題を発見します。その時点でメッセージはすでに間違った日付で宛先に存在しています。この設定を有効にしてCloudMを再実行しても、重複が作成されるだけで、すでにあるものは修正されません。

次に、宛先がGoogle Workspaceの場合、この設定には重大な制限があります。Google自身のドキュメントがこれを確認しています: GmailはAPIを通じて挿入されたメッセージのReceived:ヘッダーを常に書き換え、挿入タイムスタンプをスタンプします。これはCloudMがオーバーライドできないプラットフォームレベルの制限です。"Strip Received Headers"が有効であっても、Google Workspaceは移行日付を含む独自のReceived:ヘッダーを追加します。

Microsoft 365の宛先では、理論上この設定はより適切に機能しますが、M365のトランスポートパイプラインには独自の動作があります。Exchange Onlineは、メッセージがシステムにどのように入るかによって、独自の配送処理に基づいてINTERNALDATEを設定する場合があります。

どのCloudM移行で日付が壊れるか(壊れないか)

すべてのCloudM移行が間違った日付を生成するわけではありません。結果はソースと宛先の組み合わせ、およびCloudMが使用する特定のAPIパスによって異なります:

• Google WorkspaceからMicrosoft 365: 日付が壊れます。CloudMはGmail APIを通じて読み取り、Exchangeに書き込みます。M365のトランスポート層が新しいReceivedヘッダーをスタンプします。
• Microsoft 365からGoogle Workspace: 日付が壊れます。Strip Received Headersを使用しても、GoogleのAPIはReceivedヘッダーを挿入日付で書き換えます。CloudMのサポートドキュメントはこれを「厳格なプラットフォーム制限」と呼んでいます。
• Google WorkspaceからGoogle Workspace: 日付が壊れます。ドメイン変更、テナント統合、買収合併において、宛先のGoogleテナントは受信メッセージに常に移行日付をスタンプします。
• オンプレミスExchangeからMicrosoft 365: IMAPパスでは通常壊れます。CloudMが両側でEWSを使用する場合、日付の保持はより信頼性がありますが、保証されません。
• 汎用IMAPソースから任意の宛先: 日付が壊れます。CloudMが汎用IMAPサーバーにソースとして接続すると、宛先は独自の配送ヘッダーを追加します。

厄介な部分は何でしょうか。CloudMの移行ダッシュボードはこのいずれもフラグを立てません。進行バーが満タンになり、ステータス列は「完了」と表示し、アイテム数は一致します。CloudMの観点からは移行は成功しました。そして技術的には成功しています。メッセージは転送されました。ただ日付が移動を生き延びなかっただけです。

CloudMマネージドとセルフサービス:同じ日付問題

CloudMは2つのデプロイメントモデルを提供しています。SaaS版(ホスト型CloudM Migrate)はCloudMのインフラストラクチャ内で完全に動作します。セルフホスト版では、自社ネットワーク、Google Cloud、Azure、またはAWSにプライマリおよびセカンダリ移行サーバーをデプロイできます。

一部のMSPは、移行サーバーを直接管理するため、セルフホストオプションが日付処理により多くの制御を与えると想定しています。しかしそうではありません。日付の問題はCloudMの処理ノードではなく、宛先サーバーで発生します。移行ファームがCloudMのクラウドで動作しようと、自社のAzure VMで動作しようと、宛先メールサーバーは受信するすべてのメッセージに移行日付をスタンプします。

CloudMはまた、チームがプロジェクトを最初から最後まで管理する完全マネージド型の"Serviced Migration"も提供しています。日付に関しては同じ結果です。エンジニアリングは同一で、キーボードの上の手が違うだけです。

無効なDateヘッダーの合併症

CloudM固有のもう1つの動作があり、状況をさらに悪化させます。CloudMがRFC 822に準拠しないDate:ヘッダーを持つソースメール(不正なタイムゾーン、曜日の欠落、非標準フォーマット)に遭遇すると、メッセージを移行できるようにヘッダーを修正します。

これは、一部のメールがオリジナルの日付参照さえも失うことを意味します。修正されたDate:ヘッダーは実際の送信日と全く一致しない可能性があります。CloudMのサポートドキュメントは「移行アイテムの変更の可能性」の下でこれを既知の動作として言及していますが、修正された日付が何になるかは明記していません。

8年間で蓄積された12,000通のメッセージを持つメールボックスでは、わずかに非標準のDateヘッダーを持つメールが数百通ある可能性があります(特に古いメールサーバー、自動化システム、またはタイムゾーンフォーマットの違いがある海外の送信者からのメッセージ)。CloudMの修正と宛先サーバーによるReceivedヘッダーの書き換えの後、これらのメッセージは現実とは全く関係のない日付になります。

CloudM後に手動修正がスケールしない理由

自分で修正できるでしょうか。技術的には、オリジナルのDate:ヘッダーはほとんどのメッセージに埋め込まれたままです(CloudMがRFC準拠のために修正したものを除く)。一部の管理者はCloudM移行後に日付を修正するスクリプトを書こうとしました。

そのアプローチの現実は次の通りです。潜在的に数千のメールボックスに接続する必要があり、それぞれに数千のメッセージがあります。各メールについて、完全なヘッダーチェーンを解析し、CloudMまたは宛先サーバーが追加したReceived:ヘッダーを特定し、エッジケースを処理する必要があります(ヘッダー修正が署名を破壊するS/MIME署名付きメッセージ、PGP暗号化コンテンツ、ネストされた境界を持つマルチパートMIME構造、日本語や韓国語の送信者からのRFC 2047エンコードされた非ASCIIヘッダー)。そしてこれらすべてを、添付ファイルを1つも失わず、メールスレッドを壊さずに行う必要があります。

クリーンなメールボックスからの50通のテストメールで動作するスクリプトは、10年にわたる40,000通のメッセージを持つ本番環境との接触に耐えられません。6つのネストされた添付ファイルを持つ47MBのメールに遭遇したらどうなりますか。APIレート制限(Googleのユーザーあたり毎秒250クォータユニット、Microsoftの10分あたり約10,000リクエストのスロットリング)はどうでしょうか。メッセージ番号8,347で問題が発生した場合のロールバック計画は何ですか。

そして、ほとんどの管理者が手遅れになるまで尋ねない本当の質問:修正された各メッセージが実際に無傷であることをどのように検証しますか。

Redate.ioでCloudM移行の日付を修正する

Redate.ioは影響を受けたメールボックス(Google Workspace、Microsoft 365、またはIMAP)に直接接続し、CloudMの移行日付シグネチャを持つメールをスキャンします。スキャンは無料で、メールボックスあたり数分で完了し、いかなるコミットメントの前にも影響を受けたメッセージの正確な数を表示します。

修正は、Receivedヘッダーチェーン内のCloudM固有の移行パターンを識別する独自のヘッダーチェーン分析エンジンを使用します。Redate.ioはメッセージコンテンツを変更せずにターゲットを絞ったメタデータ修正を実行し、添付ファイル、スレッド、ラベル、フォルダ、デジタル署名を保持します。修正された各メッセージは個別の検証を経て、プロセスが先に進む前にオリジナルに対するメッセージの整合性をチェックします。

オリジナルのメールはメールボックス内の表示可能なRedate.io - Originalsバックアップフォルダに30日間保管されます。ロールバックが必要な場合、オリジナルはメールボックス内にあり、外部アーカイブに埋もれていません。

クライアント環境でCloudMを使用したMSPのために、Redate.ioは1メールボックスでも500メールボックスでも、同じメッセージごとの検証でマルチメールボックス修正を処理します。CloudMが残した日付の問題がクライアントのメール環境の永続的な特徴になる必要はありません。

CloudM移行のプラットフォーム別ガイド

修正プロセスは宛先プラットフォームに適応します。Redate.ioは各プラットフォームの仕様を自動的に処理しますが、セットアップの詳細については:

• GmailでCloudM移行の日付を修正する
• OutlookでCloudM移行の日付を修正する
• Google WorkspaceでCloudM移行の日付を修正する
• Microsoft 365でCloudM移行の日付を修正する

CloudMだけでなく、すべての移行ツールでこれが起こる理由のより詳細な説明については、移行後にメールが間違った日付を表示する理由をご覧ください。

CloudMで移行してすべてのメールの日付が間違っていますか? 無料スキャンを実行して、影響を受けたメッセージの正確な数と修正費用を確認してください。