メールボックス移行：フォルダー、フラグと履歴

メールボックス移行は、利用者が履歴を確認するまで簡単に見えます。送信済みが見えず、未読が増え、十年分のメールが今日届いたようになることがあります。コピーだけでなく対応する状態を保持する作業です。全体は管理者向け imapsync ガイドで確認できます。プラットフォーム変更でも明確な標準と検証が役立ちます。

内容だけをコピーして完了とすると、ユーザーの業務を満たしません。RFC 5322 の内容が届くだけでは足りず、送信済みの場所、既読状態、検索結果の整合性が重要です。この三つが崩れると、初日からサポート対応になる場合があります。

本ガイドは問題が起きやすい箇所、検証、TrekMail の可能な役割を説明します。原文は Starter 以上の内蔵 IMAP インポートと、ユーザー課金ではなく月額 $3.50 からのプラン料金を紹介します。一つでも百個でも、現在の機能と上限を確認します。関連計画は小規模企業向けビジネスメールと複数ドメインのメールホスティングを参照してください。

MX 切り替え後に問題が見つかる理由

内容が届いても状態が保持されない場合があります。四つの主な確認領域は、フォルダー対応、既読フラグ、内部日時、Gmail ラベルです。検証でリスクを減らせますが、無事故を保証しません。

新しい受信先が動いても、コピー全体の完全性は証明されません。MX を変えるのは自分の管理するドメインの受信先変更で、全移行先アドレスと事前コピーの確認後です。利用者には接続できるサーバーだけでなく、継続できる仕事の流れが必要です。

データベース移行のように考えます。メールには内容、フラグ、フォルダー位置、内部日時があります。メタデータを失うと開けても振る舞いが変わる場合があります。

例えば、経営者が移行先で 8,000 通の未読を見てプロバイダーを疑います。この例は内容が移り、\Seen が保持されなかった場合です。実際にはほかの原因も調べます。

見落としやすい四つの問題

送信済みの対応、\Seen、INTERNALDATE、Gmail All Mail の複数表示を確認します。進捗表示ではなく実際の操作で初めて分かることがあります。

1. 送信済みフォルダーの不一致

システムごとに名前が異なります。Sent、Sent Items、cPanel の INBOX.Sent、Gmail の [Gmail]/Sent Mail などです。

誤った対応付けで履歴は普通のフォルダーへ入り、クライアントは特殊用途の送信済みへ新しいメールを書きます。期待したフォルダーが空なので、別の場所にある履歴を失ったように見えます。

RFC 6154 は、送信済み、下書き、迷惑メール、ごみ箱をクライアントが識別する特殊用途を定義します。名前だけでなく実際の用途とクライアント設定が重要です。

2. \Seen フラグの問題

移行元とツールが対応するなら既読・未読を保持します。そうでないと長年処理したメールが未読になり、仕事を妨げる場合があります。

RFC 3501 は \Seen などのシステムフラグを説明します。試験移行で検証してください。形式的なコピー完了だけでは状態の保持を保証しません。

\Recent は異なります。従来の IMAP ではセッションに関係し、既読状態のようには移せません。現行実装が同じように使うとも限りません。旧メールが移行先セッションにとって新しく見える場合があるので、事前に説明します。

3. INTERNALDATE のリセット

Date ヘッダーとサーバーの内部日時は別です。クライアントが内部日時で並べる場合、取り込みで再設定すると内容が正しくても時系列が変わります。

RFC 3501 の APPEND は任意の日時を受け取り、指定時にはその値を内部日時に使うことが推奨され、未指定なら現在時刻が使われます。十年分のアーカイブが今日に並ぶ原因になり得ます。実際に移行元が提供した INTERNALDATE と時差、対応精度を保持します。Date だけでは不明な元サーバーの到着時刻を再構成できません。

4. Gmail All Mail の複数コピー

Gmail はラベルで整理し、IMAP ではフォルダーのように表示します。複数の表示が同じメールを含み、ツールが複数コピーを作る場合があります。

[Gmail]/All Mail と受信トレイ、送信済み、ユーザーラベルを一緒に取り込むと、容量や検索結果が増える場合があります。ただし、別フォルダーのコピーは意図したラベル表現でもあります。表示を合意し、ほかの取り込みラベルがないアーカイブも全体として確保してから除外を検討します。

移行時にフォルダーを正しく対応付ける

異なる名前には適切な対応が必要です。自動識別も検証しなければなりません。表の移行先名は例であり、普遍的な標準や TrekMail の既定値ではありません。

手動 imapsync では試験した正規表現を使えます。以下の原文例は実行用の完成形ではありません。過剰なエスケープで一部の規則が想定する元の名前に一致せず、変換は自動プレフィックス・区切り文字処理後に順番に適用されます。実際の移行先で自分の作業用コピーを修正・検証してください。コマンドは実コピーで TLS・証明書検証を明示せず、パスワードも引数に出ます。管理された試験先、対応する本当のドライラン、安全な認証情報、暗号化と証明書チェーン・ホスト名の確認が必要です。

imapsync \
  --host1 old.example.com --user1 user@old.example.com --password1 'oldpass' \
  --host2 new.example.com --user2 user@new.example.com --password2 'newpass' \
  --regextrans2 's/^Sent Messages$/Sent Items/' \
  --regextrans2 's/^INBOX\\.Sent$/Sent Items/' \
  --regextrans2 's/^INBOX\\.Trash$/Deleted Items/' \
  --exclude "\\[Gmail\\]/All Mail"

試験後に移行先から実際に送信し、新しい送信済みと履歴が同じ予定フォルダーに入るか確認します。ほかのユーザーを移す前に修正してください。

TrekMail では最新の IMAP 移行概要を読みます。原文は Gmail、Outlook、Yahoo、iCloud、ほかの IMAP 設定例、件数付きフォルダー一覧、バックグラウンド処理、重複照合を紹介します。現在の機能と実結果を確認し、Message-ID や UID を完全性の保証としないでください。直接インポートはユーザー名とパスワードで、対話型 OAuth ではありません。アプリパスワードはポリシー次第で、必要なら別の認可された OAuth 接続方法を使います。準備は Gmail からの移行と cPanel からの移行にあります。

実データで移行を検証する

件数、未読数、送信済み、日時を比較します。MIME、インデックス、保存方式が異なるのでギガバイトだけは頼れません。同じ件数も完全性の証明ではなく、内容、添付、ログ、対応付けを調べます。

緑の完了表示はジョブの状態を示すだけで、ユーザー体験の保持を保証しません。データ自体を確認します。

1. 合意した移行元・先フォルダーごとに件数を比較する。受信トレイ、送信済み、アーカイブを確認。
2. 未読数を比較する。移行元 50 通、移行先 4,000 通ならフラグ、対象範囲、フィルター、継続する元の変更を調査し、差だけで原因を断定しない。
3. 過去メールを開き、日時保持後も 2019 が 2019 として並ぶか確認する。
4. 新しいメールを送り、移行した送信履歴と同じフォルダーに入るか調べる。

MIME の問題、除外、メール以外の項目で小さな差はあり得ますが、重要な差は説明が必要です。容量はメッセージ、フラグ、添付、日時の確認を代替しません。

切り替え後には正しいクライアントも必要です。最新値は TrekMail の IMAP/SMTP ガイドにあります。原文は IMAP 対応で POP3 は非対応とし、旧プロファイル削除前にはローカルや未同期メールを保護してください。現行の TLS 設定、証明書チェーンとホスト名を検証し、管理画面の認証情報ではなくメールアドレス全体とメールボックスのパスワードで接続します。

追加同期、重複と UIDVALIDITY

初回の後に通常は少なくとも一回の追加同期が必要で、切り替え後も必要な同期を続けます。古い日付の遅着、フォルダー間の移動、フラグも含めます。キャッシュと再配送のため旧 SMTP 受信、管理者アクセス、切り戻しを残します。TTL を下げても旧キャッシュはすぐ消えません。

UIDVALIDITY はフォルダー内の UID の有効性を表します。復元、修復、再インデックスで変わる場合がありますが、必ずではありません。ツールが旧対応関係を失い、方式によって再コピーする可能性があります。UID は全体共通の番号でも内容の証明でもありません。

金曜に正常そうでも、月曜に重複が分かる場合があります。不要な保守は延期し、必要な修復は調整してください。移行を止めて状態を確認し、再開を検証するのであって、重要な修復を一律に禁止するものではありません。

多くのツールは追加コピーで、初回後の元の削除を必ず移行先に反映しません。新しい移行先メールを守れる場合がありますが、衝突の計画は必要です。利用者の作業先を一つにし、両方で利用者が操作するアカウントを安全な双方向同期と考えないでください。

ミラー削除は方向、時間、バックアップ、試験を別途確認した場合だけ検討します。誤った前提で必要なデータを消す可能性があります。

手動移行と TrekMail の管理

手動では個別コマンド、正規表現、監査が多くなる場合があります。統合した IMAP 手順は作業をまとめられますが、プラン料金がユーザー料金より適切かは要件と上限によります。

多数のメールボックスでは費用もプロトコルと同じくらい重要です。準備と管理権限も考えます。関連はメールアカウントの一括作成と顧客メールの管理です。

TrekMail は検証をなくしません。複数ドメイン画面、共有容量、IMAP、自分の SMTP または含まれる SMTP が対応プラン内で管理を助けます。追加ユーザー、容量、機能は現在の上限に従います。

移行前に TrekMail 料金を比較します。原文のカード不要の無料 Nano、有料の月額 $3.50 からの料金、有料プランのクレジットカードが必要な 14 日間無料試用は、現行条件を確認してください。

まとめ：成功したメールボックス移行の状態

送信済みが予定した場所にあり、未読が合理的で、履歴の並びが正しく、Gmail ラベルが計画どおりであることが目標です。表示だけでなく実際のメッセージで確認します。

全コピー前に対応付け、\Seen など対応フラグを保持し、APPEND で提供された INTERNALDATE を指定します。Gmail All Mail はアーカイブ全体の取り込みを確保してから除外します。容量だけでなく件数、内容、添付、日時、ログを比較してください。

この手順はコピーを管理された切り替えにし、手戻りリスクを抑えますが、無損失や無停止を保証しません。エイリアス、転送、カレンダー、連絡先などは別に再設定して検証します。

プロトコルの参考は IMAP の RFC 3501 と、特殊用途フォルダーの RFC 6154 です。