cPanel移行後のメール日付ずれ

月曜の朝、最悪の展開

cPanelの共有ホスティングからGoogle WorkspaceかMicrosoft 365への移行が完了した直後のことです。作業はうまくいった。メールボックスにアクセスできる。ユーザーもログインできている。そして9時15分、最初のチケットが届きます。「古いメールが全部同じ日付になっています。先週末の日付で。」次に2件目。気づけば10件。

これは孤立したバグではありません。cPanelからの移行がメールの日付メタデータをどう扱うか（というより、いかに扱わないか）によって生じる、直接的な結果です。

cPanel・Roundcube・Horde：特殊なIMAP環境

cPanelの共有ホスティングは、RoundcubeかHordeをウェブメールとして動かすDovecotベースのLinux IMAPサーバーです。特に変わった構成ではありません。ただ、エンタープライズプラットフォームへの移行を思ったより厄介にするいくつかの特徴があります。

まず、cPanelのメールボックスは何年も、場合によっては10年以上にわたってメールを蓄積していることが多い。2013年から共有サーバーでドメインを運用していたクライアントは、かなり深いアーカイブを持っているはずです。このボリュームと移行方法の組み合わせが、日付問題の温床になります。

次に、これらの移行で使われるツールは大抵、WHMのネイティブ移行ツール、ホスティング会社やITベンダーがコマンドラインで実行するimapsync、あるいはGoogle Workspace向けのGSMMOといった一般向けソリューションのいずれかです。

cPanel移行後に日付が壊れる理由

問題を理解するには、二つの異なる概念を把握する必要があります。メールのDate:ヘッダーとIMAP INTERNALDATEです。

Date:ヘッダーは、送信時にメッセージの本文に書き込まれるもので、RFC 2822に準拠しています。メールがいつ作成・送信されたかを示します。このヘッダーは、意図的にメッセージを改ざんしない限り変わりません。

一方、INTERNALDATEはIMAPサーバーが各メッセージに関連付けるメタデータで、メッセージ本文とは独立しています。通常の受信時には、Received:ヘッダーに基づいてINTERNALDATEが設定されます。OutlookやThunderbirdをはじめ多くのメールクライアントが、メッセージの並び替えにこの値を使います。

IMAP移行では、メッセージをサーバー間でコピーします。問題は、移行ツールが宛先サーバーに各メッセージを新規作成しなければならないこと。多くのツールでは、新規作成されたメッセージのINTERNALDATEが元のメッセージの日付ではなく移行実行日になります。さらに、移行日のタイムスタンプを持つReceived:ヘッダーがヘッダーチェーンの先頭に追加され、そこを参照して表示日付を計算するメールクライアントをさらに混乱させます。

結果、2019年のメールがGoogle Workspaceには移行日のINTERNALDATEと昨日付けのReceived:ヘッダー付きで届きます。Outlookはそれを今届いたメールとして受信トレイに表示する。アーカイブの時系列が完全に破壊されます。

WHM / cPanelの移行ツール

WHMに統合された移行ツールは、宛先が外部IMAPサーバー（Google Workspace、Microsoft 365）の場合、ほぼ確実にこの問題を引き起こします。MaildirのコンテンツをIMAP APPENDで新サーバーに書き込む際、元のINTERNALDATEを保持しません。各メッセージは操作実行時のタイムスタンプを受け取ります。

imapsyncとcPanelからの手動移行

imapsyncは強力なツールですが、デフォルトの動作では日付を常に保持するわけではありません。適切なオプション（と正しいバージョン）なしに使うと、40,000件のメッセージ全部にスクリプト実行日の日付を付けてコピーすることになりかねません。（25,000件のメールボックスで日付問題を診断するためにimapsyncのログを一行ずつ追ったことがあるなら、二度と繰り返したくない体験だとわかるはずです。）

正確に言うと、imapsyncには日付を保持しようとするオプションがありますが、それらのオプションはソース・宛先サーバーによって動作が異なり、すべてのcPanel / Dovecot構成で効果が保証されているわけではありません。

GSMMOと一般向けツール

Google Workspace Migration for Microsoft Outlook（GSMMO）はOutlookからの移行向けに設計されており、素のIMAPサーバーからの移行には対応していません。cPanelからの移行（OutlookにIMAPアカウントを設定して使う場合）に使うと、日付は同じ扱いを受けます。Google WorkspaceのINTERNALDATEは移行日に設定されます。GSMMOとメール日付の問題はそれだけ広範なため、別途まとめられています。

影響を受けるメールクライアント

日付の破損は、使用するクライアントによって現れ方が異なります。

Outlookは最も影響を受けるクライアントです。フォルダ内の並び替えにINTERNALDATE（または移行のReceived:ヘッダー）を主要な基準として使います。cPanel移行が適切に処理されなかった場合、Outlookで開いたメールボックスには、移行した週末の日付が付いたアーカイブメールが何千件も表示されます。OutlookでのimapsyncによるメールIMAPの修正は特に多くリクエストされる修正の一つです。

Gmail（Google Workspace）はメール一覧で通常Date:ヘッダーの日付を表示しますが、場合によってはINTERNALDATEが並び替えに影響することもあります。日付での検索や並び替えで不安定な動作が報告されています。

Apple MailとThunderbirdはより微妙な挙動をしますが、特に移行のReceived:ヘッダーがチェーンの先頭にある場合、どちらも問題から無縁ではありません。

朗報：元の日付はそのまま残っている

これが状況を変える技術的なポイントです。メッセージ本文のDate:ヘッダーはメールの生データに書き込まれており、移行はそこに触れません。影響を受けたメールを開いて生のヘッダーを確認すると（Gmailでは「メッセージのソースを表示」、Outlookではファイル > プロパティ）、元のDate:がそのまま残っていて、その後に移行日付を持つReceived:ヘッダーが続いているのがわかります。

この情報は常にそこにあります。メタデータの修正に活用できます。リデイト（Redate.io）の修正エンジンが行っているのはまさにこれです。

「自分で修正する」がリスクになる理由

誘惑はわかります。問題は単純に見える。元の日付を読み取って、メタデータを直して、次へ。でも仕組みを理解することと、本番環境の12,000件のメールを一件も失わずに修正することの間には、かなりの差があります。

自作スクリプトが一般的に考慮しない現実がいくつかあります。

S/MIME署名またはPGP暗号化メール：メッセージ構造に手を加えると暗号署名が無効になります。修正前は署名検証を通過していたメールが、修正後は通過しなくなります。法律事務所、金融、医療など規制遵守が求められる環境のユーザーは、最悪のタイミングでこれを発見します。
非ASCIIヘッダーとRFC 2047エンコーディング：cPanelのメールボックスは多様なメールクライアントからの何年分ものメールを蓄積しています。一部のヘッダーにはRFC 2047でエンコードされた文字が含まれています。ヘッダーを再構築する際にスクリプトの実装が不十分だと、このエンコーディングを気づかないうちに破損させます。
ネストされたMIME構造：三つの添付ファイルとHTMLの代替本文を持つメールはマルチパート構造が複雑です。MIMEの境界に少しでもエラーがあると、メッセージが読めなくなるか、最悪の場合、添付ファイルがエラーメッセージなしに消えます。
APIクォータとレート制限：Google WorkspaceとMicrosoft 365はIMAP操作の毎分実行数に厳しい制限を設けています。指数バックオフを正しく実装していないスクリプトは深夜3時に429エラーを起こし、どこで止まったか正確にわからない半端な状態で朝を迎えます。
ロールバック不可：途中で何か問題が起きたとき、どの状態に戻りますか？元のメッセージはまだありますか？重複が発生していませんか？Redate.ioは元のメッセージを30日間、見える形のバックアップフォルダに保持します。まさにこういう状況を避けるために。

開発環境で50件のテストメールに動いたスクリプトが、2011年からcPanelで運用されてきた本番メールボックスの18,000件に同じように動くとは限りません。

Redate.ioがcPanel移行後の日付を修正する方法

Redate.ioは宛先のメールボックス（Google Workspaceはドメイン委任、Microsoft 365はMicrosoft Entra ID、または直接IMAPサーバー）に直接接続し、まず無料スキャンで元のDate:ヘッダーと日付メタデータに不一致があるメールを特定します。

その後、多段階分析パイプラインがReceived:ヘッダーシグネチャのパターンマッチングを適用し、移行ツールによって追加されたものを（正当なヘッダーと区別して）特定します。メッセージ内容を変えることなくメタデータの修正を実施し、テキスト、添付ファイル、元のヘッダーはすべてそのまま残ります。修正された各メールは、処理が確定される前に個別に検証されます。

cPanelからの移行に関しては、Dovecot-to-IMAPの移行シグネチャやimapsyncスクリプトの典型的なパターンをエンジンが認識します。欧州や日本の共有ホスティング事業者の一般的な設定バリエーションも含めて。

移行先別の具体的なガイド

cPanel移行の宛先プラットフォームに応じて、以下のガイドで具体的な手順を確認できます。

cPanelから移行後、ユーザーに誤った日付が表示されていますか？ Redate.ioで無料スキャンを開始すると、承認前に何件のメールが影響を受けているかを正確に把握できます。変更は一切行いません。

cPanel移行後のメール日付ずれを修正する