メールの受信日付を変更する：技術的な限界

メールには「日付」が三つある

「メールの受信日付を変更したい」と言うとき、多くの人はWindowsでファイルの作成日を書き換えるように、どこかのフィールドを修正するだけだと思っています。実際はもう少し複雑です。メール一通には、それぞれ異なるルール、異なる管理者、そして変更した場合の異なる結果を持つ三つの日付層が存在します。

この三層を理解することで、どの修正が技術的に健全で、どれが不可能あるいは偽造として即座に検出されるのかが分かります。

層1：IMAP INTERNALDATE

INTERNALDATEは、メッセージ本体の外側にサーバー側で保存されるメタデータです。メールの内容には含まれません。IMAPサーバーが設定し、ほとんどのメールクライアントがメール一覧の並び替えに使用するのがこの値です。

例えばOutlookは、デフォルトでINTERNALDATEによってメッセージを並べます。Gmailも特定の状況では同様です。つまり、INTERNALDATEが誤っていると、メッセージ内部のヘッダーに何が書かれていようと、インターフェース上のすべてのメールが同じ日付で表示されます。

INTERNALDATEはメッセージがサーバーに置かれた時点で設定されます。IMAPプロトコル上、この値を「変更」する唯一の方法は間接的なもので、APPENDコマンドを使って希望の日付付きでメッセージの新しいコピーを置くしかありません。SETINTERNALDATEというIMAPコマンドは存在しません。このことは後で重要になります。

層2：Date:ヘッダー（RFC 2822）

これはメッセージの生ヘッダーにあるDate:フィールドです。送信時にメールクライアントが設定し、サーバーからサーバーへとメッセージと一緒に運ばれます。送信者が宣言した送信日時です。

（余談ですが、メールの生ヘッダーを見たことがない方には、少し衝撃的な光景かもしれません。一通のメッセージに、99%の人が見たことのない技術的な行が20行ほど含まれています。）

技術的には、過去あるいは未来の日付をDate:フィールドに入れてメールを送ることは防げません。SMTPサーバーはこのフィールドを検証しません。ただし、受信側のサーバーは実際の到着時刻をReceived:ヘッダーに記録するため、あらゆるメールクライアントや分析ツールで即座に確認できる不一致が生じます。

層3：積み重なるReceived:ヘッダー

SMTPサーバーがメッセージを中継するたびに、タイムスタンプ付きのReceived:ヘッダーをスタックの先頭に追加します。三つのサーバーを経由したメールには三つのReceived:ヘッダーがあります。下から上へ読みます。最も古いものが一番下、最も新しいものが一番上です。

まさにここで、移行ツールが問題を引き起こします。BitTitan MigrationWiz、CloudM、imapsync、GSMMOがメールを移行する際、IMAPを通じて新しいサーバーに再投入します。この投入によって、移行実施時刻のタイムスタンプを持つ新しいReceived:エントリーが生成されます。結果として、2019年の古いメールに2024年11月付きのReceived:が付くことになります。そして一部のメールクライアント（特にOutlook）が最新のReceived:を表示日付として使うとなると...

これが問題の全貌です。15,000通のメールがすべて同じ移行日を表示する。

これらの日付は本当に「変更」できるのか？

技術的には、INTERNALDATEは制約付きで変更できます。Date:は技術的に可能ですが意味がありません。そしてReceived:については、少し立ち止まって考える必要があります。

Received:ヘッダーの書き換えは簡単。そして即座に検出される。

Received:ヘッダーはメッセージ内のただのテキスト行です。テキストファイルと同じように編集できます。見た目どおり、それだけ単純なことです。

でも、その後に何が起きるかが問題です。

問題の一つ目：DKIM。DKIM（DomainKeys Identified Mail）署名は、場合によってはReceived:を含むメッセージヘッダーのセットから計算されます。署名済みヘッダーを変更すると署名が無効になります。DKIMを検証する受信サーバーはどれも、メッセージが改ざんされたことを即座に検出します。これは微妙な偽造ではなく、警報です。

二つ目の問題：内部識別子。Google WorkspaceやMicrosoft 365などの現代のメールサーバーは、各メッセージに単調増加するユニークな内部識別子を割り当てます。これらの識別子はINTERNALDATEと受信順序に結びついています。これらの識別子との整合性なしにReceived:を変更すると、監査ツールが難なく検出できる不整合が生じます。

三つ目の問題（より実際的なもの）：メッセージ内容のReceived:を変更しても、IMAPで投入された時点のままのINTERNALDATEには触れていません。メールクライアントは並び替えに誤った日付を使い続けます。メッセージを変更したのに何の意味もありません。

つまり。悪意ある目的でメールの日付を偽造するためにReceived:を書き換えること：技術的には簡単、専門家なら数秒で検出できます。これは現実的な手段ではありません。

Date:ヘッダー：書類上で過去を変える

Date:についても同じ理屈です。メッセージ本体で変更はできます。でも中継サーバーによって認証されたReceived:ヘッダーはそのまま残り、別の事実を語ります。時系列が矛盾します。これらのフィールドを照合するアナリストや裁判所なら即座に気づきます。

正確に言うと、.emlファイルを直接表示する場合には、一部のメールクライアントが変更されたDate:を表示することがあります。しかし認証とログを備えたライブのメールサーバー環境では、変更は透けて見えます。

IMAP移行：日付修正が正当な唯一の状況

メールの受信日付を変更することが、可能であるだけでなく技術的に正当化されるケースが一つだけあります。それは、不適切に管理されたIMAP移行によるダメージを修正することです。

具体的な状況を考えてみましょう。80個のExchangeメールボックスをMicrosoft 365に移行したとします。移行は金曜の夜に完了しました。月曜の朝、最初のチケットが届き始めます。「全メールが同じ日付になっている」「昨年のメールが見つからない」「このクライアントとのメール履歴が完全に壊れている」。80人のユーザーが立ち往生し、上司が回答を待っています。

この状況では、問題は文書化されており、識別可能で、原因も明確です。移行ツールが移行日のタイムスタンプ付きのReceived:を追加し、一部のメールクライアントがその新しいヘッダーを表示日付として使用しています。元のDate:ヘッダーは各メッセージの中に無傷のまま存在しています。変更されたことは一度もありません。正しい元の送信日時がそこに含まれています。

したがって、修正は偽造ではありません。それは復元です。真のデータ（元のDate:）から出発して、整合性のあるメタデータを再構築します。2024年のメールを2019年のメールに見せかけようとするのとは、根本的に異なります。

各ツール固有のメカニズムについて詳しくは、以下のガイドが具体的なケースを説明しています：Microsoft 365でのBitTitan日付修正、OutlookでのCloudM日付修正、あるいはGoogle Workspaceでのimapsync日付修正。

自分でスクリプトを書くべきでない理由

基本的なロジックは理解できます。IMAPフォーラムで時間を過ごしたことのあるITエンジニアなら、大まかなアプローチを再構築できます。それは問題ではありません。

問題は、50通のテストメールで動くスクリプトと、本番の40,000通を一通も失わず、添付ファイルを一つも壊さず、スレッドを一本も壊さずに処理するスクリプトとの差です。

手製スクリプトが一般的に対処できない具体的なケースをいくつか挙げます：

• S/MIME署名メール：署名は内容とヘッダーをカバーします。メッセージ構造への変更は署名を無効にします。不適切に修正された署名付きメールは、受信者側で「署名無効」として届きます。
• PGP暗号化メッセージ：同様の問題で、実装によっては結果がさらに悪化する可能性があります。
• ヘッダー内の非ASCIIエンコーディング：RFC 2047はヘッダー内の特殊文字のエンコーディングを規定しています。これらのケースを処理せずにヘッダーを操作するスクリプトは、アクセント付き文字、日本語、アラビア語の名前を含むメール件名をサイレントに破壊します。
• APIレート制限：Google WorkspaceとMicrosoft 365は積極的なスロットリングを実装しています。午前3時に、指数バックオフなしで429 Too Many Requestsエラーに衝突した10,000通のバッチ処理は、半数のメールボックスを途中の状態で放置します。
• 破損したMIME境界：添付ファイルを持つマルチパートメッセージには正確なMIME境界があります。誤って再生成すると、添付ファイルが読み取り不能になります。

そして、どんな手製スクリプトも解決できない問題があります。修正した各メールが無傷かどうか、どうやって確認するのか？40,000通を個別確認なしに変更するスクリプトは賭けです。ユーザーにとってしばしば代替不能と考えるデータへの賭けです。

移行後の日付修正に利用できる選択肢についての解説では、それぞれのアプローチとその限界を詳しく説明しています。

Redate.ioがこの状況で行うこと

リデイト（Redate.io）は、まさにこのケースのために設計されています。IMAP移行によって破損した日付を、大規模に、メッセージの整合性リスクなしに修正します。

対象のメールボックスに直接接続し（Google Workspaceはドメイン委任、Microsoft 365はAzure AD、またはダイレクトIMAP）、日付が誤っているメッセージを無料でスキャンした後、上記の限界ケースを処理する独自の修正パイプラインを適用します。修正後、各メールは個別に検証されます。オリジナルは30日間、目に見えるバックアップフォルダーに保存されます。

パターンマッチングは、BitTitan MigrationWiz、CloudM、imapsync、GSMMOおよびそれらのバリアントを含む、数百種類の既知の移行ツールのシグネチャーをカバーしています。検出は正確です。Redate.ioは日付が正しいメールには触れません。

料金体系はシンプルです。メールボックスごとの1回払い、サブスクリプションなし。診断スキャンは無料なので、何かを決める前に被害の範囲を測定できます。

この問題の影響を受けたメールボックスを管理している場合、移行後のOutlookの誤った日付に関するこの記事で最も一般的な症状と他の原因との見分け方を詳しく説明しています。

メールボックスの問題の範囲を確認する準備はできていますか？ Redate.ioで無料スキャンを開始し、修正前に何通のメールが影響を受けているかを正確に確認しましょう。