IMAP IDLE 対応は何を確認すればよいですか？
IMAP IDLE は、クライアントがメールサーバーに変更通知を受け取る準備ができたと伝え、接続上で通知を待つ仕組みです。定期的に更新を問い合わせるポーリングとは、変更を知る方法が異なります。
RFC 2177 の IDLE 仕様では、IDLE 中にサーバーが EXISTS や EXPUNGE などの応答を送れます。同仕様では、サーバーが IDLE capability を通知しない場合、クライアントは IDLE を使わず、ポーリングする必要があります。
判定は次のように分けると、失敗した段階を追えます。
| 確認する段階 | 残す記録 |
|---|---|
| 仕様上の対応 | 公式資料の記載と確認日 |
| 接続先が示す機能 | 認証後の CAPABILITY 応答とプロトコルの版 |
| 実際の動作 | IDLE 開始応答、新着通知、対象メールの取得結果 |
| 切断後の復旧 | 再接続と、切断中に届いたメールの再同期結果 |
RFC 9051では、993 番は Implicit TLS のポートです。ポート番号は接続方式の情報であり、IDLE の動作確認の代わりにはなりません。
どのメールサービスが対応していますか？
Gmail の公式資料には、IDLE を含む CAPABILITY 応答例があります。Gmail の IMAP 拡張の説明で確認できます。利用するアカウントでも、認証後の応答と通知の受信を記録してください。Mailera 側の接続条件は Gmail 接続ガイドにまとめています。
サービスを比較するときは、サービス名だけの対応表ではなく、次の条件を各試行に添えます。
- プラン、地域、接続先、認証方式
- 試験日時とタイムゾーン、接続元、クライアント名とバージョン
- 宣言された IMAP 仕様、選択したフォルダー
- IDLE 開始、新着通知、再接続後の結果、匿名化したログの保存先
認証失敗は認証段階の失敗として残します。タイムアウトも、発生した段階を記録してください。どちらも、それだけで IDLE 非対応とは判定しません。
Outlook.com と Microsoft 365 は別枠です。Mailera の Microsoft 接続は OAuth と Microsoft Graph を使います。新着検知は Graph 変更通知と定期的な補完確認によるため、その成功を IMAP IDLE の結果に数えないでください。
同じ条件で確認する手順
自分が管理する試験用メールボックスを使います。サービス間で比較するなら、観測時間と試行回数、成功条件を先に決め、失敗した試行も残してください。
- 接続条件を固定します。 前節の項目を記録し、TLS で接続して認証します。別のプランや接続元で試した結果は、別の行に分けます。
- 認証後の機能を保存します。
CAPABILITY応答を記録します。接続直後の応答だけで判断せず、宣言された IMAP の版も残してください。RFC 2177 の判定条件を使うときは、その適用範囲をそろえます。 - 通知と取得を別々に確認します。
INBOXを選択して IDLE を開始し、継続応答を記録します。別の送信経路から識別用の件名を付けた試験メールを送り、EXISTSなどの応答を待ちます。通知を受けた時刻と、対象メールを取得できた時刻を分けて残します。 - IDLE を終了して入り直します。
DONEを送り、終了を確認してから次のコマンドを実行します。RFC 2177 では、サーバーがDONEを待つ間に別のコマンドを送ってはいけません。再度 IDLE を開始できるかも確認します。 - 切断と復旧を試します。 意図的に接続を切り、その間に試験メールを送ります。再接続後、切断中のメールを再同期できるか、その後の IDLE 通知を受け取れるかをそれぞれ記録します。
長時間の観測では、接続を放置しないでください。RFC 2177 は、非活動によるログアウトを避けるため、29 分を超えない間隔で IDLE を終了して再発行するよう勧めています。これはメールサービスごとの実測タイムアウト値ではありません。
独自サーバーを Mailera に接続する際の入力項目は、カスタム IMAP 接続ガイドで確認できます。
IDLE 通知と Webhook はどう違いますか？
IDLE は IMAP 接続上の変更通知です。アプリの URL に届く HTTP 通知ではありません。変更を知る処理、メールを取得する処理、Webhook を配信する処理を分けて観測します。
Maileraは既存のメールボックスを REST API や Webhook につなぎます。Webhook は POST /webhooks で登録し、新着イベントには message.received があります。迷惑メールの message.junk、接続切断の mailbox.disconnected も区別して扱えます。
Webhook の操作には webhooks スコープが必要です。登録時の署名用シークレットは一度だけ返されるため、安全に保存してください。登録形式は 開発者向け案内から API 資料を参照できます。
メール到着から Webhook 受信までの時間を比較する場合は、プロバイダー別の到着から Webhook 受信までのベンチマークを参照してください。
Microsoft Graph も、メールボックス内のメッセージの変更を購読し、通知先 URL を指定する仕組みです。Microsoft の変更通知の説明と、IMAP・Graph・SMTP の役割の違いを参照すると、監視経路を整理できます。
Mailera の監視表示はどう読みますか？
「メールボックスを追加」から「テストして接続」を実行すると、「リアルタイム監視」の結果を確認できます。この接続テストではメールを送信しません。試験メールを使った新着通知の確認は、別に行ってください。
画面の監視結果と、生の IMAP 接続で採ったログを並べて確認します。画面には接続条件を添えて記録し、サービス全体の対応表として扱わないようにします。
API では GET /mailboxes/{id} の protocol、capabilities.live、sync を確認できます。特に protocol を見て、Graph 経由の接続と IMAP の試験を分けてください。
よくある失敗：対応しているのに通知が届きません
「接続できた」「IDLE に入れた」「新着を取得できた」は別の結果です。最後に成功した段階から調べます。
| 症状 | 確認する記録 | 次の操作 |
|---|---|---|
| 認証を通過できない | 認証応答、アカウントの接続設定 | 認証と IMAP 利用条件を確認し、IDLE 判定は後にします |
| 接続できるが IDLE を開始できない | 認証後の CAPABILITY、プロトコルの版 | 適用する仕様と開始時の応答を照合します |
| IDLE 中に試験メールの通知がない | 選択フォルダー、メールの到着先、接続状態 | 同じフォルダーに届いたか確認します |
| しばらくすると通知が止まる | 切断時刻、IDLE の終了・再発行記録 | IDLE の更新と再接続を分けて試します |
| 通知はあるが処理に進まない | メール取得結果、Webhook 受信記録 | 通知後の取得と HTTP 受信を別々に調べます |
| Mailera の確認が止まって見える | sync.state、sync.sleeping_since | 使用状態を確認し、必要なら同期を実行します |
Mailera は使用中のメールボックスをより頻繁にバックグラウンド確認し、使われていないメールボックスでは確認頻度を下げます。非アクティブなメールボックスはスリープし、利用時に復帰する場合があります。この状態を、プロバイダーの IDLE 非対応と取り違えないでください。
POST /mailboxes/{id}/sync は同期を開始し、スリープ中のメールボックスを復帰させることもできます。必要なスコープは sync です。
検証の範囲と Mailera の制限
試験結果は、その日時、アカウント、プラン、地域、接続条件に限って扱います。Proton Mail と Tuta には対応しておらず、新しいメールボックスやメールアドレスも作成しません。
ログや画像から、認証情報、メールアドレス、本文を除去してください。API キーは試験対象と必要な権限に絞ります。
既存メールボックスを AI エージェントにつなぐ構成へ進む場合も、受信メールは信頼できないデータとして扱います。メール内の指示を実行命令にせず、送信前には人の確認を挟んでください。
