VPN は接続済みなのに IMAP が同期しない？三つの層を確認する

オフィスの VPN に接続し、メールクライアントを開くと、ウェブメールは正常に読み込まれるのに受信トレイが更新されません。よくある診断は、VPN が通信は通すがメールを遮断している、あるいはアカウントのパスワードが変わったというものです。どちらの推測も、IMAP クライアントが何をするかの構造を飛ばしています。ホストへの到達、TLS の完了、認証、メールボックスの選択は四つの別の出来事であり、VPN が持つのは最初の一つだけです。

通説：一つの接続は一つのログイン

トンネルが立ち、メールサーバーが応答すればメールボックスは事実上開いている、というのが通説です。そうではありません。VPN はサービスへの経路を提供するだけで、サインインもフォルダーの選択もしません。クライアントは、完全に動作するトンネルと有効なパスワードを持ちながら、その四つ目の段階で止まっていることがあります。

「VPN 経由だと IMAP が壊れる」という報告の多くは、実際にはこの隙間にあります。

三つの IMAP 状態と、クライアントが止まる場所

IMAP は未認証状態、認証済み状態、選択済み状態を定義し、コマンドはそれを許可する状態でのみ有効です。サーバーが事前認証を提供する場合、接続はすでに認証済みで始まることもあるため、パスワード入力の有無だけでは何も証明できません。メールボックスを選択するとセッションは認証済みから選択済みへ移り、メッセージを操作するコマンドに的ができるのはその時点です。

正常に認証したあと、設定されたフォルダーを選択できないクライアントは、サーバーが正しく動作していても同期の失敗のように見えます。名前を変えたフォルダー、「受信トレイ」を別の方法で対応づけるプロバイダー、欠けたアクセス権は、すべてここに落ちます。サーバーのタグ付き NO 応答が証拠であり、拒否されたパスワードへの応答とは別ものです。

TLS は IMAP の会話より先に来る

ポート 993 の暗黙的 TLS では IMAP コマンドが送られる前に TLS ハンドシェイクが完了するため、証明書の問題はメールではなく信頼に言及するエラーになります。メールのホスト名はウェブのホスト名と同じように証明書に対して検証される必要がありますが、通信を保つトンネルは無効な証明書を有効にはしません。

エラーの文言はケースを分けます。接続タイムアウトは SYN が完了しなかったことを意味します。TLS エラーは TCP 接続は成功し、ハンドシェイクが失敗したことを意味します。IMAP の NO または BAD 応答は、その両方が成功し、プロトコル層が何かを拒否したことを意味します。どのエラーを見たかを、設定を変える前に記録します。

キャッシュされたメールは何の証拠にもならない

メールクライアントは、今日サーバーに到達できるかどうかに関係なく、以前にダウンロードしたメッセージを表示するため、受信トレイが表示されることはローカル保存が機能していることしか示しません。実際のテストではサーバー操作を強制する必要があり、フォルダーを更新する、一度もダウンロードしていないメッセージを取得する、メールボックスを選択した後にしか出さないコマンドを送る、のいずれかを行います。

破壊的でない確認を使ってください。一つのフォルダーを更新してアカウントのエラーログを読むほうが、アカウントを削除して追加し直すより有益で、後者は主に設定画面がまだ動くことを証明するだけです。

送信とウェブメールは別のプロトコル

メールの送信は投稿であり、IMAP ではありません。別のサービスと、通常は別のポートを使い、独自の TLS モードと独自の認証を持つため、送信トレイが動いても IMAP のメールボックスが選択された証拠にはならず、送信トレイが壊れていても IMAP のせいにはできません。

ウェブメールはまた別です。同じ VPN でも成功することがありますが、それはウェブフロントエンドに対する HTTPS セッションだからであり、デスクトップクライアントの IMAP ホスト、ポート、TLS モードについては何も語りません。

引き継ぎでは、VPN の経路、メールエンドポイントと TLS の結果、アカウント認証の結果、メールボックス選択の結果という四つの結果を別々に記録します。認証情報とメッセージ内容はメモに残しません。この記録は、修正がネットワーク、証明書、アカウント、フォルダー設定のどれに属するかを次の人に伝え、どちらの保護層も弱めません。