メール移行でメールを失う7つの障害パターン

メール移行は単なるコピー作業に見えます。しかし、メールが二つの環境に届き始め、利用者が古いスレッドに返信すると配信不能になり、経営者のメールボックスが契約プランの上限を85GBも超えていると判明した瞬間、その認識は崩れます。ツールの使い方から確認したい場合は、imapsync運用ガイドをご覧ください。本記事では、その周辺で起こる問題に対処するための手順を解説します。DNS、フォルダーの対応付け、帯域制限、メールボックス容量、そして日常的なメール移行を週末の障害に変える厄介な例外です。

問題の根は単純です。メールをファイルと同じように扱ってしまうことです。さらに厄介なのは、移行中もメールボックスが変化し続け、DNSキャッシュが実態と異なる情報を返し、IMAPサーバーごとにフォルダーの扱いが違う点です。必要なのは担当者の力技ではありません。段階的な準備と検証を行い、夕方6時には無害に見えても月曜朝9時には致命傷になる近道を拒むことです。

本番環境のメール移行が失敗する理由

担当者がメール移行を、棚卸し、事前転送、切り替え、差分同期、検証という管理された工程ではなく、一度きりの作業として扱うと失敗します。メールは常に変化するデータです。DNSにはキャッシュがあります。クライアントの挙動も一様ではありません。どれか一つでも省けば、完全な移行にはなりません。配信先の分断、重複、気付かないままのデータ消失が起こります。

1. DNSスプリットブレインが最初のメール移行障害を起こす

最初のメール移行障害は、多くの場合コピー処理そのものではなく、ルーティングで起こります。数分で新しいMXを使い始める送信元もあれば、古いMXを数時間キャッシュし続ける送信元もあります。その間、メールは両方のシステムに届く可能性があります。旧ホストをすでに停止していれば配信不能になり、稼働させていればメールが旧環境に取り残されます。

Microsoftは、IMAP移行の切り替え前にMXのTTLを短くし、更新されたレコードを早く伝播させるよう案内しています。地味な助言ですが、移行を救います。現在のTTLが86,400秒なのに、移行当日の夜になってMXを変更するなら、すでに時間を制御できていません。

;; T-48 hours: inspect current MX TTL
example.com.  86400  IN MX 10 oldmail.example.com.

;; T-48 hours: lower it before cutover
example.com.    300  IN MX 10 oldmail.example.com.

;; T-0: switch to new provider
example.com.    300  IN MX 10 mail.trekmail.net.

TrekMailへ移行する場合は、TrekMailへのドメイン追加で正確なレコードを確認し、移行を告知する前にドメインが有効になったことを確かめてください。TrekMailはDNSもリアルタイムで検査するため、古いMXレコードを残す典型的なミスを見つけやすくなります。

悪い切り替え例: 午後10時にMXを変更し、午後10時05分に旧ホストを停止。月曜日になって、ある取引先のゲートウェイが週末中ずっと古いレコードをキャッシュしていたと判明する。

もう一つの罠はSPFです。受信先だけ新システムに向けても、送信認証が正しくなければ返信が迷惑メールに入ります。Googleの送信者向け要件は、もはや任意ではありません。SPFレコードは一つにまとめ、DKIMを整合させ、DMARCを公開してください。

2. スロットリングが週末一回で終えるメール移行の幻想を壊す

二つ目の障害パターンは物理的な制約です。ボトルネックは通常、手元の帯域幅ではありません。移行元の事業者が、その時点で十分な量をコピーしたと判断することです。Google、Microsoftなどのホスティング環境は、負荷の高いIMAP通信を制限します。制限が始まると進捗予測は当てにならず、処理速度は極端に落ちるか、完全に止まります。

そのため、ごく小規模なチームを除き、一斉移行は適切な計画ではありません。一日あたり実質的に一部しか転送できない環境へ10GBのメールボックスをコピーしても、希望しただけでは完了しません。レート制限は保守時間の都合を考慮しません。

対策は段階的な移行です。

1. 通常は60日から90日より古いメールを先に事前転送します。
2. 平日の間、ツールに再試行と待機をさせます。
3. 過去メールの大部分が移行先に届いてからMXを切り替えます。
4. 切り替え中に直近メールの差分同期を実行します。

TrekMailのサーバー側IMAPインポートは、この流れに合わせて設計されています。ダッシュボードで移行を開始するの現行ドキュメントには、移行ツールが外部IMAPサーバーから指定したTrekMailメールボックスへメールを取り込み、重複をスキップするオプションを利用できると記載されています。安全なメール移行では複数回の実行が普通であり、異常の兆候ではありません。

従来方式と新方式の違いです。従来の事業者は利用者単位の料金を請求し、さらに別売りの移行ツールを購入させます。新方式では、組み込みのIMAP移行で段階的に作業し、月額$3.50からの定額プランを利用できます。メールボックスを追加するたびにライセンス費用が発生することもありません。

3. UIDVALIDITYの変化で同じメールボックスが三重にコピーされる

このメール移行障害は、正常に見える進捗バーの裏に隠れます。IMAPメッセージには一意の識別子がありますが、その信頼性は所属するメールボックスの規則内に限られます。サーバー上のフォルダー状態が大きく変わり、UIDVALIDITYがリセットされると、単純な移行ツールは古いメッセージを新規と誤認して再びコピーすることがあります。

IMAP4rev1 (RFC 3501)がUIDVALIDITYを定義しているのには理由があります。値が変われば、以前のメッセージUIDは信頼できません。プロトコルとしては正常な動作ですが、UIDだけに依存する移行ツールにとっては深刻な問題です。

代表的なきっかけは次のとおりです。

• 移行中に利用者がフォルダー名を変更する、またはフォルダーを作り直す。
• 移行元サーバーがインデックスを再構築する。
• 管理者がメールボックスの状態を変える保守作業を実施する。

実務上の防御策は単純です。移行期間中はメールボックスの整理を停止します。同期の実行中は、フォルダー名の変更、大量のメッセージのアーカイブへの移動、送信済みアイテムの整理をしないよう利用者に伝えてください。そのうえで、フォルダーUIDだけを盲信せず、再実行時に重複をスキップできる移行先を使います。

手動で検証する場合は、移行前後のフォルダー別件数を比較してください。受信トレイだけで終えてはいけません。送信済み、ゴミ箱、独自のプロジェクトフォルダー、共有アーカイブ構造まで確認します。重複の大量発生は、そうした場所に潜んでいます。

4. フォルダーの対応付けでメール移行は急に複雑になる

IMAPサーバー間では、階層区切り文字、システムフォルダー名、Gmailのラベルモデルが統一されていません。そのため、フォルダーの対応付けがメール移行を壊します。利用者には、フォルダーの欠落やメッセージの重複として見えます。技術的にはメールが存在していても、誤って変換されていれば混乱と問い合わせを招くには十分です。

この問題にはよくある形が二つあります。一つ目は区切り文字の不一致です。片方のサーバーはフォルダー名にピリオドを使い、もう片方はスラッシュを使います。二つ目はGmailラベルです。一つのメッセージが複数のラベルに表示され、IMAPではそれらがフォルダーのように見えます。

こうして、整理されたGmailラベルを持つ移行元メールボックスが、送信済み、独自フォルダー、アーカイブ領域に同じメールを抱える肥大化した移行先になります。Microsoftのトラブルシューティング資料でも、Gmailラベルを使う環境で[Gmail]フォルダーを除外しない場合のメール重複が明記されています。

# Example folder rules
^INBOX\.Sent$        -> Sent Items
^INBOX\.Trash$       -> Deleted Items
^\[Gmail\]/Trash$   -> Deleted Items
^\[Gmail\]/All Mail$ -> [SKIP]

Gmailから移行する場合、明確な例外要件がない限り[Gmail]/All Mailはスキップしてください。除外しなければ重複を招きます。移行後のクライアント設定については、TrekMailの全クライアント向けIMAPとSMTP設定に標準設定がまとまっています。

5. 巨大メールボックスが予算と日程を破綻させる

メール移行計画は平均値で考えると失敗します。実環境で問題になるのは外れ値です。2011年からメールを蓄積し続けている一つのメールボックスが、標準的な利用者十人分を合わせた容量より大きいこともあります。全メールボックスの容量を測らずに見積もり、移行先プラン、日程を決めれば、その一つの外れ値がプロジェクトを破綻させます。

これは移行先で下位ライセンスを選ぶ際の罠です。特に古いオンプレミス環境などの移行元は、巨大なメールボックスを許容していることがあります。一方、多くのホスティングサービスは許容しません。移行先の上限が実際のメールボックス容量より小さい場合、すぐ明確に失敗するとは限りません。何時間も転送した後で失敗することがよくあります。

必ず最初に棚卸しをしてください。例外は認めません。その後、利用者ごとの高価なアップグレードを強いずに、不均一なメールボックス容量を扱える移行先かどうかを判断します。

この点で、利用者単位のストレージより共有ストレージの方が運用に適しています。TrekMailでは、すべてのメールボックスを同じ小さな枠に押し込めるのではなく、アカウント全体でストレージを共有します。創業者、法務用メールボックス、制作会社の共有受信トレイには重要な違いです。多数のドメインを管理するチームにとって、ストレージモデルが例外的な容量を罰しないことは、複数ドメインのメールホスティングを実用的に運用する条件です。

移行後の使用量を確認する場合は、TrekMailのメールボックスのストレージ上限で上限とクォータの動作を確認できます。

6. 破損メッセージは珍しくないため運用手順で扱う

完全なメール移行とは、文字どおりすべてのアイテムが正常であることではありません。古いメールストアには、壊れたMIME構造、容量がゼロの添付ファイル、不正な形式の予定招待が蓄積します。不良アイテムのたびに全作業を止める運用では、2014年の壊れたメッセージ一件が、ほかは正常な移行を停止させます。

ここでは、精密さと適切な運用を混同しがちです。監査証跡は必要です。しかし、使えない添付ファイルを解析できないという理由で、バッチ全体を止める必要はありません。

不良アイテムの許容しきい値を設定し、スキップしたアイテムをすべて記録し、レポートを確認して処理を続けます。失敗するアイテムの多くは、不要なメール、旧システム由来の重複、誰も必要としない不正な形式の古い招待です。スキップ済みアイテムのCSVに重要なものがあれば、そのメッセージだけを手動で移してください。メール移行全体を止めるより、はるかに速く終わります。

TrekMailの組み込み移行では、ダッシュボードに進捗と失敗が表示されます。受信側で、切り替え後に想定どおりメールが届かない場合は、メールを受信できない場合を使うと、MXとメールボックスをすばやく点検できます。

7. LegacyExchangeDNは移行後も残るExchange固有の罠

このメール移行障害は特有で、厄介で、よく発生します。メールボックスは存在し、新しいメールは正常に動くのに、利用者がOutlookで古い社内スレッドに返信すると、IMCEAEXまたは受信者不明の配信不能通知が返ります。原因はSMTPではありません。過去のメッセージやキャッシュ済みアドレスに埋め込まれた、以前のExchange識別情報です。

Exchangeは、X.500形式の旧アドレス情報をLegacyExchangeDN属性に保存します。Exchange環境間の移行、または不完全なExchangeからの移行では、古いメッセージへの返信が以前の識別情報を参照し続けることがあります。移行先メールボックスに以前の値がX500プロキシアドレスとして追加されていなければ、返信は失敗します。

# Find the old LegacyExchangeDN on source
Get-Mailbox -Identity user@example.com | Format-List LegacyExchangeDN

# Add it as an X500 proxy address on destination
Set-Mailbox -Identity user@example.com -EmailAddresses @{add="X500:/o=OldOrg/ou=Exchange Administrative Group/cn=Recipients/cn=user"}

単純なIMAP移行では、完全なExchange移行のようにExchange固有のオブジェクトを運ばないため、すべてのメール移行で起こる問題ではありません。しかし、Outlook利用者が古い社内スレッドに途切れず返信できる必要があるなら、完了承認の前に確認してください。プロジェクトの完了宣言後に初めて表面化する問題の一つです。

より安全なメール移行の切り替え計画

安全なメール移行は、意図的に段階を分け、測定可能で、地味に進めます。それが目標です。自動化そのものを増やすのではなく、予想外の事態を減らす必要があります。最良の切り替えが何事もないように見えるのは、危険な作業をMX変更時ではなく事前に済ませているからです。

1. すべてのメールボックス容量を棚卸しし、異常に大きいものを特定します。
2. 切り替えの24時間から48時間前にMXのTTLを下げます。
3. 移行先のドメインとメールボックスを先に作成します。
4. 切り替え週末より前に過去メールのIMAP同期を実行します。
5. 最終同期中はフォルダー整理と大量移動を停止します。
6. 移行先が受信可能になってからMXを切り替えます。
7. 最後の差分同期を一回実行します。
8. 受信、送信、フォルダー別件数、古いスレッドへの返信をテストします。

移行先を最初から構築する場合は、独自ドメインでメールを作成する方法で設定手順を確認できます。少人数を超える利用者を登録する場合は、メールアカウントの一括作成が役立ちます。

TrekMailの場合、実務上の手順は明快です。ドメインを追加してDNSを検証し、メールボックスを作成します。有料プランで組み込みのIMAP移行を実行し、大部分のコピーが終わってから本番通信を切り替えます。料金は月額$3.50からです。有料プランにはクレジットカードが必要な14日間の無料トライアルがあります。Nanoプランは別枠で、カード不要、トライアルなし、常に無料です。

まとめ: メール移行はコピー作業ではなく運用作業

メール移行を成功させるには、DNSキャッシュ、移行元のスロットリング、統一されていないIMAPの挙動、クォータの不一致、Exchangeの残存情報という厄介な点を重視する必要があります。無視すれば、利用者がメールの欠落に気付くまで、プロジェクトは正常に見えます。メール移行を稼働中のインフラとして扱えば、予測可能な作業になります。要点はそれだけです。

移行後に定額モデルを利用するなら、TrekMailには複数ドメインのホスティング、共有ストレージ、組み込みIMAP移行、メールボックス転送、APIアクセス、標準技術を重視した利用者単位料金なしの構成があります。trekmail.netから始めるか、TrekMailの料金を比較してください。