← RFC Reference

RFC 9051: IMAP4rev2

これが存在する理由

IMAP4rev1（RFC 3501、2003年発行）は、ほぼ20年間にわたりマルチデバイスメールの中核を担ってきました。しかし、数十の拡張RFC、曖昧なエッジケース、および実世界のあらゆるサーバーが異なる方法で実装する機能が蓄積されました。RFC 9051 — IMAP4rev2 — は以下を実現するクリーンな改訂です：

• 必須の拡張機能を統合。 CONDSTORE（条件付きストア）、NAMESPACE、ESEARCH、LIST-EXTENDED、LITERAL-、MOVEなどの機能は、オプションのアドオンではなく、ベースプロトコルの一部になりました。
• 非推奨機能を削除。 古い\Recentフラグはなくなりました。同時メールボックスアクセス周辺の曖昧な動作も同様です。
• 同期セマンティクスを明確化。 UIDVALIDITY、MODSEQ、および変更追跡の正確なルールにより、信頼できるオフライン対応クライアントの構築が可能になります。

新しいメールクライアントまたは統合を構築している場合は、IMAP4rev2をターゲットにしてください。サーバーがIMAP4rev1のみをサポートしている場合、コマンドセットはほぼ同じです。個別に拡張機能をネゴシエートするだけです。

仕組み

接続と認証

IMAPはポート143（STARTTLS）またはポート993（暗黙的TLS、推奨）を使用します。接続後、クライアントは認証します：

-- ポート993（IMAPS）に接続 --
* OK [CAPABILITY IMAP4rev2 AUTH=PLAIN] サーバー準備完了
a1 LOGIN alice@example.com s3cretP@ss
a1 OK [CAPABILITY IMAP4rev2 MOVE CONDSTORE] ログイン済み

すべてのクライアントコマンドにはタグ（a1など）が付きます。サーバーは同じタグで応答し、パイプラインコマンドが可能になります。タグなし応答（*で始まる）はメッセージ数とケーパビリティリストなどのデータを伝えます。

メールボックスの選択

a2 SELECT INBOX
* 42 EXISTS                            ← INBOXに42件のメッセージ
* OK [UIDVALIDITY 1609459200]         ← UID時代；これが変わったら再同期
* OK [UIDNEXT 1053]                   ← 次に割り当てられるUID
* OK [HIGHESTMODSEQ 7834]             ← 増分同期用（CONDSTORE）
* FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
a2 OK [READ-WRITE] SELECT完了

メッセージの取得

-- メッセージ1:5のエンベロープとフラグを取得 --
a3 FETCH 1:5 (FLAGS ENVELOPE)
* 1 FETCH (FLAGS (\Seen) ENVELOPE ("Wed, 12 Mar 2025 ..." ...))
* 2 FETCH (FLAGS () ENVELOPE (...))
...
a3 OK FETCH完了

-- メッセージUID 1050の完全本文を取得 --
a4 UID FETCH 1050 (BODY[])
* 41 FETCH (UID 1050 BODY[] {4523}
(完全なRFC 5322メッセージ...)
)
a4 OK UID FETCH完了

サーバー側検索

a5 SEARCH UNSEEN FROM "bob@example.com" SINCE 1-Mar-2025
* SEARCH 38 41 42
a5 OK SEARCH完了

主要な技術詳細

UIDとシーケンス番号

すべてのメッセージには2つの識別子があります：シーケンス番号（メールボックス内の位置で、メッセージが削除されると変わる）とUID（永続的に割り当てられた番号で、増加するだけ）です。堅牢なクライアントは常にUID FETCH、UID SEARCHなどを介してUIDを使用します。UIDVALIDITY値は、キャッシュされたUIDがまだ有効かどうかをクライアントに伝えます。変更された場合、クライアントはゼロから再同期する必要があります。

フラグ

IMAP4rev2は以下のシステムフラグを定義します：

IMAP4rev1の\Recentフラグはrev2で削除されました。サーバーはカスタムキーワード（例：$Forwarded、$Junk）もサポートする場合があります。

CONDSTOREとQRESYNC

CONDSTOREはフラグ変更ごとにMODSEQ値を割り当てます。最後に見たMODSEQを知っているクライアントは「MODSEQ 7834以降何が変わったか」と尋ねて、デルタのみを取得できます。QRESYNC（クイック再同期）はこれを拡張して、削除されたメッセージを効率的に処理します。一緒に使うと、IMAPはモバイルネットワークで完全な再同期が費用がかかりすぎる場合に実行可能になります。

MOVEコマンド

IMAP4rev1では、メッセージの移動にはCOPY + STORE \Deleted + EXPUNGE — 3つのコマンドと競合状態が必要でした。IMAP4rev2はMOVEをネイティブアトミック操作として含めます：

a6 UID MOVE 1050 "Archive"
* OK [COPYUID 1609459200 1050 287]
* 41 EXPUNGE
a6 OK MOVE完了

一般的な間違い

• 永続的な参照にシーケンス番号を使用。 メッセージが削除されるとシーケンス番号は変わります。キャッシュまたはセッション間で参照するものには常にUIDを使用してください。
• UIDVALIDITY変更を無視。 セッション間でUIDVALIDITYが変わった場合、キャッシュされたすべてのUIDは無効です。ローカルキャッシュを破棄して再同期する必要があります。
• IDLEを使用する代わりにポーリング。 IDLEコマンドはサーバーが新しいメッセージ通知をプッシュするのを許可します。30秒ごとにポーリングするとプッシュ通知とバッテリーを浪費します。リアルタイム更新にはIDLEを使用してください。
• BODY.PEEK[]が必要なときにBODY[]を取得。 FETCH BODY[]は暗黙的に\Seenフラグを設定します。読む場合はBODY.PEEK[]を使用してから未読のままにしてください。
• CONDSTOREをサポートしない。 CONDSTOREなしでは、再接続するたびに完全なメールボックス再同期が必要になります。最新のIMAPクライアントは常にCONDSTOREをネゴシエートする必要があります。
• ポート143でIMAPを実行しTLSなし。 RFC 8314に従って、暗黙的TLS付きのポート993を使用してください。

配信可能性への影響

• IMAPは取得プロトコルであり、送信プロトコルではありません。 POP3と同様に、それは直接アウトバウンド配信可能性に影響しません。これは受信者があなたが送るメールをどのように経験するかを決定します。
• フラグベースのエンゲージメント信号。 大手プロバイダ（Gmail、Outlook）はIMAP フラグ変更 — メッセージを\Seenとしてマーク、フォルダに移動、スターを付ける — をエンゲージメント信号として観察します。肯定的なエンゲージメントは時間とともに送信者評判を向上させることができます。
• スパムフォルダの相互作用。 受信者がIMAP経由でメッセージをジャンク外に移動すると、プロバイダはこれを「スパムではない」信号として扱うことがよくあります。逆に、ジャンクへのIMAP移動はあなたに対してカウントされます。
• バウンスメールボックス処理。 IMAPはバウンス処理に適しています。POP3よりも、サーバー側でDSNメッセージを検索し、処理して、アーカイブに移動できるためです。すべてのメッセージをダウンロードせずに行うことができます。

Related RFCs