imapsyncは、PSTの書き出しやデスクトップクライアント、週末を費やす試行錯誤を利用者に強いることなくIMAPメールを移すための定番ツールです。そこまでは問題ありません。問題はその後です。一つの誤ったオプション、フォルダーマッピング、認証への思い込みによって、送信済みメールの欠落、フォルダーの重複、切り替え時の新着メール削除が起こります。先に全体の手順を知るには、imapsyncの運用ガイドを読んでください。
そこで本記事は範囲を意図的に絞ります。結果を実際に左右するタイムアウト、接続維持、フォルダーマッピング、速度制限、重複排除、そして稼働中のメールボックスを壊しかねない削除オプションを扱います。一つのアカウントなら面倒な再実行を防げます。五十件なら、送信済みフォルダーが三つに分かれた理由を顧客へ説明せずに済みます。
要点は、imapsyncの既定値は移行計画ではなく出発点だということです。実際の移行には段階的な実行、明示的なフォルダー規則、MX変更前の検証が必要です。TrekMailが移行先なら、有料プラン内蔵のインポートウィザードで受信側を画面から処理でき、各メールボックスをshellスクリプトで管理するより簡単です。TrekMailは$3.50/monthからで、ユーザー単位の課金ではなく共有ストレージを採用し、Gmail、Outlook、Yahoo、iCloud、一般的なIMAPからのサーバー側インポートに対応します。
既定値を信頼するとimapsyncが失敗する理由
imapsyncがコピーするのは静的ファイルではなく、稼働中のIMAPストアです。ネットワークがセッションを中断しかねない状況で、異なるフォルダー階層、サーバー固有の挙動、メッセージ識別子、認証方式を処理します。そのため、安全な実行はフォーラムから貼り付けた例より明示的です。
よくある失敗は地味でも高くつきます。
- 大きなメッセージのアップロード中にタイムアウトする。
- フォルダー名が正しく対応せず、メールが消えたように見える。
- プロバイダーが速度を制限し、接続を拒否し始める。
- 最新の認証によって通常のパスワードが拒否される。
- UID状態の変化で後続実行に重複が生じる。
- `--delete2`が切り替え後の新着メールを移行先から消す。
移行が「Sent Items以外はほぼ正常」だったなら偶然ではありません。予測可能な結果です。プロトコルに危険があり、既定値は守ってくれませんでした。
imapsyncの接続を維持するオプション
大容量メールボックスでは、メッセージの書き込み完了前に接続が切れて失敗することがよくあります。長いAPPEND処理、遅いExchangeサーバー、状態を管理するファイアウォールが主な原因です。タイムアウトを延ばし、接続維持信号を送り、状態をキャッシュして再実行時に最初から始めないようにします。
最初の本格的な実行では次を使います。
imapsync \
--host1 imap.source.tld --user1 user@source.tld --passfile1 ./pass1 \
--host2 imap.dest.tld --user2 user@dest.tld --passfile2 ./pass2 \
--timeout 120 \
--keepalive1 --keepalive2 \
--usecache各オプションの役割は次のとおりです。
| オプション | 重要な理由 | ない場合の問題 |
|---|---|---|
--timeout 120 | 遅いアップロードや大きな添付ファイルの完了を待てる。 | 接続タイムアウト後にメッセージが飛ばされる。 |
--keepalive1 --keepalive2 | 長い待機中も両方のIMAPセッションを維持する。 | ファイアウォールや負荷分散装置が切断する。 |
--usecache | 比較状態をローカル保存し、再実行を高速化する。 | 再開処理が遅くなり、すべてを再確認する。 |
キャッシュは想像以上に重要です。適切な移行は増分方式で進めます。一括処理を行い、認証やマッピングの問題を直し、一度か二度の追跡処理を行います。`--usecache`を使えば両側を読み直す時間が減ります。なければ再実行が不必要に重くなります。
ただし注意も必要です。公式文書は、`--usecache`がサイズと経過時間のフィルターを組み合わせた一部の状況で安全でないと警告しています。効率的に見えるからと無作為にフィルターを重ねないでください。最初の実行は単純に保ちます。
「フォルダー消失」を防ぐマッピングオプション
利用者がimapsyncでフォルダーを失ったと言っても、メールは残っていることが多いものです。移行先が元のパスを別の形で解釈したか、ローカライズされた特殊フォルダーが現行の送信済みに割り当てられていません。プロバイダー間で規則が違う場合は明示的な変換が必要です。
主な落とし穴は階層区切りと特殊フォルダーです。
たとえば、入れ子に点を使うサーバーも、スラッシュを使うサーバーもあります。移行元がINBOX.Clients.ProjectAで、移行先がINBOX/Clients/ProjectAを想定するなら、コピー中にパスを書き換えます。
imapsync \
--host1 old.example.com --user1 user@old.example.com --passfile1 ./pass1 \
--host2 imap.trekmail.net --user2 user@example.com --passfile2 ./pass2 \
--regextrans2 's/\./\//g'次は送信済みフォルダーです。呼び方はプロバイダーごとに違い、利用者は現在の送信済み画面に表示されることを求めます。
| 移行元フォルダー | 移行先フォルダー | 使えるオプション |
|---|---|---|
[Gmail]/Sent Mail | Sent Items | --regextrans2 's/^\[Gmail\]\/Sent Mail/Sent Items/' |
Sent | Sent Items | --regextrans2 's/^Sent/Sent Items/' |
Gesendete Elemente | Sent Items | --regextrans2 's/^Gesendete Elemente/Sent Items/' |
標準の特殊フォルダーがあるなら、まず--automapを試します。構成が乱れた、ローカライズ済みの、または古いcPanelメールボックスでは、明示的な正規表現変換が安全です。TrekMailには画面でインポートを開始する方法と、ドメインを追加する方法もあります。切り替え前の準備に役立ちます。
考え方の例：フォルダーは消えず、期待された送信済みから、クライアントが送信済みとして扱わない生のアーカイブ名へ移っただけです。同じデータでも場所が違い、結局同じ問い合わせになります。
GoogleやMicrosoftより先にimapsyncを制限する
ホスト型サービスから見ると、imapsyncは乱暴な通信に見える場合があります。多数のメールボックスでAPPENDとFETCHを集中実行すると、速度制限、一時停止、認証失敗に見える容量エラーが起きます。遮断されるより、遅く安定して進める方が速い場合があります。
Google WorkspaceやMicrosoft 365では速度を制御します。
imapsync \
--host1 imap.gmail.com --user1 user@source.tld --passfile1 ./pass1 \
--host2 imap.trekmail.net --user2 user@dest.tld --passfile2 ./pass2 \
--maxbytespersecond 500000 \
--maxmessagespersecond 2効果は二つです。プロバイダーの防御を起動する通信の山を減らし、小さなメッセージの集中による共有環境への負荷も抑えます。古いcPanel環境や既に負荷の高いOffice 365で重要です。
数値を絶対視しないでください。あくまで開始値です。適切な上限は容量、並列数、長時間IMAP処理に対する元プロバイダーの許容度で決まります。開始時は正常でも断続的に失敗し始めたら、パスワードを疑う前に速度を下げるのが原則です。
旧方式と新方式の差も明確になります。
旧方式：メールボックスごとにスクリプトを書き、試行錯誤で速度を調整し、午前2時にエラーを監視します。
新方式：TrekMail有料プランのサーバー側インポートで受信側を処理し、移行先を標準化してユーザー単位の料金を避けます。多数のドメインを扱う代理店は、一つの箱を十分早く終えることより、三日間も再試行を整理せずに済むことを重視します。該当するなら複数ドメインのメールホスティングを読んでください。
2025-2026年の認証オプション：パスワードからOAuthへ
Google WorkspaceとMicrosoft 365では、ユーザー名とパスワードだけのIMAP認証が機能するとは限りません。Googleによると、May 1, 2025以降、Workspaceアカウントでは両方だけでログインする「安全性の低いアプリ」を利用できません。Exchange OnlineもIMAPクライアントにOAuthを案内しています。
そのためimapsyncの実行方法が変わります。移行元がXOAUTH2に対応するなら、通常のパスワードではなくアクセストークンが必要です。
imapsync \
--host1 outlook.office365.com \
--user1 user@source.tld \
--authmech1 XOAUTH2 \
--oauthaccesstoken1 "ACCESS_TOKEN" \
--host2 imap.trekmail.net \
--user2 user@dest.tld --passfile2 ./pass2Google Workspaceでは、2-Step Verificationを有効にすれば、単発の移行にアプリパスワードが実用的な代替手段となります。Microsoft 365では旧プロトコル向けに文書化されたOAuthフローを使用します。「正しいパスワードなら認証できる」と考えるスクリプトは現状に合いません。
公式資料：安全性の低いアプリに関するGoogle Workspaceの案内とIMAP OAuthに関するMicrosoftの説明。
不良メールの欠落を防ぐ整合性オプション
古いサーバーには壊れたメッセージもあります。Message-IDヘッダーの欠落、不正なMIME、巨大な添付ファイル、空の本文は現実の移行で発生します。imapsyncで一部は回避できますが、方法を指定する必要があります。
最初に役立つのが--addheaderです。公式文書では、メッセージにない場合に生成したMessage-Idヘッダーを追加すると説明されています。imapsyncは識別情報で既存メッセージを判断するため重要です。
次が--maxsizeです。移行先の方針が巨大なメッセージを拒否するなら、一件で全体を止めないようにします。
imapsync \
--host1 old.example.com --user1 user@old.example.com --passfile1 ./pass1 \
--host2 imap.trekmail.net --user2 user@example.com --passfile2 ./pass2 \
--addheader \
--maxsize 35000000大きなメールが存在しないふりをするのではありません。まず99%を移し、管理された例外一覧で残りを手動処理します。
多数のメールボックスを並行展開するなら、整ったプロビジョニングも組み合わせます。作成、パスワード配布、DNS変更を別々の表で扱うと問題が悪化するため、TrekMailのメールアカウント一括作成も参考になります。
最悪のデータ損失を招くオプション：--delete2
`--delete2`は、移行元にないメッセージを移行先から削除します。完全なミラーには便利そうですが、実行時期を誤るとMX切り替え後の正当な新着メールを簡単に削除します。
失敗の流れは次のとおりです。
- 古いメールを移行先へ事前コピーする。
- MXを新しいプロバイダーへ切り替える。
- 新着メールが移行先に届き始める。
--delete2付きでimapsyncを再実行する。- 移行先だけにあるメールは移行元に存在しなかったため、imapsyncが削除する。
不具合ではなく、指示したとおりの動作です。
`--delete2`は切り替え前の管理されたミラーで、両側がまだ旧移行元を正とする場合だけ使用します。MX変更後はコマンドから外してください。移行先が稼働して受信しているなら、新着メールについて移行先を正とします。
UIDが信用できない場合はヘッダーで照合する
IMAP UIDは所属するサーバー状態の中だけで信頼できます。RFC 3501がUIDVALIDITYを定義するのは、状態変更でUIDの前提が崩れるためです。元フォルダーを再構築または再索引すると、imapsyncが全メッセージを新規と判断し、後で重複させる場合があります。
その場合はヘッダー照合が役立ちます。
imapsync \
--host1 old.example.com --user1 user@old.example.com --passfile1 ./pass1 \
--host2 imap.trekmail.net --user2 user@example.com --passfile2 ./pass2 \
--useheader 'Message-Id'サーバーUIDを信頼するより遅い一方、移行元が不安定、再構築済み、明らかに不整合な場合は安全です。公式文書も、重複問題は--useheader "Message-Id"への切り替えで解決することが多いと説明しています。
最終確認では、DNS切り替え前に慎重な照合で試行し、利用者が旧環境への書き込みを終えた後に短い差分を実行します。
安全なimapsyncコマンドのひな型
安全な実行では接続、マッピング、除外、テストモードを明示します。まず試行し、フォルダー動作を確認してから本番を実行します。最初の案で本番メールを操作しないでください。
imapsync \
--host1 imap.gmail.com --user1 user@source.com --passfile1 ./pass1 \
--host2 imap.trekmail.net --user2 user@dest.com --passfile2 ./pass2 \
--timeout 120 --keepalive1 --keepalive2 \
--usecache \
--automap \
--regextrans2 's/^\[Gmail\]\/Sent Mail/Sent Items/' \
--exclude '^\[Gmail\]/All Mail' \
--maxbytespersecond 500000 \
--maxmessagespersecond 2 \
--dry実務上の注意は三つです。
- 必ず先に
--dryを使う。 - 最初の実行では不要な巨大アーカイブを除外する。
- ログを記録し、移行単位でコマンドを版管理する。
TrekMailへ到着した後、利用者は標準IMAPでimap.trekmail.netのポート993へ接続します。TrekMailはIMAP専用でPOP3には対応しません。端末間で状態を同期するうえで適切な選択です。
まとめ：移行ツールとして運用すればimapsyncは機能する
imapsyncは今も多くの移行に適します。ただし単純なコピーコマンドではなく、状態を持つ移行ソフトとして扱う必要があります。タイムアウトと接続維持を設定し、意図的にフォルダーを対応付け、制限時には減速し、最新認証を使います。切り替え後のメールに`--delete2`を使わず、UID状態が疑わしければヘッダー照合を強制します。
受信側の管理を簡単にするなら、TrekMailは定額、共有ストレージ、有料プラン内蔵のサーバー側インポートを備えた複数ドメインの移行先となり、新しいメールボックスにもユーザー単位の料金を課しません。移行後の運用基盤にはビジネスメールの記事も参考になります。
