English
Francais
Deutsch
Espanol
Portugues
Italiano
Nederlands
Dansk
Svenska
Norsk
Suomi
Turkce
Ellinika
Russkij
Polski
Cestina
Ukrajinska
Magyar
Romana
Bulgarski
Hrvatski
Srpski
Slovencina
Slovenscina
Lietuviu
Latviesu
Eesti
日本語
한국어
العربية
Bahasa Indonesia
すべてのメールに含まれる3つの日付
IMAPサーバーに保存されたすべてのメールは、少なくとも3つの異なる日付値を持っています。これらの日付がどう機能するか、そしてメールクライアントがどの日付を表示するかを理解することが、移行が日付を壊す理由を理解する鍵です。この記事はIMAPの日付システムを技術的に深く掘り下げたもので、IT管理者や、移行後の日付問題の根本原因を知りたい方を対象としています。
1. RFC 2822の"Date"ヘッダー
"Date"ヘッダーはRFC 2822(Internet Message Format)で定義されています。送信者のメールクライアントが、メッセージを作成して送信する時点で設定します。このヘッダーはメールメッセージ本文自体の一部であり、配信経路上のメールサーバーによって変更されることはありません。典型的なDateヘッダーは次のようになります。
Date: Mon, 15 Jan 2024 09:32:17 +0100
Dateヘッダーはメッセージの「送信日」を表します。一度設定されると変更されないため、最も信頼できる日付です。ただし送信者側の時計に依存するため、時計の設定が誤っている場合もあります。まれに、Dateヘッダー自体が存在しないケースもあります(自動送信される通知メールや、形式が不正なメッセージなど)。
2. IMAP INTERNALDATE
INTERNALDATEはRFC 3501(IMAP4rev1プロトコル)で定義されています。これはサーバー側で保持されるメタデータで、メッセージがサーバーに配信された日時を表します。Dateヘッダーとは異なり、INTERNALDATEはメールメッセージ自体の一部ではなく、IMAPサーバーが別途メタデータとして保存する値です。
メールが通常配信される場合(移行ではない場合)、IMAPサーバーは配信時点の現在時刻をINTERNALDATEとして設定します。これはDateヘッダーとほぼ一致し、通常は数秒から数分程度の差しかありません。メールクライアントは、サーバーが実際にメッセージを受信した時刻を反映するという理由から、INTERNALDATEを「受信日」として使用することがよくあります。
ここが興味深い点です。メッセージがIMAP APPENDコマンド(移行ツールが使用するコマンド)で挿入される場合、クライアントはINTERNALDATEを明示的に指定できます。設計の良い移行ツールはこの機能を使い、元のサーバーのINTERNALDATEを保持します。しかし、INTERNALDATEが正しく設定されていても、後述する「Received」ヘッダーの問題によって、多くのメールクライアントでは表示される日付が上書きされてしまいます。
3. "Received"ヘッダーの連鎖
メールがメールサーバーを通過するたびに、そのサーバーは"Received"ヘッダーをメッセージの先頭に追加します。これにより、送信者から受信者までの経路を記録するReceivedヘッダーの連鎖が作られます。最も新しい(最上位の)Receivedヘッダーは最後にメッセージを処理したサーバーを示し、最も古い(最下位の)ヘッダーは最初に処理したサーバーを示します。
通常のメールには3から6個程度のReceivedヘッダーがあり、送信者の送信サーバーから中継サーバーを経て、受信者の受信サーバーに至るまでの経路が記録されています。各Receivedヘッダーにはタイムスタンプが含まれます。簡略化した例を示します。
Received: from mx.recipient.com; Mon, 15 Jan 2024 09:32:22 +0000
Received: from relay.sender.com; Mon, 15 Jan 2024 09:32:20 +0000
Received: from smtp.sender.com; Mon, 15 Jan 2024 09:32:18 +0000
Date: Mon, 15 Jan 2024 09:32:17 +0100
メールクライアントはどの日付を表示するか
Outlook(デスクトップ、Web、モバイル)
Microsoft Outlookは、受信ボックスに表示する「受信日時」を決定する際、INTERNALDATEと最上位の"Received"ヘッダーを組み合わせて使用します。実際には、Outlookは「受信日時」列に最新のReceivedヘッダーのタイムスタンプを優先して表示する傾向があります。「送信日時」列にはDateヘッダーが使われます。Outlookは初期設定で「受信日時」列でソートされるため、ユーザーが最初に目にするのはReceivedヘッダーのタイムスタンプです。
Apple Mail
macOSおよびiOSのApple Mailは、日付表示に主にIMAP INTERNALDATEを使用します。移行時にINTERNALDATEが正しく保持されていれば正しい日付が表示される場合がありますが、それはAPPEND操作の際にINTERNALDATEが明示的に設定されていた場合のみです。移行ツールがINTERNALDATEを設定していない場合、サーバーは挿入時刻(つまり移行日)を既定値として使用します。Apple Mailへの影響の詳細はApple Mailで日付が間違って表示される問題の修正を参照してください。
Thunderbird
Mozilla Thunderbirdは最も柔軟性があります。「Date」(Dateヘッダーから)と「受信日時」(Receivedヘッダーから)の両方を表示できます。初期設定ではThunderbirdはDateヘッダーの値を表示するため、Outlookでは日付が間違っていても、Thunderbirdでは正しく見える場合があります。ただしThunderbirdの「受信日時」列には、依然として移行日が表示されます。詳しくはThunderbirdで日付が間違って表示される問題の修正を参照してください。
Gmail Webインターフェース
GmailのWebクライアントは、主要な日付表示にDateヘッダーを使用します。そのため、Gmail Webでは移行後でも正しい日付が表示されることが多くあります。しかし、GmailサーバーのIMAP INTERNALDATEは依然として誤ったままであり、そのGmailアカウントに接続するすべてのIMAPクライアントに影響します。Gmail WebとOutlookやApple Mailとの間に生じるこの差異は、混乱の原因になりやすく、管理者のトラブルシューティングに多くの時間を浪費させます。
IMAP APPENDが日付を壊す理由
移行中に何が起こるか
移行ツールがサーバーAからサーバーBへメールを移動する際、まずIMAPでサーバーAに接続し、メッセージの生データをダウンロードします。次にサーバーBに接続し、APPENDコマンドでそれを挿入します。この挿入の際、サーバーBは受信したメッセージを処理し、現在時刻(移行日)を持つ新しいReceivedヘッダーを追加します。これは多くのIMAP実装で見られる一般的な挙動です。サーバーはすべてのAPPENDを新しいメッセージ配信として扱います。
結果:汚染されたヘッダーチェーン
移行後、そのメールのReceivedヘッダーは次のようになります。
Received: from migration-tool; Fri, 11 Apr 2025 14:22:08 +0000
Received: from mx.recipient.com; Mon, 15 Jan 2024 09:32:22 +0000
Received: from relay.sender.com; Mon, 15 Jan 2024 09:32:20 +0000
Date: Mon, 15 Jan 2024 09:32:17 +0100
移行ツールのReceivedヘッダーが最上位になります。表示日付の決定に最上位のReceivedヘッダーを使用するメールクライアント(特にOutlook)は、「2024年1月15日」ではなく「2025年4月11日」を表示します。元のDateヘッダーと元のReceivedヘッダーはその下にそのまま残っていますが、メールクライアントが優先する位置ではなくなっています。
INTERNALDATEが正しく設定されていても防げない理由
一部の移行ツールは、APPEND時にINTERNALDATEを正しく設定します。例えばimapsyncは、元のサーバーのINTERNALDATEを明示的に保持します。しかしReceivedヘッダーを追加するのは宛先サーバーであり、移行ツールではありません。移行ツールはこの動作を制御できません。INTERNALDATEが完璧に保持されていても、最上位のReceivedヘッダーには移行日が残ったままとなり、Outlookなどのクライアントは誤った日付を表示し続けます。
では、実際に何ができるのでしょうか。
どの移行ツールがReceivedヘッダーを追加するか
すべてのIMAP移行ツールでこの問題が発生します。理由は、Receivedヘッダーを追加するのが宛先サーバーであり、移行ツール自体ではないためです。ただし、追加されるヘッダーの内容はツールやサーバーによって異なります。
BitTitan MigrationWizは「mx.migrationwiz.com」を含むReceivedヘッダーを追加します。CloudM Migrateは「cloudm.io」を参照するヘッダーを追加します。imapsyncは宛先サーバーによる一般的なReceivedヘッダーを発生させます。GSMMOは「gmailapi.google.com」を参照するヘッダーを追加します。
解決策:正しい日付を復元する
良い知らせは、正しい日付情報がすべてのメールの中にそのまま残っているという点です。元のDateヘッダーは無傷です。元のReceivedヘッダーも無傷です。問題は、その上に汚染するヘッダーが乗っていることだけです。
Redate.io(リデイト)の独自の修正エンジンは、影響を受けたメールごとにヘッダーチェーン全体を分析します。使用された移行ツールを問わず、メールボックス内の日付の不整合そのものを検出する仕組みにより、どのヘッダーを修正すべきかを正確に特定します。複数段階の分析パイプラインは、より単純な手法ではつまずきやすい特殊なケースにも対応します。S/MIME署名付きメッセージ、PGP暗号化コンテンツ、multipart/alternative構造、Content-Transfer-Encodingの問題、非ASCIIヘッダー(RFC 2047)、サイズの大きい添付ファイル、破損したMIME境界などです。
修正後、すべてのメールは整合性検証プロセスを通過し、メッセージ構造、本文、添付ファイルが正確に保持されていることが確認されます。オリジナルのメールは削除されることなく、メールボックス内の目に見えるバックアップフォルダに移動され、クライアントが削除するまでそこに残ります。
これを自分でスクリプトを書いて試すことはできるのでしょうか。技術的には可能です。しかし「95%のメールで動作する」ことと「メールを一件も壊さずに100%動作する」ことの違いには、何ヶ月にもわたる技術的な積み重ねが必要です。そして、対象がメールボックス全体だとすれば、その5%の失敗率は、何が起きたのかを検証する手段もないまま、数百件のメールが静かに損傷することを意味します。
自分のメールボックスにある、日付が壊れたメールの数を確認したいですか? Redate.ioで無料スキャンを実行すると、影響を受けたメールの件数をすぐに確認できます。お支払いは不要です。