原文：ftp://ftp.rfc-editor.org/in-notes/rfc1730.txt
訳注：IMAP4仕様の最新はRFC3501です(2004/02/16時点)。

サイト内関連リンク：RFC 1939 POP3

Network Working Group
Request for Comments: 1730
Category: Standards Track

M. Crispin
University of Washington
December 1994

INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4

この文書の位置付け

この文書はインターネットコミュニティの為のインターネット標準トラックプロトコルについて述べており、改良に向けての議論と提案を求めている。このプロトコルの標準化の状態と状況は "Internet Official Protocol Standards"(STD 1)を参照して欲しい。この文書の配布は無制限である。

概要

Internet Message Access Protocol, Version 4 (IMAP4)は、クライアントがサーバー上の電子メールへのアクセスと操作を行う事を可能にする。IMAP4は"メールボックス"と呼ばれるリモートのメッセージフォルダの操作を可能にする。ある程度まで、それはローカルメッセージボックスに対してと同様に機能する。IMAP4はオフラインのクライアントがサーバーと再同期する機能も提供する([IMAP-DISC]参照)。

IMAP4は、メールボックスの作成・削除・名前変更、新規メッセージの確認、メッセージの完全な削除、フラグの設定と解除、RFC822とMIMEの解析、検索、メッセージの属性・文章・一部分からの選択取得の為の操作を含んでいる。IMAP4上のメッセージは数字を用いてアクセスされる。その数字は、メッセージ連番(1から始まりメールボックス内のメッセージ数までの相対位置)、またはユニーク識別子(各々のメッセージに割当てられる不変で厳密に増加する値であり、連番である必要はない)である。

IMAP4は単一サーバーをサポートする。複数IMAP4サーバーをサポートするメカニズムは[IMSP]で議論されている。

IMAP4はメール送信に付いては規定しない。その機能は[SMTP]のようなメール転送プロトコルが扱う。

IMAP4は[IMAP2]プロトコルの上位互換となるように設計されている。互換性の問題は[IMAP-COMPAT]で議論されている。

IMAP4プロトコル規約
 1. この文書の構成
 1.1. この文書の読み方
 1.2. この文書で使用される慣例
 2. プロトコル概観
 2.1. 回線水準
 2.2. 命令と応答
 2.2.1. プロトコル送信側クライアントとプロトコル受信側サーバー
 2.2.2. プロトコル送信側サーバーとプロトコル受信側クライアント
 3. 状態と流れ図
 3.1. 未認証状態
 3.2. 認証済み状態
 3.3. 選択済み状態
 3.4. ログアウト状態
 4. データフォーマット
 4.1. アトム
 4.2. 数値
 4.3. 文字列
 4.3.1. 8ビット及びバイナリの文字列
 4.4. 括弧で括られたリスト
 4.5. NIL
5. 操作上の考慮
 5.1. メールボックスの名前付け
 5.2. メールボックスサイズとメッセージス状態の更新
 5.3. 命令が進行中ではない場合の応答
 5.4. 自動ログアウトタイマー
 5.5. 進行中の複数命令
 6. クライアント命令
 6.1. クライアント命令 - 任意の状態
 6.1.1. CAPABILITY 命令
 6.1.2. NOOP 命令
 6.1.3. LOGOUT 命令
 6.2. クライアント命令 - 未認証状態
 6.2.1. AUTHENTICATE 命令
 6.2.2. LOGIN 命令
 6.3. クライアント命令 - 認証済み状態
 6.3.1. SELECT 命令
 6.3.2. EXAMINE 命令
 6.3.3. CREATE 命令
 6.3.4. DELETE 命令
 6.3.5. RENAME 命令
 6.3.6. SUBSCRIBE 命令
 6.3.7. UNSUBSCRIBE 命令
 6.3.8. LIST 命令
 6.3.9. LSUB 命令
 6.3.10. APPEND 命令
 6.4. クライアント命令 - 選択済み状態
 6.4.1. CHECK 命令
 6.4.2. CLOSE 命令
 6.4.3. EXPUNGE 命令
 6.4.4. SEARCH 命令
 6.4.5. FETCH 命令
 6.4.6. PARTIAL 命令
 6.4.7. STORE 命令
 6.4.8. COPY 命令
 6.4.9. UID 命令
 6.5. クライアント命令 - 実験的/拡張
 6.5.1. X<アトム> 命令
 7. サーバー応答
 7.1. サーバー応答 - 状態応答
 7.1.1. OK 応答
 7.1.2. NO 応答
 7.1.3. BAD 応答
 7.1.4. PREAUTH 応答
 7.1.5. BYE 応答
 7.2. サーバー応答 - サーバーとメールボックスの状態
 7.2.1. CAPABILITY 応答
 7.2.2. LIST 応答
 7.2.3. LSUB 応答
 7.2.4. SEARCH 応答
 7.2.5. FLAGS 応答
 7.3. サーバー応答 - メッセージの状態
 7.3.1. EXISTS 応答
 7.3.2. RECENT 応答
 7.3.3. EXPUNGE 応答
 7.3.4. FETCH 応答
 7.3.5. 時代遅れの応答
 7.4. サーバー応答 - 命令継続要求
 8. IMAP4セッション例
 9. 正式な文法
 10. 著者による注記
 11. セキュリティ考察
 12. 著者のアドレス
 付録
 A. 時代遅れの命令
 A.6.3.OBS.1. FIND ALL.MAILBOXES 命令
 A.6.3.OBS.2. FIND MAILBOXES 命令
 A.6.3.OBS.3. SUBSCRIBE MAILBOX 命令
 A.6.3.OBS.4. UNSUBSCRIBE MAILBOX 命令
 B. 時代遅れの応答
 B.7.2.OBS.1. MAILBOX 応答
 B.7.3.OBS.1. COPY 応答
 B.7.3.OBS.2. STORE 応答
 C. 参考文献
 E. IMAP4キーワードインデックス

IMAP4プロトコル規約

1. この文書の構成

1.1. この文書の読み方

この文書はMPAP4クライアントやIMAP4サーバー実装者の視点から書かれている。セクション2のプロトコル概観以降は、このプロトコルの操作を理解しようとする人向けには最適化されていない。セクション3からセクション5の資料は、IMAP4が扱う一般的な状況と定義を提供する。

セクション6・7・9はそれぞれ、IMAPの命令・応答・文法に付いて説明している。これらの関係は、この内のどれでも個別に理解する事はほとんど不可能な類いのものである。特に、命令のセクションのみから命令の文法を推測しようとするべきではない。その代わりに、正式な文法セクションを参照するべきである。

1.2. この文書で使用される慣例

例における"C:"と"S:"は、それぞれクライアントとサーバーから送信される行を示す。

2. プロトコル概観

2.1. 回線水準

IMAP4プロトコルは、TCPが提供するような信頼出来るデータストリームを仮定する。TCPが使用される場合、IMAP4サーバーはポート143を使用する。

2.2. 命令と応答

IMAP4セッションは、クライアント/サーバー接続の確立、サーバーからの最初の挨拶、クライアント/サーバーの対話から構成される。クライアント/サーバーの対話は、クライアントの命令、サーバーのデータ、サーバーの完了結果応答から成る。

クライアントとサーバーによって送信される全ての対話は、行形式、すなわちCRLFで終わる文字列である。IMAP4のクライアントやサーバーのプロトコル受信側は、一行を読むか、総数が分かっているオクテット列の後に一行を読む。

2.2.1. プロトコル送信側クライアントとプロトコル受信側サーバー

クライアントの命令がオペレーションを開始する。各クライアント命令には、"タグ"と呼ばれる識別子(通常は短い英数字の文字列。例えば A0001、A0002など)が置かれる。クライアントによって、各々の命令に対して異なるタグが生成される。

クライアントからの一行が完全な命令を表わさない場合が二つある。ひとつは、命令の引数がオクテット数として参照されている場合(データフォーマットにおける文字列中のリテラルに付いての説明を参照)、もうひとつは、命令の引数がサーバーの応答を必要とする場合(AUTHENTICATE命令を参照)である。どちらの場合も、サーバーが残りのコマンドと(もしあるなら)オクテットの準備が出来ると、命令継続要求応答を送る。この応答は"+"記号を前に置く。

注意: 命令実行中にサーバーがエラーを検出した場合、サーバーはその命令を拒否し、クライアントがその命令をそれ以上送信する事を防ぐ為に、その命令と一致するタグを付けたBAD完了応答(後に説明する)を送信する。

サーバーは、(複数の命令が進行中ならば)他の命令に対する完了応答またはタグ無しデータを送る事も可能である。どちらの場合でも命令継続応答は未解決のままであり、クライアントはその応答に対して適切なアクションを取り、サーバーからの別の応答を待つ。

IMAP4サーバーのプロトコル受信側は、クライアントからの命令行を読み、命令と引数を解析し、サーバーのデータや命令の完了結果応答を送信する。

2.2.2. プロトコル送信側サーバーとプロトコル受信側クライアント

サーバーからクライアントに送信されるデータや、命令完了を示す以外の状態応答は"*"記号を前に置き、タグ無し応答と呼ばれる。

サーバーデータはクライアント命令の結果として送っても良いし、サーバーから一方的に送っても良い。特定の命令の結果としてのサーバーデータと、一方的に送られるサーバーデータの間に文法的な違いはない。

サーバーの完了結果応答は操作の成功・失敗を表わし、その操作を開始したクライアント命令と同じタグを持つ。これにより、2つ以上の命令が同時進行中の場合、サーバーの完了結果応答のタグはその応答が適用される命令を指す事になる。

3つのサーバー完了応答が存在する：OK(成功を示す)、NO(失敗を示す)、BAD(認識できない命令や文法エラーといったプロトコルエラーを示す)。

IMAP4クライアントのプロトコル受信側は、サーバーからの応答行を読み、応答の最初の記号(タグ、"*"または"+")に基いて行動を起こす。これは上記で説明した通りである。

クライアントは常に、サーバーからのいかなる応答でも受け付ける用意が出来ていなければならない(MUST)。クライアントがサーバーにデータを要求する命令を送るのではなく、記録されたコピーを参照出来るように、サーバーデータは記録されるべきである(SHOULD)。特定のサーバーデータでは、その記録は強制的なものとなる。

この話題はサーバー応答セクションでより詳細に議論される。

3. 状態と流れ図

IMAP4サーバーは4つの状態の内のひとつを取る。ほとんどの命令は特定の状態でのみ有効である。ある命令が不適切な状態の時にクライアントがその命令を試みる事は、プロトコルエラーとなる。この場合サーバーは、BADまたはNO(サーバーの実装に依存する)を持つ命令完了結果を返す。

3.1. 未認証状態

未認証状態では、ユーザーは大部分の命令が許可される前に認証証明を提供しなければならない。接続が事前認証されていない限り、接続開始時にこの状態に入る。

3.2. 認証済み状態

認証済み状態ではユーザーは認証されており、メッセージに影響する命令が許可される前に、アクセスするメールボックスを選択しなければならない。この状態には、事前認証接続が開始された時、または受入可能な認証証明が提供された時、またはメールボックス選択中にエラーが起きた後に入る。

3.3. 選択済み状態

選択済み状態では、アクセスするメールボックスが選択されている。この状態にはメールボックスの選択が成功した時に入る。

3.4. ログアウト状態

ログアウト状態ではセッションは終了しようとしており、サーバーは接続を切ろうとしている。この状態には、クライアント要求の結果、または一方的なサーバーの決定によって入る。

            +--------------------------------------+
            |       初期接続とサーバーの挨拶       |
            +--------------------------------------+
                      || (1)       || (2)        || (3)
                      VV           ||            ||
            +-----------------+    ||            ||
            |     未認証      |    ||            ||
            +-----------------+    ||            ||
             || (7)   || (4)       ||            ||
             ||       VV           VV            ||
             ||     +----------------+           ||
             ||     |    認証済み    |<=++       ||
             ||     +----------------+  ||       ||
             ||       || (7)   || (5)   || (6)   ||
             ||       ||       VV       ||       ||
             ||       ||    +--------+  ||       ||
             ||       ||    |選択済み|==++       ||
             ||       ||    +--------+           ||
             ||       ||       || (7)            ||
             VV       VV       VV                VV
            +--------------------------------------+
            |        ログアウトと接続終了          |
            +--------------------------------------+

         (1) 事前認証のない接続 (OK greeting)
         (2) 事前認証された接続 (PREAUTH greeting)
         (3) 接続拒否 (BYE greeting)
         (4) LOGIN命令またはAUTHENTICATE命令の成功
         (5) SELECT命令またはEXAMINE命令の成功
         (6) CLOSE命令の後, または SELECT命令・EXAMINE命令の失敗
         (7) LOGOUT命令、サーバーシャットダウン、または接続終了

4. データフォーマット

IMAP4はテキスト形式の命令と応答を使用する。IMAP4のデータは次の形式のひとつを取る事が出来る：アトム、数値、文字列、括弧で括られたリスト、NIL。

4.1. アトム

アトムはひとつ以上の非特殊文字から成る。

4.2. 数値

数値はひとつ以上の数字からなり、数値を表わす。

4.3. 文字列

文字列は二つの形式の内のひとつを取る: リテラル、または引用符付き文字列。リテラル形式は文字列の一般的形式である。引用符付き文字列形式は、引用符付き文字列の中に含まれる文字の制限を犠牲にして、リテラルの処理のオーバーヘッドを避ける為の選択である。

リテラルは連続する0個以上のオクテット(CR、LFを含む)であり、左ブレース("{")・オクテット数・右ブレース("}")・CRLFという形式のオクテット数を前に置く。サーバーからクライアントにリテラルが送信される場合、オクテットデータの直後にCRLFが続く。クライアントからサーバーにリテラルが送信される場合、クライアントはオクテットデータ(および命令の残り)を送信する前に、命令継続要求(この文書内で後に説明する)の受信を待たなければならない。

引用符付き文字列は0個以上の7ビット文字の連続であり、CRLFを含まず、両端に二重引用符(<">)を持つ。

空文字列は、""(二重引用符の間に0文字を持つ引用符付き文字列)、または{0}の後にCRLFを付けて(オクテット数0のリテラルとして)表現される。

注意: オクテット数が0の場合でも、リテラルを送信するクライアントは命令継続要求を待たなければならない。

4.3.1. 8ビット及びバイナリの文字列

8ビットテキスト及びバイナリのメールは、[MIME-1]エンコードを通してサポートされる。IMAP4の実装は、リテラルとして8ビットまたは複数オクテットの文字を送信しても良い(MAY)が、それはその文字セットが識別可能な場合のみに限るべきである。

バイナリの本文のエンコードは定義されているが、エンコードされていないバイナリ文字列は許可されない。"バイナリ文字列"は、NUL文字を伴う任意の文字列である。データを送信する前に、実装はバイナリデータをBASE64のようなテキスト形式にエンコードしなければならない(MUST)。必須ではないが、多量のCTL文字を含む文字列もバイナリと見なして良い。

4.4. 括弧で括られたリスト

データ構造は"括弧で括られたリスト"(空白で区切られたデータ項目の並びで、両端を括弧で括る)として表わされる。括弧で括られたリストは、ネストを表す複数レベルの括弧を使用して、それ自身に別の括弧で括られたリストを含んでも良い。

空のリストは、()(メンバーを持たない括弧で括られたリスト)で表現される。

4.5. NIL

特殊なアトムである"NIL"は、文字列や括弧で括られたリストにおいて値が存在しない事を表わし、空文字列""や空のリスト()とは区別される。

5. 操作上の考慮

5.1. メールボックスの名前付け

メールボックス名の解釈は実装に依存する。ただし、INBOXというメールボックス名は、"このサーバー上でのこのユーザーの主要なメールボックス"を意味する為に予約された特別な名前である。階層的なメールボックス名をエクスポートしたい場合、メールボックス名は階層レベルを区切る為の単一文字を用いた左から右への階層構造にしなければならない。ひとつの名前の中では、全ての階層レベルの為に同じ階層区切り文字を使用する。

5.2. メールボックスサイズとメッセージ状態の更新

サーバーは、クライアントが要求していないデータをいつでも送信出来る。時々このような動作が必要になる。例えばサーバーとは別のエージェントがメールボックスにメッセージを追加したり(例えば新規メールの配送)、メールボックス中のメッセージのフラグを変更したり、メールボックスからメッセージを削除する場合である。命令処理中にメールボックスサイズの変更が検出された場合、サーバーは自動的にメールボックスサイズ更新を送信しなければならない(MUST)。クライアントからの明確な更新要求がない場合でも、サーバーは自動的にメッセージフラグ更新を送信するべきである(SHOULD)。メッセージの削除による同期エラーを防ぐ為に、サーバーからクライアントへの特別な規則の通知が存在する。詳細はEXPUNGE応答の説明を参照して欲しい。

クライアントがサーバーからのデータの記録を行うかどうかという実装の決定には関係なく、クライアントはメールボックスサイズの更新を記録しなければならない(MUST)。クライアントは最初のメールボックス選択後のいかなる命令も、メールボックスのサイズを返す事を仮定してはならない(MUST NOT)。

5.3. 命令が進行中ではない場合の応答

サーバー実装は、命令(EXPUNGEを除く)が進行中でない間にタグ無し応答を送信しても良い。このような応答を送信するサーバー実装は、フロー制御を扱わなければならない(MUST)。具体的には、(1)データのサイズが下層トランスポートで利用可能なウィンドウサイズを越えない事を確かめるか、(2)非ブロッキング書き込みを使用しなければならない。

5.4. 自動ログアウトタイマー

サーバーが非アクティブ自動ログアウトタイマーを持つ場合、タイマーは最低でも30分間持続時間を持たなければならない(MUST)。その間隔内でのクライアントからのいかなる命令の受信でも、自動ログアウトタイマーをリセットする為には十分であるべきである。

5.5. 進行中の複数命令

クライアントは、別の命令を送る前に完了結果応答を待つ必要はない(下層のフロー制御の影響は受ける)。同様にサーバーは、命令の結果が別の命令に影響を与えるような不明確さがない限り、次の命令処理を開始する前に別の命令を完了する必要はない。不明確さがある場合、サーバーはクライアントから与えられた順序で完了するように命令を実行する。

6. クライアント命令

このセクションではIMAP4の命令を説明する。命令は、その命令が許可される状態によってグループ化されている。複数の状態において許可される命令は、許可される最低限の状態にリストされている(例えば認証済み状態と選択済み状態で有効な命令は、認証済み状態にリストされている)。

以下の説明中の引数("引数:"で示されている)は、文法に従ってではなく、機能に従って説明されている。引数の正確な文法は、正式な文法セクションで説明されている。

いくつかの命令は特定のサーバーデータの返信を発生させる。これらは以下の説明中、"データ:"で示されている。これらの応答に付いての情報は応答セクションを参照し、正確な文法に付いては正式な文法セクション内の応答の説明を参照して欲しい。任意の命令の結果としてサーバーデータを送信する事が可能である。つまり、サーバーデータを特に必要としない命令では、"無し"の代わりに"その命令に対する特別なデータでは無い"データを指定しても良い。

説明中の"結果:"は、命令へのあり得るタグ付き状態応答と、それらの状態応答の特別な解釈に付いて言及している。

6.1. クライアント命令 - 任意の状態

次の命令はいかなる状態でも有効である：CAPABILITY,NOOP,LOGOUT

6.1.1. CAPABILITY 命令

引数:: 無し
データ:: タグ無し応答(必須): CAPABILITY
結果:: OK - 完了
BAD - 未知の命令、または引数が無効; CAPABILITY命令はサーバーがサポートする能力のリストを要求する。サーバーは(タグ付き)OK応答の前に、最初にリストされる能力として"IMAP4"を持つ、単独のタグ無しCAPABILITY応答を送信しなければならない(MUST)。能力のリストは接続状態やユーザーには依存しない為、あるセッション中に2回以上CAPABILITY命令を発行する必要はない。; "IMAP4"以外の能力名は、この規約の拡張または改定、改正を示す。追加情報はCAPABILITY応答の文章を参照して欲しい。どの能力も、その能力を呼び出すクライアントの明示的アクションがない限り使用出来ない。サイトや実装に特有の能力に付いては、"クライアント命令 - 実験用/拡張"のセクションを参照して欲しい。
例:: C: abcd CAPABILITY
S: * CAPABILITY IMAP4
S: abcd OK CAPABILITY completed

6.1.2. NOOP 命令

引数:: 無し
データ:: この命令への特別なデータは無い (しかし、下記参照)
結果:: OK - 完了
BAD - 未知の命令、または引数が無効; NOOP命令は常に成功する。これは何も実行しない。; 任意の命令にタグ無しデータとして状態更新を返す事が出来るので、NOOP命令は、新規メッセージや非アクティブ期間中のメッセージ状態更新の為の定期的ポーリングとして使用出来る。また、サーバーの非アクティブ自動ログアウトタイマーのリセットに使用する事も出来る。
例:: C: a002 NOOP
S: a002 OK NOOP completed
. . .
C: a047 NOOP
S: * 22 EXPUNGE
S: * 23 EXISTS
S: * 3 RECENT
S: * 14 FETCH (FLAGS (\Seen \Deleted))
S: a047 OK NOOP completed

6.1.3. LOGOUT 命令

引数:: 無し
データ:: タグ無し応答(必須): BYE
結果:: OK - 完了
BAD - 未知の命令、または引数が無効; LOGOUT命令は、クライアントがそのセッションを完了した事をサーバーに知らせる。サーバーは(タグ付き)OK応答の前に、タグ無しBYE応答を送信しなければならない。その後、ネットワーク接続を閉じる。
例:: C: A023 LOGOUT
S: * BYE IMAP4 Server logging out
S: A023 OK LOGOUT completed
(この後、サーバーとクライアントは接続を閉じる)

6.2. クライアント命令 - 未認証状態

未認証状態ではAUTHENTICATE命令またはLOGIN命令が認証を確立し、認証状態に入る。LOGIN命令が伝統的なユーザー名と平文パスワードの組合せを使用するのに対し、AUTHENTICATE命令は様々な認証技術の為の一般的メカニズムを提供する。

サーバー実装は、特定のメールボックスへの未認証アクセスを許可しても良い。慣例的には、ユーザーID"anonymous"でLOGIN命令を使用する。パスワードは必要である。パスワードに何を要求するかや、匿名ユーザーにどのようなアクセス制限を課すかは実装依存である。

一旦認証(匿名も含めて)されると、未認証状態に戻る事は出来ない。

汎用命令(CAPABILITY、NOOP、LOGOUT)に加えて、未認証状態では次の命令が有効である：AUTHENTICATE、LOGIN。

6.2.1. AUTHENTICATE 命令

引数:: 認証メカニズム名称
データ:: 継続データが要求される
結果:: OK - 認証完了。現在、認証済み状態である
NO - 認証失敗: 未サポートの認証メカニズム、証明拒否
BAD - 未知の命令、または引数が無効、認証交換の取り消し; AUTHENTICATE命令は、[IMAP-AUTH]に記述されているような認証メカニズムをサーバーに示す。サーバーは、要求された認証メカニズムをサポートしていれば、ユーザーを認証・識別する為に認証プロトコルの交換を行う。任意で、後続のプロトコル対話用の保護メカニズムも取り決める。要求された認証メカニズムがサポートされていない場合、サーバーはタグ付きNO応答の送信によってAUTHENTICATE命令を拒否するべきである。; 認証プロトコルの交換は、その認証メカニズムが規定する一連のサーバー要求と、クライアント応答から構成される。サーバー要求は、"+"の後にBASE64でエンコードされた文字列を持つ命令継続要求応答で構成される。クライアント応答は、BASE64でエンコードされた文字列を含む一行で構成される。クライアントが認証交換を取り消したい場合、単独の"*"を持つ行を発行するべきである。そのような応答を受け取った場合、サーバーはタグ付きBAD応答の送信によってAUTHENTICATE命令を拒否しなければならない。; 保護メカニズムは、プロトコルセッションに統一性と機密保護を提供する。保護メカニズムが取り決められた場合、それはその接続全体にわたって送信される後続の全データに適用される。保護メカニズムは、クライアントの認証交換を締め括るCRLFと、サーバーのタグ付きOK応答のCRLFの後、即座に効果を効果を示す。一旦保護メカニズムの影響下に入ると、命令と応答オクテットのストリームは暗号文のバッファを通して処理される。各々のバッファは、後続データの長さを表すネットワークバイトオーダーの4オクテットを最初に付けたオクテットのストリームとして、接続全体を通じて送信される。暗号文バッファの最大長は、保護メカニズムによって定義される。; サーバーは特定の認証メカニズムをサポートする必要はないし、認証メカニズムはどの保護メカニズムもサポートしなくても良い。AUTHENTICATE命令がNO応答によって失敗した場合、クライアントは別のAUTHENTICATE命令を発行する事で別の認証メカニズムを試みても良いし、LOGIN命令による認証を試みても良い。言い換えると、優先順位の高い順に認証を要求し、最後の手段としてLOGIN命令を使用して良い。
例:: S: * OK KerberosV4 IMAP4 Server
C: A001 AUTHENTICATE KERBEROS_V4
S: + AmFYig==
C: BAcAQU5EUkVXLkNNVS5FRFUAOCAsho84kLN3/IJmrMG+25a4DT
+nZImJjnTNHJUtxAA+o0KPKfHEcAFs9a3CL5Oebe/ydHJUwYFd
WwuQ1MWiy6IesKvjL5rL9WjXUb9MwT9bpObYLGOKi1Qh
S: + or//EoAADZI=
C: DiAF5A4gA+oOIALuBkAAmw==
S: A001 OK Kerberos V4 authentication successful; 注意: 最初のクライアント応答内の改行は編集上の配慮であり、実際には改行は無い。

6.2.2. LOGIN 命令

引数:: ユーザー名
パスワード
データ:: この命令への特別なデータは無い
結果:: OK - 完了。現在、認証済み状態である
NO - 失敗: ユーザー名かパスワードが拒否された
BAD - 未知の命令、または引数が無効; LOGIN命令はサーバーに対してユーザーを特定し、そのユーザーを認証する平文パスワードを送る。
例:: C: a001 LOGIN SMITH SESAME
S: a001 OK LOGIN completed

6.3. クライアント命令 - 認証済み状態

認証済み状態では、メールボックスを一塊として扱う命令が許可される。これらの命令の内SELECT命令とEXAMINE命令がアクセスするメールボックスを選択し、選択済み状態に入らせる。

認証済み状態では、汎用命令(CAPABILITY、NOOP、LOGOUT)に加えて次の命令が有効である：SELECT、 EXAMINE、 CREATE、 DELETE、 RENAME、 SUBSCRIBE、 UNSUBSCRIBE、 LIST、 LSUB、 APPEND。

6.3.1. SELECT 命令

引数:: メールボックス名
データ:: タグ無し応答(必須): FLAGS、EXISTS、RECENT
タグ無しOK応答(任意): UNSEEN、PERMANENTFLAGS
結果:: OK - 完了。現在、選択済み状態である
NO - 失敗。現在、認証済み状態である: メールボックスが存在しない。メールボックスにアクセス出来ない
BAD - 未知の命令、または引数が無効; SELECT命令は、メールボックス内のメッセージにアクセス出来るようにメールボックスを選択する。サーバーはクライアントにOKを返す前に、クライアント側でメールボックスの初期状態を定義出来るように、以下のタグ無しデータをクライアントに送信しなければならない(MUST)。
FLAGS メールボックスの定義済みフラグ

<n> EXISTS メールボックス内のメッセージ数

<n> RECENT 前回そのメールボックスが読まれた時からメールボックスに追加されたメッセージ数

OK [UIDVALIDITY <n>] ユニーク識別子を確認する値。詳細はUID命令の説明を参照して欲しい。; 前回そのメールボックスが読まれた時以降に追加されたメッセージを特定出来ない場合、全てのメッセージが新規と見なされるべきである(SHOULD)。; さらにサーバーは、メールボックス中の最初の未読メッセージのメッセージ番号を示す為に、タグ無しOK応答の中にUNSEEN応答コードを含めて送るべきである(SHOULD)。; クライアントがタグ無しFLAGS応答中にリストされるフラグの内ひとつ以上のフラグの恒久的状態を変更出来ない場合、サーバーはタグ無しOK応答の中でPERMANENTFLAGS応答コードを送り、クライアントが恒久的に変更出来るフラグをリストするべきである(SHOULD)。; ひとつのセッション中には一度にひとつのメールボックスのみ選択して良い。従って複数メールボックスに同時アクセスするには、複数セッションが必要である。; SELECT命令は、新しい選択を試みる前に、現在選択されているメールボックスを自動的に開放する。結果として、メールボックスが選択されていて、かつSELECT命令が失敗した場合、どのメールボックスも選択されない。; ユーザーがメールボックスを変更する事を許可される場合、サーバーは、タグ付きOK応答の後に、"[READ-WRITE]"応答コードを付けたテキストを置くべきである(SHOULD)。; ユーザーがメールボックスを変更する事は許可されないが読み取りは許可される場合、メールボックスは読取専用として選択され、サーバーはSELECTに対するタグ付きOK応答の後に"[READ-ONLY]"応答コードを付加したテキストを置かなければならない(MUST)。SELECT命令を通しての読取専用アクセスはEXAMINE命令と異なり、特定の読取専用メールボックスにおいて(グローバルと逆に)ユーザー毎の基準に基づく恒久的状態変更を許可される。ユーザーの.newsrcファイルに記録されるネットニュースメッセージは、そのような読取専用メールボックスで変更可能なユーザー毎の恒久的状態の例である。
例:: C: A142 SELECT INBOX
S: * 172 EXISTS
S: * 1 RECENT
S: * OK [UNSEEN 12] Message 12 is first unseen
S: * OK [UIDVALIDITY 3857529045] UIDs valid
S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
S: * OK [PERMANENTFLAGS (\Deleted \Seen \*)] Limited
S: A142 OK [READ-WRITE] SELECT completed

6.3.2. EXAMINE 命令

引数:: メールボックス名
データ:: タグ無し応答(必須): FLAGS、EXISTS、RECENT
タグ無しOK応答(任意): UNSEEN、PERMANENTFLAGS
結果:: OK - 完了。現在、選択済み状態である
NO - 失敗。現在認証済み状態である: そのメールボックスが無い。メールボックスにアクセス出来ない
BAD - 未知の命令、または引数が無効; EXAMINE命令はSELECTと同一であり、同じ出力を返す。ただし、選択されたメールボックスは読取専用と見なされ、いかなる恒久的状態変更(ユーザー毎の状態も含めて)も許可されない。; EXAMINE命令に対するタグ付きOK応答のテキストは、"[READ-ONLY]"応答コードで始まらなければならない(MUST)。
例:: C: A932 EXAMINE blurdybloop
S: * 17 EXISTS
S: * 2 RECENT
S: * OK [UNSEEN 8] Message 8 is first unseen
S: * OK [UIDVALIDITY 3857529045] UIDs valid
S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
S: * OK [PERMANENTFLAGS ()] No permanent flags permitted
S: A932 OK [READ-ONLY] EXAMINE completed

6.3.3. CREATE 命令

引数:: メールボックス名
データ:: この命令に対する特別なデータは無い
結果:: OK - 完了
NO - 失敗: その名前でメールボックスを作成出来ない
BAD - 未知の命令、または引数が無効; CREATE命令は、与えられた名前でメールボックスを作成する。OK応答は、その名前で新規メールボックスが作成された場合にのみ返される。INBOXまたは既存のメールボックスと同じ名前のメールボックスを作成しようとすると、エラーとなる。作成中のいかなるエラーも、タグ付きNO応答を返す。; メールボックス名の最後の文字がサーバーの階層区切り文字(LIST命令でサーバーから返される)の場合、それは、クライアントが将来階層内のその名前の下にメールボックスを作成するかもしれないという宣言である。この宣言を必要としないサーバー実装は、これを無視しなければならない(MUST)。; 削除されたメールボックスと同じ名前で新規メールボックスが作成された場合、そのメールボックスのユニーク識別子は、新しいメールボックスが異なるユニーク識別子有効値を持たない限り、以前のメールボックスで使用されていた全てのユニーク識別子よりも大きくなくてはならない(MUST)。詳細はUID命令の説明を参照して欲しい。
例:: C: A003 CREATE owatagusiam/
S: A003 OK CREATE completed
C: A004 CREATE owatagusiam/blurdybloop
S: A004 OK CREATE completed; 注意: この例の解釈は、LISTの階層区切りとして"/"が返されていたかどうかに依存する。"/"が階層区切りの場合、"blurdybloop"というメンバーを持つ"owatagusiam"という名前の新しい階層レベルが作成される。そうでない場合、二つのメールボックスが同じ階層レベルに作成される。

6.3.4. DELETE 命令

引数:: メールボックス名
データ:: この命令に対する特別なデータは無い
結果:: OK - 完了
NO - 失敗: その名前のメールボックスを削除出来ない
BAD - 未知の命令、または引数が無効; DELETE命令は、与えられた名前のメールボックスを完全に削除する。タグ付きOK応答は、メールボックスが削除された場合にのみ返される。INBOXまたは存在しない名前のメールボックスを削除しようと、エラーとなる。削除中のいかなるエラーも、タグ付きNO応答を返す。; 削除されたメールボックスのユニーク識別子の最大値は、同じ名前で作成された新しいメールボックスが前の識別子を再利用しないように、その新規メールボックスが異なるユニーク識別子有効値を持たない限り、保存されなければならない(MUST)。詳細はUID命令の説明を参照して欲しい。
例:: C: A683 DELETE blurdybloop
S: A683 OK DELETE completed

6.3.5. RENAME 命令

引数:: 既存メールボックス名
新規メールボックス名
データ:: この命令への特別なデータは無い
結果:: OK - 完了
NO - 失敗: そのメールボックスは名前変更出来ない。メールボックスをその名前に変更できない
BAD - 未知の命令、または引数が無効; RENAME命令は、メールボックスの名前を変更する。タグ付きOK応答は、メールボックスの名前が変更された場合にのみ返される。存在しないメールボックス名からの変更や、既に存在するメールボックス名への変更はエラーとなる。名前変更中のいかなるエラーも、タグ付きNO応答を返す。; INBOXの名前変更も許されており、その場合、新しい空のINBOXが作成される。
例:: C: Z4S9 RENAME blurdybloop owatagusiam
S: Z4S9 OK RENAME completed

6.3.6. SUBSCRIBE 命令

引数:: メールボックス
データ:: この命令に対する特別なデータは無い
結果:: OK - 完了
NO - 失敗: その名前で購読出来ない
BAD - 未知の命令、または引数が無効; SUBSCRIBE命令は指定されたメールボックスを、LSUB命令の応答として返されるサーバーの"アクティブ"または"購読中"の集合に追加する。この命令は購読が成功した場合のみ、タグ付きOK応答を返す。
例:: C: A002 SUBSCRIBE #news.comp.mail.mime
S: A002 OK SUBSCRIBE completed

6.3.7. UNSUBSCRIBE 命令

引数:: メールボックス名
データ:: この命令に対する特別なデータは無い
結果:: OK - 完了
NO - 失敗: そのメールボックスの購読を取り消し出来ない
BAD - 未知の命令、または引数が無効; UNSUBSCRIBE命令は指定されたメールボックスを、LSUB命令の応答として返されるサーバーの"アクティブ"または"購読中"の集合から削除する。この命令は購読の取り消しが成功した場合のみ、タグ付きOK応答を返す。
例:: C: A002 UNSUBSCRIBE #news.comp.mail.mime
S: A002 OK UNSUBSCRIBE completed

6.3.8. LIST 命令

引数:: 参照名
メールボックス名(ワイルドカード可)
データ:: タグ無し応答: LIST
結果:: OK - 完了
NO - 失敗: その参照または名前でのリストが出来ない
BAD - 未知の命令、または引数が無効; LIST命令は、ユーザーが利用可能な全ての名前の集合から、そのサブセットを返す。名前の属性・階層区切り文字・名前を含む、0個以上のタグ無しLIST応答が返される。より詳細はLIST応答の説明を参照して欲しい。; 空の参照名(文字列"")の引数は、SELECTされているメールボックス名であると解釈される。返されるメールボックス名は、与えられたメールボックス名のパターンと一致しなければならない。空ではない参照名の引数は、メールボックス名またはメールボックス階層レベルであり、実装定義の方法でメールボックス名が解釈される場合のコンテキストを示す。; 引数の参照名とメールボックス名は、曖昧さのない左から右へ階層を表す標準的な形式に(実装依存の方法で)解釈される。返されるメールボックス名は解釈された形式に沿う。; 解釈された形式に含まれる参照名引数のどの部分も、解釈された形式を前に置くべきである(SHOULD)。また参照名引数と同じ形式にも従うべきである。この規則によりクライアントは、返されたメールボックス名が参照引数の文脈なのか、あるいはメールボックス引数が参照引数を上書きしたかのかを判断出来る。この規則がなければ、クライアントは、どの文字が名前付けコンテキストを上書きする"ブレークアウト"なのかを含めた、サーバーの名前付け規則の情報を持たなければならないだろう。; 例として、UNIXベースのサーバーにおいて、参照とメールボックス名がどのように解釈されるかの例をここに示す。; 最初の3つの例は、参照引数の文脈中の解釈のされかたを実演している。"~smith/Mail"が"/u2/users/smith/Mail"といった形に変換されるべきではない点に注意して欲しい。そうでないと、クライアントはその解釈が参照のコンテキストである事を判断できないだろう。; 文字"*"はワイルドカードであり、その位置の0個以上の文字と一致する。文字"%"は"*"と似ているが、階層区切り文字とは一致しない。メールボックス名引数の最後の文字がワイルドカード"%"の場合、一致する階層レベルも返される。それらの階層レベルが選択出来ないメールボックスの場合、\Noselectというメールボックス名属性付きで返される(より詳細はLIST応答の説明を参照)。; サーバー実装は、特定の状況で特定の文字や名前がワイルドカードに一致する事を妨く事で、ワイルドカードとは別の方法でアクセス出来るメールボックスを"隠す"事が出来る。例えばUNIXベースのサーバーでは、先頭の"/"が"*"と一致しないように解釈を制限しても良い。; 特別な名前INBOXは、それが入力引数に一致するのならLISTの出力に含まれ、そのサーバーによってそのユーザーの為にサポートされる。INBOXが除外される条件は、SELECT INBOXが失敗を返すかどうかであり、ユーザーの実際のINBOXがそのサーバ上か別のサーバー上に存在するかどうかとは無関係である。
例:: C: A002 LIST "~/Mail/" "%"
S: * LIST (\Noselect) "/" ~/Mail/foo
S: * LIST () "/" ~/Mail/meetings
S: A002 OK LIST completed

6.3.9. LSUB 命令

引数:: 参照名
メールボックス名(ワイルドカード可)
データ:: タグ無し応答: LSUB
結果:: OK - 完了
NO - 失敗: その参照または名前でリスト出来ない
BAD - 未知の命令、または引数が無効; LSUB命令は、ユーザーが"アクティブ"または"購読中"と宣言した名前の集合から、そのサブセットを返す。0個以上のタグ無しLSUB応答が返る。LSUBへの引数は、LISTの引数と同じ形式である。
例:: C: A002 LSUB "#news." "comp.mail.*"
S: * LSUB () "." #news.comp.mail.mime
S: * LSUB () "." #news.comp.mail.misc
S: A002 OK LSUB completed

6.3.10. APPEND 命令

引数:: メールボックス名
括弧で括られたフラグのリスト(任意)
日付/時刻を表す文字列(任意)
メッセージリテラル
データ:: この命令への特別なデータは無い
結果:: OK - 完了
NO - エラー: そのメールボックスに追加出来ない。フラグ・日付/時刻・メッセージテキストにエラーがある
BAD - 未知の命令、または引数が無効; APPEND命令は、指定されたメールボックスに新しいメッセージとしてリテラルの引数を追加する。この引数は[RFC-822]メッセージ形式に従う。メッセージ中に8ビット文字を使用しても良い。8ビットデータを適切に保存出来ないサーバー実装は、APPENDする8ビットデータを[MIME-1]エンコードを使用して7ビットに可逆変換出来なければならない(MUST)。; 括弧で括られたフラグのリスト、または日付時刻が指定された場合、その情報は処理されるメッセージに対して設定さるべきである(SHOULD)。指定されていない場合、空のフラグと現在の日付/時刻が既定値として使用される。; 何らかの理由により追加が失敗した場合、メールボックスはAPPENDされる前の状態に復元されなければならない(MUST)。つまり、部分的追加は許可されない。もし現在メールボックスが選択されていれば、通常の新規メールの動作が起こるべきである。; 対象メールボックスが存在しない場合、サーバーは自動的にメールボックスを作成してはならず(MUST NOT)、エラーを返さなければならない(MUST)。対象メールボックスが作成出来ない事が確実ではない限り、サーバーはタグ付きNO応答のテキストの接頭辞として、応答コード"[TRYCREATE]"を送信しなければならない(MUST)。これはクライアントに、CREATE命令を試し、もし成功すれば再びAPPENDを試みる事が出来るというヒントを与える。
例:: C: A003 APPEND saved-messages (\Seen) {310}
C: Date: Mon, 7 Feb 1994 21:52:25 -0800 (PST)
C: From: Fred Foobar <foobar@Blurdybloop.COM>
C: Subject: afternoon meeting
C: To: mooch@owatagu.siam.edu
C: Message-Id: <B27397-0100000@Blurdybloop.COM>
C: MIME-Version: 1.0
C: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
C:
C: Hello Joe, do you think we can meet at 3:30 tomorrow?
C:
S: A003 OK APPEND completed; 注意: APPEND命令はメッセージの配送には使用されない。なぜなら [SMTP]エンベロープ情報を送信するメカニズムを提供しないからである。

6.4. クライアント命令 - 選択済み状態

選択済み状態では、メールボックス中のメッセージを操作する命令が許可される。

汎用命令(CAPABILITY、 NOOP、 LOGOUT)と、認証済み状態命令(SELECT、 EXAMINE、 CREATE、 DELETE、 RENAME、 SUBSCRIBE、 UNSUBSCRIBE、 LIST、 LSUB、 FIND ALL.MAILBOXES、 FIND MAILBOXES、 APPEND)に加えて、選択済み状態では次の命令が有効である：CHECK、 CLOSE、 EXPUNGE、 SEARCH、 FETCH、 PARTIAL、 STORE、 COPY、 UID。

6.4.1. CHECK 命令

引数:: 無し
データ:: この命令への特別なデータは無い
結果:: OK - 完了
BAD - 未知の命令、または引数が無効; CHECK命令は、現在選択されているメールボックスのチェックポイントを要求する。チェックポイントとは、各命令の一部としては通常実行されないメールボックスに関連する任意の実装依存作業(例えば、サーバーのメモリ上にあるメールボックスの状態をディスクに保存する)である。チェックポイントは即座に完了されなくても良い。サーバー実装がこのような作業を考慮していない場合、CHECKはNOOPと同じである。; CHECKの結果として、タグ無しEXISTS応答が発生する事は保証されない。新規メールのポーリングにはCHECKではなく、NOOPが使用されるべきである。
例:: C: FXXZ CHECK
S: FXXZ OK CHECK Completed

6.4.2. CLOSE 命令

引数:: 無し
データ:: この命令への特別なデータは無い
結果:: OK - 完了。現在、認証済み状態である
NO - 失敗: メールボックスが選択されていない
BAD - 未知の命令、または引数が無効; CLOSE命令は、現在選択されているメールボックスから\Deletedフラグがセットされている全てのメッセージを完全に削除し、選択済み状態から認証済み状態に戻す。タグ無しEXPUNGE応答は送信されない。; メールボックスがEXAMINE命令で選択されているか、読取専用で選択されている場合、メッセージは削除されず、エラーも発生しない。; メールボックスが選択されている場合でも、SELECT命令・EXAMINE命令・LOGOUT命令の前にCLOSE命令を送信する必要はない。SELECT命令・EXAMINE命令・LOGOUT命令は、削除を行わずに、暗黙のうちに現在選択されているメールボックスを閉じる。しかしながら多くのメッセージが削除されている場合、CLOSE-LOGOUTやCLOSE-SELECTの流れは、EXPUNGE-LOGOUTやEXPUNGE-SELECTよりもかなり速くなる。なぜなら、(おそらくクライアントは無視するであろう)タグ無しEXPUNGE応答が送信されないからである。
例:: C: A341 CLOSE
S: A341 OK CLOSE completed

6.4.3. EXPUNGE 命令

引数:: 無し
データ:: タグ無し応答: EXPUNGE
結果:: OK - 完了
NO - 失敗: 削除できない(例権限が無い)
BAD - 未知の命令、または引数が無効; EXPUNGE命令は、現在選択されているメールボックスから\Deletedフラグがセットされている全てのメールを完全に削除する。クライアントにOKが返される前に、削除されたメッセージ毎にタグ無しEXPUNGE応答が送信される。
例:: C: A202 EXPUNGE
S: * 3 EXPUNGE
S: * 3 EXPUNGE
S: * 5 EXPUNGE
S: * 8 EXPUNGE
S: A202 OK EXPUNGE completed; 注意: この例では、メッセージ3,4,7,11に\Deletedフラグがセットされていた。より詳しい説明はEXPUNGE応答の説明を参照して欲しい。

6.4.4. SEARCH 命令

引数:

文字セット指定(任意)
検索条件(ひとつ以上)

データ:

タグ無し応答(必須): SEARCH

結果:

OK - 完了
NO - エラー: その文字セットまたは条件を検索出来ない。
BAD - 未知の命令、または引数が無効

SEARCH命令は、与えられた検索条件に一致するメールボックス内のメッセージを検索する。検索条件は1つ以上の検索キーから成る。サーバーからのタグ無しSEARCH応答は、検索条件に一致するメッセージに対応するメッセージ連番のリストを含む。

複数のキーが指定された場合、結果はそれらのキーに一致するメッセージの積(AND演算)である。例えば、DELETED FROM "SMITH" SINCE 1-Feb-1994 という条件は、1994年2月1日以降にそのメールボックスに保存されてたSmithからの削除された全メッセージを表す。検索キーは1つ以上のキーが括弧で括られたリストであっても良い(例えば、OR条件やNOT条件の使用の為)。

サーバー実装は、SEARCH検索の対象からTEXTとMESSAGE以外に、[MIME-1]本文部分を除いても良い(MAY)。

オプションの文字セット指定は、単語"CHARSET"に続く登録済みMIME文字セットから構成され、検索条件に現れる文字列の文字セットを示す。RFC 822/MIMEメッセージヘッダの中に現れる[MIME-2]文字列と[MIME-1]エンコードは、検索の前にデコードされなければならない(MUST)。US-ASCIIを除き、いかなる特定の文字セットもサポートする必要はない。指定された文字セットをサポートしていない場合、サーバーはタグ付きNO応答(BADではなく)を返さなければならない(MUST)。

文字列を使用する検索キーは全て、それがフィールドの部分文字列であっても一致する。検索は大文字・小文字を区別しない。

定義済み検索キーは以下の通り。引数の正確な文法定義は、正式な文法セクションを参照して欲しい。

<メッセージセット>: 指定されたメッセージ連番の集合に一致するメッセージ連番を持つメッセージ
ALL: メールボックス中の全メッセージ。ANDの為のデフォルトキー
ANSWERED: \Answeredフラグを持つメッセージ
BCC <文字列>: エンベロープ構造のBCCフィールドに指定文字列を含むメッセージ
BEFORE <日付>: 内部日付が指定された日付より前のメッセージ
BODY <文字列>: メッセージ本文に指定文字列を含むメッセージ
CC <文字列>: エンベロープ構造のCCフィールドに指定文字列を含むメッセージ
DELETED: \Deletedフラグを持つメッセージ
DRAFT: \Draftフラグを持つメッセージ
FLAGGED: \Flaggedフラグを持つメッセージ
FROM <文字列>: エンベロープ構造のFROMフィールドに指定文字列を含むメッセージ
HEADER <フィールド名> <文字列>: ヘッダに指定フィールド名([RFC-822]で定義される)を持ち、その[RFC-822]フィールド本文に指定文字列を含むメッセージ
KEYWORD <フラグ>: 指定されたキーワードを持つメッセージ
LARGER <n>: 指定された数のオクテット数より大きいRFC822.SIZEを持つメッセージ
NEW: \Recentフラグを持ち\Seenフラグを持たないメッセージ。
これは"(RECENT UNSEEN)"と同じ機能である。
NOT <検索キー>: 指定された検索キーに一致しないメッセージ
OLD: \Recentフラグを持たないメッセージ
これは"NOT RECENT"("NOT NEW"ではなく)と同じ機能である。
ON <日付>: 内部日付が指定日付のメッセージ
OR <検索キー1> <検索キー2>: どちらかの検索キーに一致するメッセージ
RECENT: \Recentフラグを持つメッセージ
SEEN: \Seenフラグを持つメッセージ
SENTBEFORE <日付>: [RFC-822] Date:ヘッダが指定日付以前のメッセージ
SENTON <日付>: [RFC-822] Date:ヘッダが指定日付のメッセージ
SENTSINCE <日付>: [RFC-822] Date:ヘッダが指定日付以降のメッセージ
SINCE <日付>: 内部日付が指定日付以降のメッセージ
SMALLER <n>: 指定された数のオクテット数より小さいRFC822.SIZEを持つメッセージ
SUBJECT <文字列>: エンベロープ構造のSUBJECTフィールドに指定文字列を含むメッセージ
TEXT <文字列>: メッセージヘッダーまたは本文に指定文字列を含むメッセージ
TO <文字列>: エンベロープ構造のTOフィールドに指定文字列を含むメッセージ
UID <メッセージセット>: 指定されたユニーク識別子のセットに一致するユニーク識別子を持つメッセージ
UNANSWERED: \Answeredフラグを持たないメッセージ
UNDELETED: \Deletedフラグを持たないメッセージ
UNDRAFT: \Draftフラグを持たないメッセージ
UNFLAGGED: \Flaggedフラグを持たないメッセージ
UNKEYWORD <フラグ>: 指定キーワードを持たないメッセージ
UNSEEN: \Seenフラグを持たないメッセージ

例:

C: A282 SEARCH FLAGGED SINCE 1-Feb-1994 NOT FROM "Smith"
S: * SEARCH 2 84 882
S: A282 OK SEARCH completed

6.4.5. FETCH 命令

引数:

メッセージセット
メッセージデータ項目名

データ:

タグ無し応答: FETCH

結果:

OK - 完了
NO - エラー: そのデータを取得出来ない
BAD - 未知の命令、または引数が無効

FETCH命令はメールボックス内のメッセージに関連する情報を取得する。取得されるデータ項目は、単独アトムか括弧で括られたリストの何れかである。現在定義されている取得可能なデータ項目は以下の通り。

ALL

(FLAGS INTERNALDATE RFC822.SIZE ENVELOPE)と同様のマクロ

BODY

BODYSTRUCTUREの非拡張形式

BODY[<セクション>]

本文の指定セクションのテキスト。セクションの定義は、ピリオドで区切られた1つ以上のパート番号の集合である。

単一パートのメッセージは、パート1のみを持つ。

マルチパートメッセージは、メッセージに現れる順に連続するパート番号が割当てられる。あるパートがメッセージまたはマルチパートの場合、その内部のパートは、ピリオドの後に、ネストされたマルチパート内部でのパート番号を付けて表されなければならない。マルチパート部自身を取得する事は許されず、個別のメンバーのみ取得する事が許される。

MESSAGE型のパートおよびサブタイプRFC822のパートも、ネストしたパートを持つ。これらはMESSAGEパートの本文の一部である。MESSAGE型およびRFC822サブタイプのパート0は、そのメッセージの[RFC-822]ヘッダである。

全てのメッセージは最低でもひとつのパートを持つ。

ここで複合メッセージの例を、その対応するセクション番号と共に示す。

0	(メッセージの[RFC-822]ヘッダ)
	MULTIPART/MIXED
1	TEXT/PLAIN
2	APPLICATION/OCTET-STREAM
3	MESSAGE/RFC822
3.0	(メッセージの[RFC-822]ヘッダ)
3.1	TEXT/PLAIN
3.2	APPLICATION/OCTET-STREAM
	MULTIPART/MIXED
4.1	IMAGE/GIF
4.2	MESSAGE/RFC822
4.2.0	(メッセージの[RFC-822]ヘッダ)
4.2.1	TEXT/PLAIN
	MULTIPART/ALTERNATIVE
4.2.2.1	TEXT/PLAIN
4.2.2.2	TEXT/RICHTEXT

マルチパート部(セクション4と4.2.2)にはセクション番号が無い事に注意して欲しい。

\Seenフラグは暗黙のうちに設定されるが、それがフラグの変更を引き起こす場合、応答の一部に含まれるべきである。

BODY.PEEK[<セクション>]

暗黙のうちに\Seenフラグを設定されていないBODY[セクション]の、もうひとつの形式

BODYSTRUCTURE

メッセージの[MIME-1]本文構造体。[MIME-1]ヘッダ行を解析する事でサーバーによって算出される。

ENVELOPE

メッセージのエンベロープ構造体。必要なら種々のフィールドを無視しながら[RFC-822]ヘッダを各構成部分に分解する事で、サーバーによって算出される。

FAST

(FLAGS INTERNALDATE RFC822.SIZE)と同等のマクロ

FLAGS

メッセージにセットされているフラグ

FULL

(FLAGS INTERNALDATE RFC822.SIZE ENVELOPE BODY)と同等のマクロ

INTERNALDATE

RFC821で定義されているメッセージの最終配送日付・時刻

RFC822

[RFC-822]形式のメッセージ。\Seenフラグは暗黙のうちに設定されるが、それがフラグの変更を引き起こす場合、応答の一部に含まれるべきである。これはRFC822.HEADERとRFC822.TEXTの連結である。

RFC822.PEEK

暗黙のうちに\SeenフラグをセットされないRFC822のもうひとつの形式

RFC822.HEADER

ヘッダーと本文の間の区切り空行を含む、サーバー上に保存されている[RFC-822]形式のメッセージヘッダ

RFC822.HEADER.LINES <ヘッダリスト>

ヘッダリスト内のいずれかの文字列と一致するフィールド名([RFC-822]で定義される)を持つ、[RFC-822]形式のメッセージヘッダの全ヘッダ行(継続行を含む)。検索は大文字・小文字を区別しないが、厳密である。ヘッダと本文の間の区切り空行は常に含まれる。

RFC822.HEADER.LINES.NOT <ヘッダリスト>

ヘッダリスト内のいずれかの文字列と一致するフィールド名([RFC-822]で定義される)を持たない、[RFC-822]形式のメッセージヘッダの全ヘッダ行(継続行を含む)。検索は大文字・小文字を区別しないが、厳密である。ヘッダと本文の間の区切り空行は常に含まれる。

RFC822.SIZE

[RFC-822]形式で表現されたメッセージのオクテット数

RFC822.TEXT

[RFC-822]ヘッダを除くメッセージ本文のテキスト。\Seenフラグは暗黙のうちに設定されるが、それがフラグの変更を引き起こす場合、応答の一部に含まれるべきである。

RFC822.TEXT.PEEK

暗黙のうちに\SeenフラグをセットされないRFC822.TEXTのもうひとつの形式

UID

メッセージのユニーク識別子

例:

C: A654 FETCH 2:4 (FLAGS RFC822.HEADER.LINES (DATE FROM))
S: * 2 FETCH ....
S: * 3 FETCH ....
S: * 4 FETCH ....
S: A003 OK FETCH completed

6.4.6. PARTIAL 命令

引数:: メッセージ連番
メッセージデータ項目名
最初のオクテット位置
オクテット数
データ:: タグ無し応答: FETCH
結果:: OK - 完了
NO - エラー: データを取得出来ない
BAD - 未知の命令、または引数が無効; PARTIAL命令は、指定された開始オクテットから指定されたオクテット数だけ返す機能をFETCH命令に追加したものと同等である。一度にひとつのメッセージだけ取得出来る。メッセージの最初のオクテット(つまり、開始オクテットの最小値)は1である。; 次のFETCH項目がPARTIAL用に有効なデータである：RFC822、RFC822.HEADER、RFC822.TEXT、BODY[section]、及びこれらの.PEEK形式。; テキストの終端を越える部分は適切に切り捨てられる。開始オクテットがテキストの最後を越えている場合は空文字列が返される。; データはFETCH応答と共に返される。応答の中にはデータの範囲を示すものはない。連続する命令は順不同に実行されるので、各ステップでの同期処理無しに、同じデータ項目への連続した複数のPARTIAL命令を実行する事は不可能である。; 部分FETCHが特定の順序に従う必要はない。例えばオクテット1から10000までの部分取得が、扱い難いBASE64デコードに割り込まれる場合、9987から19987までなどの部分取得で継続する事が可能である。; \Seenフラグの扱いはFETCH命令と同じである。
例:: C: A005 PARTIAL 4 RFC822 1 1024
S: * 1 FETCH (RFC822 {1024}
S: Return-Path: <gray@cac.washington.edu>
S: ...
S: ......... FLAGS (\Seen))
S: A005 OK PARTIAL completed

6.4.7. STORE 命令

引数:

メッセージセット
メッセージデータ項目名
メッセージデータ項目の値

データ:

タグ無し応答: FETCH

結果:

OK - 完了
NO - エラー: そのデータを保存できない
BAD - 未知の命令、または引数が無効

STORE命令は、メールボックス内のメッセージに関連する情報を変更する。通常STORE命令は、更新された情報の値をタグ無しFETCH応答と共に返す。

データ項目名の接尾辞".SILENT"は、タグ無しFETCH応答を抑制し、サーバーはクライアントが自分で更新された値を特定するか、更新された値に付いて気にしないと仮定するべきである。

現在定義されているSTORE可能なデータ項目は以下の通り。

FLAGS <フラグリスト>: メッセージのフラグを引数のフラグに置き換える。新しいフラグの値が取得されたかのように返される。
FLAGS.SILENT <フラグリスト>: FLAGSと同等であるが、新しい値は返さない。
+FLAGS <フラグリスト>: メッセージのフラグに引数のフラグを追加する。新しいフラグの値が取得されたかのように返される。
+FLAGS.SILENT <フラグリスト>: +FLAGSと同等であるが、新しい値は返さない。
-FLAGS <フラグリスト>: メッセージのフラグから引数のフラグを取り除く。新しいフラグの値が取得されたかのように返される。
-FLAGS.SILENT <フラグリスト>: -FLAGSと同等であるが、新しい値は返さない。

例:

C: A003 STORE 2:4 +FLAGS (\Deleted)
S: * 2 FETCH FLAGS (\Deleted \Seen)
S: * 3 FETCH FLAGS (\Deleted)
S: * 4 FETCH FLAGS (\Deleted \Flagged \Seen)
S: A003 OK STORE completed

6.4.8. COPY 命令

引数:: メッセージセット
メールボックス名
データ:: この命令への特別なデータは無い
結果:: OK - 完了
NO - エラー: メッセージをコピー出来ない、またはその名前にコピー出来ない。
BAD - 未知の命令、または引数が無効; COPY命令は、指定されたメッセージを指定されたメールボックスにコピーする。元のメッセージのフラグと内部情報は、コピーに対しても保存されるべきである(SHOULD)。; コピー先メールボックスが存在しない場合、サーバーはエラーを返すべきであり(SHOULD)、自動的にメールボックスを作成するべきではない(SHOULD NOT)。目的のメールボックスが作成出来ない事が確実ではない限り、サーバーはタグ付きNO応答のテキストの接頭辞として、応答コード"[TRYCREATE]"を送信しなければならない(MUST)。これはクライアントに、CREATE命令を試し、もし成功すれば再びCREATEを試みる事が出来るというヒントを与える。; 何らかの理由によりCOPY命令が失敗した場合、サーバーは対象メールボックスをCOPYが試みられる前の状態に復元されなければならない(MUST)。
例:: C: A003 COPY 2:4 MEETING
S: A003 OK COPY completed

6.4.9. UID 命令

引数:: 命令名
命令の引数
データ:: タグ無し応答: FETCH, SEARCH
結果:: OK - UID 命令完了
NO - UID 命令失敗
BAD - 未知の命令、または引数が無効; UID命令は二つの形式を持つ。一つ目の形式ではその引数として、COPY命令・FETCH命令・STORE命令と、それに関連する引数を取る。ただしメッセージセット引数の数字はメッセージ連番ではなく、ユニーク識別子である。; 二番目の形式では引数としてSEARCH命令とその引数を取る。この引数の解釈はSEARCH命令と同じであるが、UID SEARCH命令に対するSEARCH応答で返される数値はメッセージ連番ではなく、ユニーク識別子である。例えば命令UID SEARCH 1:100 UID 443:557は、メッセージ連番セット1:100とUIDセット443:557の積に対応するユニーク識別子を返す。; メッセージのユニーク識別子は数値であり、メールボックス中のいかなる他のメッセージも参照しない事が保証される。ユニーク識別子は、メールボックスに追加されたメッセージ毎に厳密に増加する方法で割り当てられる。メッセージ連番とは異なり、ユニーク識別子はセッションをまたいで継続する。これによりクライアント(例えば切断されたかオフラインのクライアント)は、そのサーバーとの前回のセッション以降の状態を再同期出来る。これについては[IMAP-DISC]でより詳細に議論されている。; 全てのメールボックスがユニーク識別子有効値を持っており、メッセージ選択時のタグ無しOK応答中のUIDVALIDITY応答コードの中で送信される。前回のセッションでのユニーク識別子が今回のセッションでの継続利用に失敗した場合、ユニーク識別子有効値は前回のセッションの時よりも大きくなければならない(MUST)。; 注意: ユニーク識別子有効値に使用するのに都合の良い値の例は、メールボックスの作成日付/時刻の32ビット表現だろう。1のような定数を使用しても構わないが、それは、そのメールボックスが削除され、将来新しいメールボックスが同じ名前で作成された場合でも、そのユニーク識別子が決して再利用されない事が保証される場合だけである。; メッセージセットの範囲指定は可能だが、ユニーク識別子が連続している事は保証されない。メッセージセット範囲内に存在しないユニーク識別子は、何のエラーメッセージも発生させず、無視される。; タグ無しFETCH応答中の"*"の後の数字は、UID命令に対する応答の場合でもユニーク識別子ではなく、通常はメッセージ連番である。しかしながらサーバー実装は、FETCH命令へのメッセージデータ項目としてUIDが指定されているかどうかに関係なく、UID命令に対するFETCH応答の一部としてUIDメッセージデータ項目を暗黙のうちに含めなければならない(MUST)。
例:: C: A003 UID FETCH 4827313:4828442 FLAGS
S: * 23 FETCH (FLAGS (\Seen) UID 4827313)
S: * 24 FETCH (FLAGS (\Seen) UID 4827943)
S: * 25 FETCH (FLAGS (\Seen) UID 4828442)
S: A999 UID FETCH completed

6.5. クライアント命令 - 実験的/拡張

6.5.1. X<アトム> 命令

引数:: 実装により定義される
データ:: 実装により定義される
結果:: OK - 完了
NO - 失敗
BAD - 未知の命令、または引数が無効; 文字Xで始まる命令は実験的命令である。この規約や標準、あるいはこの規約の標準改訂の一部ではない命令は、接頭辞Xを使用しなければならない(MUST)。; 実験的命令に対して発行されるタグ無し応答は、全てXを前に置かなければならない(MUST)。クライアントが実験的命令の発行で要求しない限り、サーバー実装はこのようなタグ無し応答を送信してはならない(MUST NOT)。
例:: C: a441 CAPABILITY
S: * CAPABILITY IMAP4 XPIG-LATIN
S: a441 OK CAPABILITY completed
C: A442 XPIG-LATIN
S: * XPIG-LATIN ow-nay eaking-spay ig-pay atin-lay
S: A442 OK XPIG-LATIN ompleted-cay

7. サーバー応答

サーバー応答は三つの形式を持つ：状態応答、サーバーデータ、命令継続要求。

下記の説明中"データ:"で示されるサーバー応答情報は、文法に従ってではなく、機能に従って記述されている。サーバー応答の正確な文法は、正式な文法セクションで説明されている。

クライアントは常に、サーバーからのいかなる応答でも受け付ける準備が出来ていなければならない(MUST)。

タグ付きの状態応答はクライアント命令の完了結果を示し、命令と同じタグを持つ。

いくつかの状態応答と全てのサーバーデータは、タグ無しである。タグ無し応答はタグの代わりに記号"*"で表される。タグ無しの状態応答は、サーバー挨拶、または命令の完了を表さないサーバー状態を表す。厳密には一方的サーバーデータのみが真に"未承諾情報(unsolicited data)"なのだが、歴史的理由により、タグ無しサーバーデータ応答が"未承諾(unsolicited)"とも呼ばれる。

特定のサーバーデータは、それが受信された時にクライアントによって記録されなければならない(MUST)。これはそのデータの説明で注記する。そのようなデータは後続の命令と応答の解釈に影響する重要な情報(例えばメッセージの生成や破棄に影響する更新)を伝える。

他のサーバーデータは、後で参照出来るように記録されるべき(SHOULD)だが、そのデータを記録する必要が無いか、そのデータの記録に明確な目的がない場合(例えばSEARCH命令が実行されていない間のSEARCH応答)、そのデータは無視されるべきである(SHOULD)。

一方的タグ無し応答の例は、IMAP接続が選択済み状態の時に発生する。選択済み状態では、サーバーは各命令実行動作の一部として、新規メッセージの確認の為にメールボックスをチェックする。新規メッセージが見つかった場合、サーバーはメールボックスの新しいサイズを反映したタグ無しのEXISTS応答とRECENT応答を送信する。さらに、同じメールボックスへの複数同時アクセスを提供するサーバー実装は、別のエージェントがメッセージフラグの状態を変更したりメッセージを削除した場合に、適切な一方的タグ無しのFETCH応答とEXPUNGE応答を送信する。

命令継続要求応答は、タグの代わりに"+"記号を使用する。これらの応答は、不完全なクライアント命令の受け付けや、残りの命令への準備完了を示す為に、サーバーから送信される。

7.1. サーバー応答 - 状態応答

ステータス応答は任意の応答コードを含んでも良い。応答コードは、スクエアブラケットの内のアトム形式のデータから構成され、たいていは空白と引数がそれに続く。応答コードは、クライアントソフトウェアの為の追加情報やOK/NO/BAD以上のステータスコードを含み、クライアントが追加情報に基いて取る事の出来る特定の動作がある場合に定義される。

現在定義されている応答コードは以下の通り。

ALERT: 特定の警告を含む可読テキストで、ユーザーの注意を引く方法で表示しなければならない(MUST)。
PARSE: メールボックス内の[RFC-822]または[MIME-1]メッセージヘッダの解析中に起きたエラーを示す可読テキスト。
PERMANENTFLAGS: 後に括弧で括られたフラグのリストを続けて、クライアントが恒久的に変更出来る既知のフラグを示す。タグ無しFLAGS応答中には含まれるがPERMANENTFLAGSリストには含まれないフラグは、恒久的に設定する事は出来ない。クライアントがPERMANENTFLAGSリストに含まれないフラグの保存(STORE)を試みた場合、サーバーはNOを返し拒否するか、現行セッションの間だけその状態を保存する。PERMANENTFLAGSリストは特別なフラグ\*を含んでも良く、それはメールボックスにフラグの保存を試みる事で新しいキーワードを作成可能である事を示す。
READ-ONLY: メールボックスが読取専用で選択されている、または選択中にアクセス権が読み書き可能から読取専用に変更された。
READ-WRITE: メールボックスが読み書き専用で選択されている、または選択中にそのアクセス権が読取専用から読み書き可能に変更された。
TRYCREATE: APPENDまたはCOPYが、対象メールボックスが存在しない為に失敗した。これは、先にCREATE命令でメールボックスを作成すれば操作が成功するかもしれないという、クライアントへのヒントである。
UIDVALIDITY: 後に10進数値を続けて、ユニーク識別子有効値を示す。より詳細はUID命令の説明を参照して欲しい。
UNSEEN: 後に10進数値を続けて、\Seenフラグが設定されていない最初のメッセージの番号を示す。

特定のクライアント実装またはサーバー実装によって定義される追加の応答コードは、それがこのプロトコルの改訂により追加されない限り、"X"を前に置くべきである。クライアント実装は認識できない応答コードを無視するべきである。

7.1.1. OK 応答

データ:: 応答コード(任意)
可読テキスト; OK応答はサーバーからの情報メッセージを示す。タグ付きの場合、対応する命令が成功した事を示す。可読テキストは情報としてユーザーに見せても良い。タグ無し形式は情報のみのメッセージを表し、情報の本質は応答コードで示されるても良い。; さらにタグ無し形式は、セッション開始時に取り得る三つの挨拶のひとつとしても使用される。それは、セッションがまだ認証されておらず、LOGIN命令が必要である事を示す。
例:: S: * OK IMAP4 server ready
C: A001 LOGIN fred blurdybloop
S: * OK [ALERT] System shutdown in 10 minutes
S: A001 OK LOGIN Completed

7.1.2. NO 応答

データ:: 応答コード(任意)
可読テキスト; NO応答は、サーバーからの操作エラーメッセージを示す。タグ付きの場合、対応する命令が失敗した事を示す。タグ無し形式は警告を表し、命令が今のところは成功しているという事を示す。
例:: C: A222 COPY 1:2 owatagusiam
S: * NO Disk is 98% full, please delete unnecessary data
S: A222 OK COPY completed
C: A222 COPY 3:200 blurdybloop
S: * NO Disk is 98% full, please delete unnecessary data
S: * NO Disk is 99% full, please delete unnecessary data
S: A222 NO COPY failed: disk is full

7.1.3. BAD 応答

データ:: 応答コード(任意)
可読テキスト; BAD応答はサーバーからのエラーメッセージを示す。タグ付きの場合、クライアントが発行した命令のプロトコルレベルのエラーを報告しており、そのタグがエラーを発生させた命令を示す。タグ無しの場合、対応する命令を特定できないプロトコルレベルのエラーを示す(サーバー内部エラーを示しているのかもしれない)。可読テキストはその状況を示す。
例:: C: ...非常に長い命令行...
S: * BAD Command line too long
C: ...空行...
S: * BAD Empty command line
C: A443 EXPUNGE
S: * BAD Disk crash, attempting salvage to a new disk!
S: * OK Salvage successful, no data lost
S: A443 OK Expunge completed

7.1.4. PREAUTH 応答

データ:: 応答コード(任意)
可読テキスト; PREAUTH応答は常にタグ無しで、セッション開始時の三つの取り得る挨拶のひとつである。これは、セッションが既に外部の手段によって認証済みであり、LOGIN命令は不要である事を示す。
例:: S: * PREAUTH IMAP4 server ready and logged in as Smith

7.1.5. BYE 応答

データ:: 応答コード(任意)
可読テキスト; BYE応答は常にタグ無しであり、サーバーが接続を閉じようとしている事を示す。可読テキストは、クライアントによるユーザーへの状況報告の中表示されても良い。BYE応答は、通常のログアウト手順の一部としてか、またはサーバーのパニックによるシャットダウン表明として送信されても良い。いくつかのサーバー実装では、不活性自動ログアウトの表明としても使用される。
例:: S: * BYE Autologout; idle for too long

7.2. サーバー応答 - サーバーとメールボックスの状態

これらの応答は常にタグ無しである。これはしばしば、同名命令の結果として、サーバーからクライアントにどのようなデータが送信されたかを示す。

7.2.1. CAPABILITY 応答

データ:: 能力リスト; CAPABILITY応答はCAPABILITY命令の結果として起こる。能力リストはサーバーがサポートする能力名を空白で区切ったリストを含む。能力リストの最初の名前は、アトム"IMAP4"でなければならない(MUST)。; IMAP4以外の能力名は、サーバーがIMAP4プロトコルの拡張、改訂、改正をサポートする事を示す。クライアントがその能力を使用する命令を発行しない限り、サーバー応答はこの文書に従わなければならない(MUST)。; 能力名は"X"で始まるか、標準または標準トラックIMAP4拡張、改訂、またはIANAによって登録された改正の何れかでなければならない(MUST)。"X"を前に置く名前ではない限り、サーバーは未登録または非標準の能力名を提供してはならない(MUST NOT)。; クライアント実装は、"IMAP4"以外のいかなる能力名も要求されるべきではなく(SHOULD NOT)、未知の能力名を無視しなければならない(MUST)。
例:: S: * CAPABILITY IMAP4 XPIG-LATIN

7.2.2. LIST 応答

データ:

名前属性
階層区切り文字
名前

LIST応答はLIST命令の結果として起こり、LIST命令の指定に一致する単一の名前を返す。単独のLIST命令に対して複数のLIST応答が許される。

4つの名前属性が定義されている。

\Noinferiors: この名前の下位にはいかなる子階層レベルも存在出来ず、現在も子階層は存在せず、将来も作成できない。
\Noselect: 選択可能メールボックスとして、この名前を使用出来ない。
\Marked: おそらく最後に選択された時以降に追加されたメッセージを含んでいる為、このメールボックスはサーバーによって"興味がある(interesting)"としてマークされている。
\Unmarked: このメールボックスは、前回選択された時以降に追加されたメッセージを含んでいない。

そのメールボックスが"興味がある(interesting)"かどうかを判断する事が出来ないか、そのメールボックスが\Noselectの場合、サーバーは\Markedや\Unmarkedを送信するべきではない。

階層区切り文字はメールボックスの階層レベルを区切る為に使用される文字である。クライアントはそれを、子メールボックスを作成したり、名前階層の上位や下位の検索を行ったりする為に使用しても良い。最上位レベル階層の全ての子ノードは、同じ区切り文字を使用しなければならない。階層区切り文字NILは階層が無い事を意味し、その名前は"フラットな(flat)"名前である。

名前は曖昧さのない左から右の階層を表現し、LIST命令やLSUB命令内で参照として使用される為に有効でなければならない(MUST)。\Noselectが付いていない限り、その名前はSELECTのようなメールボックスを受け付ける命令の引数としても有効でなければならない。

例:

S: * LIST (\Noselect) "/" ~/Mail/foo

7.2.3. LSUB 応答

データ:: 名前属性
階層区切り文字
名前; LSUB応答は、LSUB命令の結果として起こり、LSUB命令の指定に一致する単一の名前を返す。単独のLSUB命令に対して複数のLSUB応答が許される。データはLIST応答と同一の形式である。
例:: S: * LSUB () "." #news.comp.mail.misc

7.2.4. SEARCH 応答

データ:: ゼロ個以上の数値; SEARCH応答は、SEARCH命令またはUID SEARCH命令の結果として起こる。数値は検索条件に一致するメッセージを参照する。SEARCH命令の場合、それらはメッセージ連番であり、UID SEARCH命令の場合、それらはユニーク識別子である。各数値は空白で区切られる。
例:: S: * SEARCH 2 3 6

7.2.5. FLAGS 応答

データ:: 括弧で括られたフラグのリスト; FLAGS応答は、SELECT命令またはEXAMINE命令の結果として起こる。括弧で括られたフラグのリストは、このメールボックスに適用出来るフラグ(最低限なら、システム定義のフラグ)を識別する。サーバー実装によっては、システムフラグ以外のフラグが存在しても良い。; FLAGS応答の更新はクライアントによって記録されなければならない(MUST)。
例:: S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)

7.3. サーバー応答 - メッセージ状態

これらの応答は常にタグ無しである。これはしばしば、同名命令の結果として、サーバーからクライアントにどのようなメッセージデータが送信されたかを示す。"*"の直後に続くのは、メッセージ連番またはメッセージ総数のどちらかを表す数値である。

7.3.1. EXISTS 応答

データ:: 無し; EXISTS応答はメールボックス内のメッセージ数を報告する。この応答は、SELECT命令またはEXAMINE命令の結果、あるいはメールボックスサイズの変更の結果として起こる。; EXISTS応答の更新はクライアントによって記録されなければならない(MUST)。
例:: S: * 23 EXISTS

7.3.2. RECENT 応答

データ:: 無し; RECENT応答は、そのメールボックスで前回SELECT命令が実行された時以降に到達したメッセージ数を報告する。この応答はSELECT命令またはEXAMINE命令の結果、あるいはメールボックスサイズの変更(例えば新規メール)の結果として起こる。; RECENT応答の更新はクライアントによって記録されなければならない(MUST)。
例:: S: * 5 RECENT

7.3.3. EXPUNGE 応答

データ:: 無し; EXPUNGE応答は、特定のメッセージ連番がメールボックスから永久に削除されたという事を報告する。メールボックス内の連続するメッセージのメッセージ連番は即座に1減算され、その減少は後に続く応答(別のタグ無しEXPUNGE応答も含む)でのメッセージ連番に影響する。; 即座に減算されるという規則の結果、連続するEXPUNGE応答の中に現れるメッセージ連番は、メッセージが昇順に削除されるか降順に削除されるかに依存する。例えば、9個のメッセージを含むメールボックス内の最後の5個のメッセージが削除された場合、"昇順"のサーバーはメッセージ連番5のタグ無しEXPUNGE応答を5回送信し、"降順"のサーバーはメッセージ連番9、8、7、6、5の連続したタグ無しEXPUNGE応答を送信する。; EXPUNGE応答は、命令が進行中ではない時や、FETCH命令・STORE命令・SEARCH命令への応答中には送られてはならない(MUST NOT)。この規則は、クライアントとサーバー間でのメッセージ連番の同期が損なわれる事を防ぐ為に必要である。; EXPUNGE応答の更新はクライアントによって記録されなければならない(MUST)。
例:: S: * 44 EXPUNGE

7.3.4. FETCH 応答

データ:

メッセージデータ

FETCH応答はクライアントにメッセージに関する情報を返す。情報はデータ項目名とその値の組が括弧に囲まれたものである。この応答は、FETCHまたはSTORE命令の結果として、または一方的なサーバーの判断(例えばフラグの更新)の結果として起こる。

データ項目は以下の通り。

BODY

拡張情報を含まないBODYSTRUCTURE。

BODY[セクション]

指定セクションの本文の内容を表す文字列。クライアントは、変換エンコード、本文のタイプ、サブタイプに従ってこの文字列を解釈するべきである。

8ビットテキストデータは、このセクションの為の括弧で括られたパラメータリストに、その為の文字セット識別子が含まれる場合にのみ許可される。

バイナリデータのような非テキストデータは、クライアントへ送信される前に、BASE64のようなテキスト形式にエンコードされてから送信されなければならない。

クライアントは元のバイナリデータを取得する為に、そのエンコードされた文字列をデコードしなければならない。

BODYSTRUCTURE

メッセージの本文構造を記述する括弧で括られたリスト。これは、[RFC-822]ヘッダと本文を各構成部分へと(必要であれば種々のフィールドにデフォルト値を採用して)解析する事で、サーバーによって算出される。

マルチパート部は括弧のネストで示される。括弧で括られたリストの最初の要素として、本文タイプの代わりにネストした本文が存在する。括弧で括られたリストの二番目の要素は、マルチパート部のサブタイプ(混合・要約・類似・代用など)である。

マルチパート部のサブタイプの後に拡張データが続く。拡張データはBODYの取得では返されないが、BODYSTRUCTUREの取得では返されても良い。拡張データがある場合には、定義済みの順序でなければならない。

マルチパートの本文の拡張データは以下の順序である。

本文の括弧で括られたパラメータリスト: [MIME-1]で定義されている属性/値の組が括弧で括られたリスト[例 (foo bar baz rag)なら"bar"は"foo"の値、"rag"は"baz"の値]

プロトコルのこのバージョンでは、この後に続く拡張データはまだ定義されていない。そのような拡張データは0個以上のNIL、文字列、数値、または場合によってはそのようなデータのネストされた括弧で括られたリストを含んでも良い。BODYSTRUCTUREの取得を行うクライアント実装は、このような拡張データを受け取れる用意がなければならない(MUST)。このプロトコルの改訂でそのような拡張データが定義されるまで、サーバー実装はそのような拡張データを送信してはならない(MUST NOT)。

マルチパートではない本文の基本フィールドは以下の順序である。

本文のタイプ: [MIME-1]で定義されている、内容のタイプ名を表す文字列。
本文のサブタイプ: [MIME-1]で定義されている、内容サブタイプ名を表す文字列。
本文の括弧で括られたパラメータリスト: [MIME-1]で定義されている、属性/値の組が括弧で括られたリスト。[例 (foo bar baz rag)では"bar"は"foo"の値、"rag"は"baz"の値]
本文id: [MIME-1]で定義されている、内容idを表す文字列。
本文の記述: [MIME-1]で定義されている、内容記述を表す文字列
本文エンコード: [MIME-1]で定義されている、内容変換エンコードを表す文字列。
本文サイズ: 本文のサイズをオクテット単位で表す数字。このサイズは変換エンコードされたサイズであり、デコードされた後のサイズではない事に注意。

基本フィールドの直後に来る本文タイプMESSAGEとRFC822サブタイプは、エンベロープ構造、本文構造、カプセル化されたメッセージのサイズを表すテキスト行を含む。

基本フィールドの直後に来るTEXTタイプの本文タイプは、本文のサイズを表すテキスト行を含む。このサイズは変換エンコードされたサイズであり、デコードされた後のサイズではない事に注意。

拡張データは、基本フィールドと前述のタイプ固有のフィールドに続く。拡張データはBODYの取得で返される事はないが、BODYSTRUCTUREの取得では返されても良い。拡張データがある場合には、定義済みの順序でなければならない。

マルチパートではない本文の拡張データは、以下の順序である。

本文のMD5: [MIME-1]で定義されている、内容のMD5値を表す文字列。

プロトコルのこのバージョンでは、この後に続く拡張データはまだ定義されておらず、マルチパート部の拡張データのところで前述したようになるだろう。

ENVELOPE

メッセージエンベロープ構造が記述された、括弧で括られたリスト。これは、[RFC-822]ヘッダを各構成部分へと(必要であれば種々のフィールドにデフォルト値を採用して)解析する事で、サーバーによって算出される。

エンベロープ構造のフィールドは次の順序である：date, subject, from, sender, reply-to, to, cc, bcc,in-reply-to, message-id。
date, subject, in-reply-to,message-idの各フィールドは文字列である。from, sender,reply-to, to, cc, bccの各フィールドはアドレス構造の括弧で括られたリストである。

アドレス構造は、電子メールアドレスが記述された、括弧で括られたリストである。アドレス構造のフィールドは次の順序である：personal name, [SMTP] at-domain-list(source route), mailbox name, and host name。

[RFC-822]グループは、host nameフィールドがNILという特殊なアドレス構造の文法で表される。mailbox nameフィールドもNILの場合、それはグループの終端の目印である(RFC822文法ではセミコロン)。mailbox nameがNILではない場合、それはグループの開始の目印であり、mailbox nameフィールドがグループ名を保持している。

エンベロープ構造やアドレス構造の中の適用出来ないフィールドは、NILで表される。サーバーは、reply-toとsenderのデフォルト値としてfromフィールドを使用しなければならない(クライアントはそれが行われた事を知っていると期待されない)事に注意して欲しい。

FLAGS

このメッセージにセットされているフラグの、括弧で括られたリスト。これには以下のシステムフラグだけでなく、キーワードを含んでも良い。

\Seen: このメッセージは既読である。
\Answered: このメッセージは返信済みである。
\Flagged: このメッセージは、緊急または特別な注意の為に"フラグが付けられた状態(flagged)"である。。
\Deleted: このメッセージは、前回のEXPUNGEによる削除により"削除済み(deleted)"になっている
\Draft: メッセージは作成途中である(下書きとしてマークされている)

次の特別なフラグは取得されても良いが保存はされない。

\Recent: このメッセージは、前回このメールボックスが選択された時以降に届いた。

INTERNALDATE

[SMTP]で定義されているメッセージの最終配送日付と時刻を含む文字列。

RFC822

[RFC-822]形式でメッセージを表す文字列。メッセージのヘッダ部分は7ビットでなければならない。8ビット文字は、メッセージ中にそのメッセージの文字セットを示す[MIME-1]データが存在する場合にのみ、メッセージのヘッダ以外の部分で許可される。

RFC822.HEADER

[RFC-822]形式のメッセージヘッダを表す文字列であり、ヘッダと本文の間の区切りの空行を含む。ヘッダには8ビット文字は許可されないので、全てが7ビット文字でなければならない。RFC822.HEADERは、RFC822.HEADER、 RFC822.HEADER.LINES、 RFC822.HEADER.LINES.NOTの各FETCHデータ項目の応答情報として使用される。ヘッダ行の制限に関係なく、空行は常に含まれる事に注意して欲しい。

RFC822.SIZE

[RFC-822]形式メッセージのオクテット数を表す数値。

RFC822.TEXT

[RFC-822]ヘッダを除くメッセージ本文のテキストを表す文字列。8ビット文字は、メッセージ中にそのメッセージの文字セットを示す[MIME-1]データが存在する場合にのみ許可される。

UID

メッセージのユニーク識別子を表す数値。

例:

S: * 23 FETCH (FLAGS (\Seen) RFC822.SIZE 44827)

7.3.5. 時代遅れの応答

ここまでに挙げた応答に加え、クライアント実装は、付録Bで説明される時代遅れの応答の受入れと実装を行わなければならない(MUST)。

7.4. サーバー応答 - 命令継続要求

命令完了要求応答はタグの代わりに"+"で示される。この応答形式は、サーバーがクライアントからの命令の続きを受け付ける準備が出来た事を示す。この応答の残りはテキスト行である。

この応答はAUTHORIZATION命令中にサーバーのデータをクライアントに送信する為に使用され、クライアントの追加データを要求する。また、命令の引数がリテラルの場合にも使用される。

サーバーがリテラルのオクテットを要求するまで、クライアントはリテラルのオクテットを送信する事を許されない。これにより、サーバーが逐次行(line-by-line)の原則に基づいて命令処理とエラー拒否を行う事が可能になる。命令の残り(終端のCRLFを含む)は、このリテラルのオクテットの後に続く。追加の命令引数がある場合、このリテラルの後に、空白とその引数が続く。

例:: C: A001 LOGIN {11}
S: + Ready for additional command text
C: FRED FOOBAR {7}
S: + Ready for additional command text
C: fat man
S: A001 OK LOGIN completed
C: A044 BLURDYBLOOP {102856}
S: A044 BAD No such command as "BLURDYBLOOP"

8. IMAP4セッションの例

以下は、あるIMAP4セッションの記録である。長い行は編集上の配慮により区切られている。

   S:   * OK IMAP4 Service Ready
   C:   a001 login mrc secret
   S:   a001 OK LOGIN completed
   C:   a002 select inbox
   S:   * 18 EXISTS
   S:   * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
   S:   * 2 RECENT
   S:   * OK [UNSEEN 17] Message 17 is the first unseen message
   S:   * OK [UIDVALIDITY 3857529045] UIDs valid
   S:   a002 OK [READ-WRITE] SELECT completed
   C:   a003 fetch 12 full
   S:   * 12 FETCH (FLAGS (\Seen) INTERNALDATE "14-Jul-1993 02:44:25 -0700"
         RFC822.SIZE 4282 ENVELOPE ("Wed, 14 Jul 1993 02:23:25 -0700 (PDT)"
         "IMAP4 WG mtg summary and minutes"
         (("Terry Gray" NIL "gray" "cac.washington.edu"))
         (("Terry Gray" NIL "gray" "cac.washington.edu"))
         (("Terry Gray" NIL "gray" "cac.washington.edu"))
         ((NIL NIL "imap" "cac.washington.edu"))
         ((NIL NIL "minutes" "CNRI.Reston.VA.US")
         ("John Klensin" NIL "KLENSIN" "INFOODS.MIT.EDU")) NIL NIL
         "<B27397-0100000@cac.washington.edu>")
          BODY ("TEXT" "PLAIN" ("CHARSET" "US-ASCII") NIL NIL "7BIT" 3028 92))
   S:    a003 OK FETCH completed
   C:    a004 fetch 12 rfc822.header
   S:    * 12 FETCH (RFC822.HEADER {346}
   S:    Date: Wed, 14 Jul 1993 02:23:25 -0700 (PDT)
   S:    From: Terry Gray <gray@cac.washington.edu>
   S:    Subject: IMAP4 WG mtg summary and minutes
   S:    To: imap@cac.washington.edu
   S:    cc: minutes@CNRI.Reston.VA.US, John Klensin <KLENSIN@INFOODS.MIT.EDU>
   S:    Message-Id: <B27397-0100000@cac.washington.edu>
   S:    MIME-Version: 1.0
   S:    Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
   S:
   S:    )
   S:    a004 OK FETCH completed
   C:    a005 store 12 +flags \deleted
   S:    * 12 FETCH (FLAGS (\Seen \Deleted))
   S:    a005 OK +FLAGS completed
   C:    a006 logout
   S:    * BYE IMAP4 server terminating connection
   S:    a006 OK LOGOUT completed

9. 正式な文法

以下の文法仕様は、一つの例外("#"構造の区切り記号は単独の空白(SPACE)であり、カンマではない)を除き、[RFC-822]で規定されるAugmented Backus-Naur Form(ABNF)記法を使用している。

特に注記がなければ、全てのアルファベットの大文字・小文字は区別されない。トークン文字列を定義する為の大文字・小文字の使用は、単に編集上の配慮である。実装は大文字・小文字を区別しない様式でこれらの文字列を受入れなければならない(MUST)。

obsolete(時代遅れ)と記されている文法は、このプロトコルの以前のバージョン(例えばIMAP2)用に作られた実装で使用される。新しい実装は入力としてそ文法を受入れるべき(SHOULD)だが、他ではそのような文法を使用してはならない(MUST NOT)。

address	::=	"(" addr_name SPACE addr_adl SPACE addr_mailbox SPACE addr_host ")"
addr_adl	::=	nstring
addr_host	::=	nstring ;; NILは[RFC-822]グループの文法を表す
addr_mailbox	::=	nstring ;; NILは[RFC-822]グループの終わりを表す ;; NILではなく、かつaddr_hostがNILLの場合、 ;; [RFC-822]グループの名称である
addr_name	::=	nstring
alpha	::=	"A" / "B" / "C" / "D" / "E" / "F" / "G" / "H" / "I" / "J" / "K" / "L" / "M" / "N" / "O" / "P" / "Q" / "R" / "S" / "T" / "U" / "V" / "W" / "X" / "Y" / "Z" / "a" / "b" / "c" / "d" / "e" / "f" / "g" / "h" / "i" / "j" / "k" / "l" / "m" / "n" / "o" / "p" / "q" / "r" / "s" / "t" / "u" / "v" / "w" / "x" / "y" / "z" / ;; 大文字・小文字は区別される
append	::=	"APPEND" SPACE mailbox [SPACE flag_list][SPACE date_time] SPACE literal
astring	::=	atom / string
atom	::=	1*ATOM_CHAR
ATOM_CHAR	::=	<atom_specialsを除く任意のCHAR>
atom_specials	::=	"(" / ")" / "{" / SPACE / CTLs / list_wildcards / quoted_specials
authenticate	::=	"AUTHENTICATE" SPACE auth_type *(CRLF base64)
auth_type	::=	atom
base64	::=	*(4base64_char) [base64_terminal]
base64_char	::=	alpha / digit / "+" / "/"
base64_terminal	::=	(2base64_char "==") / (3base64_char "=")
body	::=	"(" body_type_1part / body_type_mpart ")"
body_extension	::=	nstring / number / "(" 1#body_extension ")" ;; 将来の拡張用。 ;; クライアント実装はbody_extensionフィール ;; ドを受け入れなければならない(MUST)。 ;; サーバー実装は、この仕様の将来の改定で ;; 定義されない限り、このフィールドを ;; 生成してはならない(MUST NOT)。
body_ext_1part	::=	body_fld_md5 [SPACE 1#body_extension] ;; 拡張不可能な"BODY"の取得に対して返されて ;; はならない(MUST NOT)
body_ext_mpart	::=	body_fld_param [SPACE 1#body_extension]] ;; 拡張不可能な"BODY"の取得に対して返されて ;; はならない(MUST NOT)
body_fields	::=	body_fld_param SPACE body_fld_id SPACE body_fld_desc SPACE body_fld_enc SPACE body_fld_octets
body_fld_desc	::=	nstring
body_fld_enc	::=	(<"> ("7BIT" / "8BIT" / "BINARY" / "BASE64"/ "QUOTED-PRINTABLE") <">) / string
body_fld_id	::=	nstring
body_fld_lines	::=	number
body_fld_md5	::=	nstring
body_fld_octets	::=	number
body_fld_param	::=	"(" 1#(string string) ")" / nil
body_fld_subtyp	::=	string
body_type_1part	::=	(body_type_basic / body_type_msg / body_type_text) [SPACE body_ext_1part]
body_type_basic	::=	(<"> ("APPLICATION" / "AUDIO" / "IMAGE" / "MESSAGE" / "VIDEO") <">) / string) SPACE body_fld_subtyp SPACE body_fields ;; サブタイプMESSAGEは"RFC822"であっては ;; ならない(MUST NOT)。
body_type_mpart	::=	1*body SPACE body_fld_subtyp [SPACE body_ext_mpart]
body_type_msg	::=	<"> "MESSAGE" <"> SPACE <"> "RFC822" <"> SPACE body_fields SPACE envelope SPACE body SPACE body_fld_lines
body_type_text	::=	<"> "TEXT" <"> SPACE body_fld_subtyp SPACE body_fields SPACE body_fld_lines
capability	::=	atom ;; "X"de始まるか、IANAによって標準として ;; 登録されていなければならない
capability_data	::=	"CAPABILITY" SPACE "IMAP4" [SPACE 1#capability]
CHAR	::=	<NULとを除く任意の7ビットUS-ASCII文字 0x01 - 0x7f>
CHAR8	::=	<NULを除く任意の8ビットオクテット 0x01 - 0xff>
command	::=	tag SPACE (command_any / command_auth / command_nonauth / command_select) CRLF ;; 状態に基づく
command_any	::=	"CAPABILITY" / "LOGOUT" / "NOOP" / x_command ;; 全ての状態で有効
command_auth	::=	append / create / delete / examine / find / list / lsub / rename / select / subscribe / unsubscribe / ;; 認証済み状態または選択済み状態でのみ有効
command_nonauth	::=	login / authenticate ;; 未認証状態でのみ有効
command_select	::=	"CHECK" / "CLOSE" / "EXPUNGE" / copy / fetch / partial / store / uid / search ;; 選択済み状態でのみ有効
continue_req	::=	"+" SPACE (resp_text / base64)
copy	::=	"COPY" SPACE set SPACE mailbox
CR	::=	<ASCII CR, carriage return, 0x0C>
create	::=	"CREATE" SPACE mailbox ;; INBOXの場合はNOエラーになる
CRLF	::=	CR LF
CTL	::=	<ASCII制御文字およびDEL、0x00 - 0x1f、0x7f>
date	::=	date_text / <"> date_text <">
date_day	::=	1*2digit ;; 日
date_day_fixed	::=	(SPACE digit) / 2digit ;; date_dayの固定フォーマット版
date_month	::=	"Jan" / "Feb" / "Mar" / "Apr" / "May" / "Jun" / "Jul" / "Aug" / "Sep" / "Oct" / "Nov" / "Dec"
date_text	::=	date_day "-" date_month "-" (date_year / date_year_old)
date_year	::=	4digit
date_year_old	::=	2digit ;; 時代遅れ(obsolete)、(year - 1900)
date_time	::=	<"> (date_time_new / date_time_old) <">
date_time_new	::=	date_day_fixed "-" date_month "-" date_year SPACE time SPACE zone
date_time_old	::=	date_day_fixed "-" date_month "-" date_year_old SPACE time "-" zone_old ;; 時代遅れ(obsolete)
delete	::=	"DELETE" SPACE mailbox ;; INBOXの場合はNOエラーになる
digit	::=	"0" / digit_nz
digit_nz	::=	"1" / "2" / "3" / "4" / "5" / "6" / "7" / "8" / "9"
envelope	::=	"(" env_date SPACE env_subject SPACE env_from SPACE env_sender SPACE env_reply-to SPACE env_to SPACE env_cc SPACE env_bcc SPACE env_in-reply-to SPACE env_message-id ")"
env_bcc	::=	"(" 1*address ")" / nil
env_cc	::=	"(" 1*address ")" / nil
env_date	::=	nstring
env_from	::=	"(" 1*address ")" / nil
env_in-reply-to	::=	nstring
env_message-id	::=	nstring
env_reply-to	::=	"(" 1*address ")" / nil
env_sender	::=	"(" 1*address ")" / nil
env_subject	::=	nstring
env_to	::=	"(" 1*address ")" / nil
examine	::=	"EXAMINE" SPACE mailbox
fetch	::=	"FETCH" SPACE set SPACE ("ALL" / "FULL" / "FAST" / fetch_att / "(" 1#fetch_att ")")
fetch_att	::=	"BODY" / "BODYSTRUCTURE" / "BODY" [".PEEK"] "[" section "]" / "ENVELOPE" / "FLAGS" / "INTERNALDATE" / "UID" / "RFC822" (([".TEXT"] [".PEEK"]) / ".SIZE" / (".HEADER" [".LINES" [".NOT"] SPACE header_list])
find	::=	"FIND" SPACE ["ALL."] "MAILBOXES" SPACE list_mailbox ;; 時代遅れ(obsolete)OBSOLETE
flag	::=	"\Answered" / "\Flagged" / "\Deleted" / "\Seen" / "\Draft" / flag_keyword / flag_extension
flag_extension	::=	"\" atom ;; 将来の拡張用。 ;; クライアント実装はflag_extensionフィール ;; ドを受け入れなければならない(MUST)。 ;; サーバー実装は、この仕様の将来の改定で ;; 定義されない限り、このフィールドを ;; 生成してはならない(MUST NOT)。
flag_keyword	::=	atom
flag_list	::=	"(" #flag ")"
greeting	::=	"*" SPACE (resp_cond_auth / resp_cond_bye) CRLF
header_line	::=	astring
header_list	::=	"(" 1#header_line ")"
LF	::=	<ASCII LF, line feed, 0x0A>
list	::=	"LIST" SPACE mailbox SPACE list_mailbox
list_mailbox	::=	1*(ATOM_CHAR / list_wildcards) / string
list_wildcards	::=	"%" / "*"
literal	::=	"{" number "}" CRLF *CHAR8 ;; numberはCHAR8オクテットの数字を表す
login	::=	"LOGIN" SPACE userid SPACE password
lsub	::=	"LSUB" SPACE mailbox SPACE list_mailbox
mailbox	::=	"INBOX" / astring ;; INBOXの大文字・小文字は区別されない ;; その他の名前の大文字・小文字の区 ;; 別は実装に依存する
mailbox_data	::=	"FLAGS" SPACE flag_list / "LIST" SPACE mailbox_list / "LSUB" SPACE mailbox_list / "MAILBOX" SPACE text / "SEARCH" [SPACE 1#nz_number] / number SPACE "EXISTS" / number SPACE "RECENT"
mailbox_list	::=	"(" #("\Marked" / "\Noinferiors" / "\Noselect" / "\Unmarked" / flag_extension) ")" SPACE (<"> QUOTED_CHAR <"> / nil) SPACE mailbox
message_data	::=	nz_number SPACE ("EXPUNGE" / ("FETCH" SPACE msg_fetch) / msg_obsolete)
msg_fetch	::=	"(" 1#("BODY" SPACE body / "BODYSTRUCTURE" SPACE body / "BODY[" section "]" SPACE nstring / "ENVELOPE" SPACE envelope / "FLAGS" SPACE "(" #(flag / "\Recent") ")" / "INTERNALDATE" SPACE date_time / "RFC822" [".HEADER" / ".TEXT"] SPACE nstring / "RFC822.SIZE" SPACE number / "UID" SPACE uniqueid) ")"
msg_obsolete	::=	"COPY" / ("STORE" SPACE msg_fetch) ;; 時代遅れ(obsolete)のタグ無し応答
nil	::=	"NIL"
nstring	::=	string / nil
number	::=	1*digit ;; 符号無し32ビット整数 ;; (0 <= n < 4,294,967,296)
nz_number	::=	digit_nz *digit ;; 非ゼロの符号無し32ビット整数 ;; (0 < n < 4,294,967,296)
partial	::=	"PARTIAL" SPACE nz_number SPACE ("BODY" [".PEEK"] "[" section "]" / "RFC822" (([".TEXT"] [".PEEK"]) / ".HEADER") SPACE number SPACE number
password	::=	astring
quoted	::=	<"> *QUOTED_CHAR <">
QUOTED_CHAR	::=	<any TEXT_CHAR except quoted_specials> / "\" quoted_specials
quoted_specials	::=	<"> / "\"
rename	::=	"RENAME" SPACE mailbox SPACE mailbox ;; 変更先にINBOXUを使用するとNOエラーになる
response	::=	*response_data response_done
response_data	::=	"*" SPACE (resp_cond_state / resp_cond_bye / mailbox_data / message_data / capability_data) CRLF
response_done	::=	response_tagged / response_fatal
response_fatal	::=	"*" SPACE resp_cond_bye CRLF
response_tagged	::=	tag SPACE resp_cond_state CRLF
resp_cond_auth	::=	("OK" / "PREAUTH") SPACE resp_text ;; 認証条件
resp_cond_bye	::=	"BYE" SPACE resp_text ;; サーバーの切断条件
resp_cond_state	::=	("OK" / "NO" / "BAD") SPACE resp_text ;; 状態条件
resp_text	::=	["[" resp_text_code "]" SPACE] (text_mime2 / text)
resp_text_code	::=	"ALERT" / "PARSE" / "PERMANENTFLAGS" SPACE "(" #(flag / "\") ")" / "READ-ONLY" / "READ-WRITE" / "TRYCREATE" / "UIDVALIDITY" SPACE nz_number / "UNSEEN" SPACE nz_number / atom [SPACE 1<any TEXT_CHAR except "]">]
search	::=	"SEARCH" SPACE ["CHARSET" SPACE astring SPACE] search_criteria ;; 文字セット(CHARSET)は、IANAによっ ;; てMIME文字セットとして登録済みでなければならない
search_criteria	::=	1#search_key
search_key	::=	search_new / search_old
search_new	::=	"DRAFT" / "HEADER" SPACE header_line SPACE astring / "LARGER" SPACE number / "NOT" SPACE search_key / "OR" SPACE search_key SPACE search_key / "SENTBEFORE" SPACE date / "SENTON" SPACE date / "SENTSINCE" SPACE date / "SMALLER" SPACE number / "UID" SPACE set / "UNDRAFT" / set / "(" search_criteria ")" ;; IMAP4で追加された
search_old	::=	"ALL" / "ANSWERED" / "BCC" SPACE astring / "BEFORE" SPACE date / "BODY" SPACE astring / "CC" SPACE astring / "DELETED" / "FLAGGED" / "FROM" SPACE astring / "KEYWORD" SPACE flag_keyword / "NEW" / "OLD" / "ON" SPACE date / "RECENT" / "SEEN" / "SINCE" SPACE date / "SUBJECT" SPACE astring / "TEXT" SPACE astring / "TO" SPACE astring / "UNANSWERED" / "UNDELETED" / "UNFLAGGED" / "UNKEYWORD" SPACE flag_keyword / "UNSEEN" ;; [IMAP2]で定義されている
section	::=	"0" / nz_number ["." section]
select	::=	"SELECT" SPACE mailbox
sequence_num	::=	nz_number / "" ;; は使用中の最大の数値を表す。メッセー ;; ジ連番の場合、メールボックス内のメッセー ;; ジ数。ユニーク識別子の場合、メールボック ;; ス内の最後のメッセージのユニーク識別子
set	::=	sequence_num / (sequence_num ":" sequence_num) / (set "," set) ;; メッセージの集合を表す。 ;; メッセージ連番の場合、それらは1からメー ;; ルボックス内のメール数までの連続する番号 ;; である。カンマは個々の数字の区切り、コロ ;; ンは範囲指定の二つの数字の区切りである。 ;; 例: 15のメッセージを持つメールボックスに ;; おける 2,4:7,9,12:* は2,4,5,6,7,9,12,13, ;; 14,15を表す。
SPACE	::=	<ASCII SP, space, 0x20>
store	::=	"STORE" SPACE set SPACE store_att_flags
store_att_flags	::=	(["+" / "-"] "FLAGS" [".SILENT"]) SPACE (flag_list / #flag)
string	::=	quoted / literal
subscribe	::=	("SUBSCRIBE" SPACE mailbox) / subscribe_obs
subscribe_obs	::=	"SUBSCRIBE" SPACE "MAILBOX" SPACE mailbox ;; 時代遅れ(obsolete)
tag	::=	1*<any ATOM_CHAR except "+">
text	::=	1*TEXT_CHAR
text_mime2	::=	"=?" <charset> "?" <encoding> "?" <encoded-text> "?=" ;; 文法は[MIME-2]で定義されている
TEXT_CHAR	::=	<any CHAR except CR and LF>
time	::=	2digit ":" 2digit ":" 2digit ;; 時分秒
uid	::=	"UID" SPACE (copy / fetch / search / store) ;; メッセージ連番の代わりに使用されるユニー ;; ク識別子
uniqueid	::=	nz_number ;; 厳密に増加するStrictly ascending
unsubscribe	::=	("UNSUBSCRIBE" SPACE mailbox) / unsubscribe_obs
unsubscribe_obs	::=	"UNSUBSCRIBE" SPACE "MAILBOX" SPACE mailbox ;; 時代遅れ(obsolete)
userid	::=	astring
x_command	::=	"X" atom <experimental command arguments>
zone	::=	("+" / "-") 4digit ;; 西半球の時間・分を表す符号付4桁数字(グリ ;; ニッジ標準時との差異) ;; 与えられた時刻からタイムゾーンを減算する ;; と万国標準時形式となる。 ;; 万国標準時のゾーンは"+0000"である。
zone_old	::=	"UT" / "GMT" / "Z" / ;; +0000 "AST" / "EDT" / ;; -0400 "EST" / "CDT" / ;; -0500 "CST" / "MDT" / ;; -0600 "MST" / "PDT" / ;; -0700 "PST" / "YDT" / ;; -0800 "YST" / "HDT" / ;; -0900 "HST" / "BDT" / ;; -1000 "BST" / ;; -1100 "A" / "B" / "C" / "D" / "E" / "F" / ;; +1 to +6 "G" / "H" / "I" / "K" / "L" / "M" / ;; +7 to +12 "N" / "O" / "P" / "Q" / "R" / "S" / ;; -1 to -6 "T" / "U" / "V" / "W" / "X" / "Y" ;; -7 to -12 ;; 時代遅れ(obsolete)

10. 著者による注記

この文書は以前の文書の書き換えまたは改訂であり、以下のプロトコル規定の文書に取って代わる物である：IMAP4 Internet drafts, the IMAP2bis Internet drafts, IMAP2bis.TXT(未公開), RFC 1176, and RFC 1064。

11. セキュリティ考察

AUTHENTICATE命令でオプションの秘密保護が取り決められていない限り、IMAPプロトコルのやり取り(電子メールの内容も含む)は、ネットワーク上をそのまま送信される。

無効な証明書により失敗したAUTHENTICATE命令に対するサーバーエラーメッセージは、その証明書が無効である理由を詳述するべきではない。

LOGIN命令を使用する場合、パスワードは平文で送信される。代わりにAUTHENTICATE命令を使用する事で避けられる。

LOGIN命令の失敗に対するサーバーエラーメッセージは、(パスワードではなく)ユーザー名が無効であると指摘するべきではない。

AUTHENTICATE命令とLOGIN命令について議論したセクションで、さらなるセキュリティ考察が議論されている。

12. 著者のアドレス

Mark R. Crispin
Networks and Distributed Computing, JE-30
University of Washington
Seattle, WA 98195

Phone: (206) 543-5762

EMail: MRC@CAC.Washington.EDU

付録

A. 時代遅れの命令

以下の命令は時代遅れである。新しいサーバー実装では、これらの命令をサポートする必要はない。これは古いクライアント実装との互換性の為にこれらをサポーする事を望む実装者の為にここに記述されている。

各命令のセクション表題は、それが時代遅れでなかった場合に文書中で置かれていたであろう関連する場所を示している

A.6.3.OBS.1. FIND ALL.MAILBOXES 命令

引数:: メールボックス名(ワイルドカード可)
データ:: タグ無し応答: MAILBOX
結果:: OK - 完了
NO - 失敗: その名前をリスト出来ない
BAD - 未知の命令、または引数が無効; FIND ALL.MAILBOXES命令は、そのユーザーが利用可能な全ての名前のセットから、そのサブセットを返す。これは、0個以上のタグ無しMAILBOX応答を返す。メールボックス名引数は、"%"と"?"が単一文字に一致する点を除いて、空の参照名の引数を取るLIST命令と同じである。
例:: C: A002 FIND ALL.MAILBOXES *
S: * MAILBOX blurdybloop
S: * MAILBOX INBOX
S: A002 OK FIND ALL.MAILBOXES completed

A.6.3.OBS.2. FIND MAILBOXES 命令

引数:: メールボックス名(ワイルドカード可)
データ:: タグ無し応答: MAILBOX
結果:: OK - 完了
NO - 失敗: その名前をリスト出来ない
BAD - 未知の命令、または引数が無効; FIND MAILBOXES命令は、ユーザーが"アクティブ"または"購読中"と宣言した名前のセットから、そのサブセットを返す。これは0個以上のタグ無しMAILBOX応答を返す。FIND MAILBOXESのメールボックス引数は、"%"と"?"が単一文字に一致する点を除いて、空の参照名の引数を取るLSUB命令と同じである。
例:: C: A002 FIND MAILBOXES *
S: * MAILBOX blurdybloop
S: * MAILBOX INBOX
S: A002 OK FIND MAILBOXES completed

A.6.3.OBS.3. SUBSCRIBE MAILBOX 命令

引数:: メールボックス名
データ:: この命令への特別なデータは無い
結果:: OK - 完了
NO - 失敗: その名前を購読出来ない
BAD - 未知の命令、または引数が無効; SUBSCRIBE MAILBOX命令は、実質的にSUBSCRIBE命令と同じである。この命令を実装するサーバーは、SUBSCRIBE MAILBOX命令と、"MAILBOX"というメールボックス引数を持つSUBSCRIBE命令とを区別出来なければならない。
例:: C: A002 SUBSCRIBE MAILBOX #news.comp.mail.mime
S: A002 OK SUBSCRIBE MAILBOX to #news.comp.mail.mime completed
C: A003 SUBSCRIBE MAILBOX
S: A003 OK SUBSCRIBE to MAILBOX completed

A.6.3.OBS.4. UNSUBSCRIBE MAILBOX 命令

引数:: メールボックス名
データ:: この命令への特別なデータは無い
結果:: OK - 完了
NO - 失敗: その名前を購読解除出来ない
BAD - 未知の命令、または引数が無効; UNSUBSCRIBE MAILBOX命令は、実質的にUNSUBSCRIBE命令と同じである。この命令を実装するサーバーは、UNSUBSCRIBE MAILBOX命令と、"MAILBOX"というメールボックス引数を持つUNSUBSCRIBE命令とを区別出来なければならない。
例:: C: A002 UNSUBSCRIBE MAILBOX #news.comp.mail.mime
S: A002 OK UNSUBSCRIBE MAILBOX from #news.comp.mail.mime completed
C: A003 UNSUBSCRIBE MAILBOX
S: A003 OK UNSUBSCRIBE from MAILBOX completed

B. 時代遅れの応答

以下の応答は時代遅れである。注記されている場合を除き、これらの応答は新しいサーバー実装によって送信されてはならない(MUST NOT)。

各命令のセクション表題は、それが時代遅れでなかった場合に主文書中で置かれていたであろう関連する場所を示している

B.7.2.OBS.1. MAILBOX 応答

データ:: 名前; MAILBOX応答は、時代遅れのFIND MAILBOXES命令とFIND ALL.MAILBOXES命令への応答の場合を除き、サーバー実装によって送信されてはならない(MUST NOT)。これらの命令を使用しないクライアント実装は、この応答を無視しても良い(MAY)。これは古いクライアント実装との互換性の為にこれをサポートする事を望む実装者の為にここに記述されている。; この応答はFIND MAILBOXES命令とFIND ALL.MAILBOXES命令の結果として起こり、その指定に一致する単一の名前を返す。属性や階層区切りは含まれない。
例:: S: * MAILBOX blurdybloop

B.7.3.OBS.1. COPY 応答

データ:: 無し; 新しいサーバー実装はCOPY応答を送信してはならない(MUST NOT)。クライアント実装はCOPY応答を無視しなければならない(MUST)。これは古いサーバー実装からこの応答を受けるかもしれないクライアント実装者の為にここに記述されている。; この応答は、このプロトコルのいくつかの試験的バージョンにおいて、メッセージ毎にコピーが成功した事を示す為に、COPY命令への応答の中で返されていた。
例:: S: * 44 COPY

B.7.3.OBS.2. STORE 応答

データ:: メッセージデータmessage data; 新しいサーバー実装はSTORE応答を送信してはならない(MUST NOT)。クライアント実装はSTORE応答をFETCH応答と同等のものとして扱わなければならない(MUST)。これは古いサーバー実装からこの応答を受けるかもしれないクライアント実装者の為にここに記述されている。; このプロトコルのいくつかの試験的バージョンにおいて、この応答はフラグの新しい値を報告する為に、STORE命令への応答の中でFETCHの代わりに返されていた。
例:: S: * 69 STORE (FLAGS (\Deleted))

C. 参考文献

[IMAP-AUTH] Myers, J., "IMAP4 Authentication Mechanism", RFC 1731. Carnegie-Mellon University, December 1994.

[IMAP-COMPAT] Crispin, M. "IMAP4 Compatibility with IMAP2 and IMAP2bis", RFC 1732, University of Washington, December 1994.

[IMAP-DISC] Austein, R. "Synchronization Operations for Disconnected IMAP4 Clients", Work in Progress.

[IMAP-MODEL] Crispin, M. "Distributed Electronic Mail Models in IMAP4", RFC 1733, University of Washington, December 1994.

[IMAP-NAMING] Crispin, M. "Mailbox Naming Convention in IMAP4", Work in Progress.

[IMAP2] Crispin, M., "Interactive Mail Access Protocol - Version 2", RFC 1176, University of Washington, August 1990.

[IMSP] Myers, J. "IMSP -- Internet Message Support Protocol", Work in Progress.

[MIME-1] Borenstein, N., and Freed, N., "MIME (Multipurpose Internet Mail Extensions) Part One: Mechanisms for Specifying and Describing the Format of Internet Message Bodies", RFC 1521, Bellcore, Innosoft, September 1993.

[MIME-2] Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part Two: Message Header Extensions for Non-ASCII Text", RFC 1522, University of Tennessee, September 1993.

[RFC-822] Crocker, D., "Standard for the Format of ARPA Internet Text Messages", STD 11, RFC 822, University of Delaware, August 1982.

[SMTP] Postel, Jonathan B. "Simple Mail Transfer Protocol", STD 10, RFC 821, USC/Information Sciences Institute, August 1982.

E. IMAP4キーワードインデックス

トップページ - 翻訳ドキュメント - RFC 1730

INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4

この文書の位置付け

概要

目次