あらゆるメールボックスのためのIMAP MCPサーバー、
Claude、Cursor、ChatGPT、どのMCPクライアントでも

見る場所は4つあり、手軽な順に並べます。1つ目、プロバイダー自身のヘルプページ。プロバイダー名と「IMAP 設定」で検索します。このサイトの各プロバイダーページはそのためにあります。2つ目、コントロールパネル。cPanelなら「Email Accounts」、「Connect Devices」、そして手動設定のブロック。Pleskなら「Mail」、該当アドレス、メールボックスへの接続画面です。たいていのホスティングパネルに相当する画面があり、あなたのアカウントについてはそれが正解です。3つ目、DNS。RFC 6186に従うプロバイダーは_imaps._tcp.yourdomain.comのSRVレコードでホストとポートをそのまま公開しています。4つ目、MXレコード。メールを受け取るマシンの名前が書かれており、IMAPホストと同じ系統の名前であることがとても多いです。通用しないのはimap.yourdomain.comと推測して祈ることです。ドメインと無関係な名前でメールを提供しているホストはいくらでもあります。

ほとんどのホスティング会社はmail.yourdomain.comを自社のメールサーバーに向けることを快く許可しますし、厳密に検証しないクライアントでは動きます。サーバーが提示する証明書は、ホスティング会社自身の名前、たとえばserver24.hostingprovider.netや自社ドメインのワイルドカードに対して発行されたもので、あなたのドメインに対してではありません。TLSを正しく検証するクライアントはホスト名の不一致で接続を拒否します。これはパスワード拒否とは別の失敗ですが、多くのインターフェイスは両者を区別しません。AIエージェントが送信できるメールボックスで、検証を切るのは許容できる対処ではありません。解決策は、証明書が本当に発行されている共有ホスト名、つまりプロバイダーが文書化している名前に接続することで、私たちが使うのもその名前です。

RFC 8314はプロバイダーに暗黙的TLSを優先するよう求めています。最初のバイトから接続が暗号化されるもので、IMAPはポート993、送信は465です。古い構成では143と587を使い、平文で始めてSTARTTLSでアップグレードします。プロバイダーのラベル付けはばらばらで、それが混乱の主因です。設定表の「SSL/TLS」はほぼ必ず993または465の暗黙的TLSを指し、「TLS」や「STARTTLS」はほぼ必ず143または587を指します。自分で解く必要はありません。アドレスを入力すれば、MCPEmailsが認識したホストについて両方のホスト、両方のポート、両方のセキュリティモードを埋め、試したトランスポートが応答しなければもう一方の標準を自動で再試行します。

SASL-IR（RFC 4959）：これを通知しないサーバーは、AUTHENTICATEコマンドと同じ行で送られた認証情報を拒否し、説明なしのBADだけを返します。パスワード間違いとまったく同じに見えます。MCPEmailsはこれを検出して2段階のやり取りで再試行するので、他のツールでは失敗するホストがここでは動きます。MOVE（RFC 6851）：これがないとメッセージをアトミックに移動できず、移動はコピー、フラグ更新、expungeになり、途中で接続が切れるとメッセージが両方のフォルダーに残ることがあります。SPECIAL-USE（RFC 6154）：これがないとサーバーは送信済み、下書き、ゴミ箱、迷惑メールを役割で示さず、フォルダーは名前で照合されます。ドイツ語、ノルウェー語、ロシア語で作られたメールボックスのシステムフォルダーは、あなたが名前を指定しない限りエージェントが認識できない名前になっています。フォルダー操作の挙動がおかしいときは、たいていこの3つのどれかが原因です。

• サーバーは公開インターネットから到達できる必要があります。プライベートネットワーク上、VPNの背後、プライベートIPアドレス上のメールボックスは意図的に拒否します。ホスト名を解決し、プライベート範囲のアドレスは弾きます。
• ダイヤルするのは標準のメールポートだけです。IMAPは143と993、SMTPは25、465、587。カスタムポートで待ち受けるサーバーには接続できません。
• OAuthを必須とし、IMAPでパスワードを受け付けないメールボックスはこの方法では接続できません。もっとも多いのはMicrosoft 365とOutlook.comで、IMAPではなくOutlookの選択肢（Microsoftでサインイン）で接続してください。