1730原文:ftp://ftp.rfc-editor.org/in-notes/rfc1730.txt訳注:IMAP4仕様の最新はRFC3501です(2004/02/16時点)。4この文書の位置付けこの文書はインターネットコミュニティの為のインターネット標準トラックプロトコルについて述べており、改良に向けての議論と提案を求めている。1)を参照して欲しい。この文書の配布は無制限である。(IMAP4)は、クライアントがサーバー上の電子メールへのアクセスと操作を行う事を可能にする。IMAP4は"メールボックス"と呼ばれるリモートのメッセージフォルダの操作を可能にする。ある程度まで、それはローカルメッセージボックスに対してと同様に機能する。IMAP4はオフラインのクライアントがサーバーと再同期する機能も提供する([IMAP-DISC]参照)。選択取得の為の操作を含んでいる。IMAP4上のメッセージは数字を用いてアクセスされる。その数字は、メッセージ連番(1から始まりメールボックス内のメッセージ数までの相対位置)、またはユニーク識別子(各々のメッセージに割当てられる不変で厳密に増加する値であり、連番である必要はない)である。IMAP4は単一サーバーをサポートする。複数IMAP4サーバーをサポートするメカニズムは[IMSP]で議論されている。IMAP4はメール送信に付いては規定しない。その機能は[SMTP]のようなメール転送プロトコルが扱う。IMAP4は[IMAP2]プロトコルの上位互換となるように設計されている。互換性の問題は[IMAP-COMPAT]で議論されている。この文書の読み方この文書はMPAP4クライアントやIMAP4サーバー実装者の視点から書かれている。セクション2のプロトコル概観以降は、このプロトコルの操作を理解しようとする人向けには最適化されていない。セクション3からセクション5の資料は、IMAP4が扱う一般的な状況と定義を提供する。セクション6・7・9はそれぞれ、IMAPの命令・応答・文法に付いて説明している。これらの関係は、この内のどれでも個別に理解する事はほとんど不可能な類いのものである。命令のセクションのみから命令の文法を推測しようとするべきではない。その代わりに、正式な文法セクションを参照するべきである。例における"C:"と"S:"は、それぞれクライアントとサーバーから送信される行を示す。回線水準IMAP4プロトコルは、TCPが提供するような信頼出来るデータストリームを仮定する。TCPが使用される場合、IMAP4サーバーはポート143を使用する。命令と応答IMAP4セッションは、クライアント/サーバー接続の確立、サーバーからの最初の挨拶、クライアント/サーバーの対話から構成される。クライアント/サーバーの対話は、クライアントの命令、サーバーのデータ、サーバーの完了結果応答から成る。クライアントとサーバーによって送信される全ての対話は、行形式、すなわちCRLFで終わる文字列である。IMAP4のクライアントやサーバーのプロトコル受信側は、一行を読むか、総数が分かっているオクテット列の後に一行を読む。プロトコル送信側クライアントとプロトコル受信側サーバークライアントの命令がオペレーションを開始する。各クライアント命令には、"タグ"と呼ばれる識別子(通常は短い英数字の文字列。A0001、A0002など)が置かれる。クライアントによって、各々の命令に対して異なるタグが生成される。クライアントからの一行が完全な命令を表わさない場合が二つある。ひとつは、命令の引数がオクテット数として参照されている場合(データフォーマットにおける文字列中のリテラルに付いての説明を参照)、もうひとつは、命令の引数がサーバーの応答を必要とする場合(AUTHENTICATE命令を参照)である。この応答は"+"記号を前に置く。命令実行中にサーバーがエラーを検出した場合、サーバーはその命令を拒否し、クライアントがその命令をそれ以上送信する事を防ぐ為に、その命令と一致するタグを付けたBAD完了応答(後に説明する)を送信する。サーバーは、(複数の命令が進行中ならば)他の命令に対する完了応答またはタグ無しデータを送る事も可能である。どちらの場合でも命令継続応答は未解決のままであり、クライアントはその応答に対して適切なアクションを取り、サーバーからの別の応答を待つ。IMAP4サーバーのプロトコル受信側は、クライアントからの命令行を読み、命令と引数を解析し、サーバーのデータや命令の完了結果応答を送信する。プロトコル送信側サーバーとプロトコル受信側クライアントサーバーからクライアントに送信されるデータや、命令完了を示す以外の状態応答は"*"記号を前に置き、タグ無し応答と呼ばれる。サーバーデータはクライアント命令の結果として送っても良いし、サーバーから一方的に送っても良い。特定の命令の結果としてのサーバーデータと、一方的に送られるサーバーデータの間に文法的な違いはない。サーバーの完了結果応答は操作の成功・失敗を表わし、その操作を開始したクライアント命令と同じタグを持つ。これにより、2つ以上の命令が同時進行中の場合、サーバーの完了結果応答のタグはその応答が適用される命令を指す事になる。3つのサーバー完了応答が存在する:OK(成功を示す)、NO(失敗を示す)、BAD(認識できない命令や文法エラーといったプロトコルエラーを示す)。IMAP4クライアントのプロトコル受信側は、サーバーからの応答行を読み、応答の最初の記号(タグ、"*"または"+")に基いて行動を起こす。これは上記で説明した通りである。クライアントは常に、サーバーからのいかなる応答でも受け付ける用意が出来ていなければならない(MUST)。クライアントがサーバーにデータを要求する命令を送るのではなく、記録されたコピーを参照出来るように、サーバーデータは記録されるべきである(SHOULD)。特定のサーバーデータでは、その記録は強制的なものとなる。この話題はサーバー応答セクションでより詳細に議論される。状態と流れ図IMAP4サーバーは4つの状態の内のひとつを取る。ほとんどの命令は特定の状態でのみ有効である。ある命令が不適切な状態の時にクライアントがその命令を試みる事は、プロトコルエラーとなる。この場合サーバーは、BADまたはNO(サーバーの実装に依存する)を持つ命令完了結果を返す。ユーザーは大部分の命令が許可される前に認証証明を提供しなければならない。接続が事前認証されていない限り、接続開始時にこの状態に入る。認証済み状態ではユーザーは認証されており、メッセージに影響する命令が許可される前に、アクセスするメールボックスを選択しなければならない。この状態には、事前認証接続が開始された時、または受入可能な認証証明が提供された時、またはメールボックス選択中にエラーが起きた後に入る。選択済み状態では、アクセスするメールボックスが選択されている。この状態にはメールボックスの選択が成功した時に入る。ログアウト状態ログアウト状態ではセッションは終了しようとしており、サーバーは接続を切ろうとしている。この状態には、クライアント要求の結果、または一方的なサーバーの決定によって入る。データフォーマットIMAP4はテキスト形式の命令と応答を使用する。括られたリスト、NIL。アトムアトムはひとつ以上の非特殊文字から成る。数値はひとつ以上の数字からなり、数値を表わす。リテラル、または引用符付き文字列。リテラル形式は文字列の一般的形式である。引用符付き文字列形式は、引用符付き文字列の中に含まれる文字の制限を犠牲にして、リテラルの処理のオーバーヘッドを避ける為の選択である。リテラルは連続する0個以上のオクテット(CR、LFを含む)であり、左ブレース("{")・オクテット数・右ブレース("}")・CRLFという形式のオクテット数を前に置く。サーバーからクライアントにリテラルが送信される場合、オクテットデータの直後にCRLFが続く。クライアントからサーバーにリテラルが送信される場合、クライアントはオクテットデータ(および命令の残り)を送信する前に、命令継続要求(この文書内で後に説明する)の受信を待たなければならない。引用符付き文字列は0個以上の7ビット文字の連続であり、CRLFを含まず、両端に二重引用符(<">)を持つ。空文字列は、""(二重引用符の間に0文字を持つ引用符付き文字列)、または{0}の後にCRLFを付けて(オクテット数0のリテラルとして)表現される。オクテット数が0の場合でも、リテラルを送信するクライアントは命令継続要求を待たなければならない。8ビット及びバイナリの文字列8ビットテキスト及びバイナリのメールは、[MIME-1]エンコードを通してサポートされる。IMAP4の実装は、リテラルとして8ビットまたは複数オクテットの文字を送信しても良い(MAY)が、それはその文字セットが識別可能な場合のみに限るべきである。バイナリの本文のエンコードは定義されているが、エンコードされていないバイナリ文字列は許可されない。"バイナリ文字列"は、NUL文字を伴う任意の文字列である。データを送信する前に、実装はバイナリデータをBASE64のようなテキスト形式にエンコードしなければならない(MUST)。必須ではないが、多量のCTL文字を含む文字列もバイナリと見なして良い。括弧で括られたリストデータ構造は"括弧で括られたリスト"(空白で区切られたデータ項目の並びで、両端を括弧で括る)として表わされる。括弧で括られたリストは、ネストを表す複数レベルの括弧を使用して、それ自身に別の括弧で括られたリストを含んでも良い。空のリストは、()(メンバーを持たない括弧で括られたリスト)で表現される。NIL特殊なアトムである"NIL"は、文字列や括弧で括られたリストにおいて値が存在しない事を表わし、空文字列""や空のリスト()とは区別される。メールボックスの名前付けメールボックス名の解釈は実装に依存する。INBOXというメールボックス名は、"このサーバー上でのこのユーザーの主要なメールボックス"を意味する為に予約された特別な名前である。階層的なメールボックス名をエクスポートしたい場合、メールボックス名は階層レベルを区切る為の単一文字を用いた左から右への階層構造にしなければならない。ひとつの名前の中では、全ての階層レベルの為に同じ階層区切り文字を使用する。メールボックスサイズとメッセージ状態の更新サーバーは、クライアントが要求していないデータをいつでも送信出来る。時々このような動作が必要になる。サーバーとは別のエージェントがメールボックスにメッセージを追加したり(例えば新規メールの配送)、メールボックス中のメッセージのフラグを変更したり、メールボックスからメッセージを削除する場合である。命令処理中にメールボックスサイズの変更が検出された場合、サーバーは自動的にメールボックスサイズ更新を送信しなければならない(MUST)。クライアントからの明確な更新要求がない場合でも、サーバーは自動的にメッセージフラグ更新を送信するべきである(SHOULD)。メッセージの削除による同期エラーを防ぐ為に、サーバーからクライアントへの特別な規則の通知が存在する。詳細はEXPUNGE応答の説明を参照して欲しい。クライアントがサーバーからのデータの記録を行うかどうかという実装の決定には関係なく、クライアントはメールボックスサイズの更新を記録しなければならない(MUST)。命令が進行中ではない場合の応答サーバー実装は、命令(EXPUNGEを除く)が進行中でない間にタグ無し応答を送信しても良い。このような応答を送信するサーバー実装は、フロー制御を扱わなければならない(MUST)。具体的には、(1)データのサイズが下層トランスポートで利用可能なウィンドウサイズを越えない事を確かめるか、(2)非ブロッキング書き込みを使用しなければならない。自動ログアウトタイマーサーバーが非アクティブ自動ログアウトタイマーを持つ場合、タイマーは最低でも30分間持続時間を持たなければならない(MUST)。その間隔内でのクライアントからのいかなる命令の受信でも、自動ログアウトタイマーをリセットする為には十分であるべきである。進行中の複数命令クライアントは、別の命令を送る前に完了結果応答を待つ必要はない(下層のフロー制御の影響は受ける)。同様にサーバーは、命令の結果が別の命令に影響を与えるような不明確さがない限り、次の命令処理を開始する前に別の命令を完了する必要はない。不明確さがある場合、サーバーはクライアントから与えられた順序で完了するように命令を実行する。クライアント命令このセクションではIMAP4の命令を説明する。命令は、その命令が許可される状態によってグループ化されている。複数の状態において許可される命令は、許可される最低限の状態にリストされている(例えば認証済み状態と選択済み状態で有効な命令は、認証済み状態にリストされている)。以下の説明中の引数("引数:"で示されている)は、文法に従ってではなく、機能に従って説明されている。引数の正確な文法は、正式な文法セクションで説明されている。いくつかの命令は特定のサーバーデータの返信を発生させる。これらは以下の説明中、"データ:"で示されている。これらの応答に付いての情報は応答セクションを参照し、正確な文法に付いては正式な文法セクション内の応答の説明を参照して欲しい。任意の命令の結果としてサーバーデータを送信する事が可能である。サーバーデータを特に必要としない命令では、"無し"の代わりに"その命令に対する特別なデータでは無い"データを指定しても良い。説明中の"結果:"は、命令へのあり得るタグ付き状態応答と、それらの状態応答の特別な解釈に付いて言及している。未知の命令、または引数が無効CAPABILITY命令はサーバーがサポートする能力のリストを要求する。サーバーは(タグ付き)OK応答の前に、最初にリストされる能力として"IMAP4"を持つ、単独のタグ無しCAPABILITY応答を送信しなければならない(MUST)。能力のリストは接続状態やユーザーには依存しない為、あるセッション中に2回以上CAPABILITY命令を発行する必要はない。"IMAP4"以外の能力名は、この規約の拡張または改定、改正を示す。追加情報はCAPABILITY応答の文章を参照して欲しい。どの能力も、その能力を呼び出すクライアントの明示的アクションがない限り使用出来ない。実験用/拡張"のセクションを参照して欲しい。未知の命令、または引数が無効NOOP命令は常に成功する。これは何も実行しない。任意の命令にタグ無しデータとして状態更新を返す事が出来るので、NOOP命令は、新規メッセージや非アクティブ期間中のメッセージ状態更新の為の定期的ポーリングとして使用出来る。サーバーの非アクティブ自動ログアウトタイマーのリセットに使用する事も出来る。未知の命令、または引数が無効LOGOUT命令は、クライアントがそのセッションを完了した事をサーバーに知らせる。サーバーは(タグ付き)OK応答の前に、タグ無しBYE応答を送信しなければならない。その後、ネットワーク接続を閉じる。AUTHENTICATE命令またはLOGIN命令が認証を確立し、認証状態に入る。LOGIN命令が伝統的なユーザー名と平文パスワードの組合せを使用するのに対し、AUTHENTICATE命令は様々な認証技術の為の一般的メカニズムを提供する。サーバー実装は、特定のメールボックスへの未認証アクセスを許可しても良い。慣例的には、ユーザーID"anonymous"でLOGIN命令を使用する。パスワードは必要である。パスワードに何を要求するかや、匿名ユーザーにどのようなアクセス制限を課すかは実装依存である。認証(匿名も含めて)されると、未認証状態に戻る事は出来ない。汎用命令(CAPABILITY、NOOP、LOGOUT)に加えて、未認証状態では次の命令が有効である:AUTHENTICATE、LOGIN。未知の命令、または引数が無効、認証交換の取り消しAUTHENTICATE命令は、[IMAP-AUTH]に記述されているような認証メカニズムをサーバーに示す。サーバーは、要求された認証メカニズムをサポートしていれば、ユーザーを認証・識別する為に認証プロトコルの交換を行う。任意で、後続のプロトコル対話用の保護メカニズムも取り決める。要求された認証メカニズムがサポートされていない場合、サーバーはタグ付きNO応答の送信によってAUTHENTICATE命令を拒否するべきである。認証プロトコルの交換は、その認証メカニズムが規定する一連のサーバー要求と、クライアント応答から構成される。サーバー要求は、"+"の後にBASE64でエンコードされた文字列を持つ命令継続要求応答で構成される。クライアント応答は、BASE64でエンコードされた文字列を含む一行で構成される。クライアントが認証交換を取り消したい場合、単独の"*"を持つ行を発行するべきである。そのような応答を受け取った場合、サーバーはタグ付きBAD応答の送信によってAUTHENTICATE命令を拒否しなければならない。保護メカニズムは、プロトコルセッションに統一性と機密保護を提供する。保護メカニズムが取り決められた場合、それはその接続全体にわたって送信される後続の全データに適用される。保護メカニズムは、クライアントの認証交換を締め括るCRLFと、サーバーのタグ付きOK応答のCRLFの後、即座に効果を効果を示す。保護メカニズムの影響下に入ると、命令と応答オクテットのストリームは暗号文のバッファを通して処理される。各々のバッファは、後続データの長さを表すネットワークバイトオーダーの4オクテットを最初に付けたオクテットのストリームとして、接続全体を通じて送信される。暗号文バッファの最大長は、保護メカニズムによって定義される。サーバーは特定の認証メカニズムをサポートする必要はないし、認証メカニズムはどの保護メカニズムもサポートしなくても良い。AUTHENTICATE命令がNO応答によって失敗した場合、クライアントは別のAUTHENTICATE命令を発行する事で別の認証メカニズムを試みても良いし、LOGIN命令による認証を試みても良い。言い換えると、優先順位の高い順に認証を要求し、最後の手段としてLOGIN命令を使用して良い。最初のクライアント応答内の改行は編集上の配慮であり、実際には改行は無い。未知の命令、または引数が無効LOGIN命令はサーバーに対してユーザーを特定し、そのユーザーを認証する平文パスワードを送る。認証済み状態では、メールボックスを一塊として扱う命令が許可される。これらの命令の内SELECT命令とEXAMINE命令がアクセスするメールボックスを選択し、選択済み状態に入らせる。メールボックスが存在しない。未知の命令、または引数が無効SELECT命令は、メールボックス内のメッセージにアクセス出来るようにメールボックスを選択する。サーバーはクライアントにOKを返す前に、クライアント側でメールボックスの初期状態を定義出来るように、以下のタグ無しデータをクライアントに送信しなければならない(MUST)。ユニーク識別子を確認する値。詳細はUID命令の説明を参照して欲しい。前回そのメールボックスが読まれた時以降に追加されたメッセージを特定出来ない場合、全てのメッセージが新規と見なされるべきである(SHOULD)。サーバーは、メールボックス中の最初の未読メッセージのメッセージ番号を示す為に、タグ無しOK応答の中にUNSEEN応答コードを含めて送るべきである(SHOULD)。クライアントがタグ無しFLAGS応答中にリストされるフラグの内ひとつ以上のフラグの恒久的状態を変更出来ない場合、サーバーはタグ無しOK応答の中でPERMANENTFLAGS応答コードを送り、クライアントが恒久的に変更出来るフラグをリストするべきである(SHOULD)。ひとつのセッション中には一度にひとつのメールボックスのみ選択して良い。従って複数メールボックスに同時アクセスするには、複数セッションが必要である。SELECT命令は、新しい選択を試みる前に、現在選択されているメールボックスを自動的に開放する。結果として、メールボックスが選択されていて、かつSELECT命令が失敗した場合、どのメールボックスも選択されない。ユーザーがメールボックスを変更する事を許可される場合、サーバーは、タグ付きOK応答の後に、"[READ-WRITE]"応答コードを付けたテキストを置くべきである(SHOULD)。ユーザーがメールボックスを変更する事は許可されないが読み取りは許可される場合、メールボックスは読取専用として選択され、サーバーはSELECTに対するタグ付きOK応答の後に"[READ-ONLY]"応答コードを付加したテキストを置かなければならない(MUST)。SELECT命令を通しての読取専用アクセスはEXAMINE命令と異なり、特定の読取専用メールボックスにおいて(グローバルと逆に)ユーザー毎の基準に基づく恒久的状態変更を許可される。ユーザーの.newsrcファイルに記録されるネットニュースメッセージは、そのような読取専用メールボックスで変更可能なユーザー毎の恒久的状態の例である。そのメールボックスが無い。未知の命令、または引数が無効EXAMINE命令はSELECTと同一であり、同じ出力を返す。選択されたメールボックスは読取専用と見なされ、いかなる恒久的状態変更(ユーザー毎の状態も含めて)も許可されない。EXAMINE命令に対するタグ付きOK応答のテキストは、"[READ-ONLY]"応答コードで始まらなければならない(MUST)。未知の命令、または引数が無効CREATE命令は、与えられた名前でメールボックスを作成する。OK応答は、その名前で新規メールボックスが作成された場合にのみ返される。INBOXまたは既存のメールボックスと同じ名前のメールボックスを作成しようとすると、エラーとなる。作成中のいかなるエラーも、タグ付きNO応答を返す。メールボックス名の最後の文字がサーバーの階層区切り文字(LIST命令でサーバーから返される)の場合、それは、クライアントが将来階層内のその名前の下にメールボックスを作成するかもしれないという宣言である。この宣言を必要としないサーバー実装は、これを無視しなければならない(MUST)。削除されたメールボックスと同じ名前で新規メールボックスが作成された場合、そのメールボックスのユニーク識別子は、新しいメールボックスが異なるユニーク識別子有効値を持たない限り、以前のメールボックスで使用されていた全てのユニーク識別子よりも大きくなくてはならない(MUST)。詳細はUID命令の説明を参照して欲しい。この例の解釈は、LISTの階層区切りとして"/"が返されていたかどうかに依存する。"/"が階層区切りの場合、"blurdybloop"というメンバーを持つ"owatagusiam"という名前の新しい階層レベルが作成される。ない場合、二つのメールボックスが同じ階層レベルに作成される。未知の命令、または引数が無効DELETE命令は、与えられた名前のメールボックスを完全に削除する。タグ付きOK応答は、メールボックスが削除された場合にのみ返される。INBOXまたは存在しない名前のメールボックスを削除しようと、エラーとなる。削除中のいかなるエラーも、タグ付きNO応答を返す。削除されたメールボックスのユニーク識別子の最大値は、同じ名前で作成された新しいメールボックスが前の識別子を再利用しないように、その新規メールボックスが異なるユニーク識別子有効値を持たない限り、保存されなければならない(MUST)。詳細はUID命令の説明を参照して欲しい。そのメールボックスは名前変更出来ない。未知の命令、または引数が無効RENAME命令は、メールボックスの名前を変更する。タグ付きOK応答は、メールボックスの名前が変更された場合にのみ返される。存在しないメールボックス名からの変更や、既に存在するメールボックス名への変更はエラーとなる。名前変更中のいかなるエラーも、タグ付きNO応答を返す。INBOXの名前変更も許されており、その場合、新しい空のINBOXが作成される。未知の命令、または引数が無効SUBSCRIBE命令は指定されたメールボックスを、LSUB命令の応答として返されるサーバーの"アクティブ"または"購読中"の集合に追加する。この命令は購読が成功した場合のみ、タグ付きOK応答を返す。未知の命令、または引数が無効UNSUBSCRIBE命令は指定されたメールボックスを、LSUB命令の応答として返されるサーバーの"アクティブ"または"購読中"の集合から削除する。この命令は購読の取り消しが成功した場合のみ、タグ付きOK応答を返す。未知の命令、または引数が無効LIST命令は、ユーザーが利用可能な全ての名前の集合から、そのサブセットを返す。名前の属性・階層区切り文字・名前を含む、0個以上のタグ無しLIST応答が返される。詳細はLIST応答の説明を参照して欲しい。空の参照名(文字列"")の引数は、SELECTされているメールボックス名であると解釈される。返されるメールボックス名は、与えられたメールボックス名のパターンと一致しなければならない。空ではない参照名の引数は、メールボックス名またはメールボックス階層レベルであり、実装定義の方法でメールボックス名が解釈される場合のコンテキストを示す。引数の参照名とメールボックス名は、曖昧さのない左から右へ階層を表す標準的な形式に(実装依存の方法で)解釈される。返されるメールボックス名は解釈された形式に沿う。解釈された形式に含まれる参照名引数のどの部分も、解釈された形式を前に置くべきである(SHOULD)。参照名引数と同じ形式にも従うべきである。この規則によりクライアントは、返されたメールボックス名が参照引数の文脈なのか、あるいはメールボックス引数が参照引数を上書きしたかのかを判断出来る。この規則がなければ、クライアントは、どの文字が名前付けコンテキストを上書きする"ブレークアウト"なのかを含めた、サーバーの名前付け規則の情報を持たなければならないだろう。例として、UNIXベースのサーバーにおいて、参照とメールボックス名がどのように解釈されるかの例をここに示す。~fred/Mail/*最初の3つの例は、参照引数の文脈中の解釈のされかたを実演している。"~smith/Mail"が"/u2/users/smith/Mail"といった形に変換されるべきではない点に注意して欲しい。ないと、クライアントはその解釈が参照のコンテキストである事を判断できないだろう。文字"*"はワイルドカードであり、その位置の0個以上の文字と一致する。文字"%"は"*"と似ているが、階層区切り文字とは一致しない。メールボックス名引数の最後の文字がワイルドカード"%"の場合、一致する階層レベルも返される。それらの階層レベルが選択出来ないメールボックスの場合、\Noselectというメールボックス名属性付きで返される(より詳細はLIST応答の説明を参照)。サーバー実装は、特定の状況で特定の文字や名前がワイルドカードに一致する事を妨く事で、ワイルドカードとは別の方法でアクセス出来るメールボックスを"隠す"事が出来る。UNIXベースのサーバーでは、先頭の"/"が"*"と一致しないように解釈を制限しても良い。特別な名前INBOXは、それが入力引数に一致するのならLISTの出力に含まれ、そのサーバーによってそのユーザーの為にサポートされる。INBOXが失敗を返すかどうかであり、ユーザーの実際のINBOXがそのサーバ上か別のサーバー上に存在するかどうかとは無関係である。未知の命令、または引数が無効LSUB命令は、ユーザーが"アクティブ"または"購読中"と宣言した名前の集合から、そのサブセットを返す。0個以上のタグ無しLSUB応答が返る。LSUBへの引数は、LISTの引数と同じ形式である。そのメールボックスに追加出来ない。未知の命令、または引数が無効APPEND命令は、指定されたメールボックスに新しいメッセージとしてリテラルの引数を追加する。この引数は[RFC-822]メッセージ形式に従う。メッセージ中に8ビット文字を使用しても良い。8ビットデータを適切に保存出来ないサーバー実装は、APPENDする8ビットデータを[MIME-1]エンコードを使用して7ビットに可逆変換出来なければならない(MUST)。括弧で括られたフラグのリスト、または日付時刻が指定された場合、その情報は処理されるメッセージに対して設定さるべきである(SHOULD)。指定されていない場合、空のフラグと現在の日付/時刻が既定値として使用される。何らかの理由により追加が失敗した場合、メールボックスはAPPENDされる前の状態に復元されなければならない(MUST)。部分的追加は許可されない。現在メールボックスが選択されていれば、通常の新規メールの動作が起こるべきである。NOT)、エラーを返さなければならない(MUST)。対象メールボックスが作成出来ない事が確実ではない限り、サーバーはタグ付きNO応答のテキストの接頭辞として、応答コード"[TRYCREATE]"を送信しなければならない(MUST)。これはクライアントに、CREATE命令を試し、もし成功すれば再びAPPENDを試みる事が出来るというヒントを与える。APPEND命令はメッセージの配送には使用されない。[SMTP]エンベロープ情報を送信するメカニズムを提供しないからである。選択済み状態では、メールボックス中のメッセージを操作する命令が許可される。未知の命令、または引数が無効CHECK命令は、現在選択されているメールボックスのチェックポイントを要求する。チェックポイントとは、各命令の一部としては通常実行されないメールボックスに関連する任意の実装依存作業(例えば、サーバーのメモリ上にあるメールボックスの状態をディスクに保存する)である。チェックポイントは即座に完了されなくても良い。サーバー実装がこのような作業を考慮していない場合、CHECKはNOOPと同じである。CHECKの結果として、タグ無しEXISTS応答が発生する事は保証されない。新規メールのポーリングにはCHECKではなく、NOOPが使用されるべきである。未知の命令、または引数が無効CLOSE命令は、現在選択されているメールボックスから\Deletedフラグがセットされている全てのメッセージを完全に削除し、選択済み状態から認証済み状態に戻す。タグ無しEXPUNGE応答は送信されない。メールボックスがEXAMINE命令で選択されているか、読取専用で選択されている場合、メッセージは削除されず、エラーも発生しない。メールボックスが選択されている場合でも、SELECT命令・EXAMINE命令・LOGOUT命令の前にCLOSE命令を送信する必要はない。SELECT命令・EXAMINE命令・LOGOUT命令は、削除を行わずに、暗黙のうちに現在選択されているメールボックスを閉じる。多くのメッセージが削除されている場合、CLOSE-LOGOUTやCLOSE-SELECTの流れは、EXPUNGE-LOGOUTやEXPUNGE-SELECTよりもかなり速くなる。(おそらくクライアントは無視するであろう)タグ無しEXPUNGE応答が送信されないからである。未知の命令、または引数が無効EXPUNGE命令は、現在選択されているメールボックスから\Deletedフラグがセットされている全てのメールを完全に削除する。クライアントにOKが返される前に、削除されたメッセージ毎にタグ無しEXPUNGE応答が送信される。この例では、メッセージ3,4,7,11に\Deletedフラグがセットされていた。詳しい説明はEXPUNGE応答の説明を参照して欲しい。その文字セットまたは条件を検索出来ない。未知の命令、または引数が無効SEARCH命令は、与えられた検索条件に一致するメールボックス内のメッセージを検索する。検索条件は1つ以上の検索キーから成る。サーバーからのタグ無しSEARCH応答は、検索条件に一致するメッセージに対応するメッセージ連番のリストを含む。複数のキーが指定された場合、結果はそれらのキーに一致するメッセージの積(AND演算)である。いう条件は、1994年2月1日以降にそのメールボックスに保存されてたSmithからの削除された全メッセージを表す。検索キーは1つ以上のキーが括弧で括られたリストであっても良い(例えば、OR条件やNOT条件の使用の為)。サーバー実装は、SEARCH検索の対象からTEXTとMESSAGE以外に、[MIME-1]本文部分を除いても良い(MAY)。オプションの文字セット指定は、単語"CHARSET"に続く登録済みMIME文字セットから構成され、検索条件に現れる文字列の文字セットを示す。822/MIMEメッセージヘッダの中に現れる[MIME-2]文字列と[MIME-1]エンコードは、検索の前にデコードされなければならない(MUST)。US-ASCIIを除き、いかなる特定の文字セットもサポートする必要はない。指定された文字セットをサポートしていない場合、サーバーはタグ付きNO応答(BADではなく)を返さなければならない(MUST)。文字列を使用する検索キーは全て、それがフィールドの部分文字列であっても一致する。検索は大文字・小文字を区別しない。定義済み検索キーは以下の通り。引数の正確な文法定義は、正式な文法セクションを参照して欲しい。<メッセージセット>指定されたメッセージ連番の集合に一致するメッセージ連番を持つメッセージALLメールボックス中の全メッセージ。<n>指定された数のオクテット数より大きいRFC822.SIZEを持つメッセージNEW\Recentフラグを持ち\Seenフラグを持たないメッセージ。UNSEEN)"と同じ機能である。NEW"ではなく)と同じ機能である。未知の命令、または引数が無効FETCH命令はメールボックス内のメッセージに関連する情報を取得する。現在定義されている取得可能なデータ項目は以下の通り。ENVELOPE)と同様のマクロBODYBODYSTRUCTUREの非拡張形式BODY[<セクション>]本文の指定セクションのテキスト。セクションの定義は、ピリオドで区切られた1つ以上のパート番号の集合である。単一パートのメッセージは、パート1のみを持つ。マルチパートメッセージは、メッセージに現れる順に連続するパート番号が割当てられる。あるパートがメッセージまたはマルチパートの場合、その内部のパートは、ピリオドの後に、ネストされたマルチパート内部でのパート番号を付けて表されなければならない。マルチパート部自身を取得する事は許されず、個別のメンバーのみ取得する事が許される。MESSAGE型のパートおよびサブタイプRFC822のパートも、ネストしたパートを持つ。これらはMESSAGEパートの本文の一部である。MESSAGE型およびRFC822サブタイプのパート0は、そのメッセージの[RFC-822]ヘッダである。全てのメッセージは最低でもひとつのパートを持つ。ここで複合メッセージの例を、その対応するセクション番号と共に示す。TEXT/RICHTEXTマルチパート部(セクション4と4.2.2)にはセクション番号が無い事に注意して欲しい。\Seenフラグは暗黙のうちに設定されるが、それがフラグの変更を引き起こす場合、応答の一部に含まれるべきである。BODY.PEEK[<セクション>]暗黙のうちに\Seenフラグを設定されていないBODY[セクション]の、もうひとつの形式BODYSTRUCTUREメッセージの[MIME-1]本文構造体。[MIME-1]ヘッダ行を解析する事でサーバーによって算出される。ENVELOPEメッセージのエンベロープ構造体。必要なら種々のフィールドを無視しながら[RFC-822]ヘッダを各構成部分に分解する事で、サーバーによって算出される。RFC822[RFC-822]形式のメッセージ。\Seenフラグは暗黙のうちに設定されるが、それがフラグの変更を引き起こす場合、応答の一部に含まれるべきである。これはRFC822.HEADERとRFC822.TEXTの連結である。<ヘッダリスト>ヘッダリスト内のいずれかの文字列と一致するフィールド名([RFC-822]で定義される)を持つ、[RFC-822]形式のメッセージヘッダの全ヘッダ行(継続行を含む)。検索は大文字・小文字を区別しないが、厳密である。ヘッダと本文の間の区切り空行は常に含まれる。<ヘッダリスト>ヘッダリスト内のいずれかの文字列と一致するフィールド名([RFC-822]で定義される)を持たない、[RFC-822]形式のメッセージヘッダの全ヘッダ行(継続行を含む)。検索は大文字・小文字を区別しないが、厳密である。ヘッダと本文の間の区切り空行は常に含まれる。RFC822.SIZE[RFC-822]形式で表現されたメッセージのオクテット数RFC822.TEXT[RFC-822]ヘッダを除くメッセージ本文のテキスト。\Seenフラグは暗黙のうちに設定されるが、それがフラグの変更を引き起こす場合、応答の一部に含まれるべきである。未知の命令、または引数が無効PARTIAL命令は、指定された開始オクテットから指定されたオクテット数だけ返す機能をFETCH命令に追加したものと同等である。一度にひとつのメッセージだけ取得出来る。メッセージの最初のオクテット(つまり、開始オクテットの最小値)は1である。次のFETCH項目がPARTIAL用に有効なデータである:RFC822、RFC822.HEADER、RFC822.TEXT、BODY[section]、及びこれらの.PEEK形式。テキストの終端を越える部分は適切に切り捨てられる。開始オクテットがテキストの最後を越えている場合は空文字列が返される。データはFETCH応答と共に返される。応答の中にはデータの範囲を示すものはない。連続する命令は順不同に実行されるので、各ステップでの同期処理無しに、同じデータ項目への連続した複数のPARTIAL命令を実行する事は不可能である。部分FETCHが特定の順序に従う必要はない。オクテット1から10000までの部分取得が、扱い難いBASE64デコードに割り込まれる場合、9987から19987までなどの部分取得で継続する事が可能である。\Seenフラグの扱いはFETCH命令と同じである。未知の命令、または引数が無効STORE命令は、メールボックス内のメッセージに関連する情報を変更する。通常STORE命令は、更新された情報の値をタグ無しFETCH応答と共に返す。データ項目名の接尾辞".SILENT"は、タグ無しFETCH応答を抑制し、サーバーはクライアントが自分で更新された値を特定するか、更新された値に付いて気にしないと仮定するべきである。現在定義されているSTORE可能なデータ項目は以下の通り。<フラグリスト>メッセージのフラグを引数のフラグに置き換える。新しいフラグの値が取得されたかのように返される。<フラグリスト>FLAGSと同等であるが、新しい値は返さない。<フラグリスト>メッセージのフラグに引数のフラグを追加する。新しいフラグの値が取得されたかのように返される。<フラグリスト>+FLAGSと同等であるが、新しい値は返さない。<フラグリスト>メッセージのフラグから引数のフラグを取り除く。新しいフラグの値が取得されたかのように返される。<フラグリスト>-FLAGSと同等であるが、新しい値は返さない。メッセージをコピー出来ない、またはその名前にコピー出来ない。未知の命令、または引数が無効COPY命令は、指定されたメッセージを指定されたメールボックスにコピーする。元のメッセージのフラグと内部情報は、コピーに対しても保存されるべきである(SHOULD)。目的のメールボックスが作成出来ない事が確実ではない限り、サーバーはタグ付きNO応答のテキストの接頭辞として、応答コード"[TRYCREATE]"を送信しなければならない(MUST)。これはクライアントに、CREATE命令を試し、もし成功すれば再びCREATEを試みる事が出来るというヒントを与える。何らかの理由によりCOPY命令が失敗した場合、サーバーは対象メールボックスをCOPYが試みられる前の状態に復元されなければならない(MUST)。未知の命令、または引数が無効UID命令は二つの形式を持つ。一つ目の形式ではその引数として、COPY命令・FETCH命令・STORE命令と、それに関連する引数を取る。メッセージセット引数の数字はメッセージ連番ではなく、ユニーク識別子である。二番目の形式では引数としてSEARCH命令とその引数を取る。SEARCH命令に対するSEARCH応答で返される数値はメッセージ連番ではなく、ユニーク識別子である。443:557は、メッセージ連番セット1:100とUIDセット443:557の積に対応するユニーク識別子を返す。メッセージのユニーク識別子は数値であり、メールボックス中のいかなる他のメッセージも参照しない事が保証される。ユニーク識別子は、メールボックスに追加されたメッセージ毎に厳密に増加する方法で割り当てられる。メッセージ連番とは異なり、ユニーク識別子はセッションをまたいで継続する。これによりクライアント(例えば切断されたかオフラインのクライアント)は、そのサーバーとの前回のセッション以降の状態を再同期出来る。これについては[IMAP-DISC]でより詳細に議論されている。全てのメールボックスがユニーク識別子有効値を持っており、メッセージ選択時のタグ無しOK応答中のUIDVALIDITY応答コードの中で送信される。前回のセッションでのユニーク識別子が今回のセッションでの継続利用に失敗した場合、ユニーク識別子有効値は前回のセッションの時よりも大きくなければならない(MUST)。ユニーク識別子有効値に使用するのに都合の良い値の例は、メールボックスの作成日付/時刻の32ビット表現だろう。1のような定数を使用しても構わないが、それは、そのメールボックスが削除され、将来新しいメールボックスが同じ名前で作成された場合でも、そのユニーク識別子が決して再利用されない事が保証される場合だけである。メッセージセットの範囲指定は可能だが、ユニーク識別子が連続している事は保証されない。メッセージセット範囲内に存在しないユニーク識別子は、何のエラーメッセージも発生させず、無視される。タグ無しFETCH応答中の"*"の後の数字は、UID命令に対する応答の場合でもユニーク識別子ではなく、通常はメッセージ連番である。サーバー実装は、FETCH命令へのメッセージデータ項目としてUIDが指定されているかどうかに関係なく、UID命令に対するFETCH応答の一部としてUIDメッセージデータ項目を暗黙のうちに含めなければならない(MUST)。文字Xで始まる命令は実験的命令である。この規約や標準、あるいはこの規約の標準改訂の一部ではない命令は、接頭辞Xを使用しなければならない(MUST)。実験的命令に対して発行されるタグ無し応答は、全てXを前に置かなければならない(MUST)。説明中"データ:"で示されるサーバー応答情報は、文法に従ってではなく、機能に従って記述されている。サーバー応答の正確な文法は、正式な文法セクションで説明されている。クライアントは常に、サーバーからのいかなる応答でも受け付ける準備が出来ていなければならない(MUST)。タグ付きの状態応答はクライアント命令の完了結果を示し、命令と同じタグを持つ。いくつかの状態応答と全てのサーバーデータは、タグ無しである。タグ無し応答はタグの代わりに記号"*"で表される。タグ無しの状態応答は、サーバー挨拶、または命令の完了を表さないサーバー状態を表す。data)"なのだが、歴史的理由により、タグ無しサーバーデータ応答が"未承諾(unsolicited)"とも呼ばれる。特定のサーバーデータは、それが受信された時にクライアントによって記録されなければならない(MUST)。これはそのデータの説明で注記する。そのようなデータは後続の命令と応答の解釈に影響する重要な情報(例えばメッセージの生成や破棄に影響する更新)を伝える。他のサーバーデータは、後で参照出来るように記録されるべき(SHOULD)だが、そのデータを記録する必要が無いか、そのデータの記録に明確な目的がない場合(例えばSEARCH命令が実行されていない間のSEARCH応答)、そのデータは無視されるべきである(SHOULD)。一方的タグ無し応答の例は、IMAP接続が選択済み状態の時に発生する。選択済み状態では、サーバーは各命令実行動作の一部として、新規メッセージの確認の為にメールボックスをチェックする。新規メッセージが見つかった場合、サーバーはメールボックスの新しいサイズを反映したタグ無しのEXISTS応答とRECENT応答を送信する。タグの代わりに"+"記号を使用する。これらの応答は、不完全なクライアント命令の受け付けや、残りの命令への準備完了を示す為に、サーバーから送信される。状態応答ステータス応答は任意の応答コードを含んでも良い。応答コードは、スクエアブラケットの内のアトム形式のデータから構成され、たいていは空白と引数がそれに続く。応答コードは、クライアントソフトウェアの為の追加情報やOK/NO/BAD以上のステータスコードを含み、クライアントが追加情報に基いて取る事の出来る特定の動作がある場合に定義される。現在定義されている応答コードは以下の通り。ALERT特定の警告を含む可読テキストで、ユーザーの注意を引く方法で表示しなければならない(MUST)。PARSEメールボックス内の[RFC-822]または[MIME-1]メッセージヘッダの解析中に起きたエラーを示す可読テキスト。PERMANENTFLAGS後に括弧で括られたフラグのリストを続けて、クライアントが恒久的に変更出来る既知のフラグを示す。タグ無しFLAGS応答中には含まれるがPERMANENTFLAGSリストには含まれないフラグは、恒久的に設定する事は出来ない。クライアントがPERMANENTFLAGSリストに含まれないフラグの保存(STORE)を試みた場合、サーバーはNOを返し拒否するか、現行セッションの間だけその状態を保存する。PERMANENTFLAGSリストは特別なフラグ\*を含んでも良く、それはメールボックスにフラグの保存を試みる事で新しいキーワードを作成可能である事を示す。READ-ONLYメールボックスが読取専用で選択されている、または選択中にアクセス権が読み書き可能から読取専用に変更された。READ-WRITEメールボックスが読み書き専用で選択されている、または選択中にそのアクセス権が読取専用から読み書き可能に変更された。TRYCREATEAPPENDまたはCOPYが、対象メールボックスが存在しない為に失敗した。これは、先にCREATE命令でメールボックスを作成すれば操作が成功するかもしれないという、クライアントへのヒントである。UIDVALIDITY後に10進数値を続けて、ユニーク識別子有効値を示す。詳細はUID命令の説明を参照して欲しい。UNSEEN後に10進数値を続けて、\Seenフラグが設定されていない最初のメッセージの番号を示す。特定のクライアント実装またはサーバー実装によって定義される追加の応答コードは、それがこのプロトコルの改訂により追加されない限り、"X"を前に置くべきである。クライアント実装は認識できない応答コードを無視するべきである。応答データ:応答コード(任意)可読テキストOK応答はサーバーからの情報メッセージを示す。タグ付きの場合、対応する命令が成功した事を示す。可読テキストは情報としてユーザーに見せても良い。タグ無し形式は情報のみのメッセージを表し、情報の本質は応答コードで示されるても良い。タグ無し形式は、セッション開始時に取り得る三つの挨拶のひとつとしても使用される。それは、セッションがまだ認証されておらず、LOGIN命令が必要である事を示す。応答データ:応答コード(任意)可読テキストNO応答は、サーバーからの操作エラーメッセージを示す。タグ付きの場合、対応する命令が失敗した事を示す。タグ無し形式は警告を表し、命令が今のところは成功しているという事を示す。応答データ:応答コード(任意)可読テキストBAD応答はサーバーからのエラーメッセージを示す。タグ付きの場合、クライアントが発行した命令のプロトコルレベルのエラーを報告しており、そのタグがエラーを発生させた命令を示す。タグ無しの場合、対応する命令を特定できないプロトコルレベルのエラーを示す(サーバー内部エラーを示しているのかもしれない)。可読テキストはその状況を示す。応答データ:応答コード(任意)可読テキストPREAUTH応答は常にタグ無しで、セッション開始時の三つの取り得る挨拶のひとつである。これは、セッションが既に外部の手段によって認証済みであり、LOGIN命令は不要である事を示す。応答データ:応答コード(任意)可読テキストBYE応答は常にタグ無しであり、サーバーが接続を閉じようとしている事を示す。可読テキストは、クライアントによるユーザーへの状況報告の中表示されても良い。BYE応答は、通常のログアウト手順の一部としてか、またはサーバーのパニックによるシャットダウン表明として送信されても良い。いくつかのサーバー実装では、不活性自動ログアウトの表明としても使用される。サーバーとメールボックスの状態これらの応答は常にタグ無しである。これはしばしば、同名命令の結果として、サーバーからクライアントにどのようなデータが送信されたかを示す。応答データ:能力リストCAPABILITY応答はCAPABILITY命令の結果として起こる。能力リストはサーバーがサポートする能力名を空白で区切ったリストを含む。能力リストの最初の名前は、アトム"IMAP4"でなければならない(MUST)。IMAP4以外の能力名は、サーバーがIMAP4プロトコルの拡張、改訂、改正をサポートする事を示す。クライアントがその能力を使用する命令を発行しない限り、サーバー応答はこの文書に従わなければならない(MUST)。能力名は"X"で始まるか、標準または標準トラックIMAP4拡張、改訂、またはIANAによって登録された改正の何れかでなければならない(MUST)。NOT)、未知の能力名を無視しなければならない(MUST)。名前LIST応答はLIST命令の結果として起こり、LIST命令の指定に一致する単一の名前を返す。単独のLIST命令に対して複数のLIST応答が許される。4つの名前属性が定義されている。\Noinferiorsこの名前の下位にはいかなる子階層レベルも存在出来ず、現在も子階層は存在せず、将来も作成できない。\Noselect選択可能メールボックスとして、この名前を使用出来ない。\Markedおそらく最後に選択された時以降に追加されたメッセージを含んでいる為、このメールボックスはサーバーによって"興味がある(interesting)"としてマークされている。\Unmarkedこのメールボックスは、前回選択された時以降に追加されたメッセージを含んでいない。そのメールボックスが"興味がある(interesting)"かどうかを判断する事が出来ないか、そのメールボックスが\Noselectの場合、サーバーは\Markedや\Unmarkedを送信するべきではない。階層区切り文字はメールボックスの階層レベルを区切る為に使用される文字である。クライアントはそれを、子メールボックスを作成したり、名前階層の上位や下位の検索を行ったりする為に使用しても良い。最上位レベル階層の全ての子ノードは、同じ区切り文字を使用しなければならない。階層区切り文字NILは階層が無い事を意味し、その名前は"フラットな(flat)"名前である。名前は曖昧さのない左から右の階層を表現し、LIST命令やLSUB命令内で参照として使用される為に有効でなければならない(MUST)。\Noselectが付いていない限り、その名前はSELECTのようなメールボックスを受け付ける命令の引数としても有効でなければならない。名前LSUB応答は、LSUB命令の結果として起こり、LSUB命令の指定に一致する単一の名前を返す。単独のLSUB命令に対して複数のLSUB応答が許される。データはLIST応答と同一の形式である。SEARCH命令の結果として起こる。数値は検索条件に一致するメッセージを参照する。SEARCH命令の場合、それらはユニーク識別子である。各数値は空白で区切られる。応答データ:括弧で括られたフラグのリストFLAGS応答は、SELECT命令またはEXAMINE命令の結果として起こる。括弧で括られたフラグのリストは、このメールボックスに適用出来るフラグ(最低限なら、システム定義のフラグ)を識別する。サーバー実装によっては、システムフラグ以外のフラグが存在しても良い。FLAGS応答の更新はクライアントによって記録されなければならない(MUST)。メッセージ状態これらの応答は常にタグ無しである。これはしばしば、同名命令の結果として、サーバーからクライアントにどのようなメッセージデータが送信されたかを示す。"*"の直後に続くのは、メッセージ連番またはメッセージ総数のどちらかを表す数値である。応答データ:無しEXISTS応答はメールボックス内のメッセージ数を報告する。この応答は、SELECT命令またはEXAMINE命令の結果、あるいはメールボックスサイズの変更の結果として起こる。EXISTS応答の更新はクライアントによって記録されなければならない(MUST)。応答データ:無しRECENT応答は、そのメールボックスで前回SELECT命令が実行された時以降に到達したメッセージ数を報告する。この応答はSELECT命令またはEXAMINE命令の結果、あるいはメールボックスサイズの変更(例えば新規メール)の結果として起こる。RECENT応答の更新はクライアントによって記録されなければならない(MUST)。応答データ:無しEXPUNGE応答は、特定のメッセージ連番がメールボックスから永久に削除されたという事を報告する。メールボックス内の連続するメッセージのメッセージ連番は即座に1減算され、その減少は後に続く応答(別のタグ無しEXPUNGE応答も含む)でのメッセージ連番に影響する。即座に減算されるという規則の結果、連続するEXPUNGE応答の中に現れるメッセージ連番は、メッセージが昇順に削除されるか降順に削除されるかに依存する。9個のメッセージを含むメールボックス内の最後の5個のメッセージが削除された場合、"昇順"のサーバーはメッセージ連番5のタグ無しEXPUNGE応答を5回送信し、"降順"のサーバーはメッセージ連番9、8、7、6、5の連続したタグ無しEXPUNGE応答を送信する。この規則は、クライアントとサーバー間でのメッセージ連番の同期が損なわれる事を防ぐ為に必要である。EXPUNGE応答の更新はクライアントによって記録されなければならない(MUST)。応答データ:メッセージデータFETCH応答はクライアントにメッセージに関する情報を返す。情報はデータ項目名とその値の組が括弧に囲まれたものである。この応答は、FETCHまたはSTORE命令の結果として、または一方的なサーバーの判断(例えばフラグの更新)の結果として起こる。データ項目は以下の通り。BODY拡張情報を含まないBODYSTRUCTURE。BODY[セクション]指定セクションの本文の内容を表す文字列。クライアントは、変換エンコード、本文のタイプ、サブタイプに従ってこの文字列を解釈するべきである。8ビットテキストデータは、このセクションの為の括弧で括られたパラメータリストに、その為の文字セット識別子が含まれる場合にのみ許可される。バイナリデータのような非テキストデータは、クライアントへ送信される前に、BASE64のようなテキスト形式にエンコードされてから送信されなければならない。クライアントは元のバイナリデータを取得する為に、そのエンコードされた文字列をデコードしなければならない。BODYSTRUCTUREメッセージの本文構造を記述する括弧で括られたリスト。これは、[RFC-822]ヘッダと本文を各構成部分へと(必要であれば種々のフィールドにデフォルト値を採用して)解析する事で、サーバーによって算出される。マルチパート部は括弧のネストで示される。括弧で括られたリストの最初の要素として、本文タイプの代わりにネストした本文が存在する。マルチパート部のサブタイプの後に拡張データが続く。拡張データはBODYの取得では返されないが、BODYSTRUCTUREの取得では返されても良い。拡張データがある場合には、定義済みの順序でなければならない。マルチパートの本文の拡張データは以下の順序である。rag)なら"bar"は"foo"の値、"rag"は"baz"の値]プロトコルのこのバージョンでは、この後に続く拡張データはまだ定義されていない。そのような拡張データは0個以上のNIL、文字列、数値、または場合によってはそのようなデータのネストされた括弧で括られたリストを含んでも良い。BODYSTRUCTUREの取得を行うクライアント実装は、このような拡張データを受け取れる用意がなければならない(MUST)。マルチパートではない本文の基本フィールドは以下の順序である。本文のタイプ[MIME-1]で定義されている、内容のタイプ名を表す文字列。本文のサブタイプ[MIME-1]で定義されている、内容サブタイプ名を表す文字列。本文の括弧で括られたパラメータリスト[MIME-1]で定義されている、属性/値の組が括弧で括られたリスト。rag)では"bar"は"foo"の値、"rag"は"baz"の値]本文id[MIME-1]で定義されている、内容idを表す文字列。本文エンコード[MIME-1]で定義されている、内容変換エンコードを表す文字列。本文サイズ本文のサイズをオクテット単位で表す数字。このサイズは変換エンコードされたサイズであり、デコードされた後のサイズではない事に注意。基本フィールドの直後に来る本文タイプMESSAGEとRFC822サブタイプは、エンベロープ構造、本文構造、カプセル化されたメッセージのサイズを表すテキスト行を含む。基本フィールドの直後に来るTEXTタイプの本文タイプは、本文のサイズを表すテキスト行を含む。このサイズは変換エンコードされたサイズであり、デコードされた後のサイズではない事に注意。拡張データは、基本フィールドと前述のタイプ固有のフィールドに続く。拡張データはBODYの取得で返される事はないが、BODYSTRUCTUREの取得では返されても良い。拡張データがある場合には、定義済みの順序でなければならない。マルチパートではない本文の拡張データは、以下の順序である。本文のMD5[MIME-1]で定義されている、内容のMD5値を表す文字列。プロトコルのこのバージョンでは、この後に続く拡張データはまだ定義されておらず、マルチパート部の拡張データのところで前述したようになるだろう。ENVELOPEメッセージエンベロープ構造が記述された、括弧で括られたリスト。これは、[RFC-822]ヘッダを各構成部分へと(必要であれば種々のフィールドにデフォルト値を採用して)解析する事で、サーバーによって算出される。message-id。in-reply-to,message-idの各フィールドは文字列である。bccの各フィールドはアドレス構造の括弧で括られたリストである。アドレス構造は、電子メールアドレスが記述された、括弧で括られたリストである。nameフィールドがNILという特殊なアドレス構造の文法で表される。nameフィールドもNILの場合、それはグループの終端の目印である(RFC822文法ではセミコロン)。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.LINES.NOTの各FETCHデータ項目の応答情報として使用される。ヘッダ行の制限に関係なく、空行は常に含まれる事に注意して欲しい。RFC822.SIZE[RFC-822]形式メッセージのオクテット数を表す数値。RFC822.TEXT[RFC-822]ヘッダを除くメッセージ本文のテキストを表す文字列。8ビット文字は、メッセージ中にそのメッセージの文字セットを示す[MIME-1]データが存在する場合にのみ許可される。UIDメッセージのユニーク識別子を表す数値。時代遅れの応答ここまでに挙げた応答に加え、クライアント実装は、付録Bで説明される時代遅れの応答の受入れと実装を行わなければならない(MUST)。タグの代わりに"+"で示される。この応答形式は、サーバーがクライアントからの命令の続きを受け付ける準備が出来た事を示す。この応答の残りはテキスト行である。この応答はAUTHORIZATION命令中にサーバーのデータをクライアントに送信する為に使用され、クライアントの追加データを要求する。命令の引数がリテラルの場合にも使用される。サーバーがリテラルのオクテットを要求するまで、クライアントはリテラルのオクテットを送信する事を許されない。これにより、サーバーが逐次行(line-by-line)の原則に基づいて命令処理とエラー拒否を行う事が可能になる。命令の残り(終端のCRLFを含む)は、このリテラルのオクテットの後に続く。追加の命令引数がある場合、このリテラルの後に、空白とその引数が続く。以下は、あるIMAP4セッションの記録である。長い行は編集上の配慮により区切られている。Form(ABNF)記法を使用している。注記がなければ、全てのアルファベットの大文字・小文字は区別されない。トークン文字列を定義する為の大文字・小文字の使用は、単に編集上の配慮である。実装は大文字・小文字を区別しない様式でこれらの文字列を受入れなければならない(MUST)。obsolete(時代遅れ)と記されている文法は、このプロトコルの以前のバージョン(例えばIMAP2)用に作られた実装で使用される。