Zoho Mail移行後の日付エラーを修正する方法

Zoho Mailと日付の問題

Zoho Mailは中小企業に人気のメールプラットフォームで、Google WorkspaceやMicrosoft 365に代わる経済的な選択肢です。多くの組織がコスト削減のためにZohoへ移行します。逆に、より大規模なプラットフォームへの拡張に伴い、Zohoから移行する組織もあります。

どちらの方向の移行でも、メールの日付がおかしくなることがあります。メールボックス内のすべてのメッセージが、元の送受信日ではなく移行日でスタンプされてしまうのです。これはかなり厄介な問題で、多くの管理者が想定するよりも頻繁に発生します。

よくあるZoho移行シナリオ

Zoho Mailへの移行

Zoho Mailへ移行する組織は、通常Google Workspace、Microsoft 365、または汎用IMAPホスト(cPanel、Plesk、Dovecotなど)から移行します。Zohoは、ほとんどのメールプロバイダーからのIMAPインポートに対応した独自の移行ウィザードを提供しています。このウィザードは元のサーバーに接続し、IMAP経由でメールをダウンロードして、Zoho Mailアカウントに挿入します。この挿入処理の際、ZohoのメールサーバーはすべてのメッセージにMigrationのタイムスタンプを持つ「Received」ヘッダーを追加します。この新しいヘッダーはヘッダーチェーンの最上位エントリになり、メールクライアントに移行日を表示させる原因となります。

Zoho Mailからの移行

組織がZohoの機能を超えた要件を持つようになったり、Google WorkspaceやMicrosoft 365専用の機能が必要になったりすると、Zohoから移行することがあります。BitTitan MigrationWiz、imapsync、あるいはThunderbirdを使った手動IMAPコピーなどのツールがよく使われます。これらの方法はいずれも、Zohoからメールをダウンロードし、IMAP APPENDでコピー先のサーバーに再挿入するため、同じReceivedヘッダーの問題が発生します。ツールごとの詳細については、BitTitan、imapsync、手動IMAPコピーのガイドをご覧ください。

Zohoアカウント間の移行

Zoho Mailアカウント間の移行(たとえば組織再編やドメイン変更の際)でも、日付の問題が発生することがあります。メールがダウンロードされ、IMAP経由で再挿入される限り、コピー先のサーバーは必ずReceivedヘッダーを追加します。送信元と送信先が両方Zohoアカウントであっても関係ありません。

Zoho MailのIMAP日付処理

ZohoのIMAP実装

Zoho Mailは標準のIMAP4rev1(RFC 3501)に対応しています。IMAP APPENDでメッセージが挿入されると、Zohoのサーバーはプロトコル仕様に従い、現在のタイムスタンプを持つReceivedヘッダーを追加し、INTERNALDATEとともにメッセージを保存します。APPENDコマンドに明示的なINTERNALDATEパラメータが含まれている場合、Zohoはそれを尊重します。しかし、Receivedヘッダーはどのような場合でも必ず追加されます。

ZohoのウェブメールとIMAPクライアントの違い

ここが混乱しやすいポイントです。

ZohoのウェブメールインターフェースはメールのDateヘッダーに基づいて日付を表示します。これはGmailのウェブインターフェースと似た仕組みです。そのため、Zohoのウェブメールでメールを見ると、日付が正しく表示されているように見えることがあります。しかし、Zohoアカウントに接続するIMAPクライアント(Outlook、Apple Mail、Thunderbirdなど)は、Receivedヘッダーまたは INTERNALDATEを使用するため、元の日付ではなく移行日が表示されます。

管理者がZohoのウェブメールを確認して正しい日付を見つけ、移行は成功したと結論づけてしまうことがあります。一方で、Outlookやapple Mailで接続しているユーザーは、すべてのメールが同じ日付になっていると報告してくるのです。クライアントごとの日付の扱いについては、IMAP INTERNALDATEの技術的解説を参照してください。

Zoho Mailで問題を特定する

メールヘッダーを確認する

移行時のReceivedヘッダーが日付問題の原因であることを確認するには、Zohoのウェブメールで対象のメールを開き、生のヘッダーを表示します。メールの三点メニューをクリックし、「Show Original」を選択してください。最上位のReceivedヘッダーを確認します。そこに移行日と一致するタイムスタンプが記載され、元の配信経路には存在しなかった移行ツールやサーバーが参照されていれば、問題は確定です。

クライアント間で日付を比較する

同じメールをZohoのウェブメールとOutlookなどのIMAPクライアントの両方で開いてみてください。Zohoのウェブメールでは「2024年1月15日」と表示され、Outlookでは「2025年4月11日」(移行日)と表示される場合、原因はReceivedヘッダーの問題です。

Redate.ioによるZoho Mailの日付修正

IMAPでの接続

リデイト(Redate.io)は、標準のIMAP経由でZoho Mailアカウントに接続します。Zoho Mailアカウントを接続するには、IMAPサーバーアドレス(データセンターによってimap.zoho.comまたはimap.zoho.eu)、メールアドレス、そしてアプリ専用パスワードが必要です。二段階認証が有効になっている場合(これが推奨されるセキュリティ設定です)、ZohoはIMAP接続にアプリ専用パスワードを要求します。

Zohoでアプリ専用パスワードを生成するには、Zohoアカウント設定から「セキュリティ」、次に「アプリケーション専用パスワード」に進み、Redate.io用の新しいパスワードを生成します。このパスワードは、メインアカウントのパスワードを公開せずにIMAPアクセスを許可します。

スキャンと修正のプロセス

接続後、Redate.ioはZohoのメールボックス全体をスキャンし、移行時のReceivedヘッダーを持つメールを特定します。スキャンはすべてのフォルダ(受信トレイ、送信済み、ドラフト、カスタムフォルダ)を確認し、影響を受けたメールの数を数えます。このスキャンは無料です。

Redate.ioの独自の修正エンジンは、影響を受けた各メールの完全なヘッダーチェーンを分析します。検出は特定の移行ツールのシグネチャに依存するのではなく、日付の異常そのものに基づいているため、どの移行ツールを使った場合でも機能します。多段階の処理パイプラインは、エンコーディングの問題、マルチパートのメッセージ構造、インライン添付ファイル、デジタル署名、そして単純な方法では見落としてしまう数多くのエッジケースに対応します。修正されたすべてのメールは整合性検証を経てから、元のメールはメールボックス内に表示される「Redate.io - Originals」というバックアップフォルダに移動され、削除されるまでそこに保管されます。

自分でスクリプトを書けばいいのでは、と思うかもしれません。しかし、実際に問題が起こるのはエッジケースです。S/MIME署名付きメール、破損したMIME境界、RFC 2047でエンコードされた非ASCII文字のヘッダー、入れ子になったマルチパート構造、Dateヘッダー自体が存在しないメッセージなど。メールの90%を正しく処理し、残りの10%を静かに壊してしまうスクリプトは、何もしないよりも悪い結果を招きます(月曜の朝に発見したくない類の問題です)。

Zoho固有の注意点

ZohoのIMAPレート制限

Zoho Mailは、不正利用を防ぐためにIMAP接続にレート制限を課しています。Redate.ioはこの制限を尊重し、Zohoの許容リクエスト率を超えないよう修正処理の速度を調整します。メール数が多いメールボックスでは、レート制限がより緩やかなプラットフォームに比べて修正に時間がかかることがあります。

Zohoの無料プランと有料プラン

ZohoのMail無料プランはIMAPアクセスに対応していません。IMAPはZoho Mailの有料プラン(Mail Lite以上)でのみ利用できます。対象のZohoアカウントが無料プランの場合、Redate.ioが接続する前に、プランをアップグレードしてIMAPを有効にする必要があります。

Zohoのデータセンターの所在地

Zohoは複数の地域(米国、EU、インド、オーストラリア、日本)でデータセンターを運用しています。IMAPサーバーアドレスは地域によって異なります。米国はimap.zoho.com、EUはimap.zoho.eu、インドはimap.zoho.in、オーストラリアはimap.zoho.com.auです。Redate.ioを接続する際は、正しい地域のサーバーアドレスを使用してください。

Zoho Mailで移行後に日付が間違って表示されていませんか。Redate.ioで無料スキャンを開始して、影響を受けたメールの数を正確に確認しましょう。