メインコンテンツまでスキップ

2. プロトコル概要 (Protocol Overview)

IMAP4rev1プロトコルは、TCPが提供するような信頼性のあるデータストリームを前提としています。TCPが使用される場合、IMAP4rev1サーバーはポート143でリッスンします。

2.2. コマンドとレスポンス (Commands and Responses)​

IMAP4rev1接続は、クライアント/サーバーのネットワーク接続の確立、サーバーからの初期挨拶 (greeting)、およびクライアント/サーバーの相互作用で構成されます。これらのクライアント/サーバーの相互作用は、クライアントコマンド、サーバーデータ、およびサーバー完了結果レスポンスで構成されます。

クライアントとサーバーによって送信されるすべての相互作用は、行の形式、つまりCRLFで終わる文字列です。IMAP4rev1クライアントまたはサーバーのプロトコル受信者は、行を読み取っているか、既知のカウントに続く行を持つオクテットのシーケンスを読み取っています。

2.2.1. クライアントプロトコル送信者とサーバープロトコル受信者 (Client Protocol Sender and Server Protocol Receiver)​

クライアントコマンドは操作を開始します。各クライアントコマンドには、「タグ (tag)」と呼ばれる識別子（通常は短い英数字の文字列、例えばA0001、A0002など）が接頭辞として付けられます。各コマンドに対してクライアントによって異なるタグが生成されます。

クライアントは、この仕様で概説されている構文に厳密に従わなければなりません (MUST)。スペースや引数が欠落しているか余分なコマンドを送信することは構文エラーです。

クライアントからの行が完全なコマンドを表さない2つのケースがあります。1つのケースでは、コマンド引数がオクテットカウントで引用されます（データフォーマットの文字列の下のリテラルの説明を参照）。もう1つのケースでは、コマンド引数にサーバーフィードバックが必要です（AUTHENTICATEコマンドを参照）。いずれの場合も、サーバーは、オクテット（適切な場合）とコマンドの残りの部分の準備ができている場合、コマンド継続リクエストレスポンスを送信します。このレスポンスには、トークン「+」が接頭辞として付けられます。

注意: 代わりに、サーバーがコマンドでエラーを検出した場合、コマンドを拒否し、クライアントがコマンドのそれ以上を送信しないようにするために、コマンドに一致するタグを持つBAD完了レスポンス（以下で説明）を送信します。

また、サーバーが他のコマンド（複数のコマンドが進行中の場合）の完了レスポンス、またはタグなしデータを送信することも可能です。いずれの場合も、コマンド継続リクエストはまだ保留中です。クライアントはレスポンスに対して適切なアクションを実行し、サーバーから別のレスポンスを読み取ります。すべての場合において、クライアントは新しいコマンドを開始する前に、完全なコマンド（コマンドのすべてのコマンド継続リクエストレスポンスとコマンド継続の受信を含む）を送信しなければなりません (MUST)。

IMAP4rev1サーバーのプロトコル受信者は、クライアントからコマンド行を読み取り、コマンドとその引数を解析し、サーバーデータとサーバーコマンド完了結果レスポンスを送信します。

2.2.2. サーバープロトコル送信者とクライアントプロトコル受信者 (Server Protocol Sender and Client Protocol Receiver)​

サーバーからクライアントに送信されるデータと、コマンドの完了を示さないステータスレスポンスには、トークン「*」が接頭辞として付けられ、タグなしレスポンス (untagged responses) と呼ばれます。

サーバーデータは、クライアントコマンドの結果として送信される場合 (MAY) もあれば、サーバーによって一方的に送信される場合 (MAY) もあります。特定のコマンドから生じたサーバーデータと、一方的に送信されたサーバーデータの間に構文上の違いはありません。

サーバー完了結果レスポンスは、操作の成功または失敗を示します。これには、操作を開始したクライアントコマンドと同じタグがタグ付けされます。したがって、複数のコマンドが進行中の場合、サーバー完了レスポンスのタグは、レスポンスが適用されるコマンドを識別します。3つの可能なサーバー完了レスポンスがあります: OK（成功を示す）、NO（失敗を示す）、またはBAD（認識されないコマンドやコマンド構文エラーなどのプロトコルエラーを示す）。

サーバーは、この仕様で概説されている構文を厳密に実施すべきです (SHOULD)。スペースや引数の欠落または余分なものを含む（ただしこれに限定されない）プロトコル構文エラーのあるクライアントコマンドは、BAD完了レスポンスで拒否されるべきです (SHOULD)。

2.3. メッセージ属性 (Message Attributes)​

メッセージ属性 (Message Attributes) に加えて、IMAPは複数のサーバー定義のデータアイテムをサポートします。これらのサーバーデータアイテムは、サーバー実装によって異なる場合があり、拡張可能です。

2.3.1. メッセージ番号 (Message Numbers)​

メッセージは、メッセージシーケンス番号 (Message Sequence Number) または一意識別子 (Unique Identifier, UID) のいずれかによって識別されます。

2.3.1.1. 一意識別子 (UID) メッセージ属性 (Unique Identifier (UID) Message Attribute)​

一意識別子 (Unique Identifier, UID) は、メールボックス内のメッセージに関連付けられた32ビット値です。この一意識別子は、メールボックス内で時間の経過とともに一意でなければなりません (MUST)。UIDは、メッセージが削除されても変更されることはありません。

UIDは、厳密に昇順でなければなりません (MUST)。

メッセージがメールボックスに追加されるたびに、以前に使用されたUIDよりも大きいUIDが割り当てられます。たとえ以前のUIDがもはや使用されていなくても（つまり、メッセージが削除された場合）です。

UIDの一意性の要件により、サーバーは、以前に使用された各UIDの記録を維持し、それを再利用しないようにする必要があります。UIDの一意性を保証する最も簡単な方法は、単純に単調にUIDを割り当てることです。つまり、新しいメッセージが到着するたびに、その前のメッセージのUIDよりも1大きいUIDを割り当てることです。

2.3.1.2. メッセージシーケンス番号メッセージ属性 (Message Sequence Number Message Attribute)​

メッセージシーケンス番号 (Message Sequence Number) は、メールボックス内のメッセージの相対位置です。メッセージシーケンス番号は、1から始まり、メールボックス内のメッセージの総数まで連続する整数です。

メッセージシーケンス番号は、メールボックスの内容が変更されると変更される可能性があります。特に、メッセージが削除または追加されると、影響を受けるメッセージシーケンス番号以降のすべてのメッセージシーケンス番号が変更されます。

メッセージシーケンス番号は、セッション中にのみ有効です。セッションが終了すると、メッセージシーケンス番号は意味を持たなくなります。

2.3.2. フラグメッセージ属性 (Flags Message Attribute)​

フラグは、メッセージに関連付けられたキーワードまたはトークンです。フラグには2つのタイプがあります: システムフラグとキーワードです。

システムフラグは、バックスラッシュ（「\」）文字で始まる特別な意味を持つフラグです。システムフラグは次のとおりです:

  • \Seen - メッセージが読まれました
  • \Answered - メッセージが返信されました
  • \Flagged - メッセージにマークが付けられています
  • \Deleted - メッセージが削除のためにマークされています
  • \Draft - メッセージが下書きです
  • \Recent - メッセージが最近到着しました（このセッション）

キーワードは、サーバーまたはクライアントによって定義されるフラグです。キーワードは、バックスラッシュで始まってはいけません (MUST NOT)。

2.3.3. 内部日付メッセージ属性 (Internal Date Message Attribute)​

内部日付 (Internal Date) は、メッセージがメールボックスに到着した日時です。これは、メッセージのDate:ヘッダーフィールドとは異なる場合があります。

2.3.4. [RFC-2822] サイズメッセージ属性 ([RFC-2822] Size Message Attribute)​

[RFC-2822]サイズは、メッセージのサイズ（オクテット単位）です。

2.3.5. エンベロープ構造メッセージ属性 (Envelope Structure Message Attribute)​

エンベロープ構造 (Envelope Structure) は、メッセージヘッダーから導出された情報です。

2.3.6. ボディ構造メッセージ属性 (Body Structure Message Attribute)​

ボディ構造 (Body Structure) は、メッセージのMIME構造に関する情報です。

2.4. メッセージテキスト (Message Texts)​

メッセージテキストには、メッセージの完全なヘッダーとボディが含まれます。メッセージテキストは、[RFC-2822]形式でなければなりません (MUST)。

に最終更新