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

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 つは, コマンド引数がオクテットカウントで引用符付けされる場合 (データ形式 (Data Formats) の文字列 (String) の下にあるリテラル (literal) の説明を参照) である. もう 1 つは, コマンド引数にサーバーのフィードバックが必要な場合 (AUTHENTICATE コマンドを参照) である. いずれの場合も, サーバーは, オクテット (適切な場合) とコマンドの残りの部分の準備ができているならば, コマンド継続リクエストレスポンスを送信する. このレスポンスにはトークン "+" が接頭辞として付けられる.

RFC 3501 IMAPv4 March 2003

 注記: 代わりに, サーバーがコマンド内のエラーを検出した場合は, コマンドを拒否し, クライアントがコマンドの残りを送信しないようにするために, コマンドに一致するタグを持つ BAD 完了レスポンス (以下で説明) を送信する.

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

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

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

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

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

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

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

RFC 3501 IMAPv4 March 2003

拒否されるべきであり (SHOULD), クライアントには BAD サーバー完了レスポンスが与えられる.

IMAP4rev1 クライアントのプロトコル受信者は, サーバーからレスポンス行を読み取る. 次に, レスポンスの最初のトークン (タグ, "*", または "+" のいずれか) に基づいて, そのレスポンスに対してアクションを実行する.

クライアントは, 常に任意のサーバーレスポンスを受け入れる準備ができていなければならない (MUST). これには, 要求されていないサーバーデータも含まれる. サーバーデータは記録されるべきであり (SHOULD), クライアントはデータを要求するコマンドをサーバーに送信する代わりに, その記録済みコピーを参照できる. 特定のサーバーデータの場合, データは記録されなければならない (MUST).

このトピックについては, サーバーレスポンス (Server Responses) の章で詳しく説明する.

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

メッセージテキストに加えて, 各メッセージにはいくつかの属性が関連付けられている. これらの属性は, 単独で, または他の属性やメッセージテキストと組み合わせて取得できる.

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

IMAP4rev1 のメッセージは, 2 つの番号のいずれかによってアクセスされる: 一意識別子 (unique identifier) またはメッセージシーケンス番号 (message sequence number) である.

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

各メッセージに割り当てられる 32 ビット値. これは, 一意識別子有効性値 (unique identifier validity value, 下記参照) とともに使用すると 64 ビット値を形成し, その値は, メールボックス内の他のメッセージ, または今後作成される同じ名前のメールボックス内のメッセージを永遠に参照してはならない (MUST NOT). 一意識別子はメールボックス内で厳密に昇順で割り当てられる: メッセージがメールボックスに追加されるたびに, 以前に追加されたメッセージより高い UID が割り当てられる. メッセージシーケンス番号とは異なり, 一意識別子は必ずしも連続しているとは限らない.

メッセージの一意識別子は, セッション中に変更されてはならず (MUST NOT), セッション間で変更されるべきではない (SHOULD NOT). セッション間での一意識別子の変更は, 下記で説明する UIDVALIDITY メカニズムを使用して検出可能でなければならない (MUST). 永続的な一意識別子は, クライアントが以前のセッションの状態をサーバーと再同期するために必要である (例えば, 切断またはオフラインアクセスクライアント). これについては [IMAP-DISC] でさらに説明する.

RFC 3501 IMAPv4 March 2003

すべてのメールボックスには, 一意識別子の処理に役立つ 2 つの値が関連付けられている: 次の一意識別子値 (next unique identifier value) と一意識別子有効性値 (unique identifier validity value) である.

次の一意識別子値は, メールボックス内の新しいメッセージに割り当てられると予測される値である. 一意識別子有効性値も変更されない限り (下記参照), 次の一意識別子値は次の 2 つの特性を持たなければならない (MUST). 第一に, 新しいメッセージがメールボックスに追加されない限り, 次の一意識別子値は変更されてはならない (MUST NOT). 第二に, 新しいメッセージがメールボックスに追加されるたびに, 次の一意識別子値は変更されなければならない (MUST). その新しいメッセージが後で破棄 (expunged) された場合でも同様である.

 注記: 次の一意識別子値は, クライアントが前回この値を確認した以降にメッセージがメールボックスに配信されたかどうかを判断する手段を提供することを意図している. 特定のメッセージがこの一意識別子を持つことを保証することを意図したものではない. クライアントは, 次の一意識別子値を取得した時点で, その後に到着するメッセージの UID がその値以上になることだけを想定できる.

一意識別子有効性値は, メールボックス選択時に OK タグなしレスポンス内の UIDVALIDITY レスポンスコードで送信される. 以前のセッションの一意識別子がこのセッションで永続しない場合, 一意識別子有効性値は, 以前のセッションで使用された値より大きくなければならない (MUST).

 注記: 理想的には, 一意識別子は常に永続するべきである (SHOULD). この仕様は, 特定のサーバー環境では永続しないことが避けられない場合があることを認識しているが, この問題を回避するメッセージストア実装技術を強く推奨する (STRONGLY ENCOURAGES). 例えば:

   1) 一意識別子は, メールボックス内で常に厳密に昇順でなければならない (MUST). 物理メッセージストアが非 IMAP エージェントによって並べ替えられた場合, 並べ替えの結果として以前の一意識別子がもはや厳密に昇順でなくなるため, メールボックス内の一意識別子を再生成する必要がある.

   2) メッセージストアに一意識別子を保存するメカニズムがない場合, 各セッションで一意識別子を再生成し, 各セッションで一意の UIDVALIDITY 値を持たなければならない.

RFC 3501 IMAPv4 March 2003

   3) メールボックスが削除され, 後日同じ名前の新しいメールボックスが作成された場合, サーバーはメールボックスの以前のインスタンスの一意識別子を追跡するか, 新しいインスタンスに新しい UIDVALIDITY 値を割り当てなければならない. この場合に使用する適切な UIDVALIDITY 値は, メールボックスの作成日時を 32 ビットで表現したものである. 1 のような定数を使用することも許容されるが, それは, メールボックスが削除 (または名前変更) され, 将来同じ名前の新しいメールボックスが作成された場合でも, 一意識別子が決して再利用されないことが保証される場合に限る.

   4) メールボックス名, UIDVALIDITY, および UID の組み合わせは, そのサーバー上の単一の不変メッセージを永遠に参照しなければならない. 特に, 内部日付 (internal date), [RFC-2822] サイズ, エンベロープ (envelope), ボディ構造 (body structure), およびメッセージテキスト (RFC822, RFC822.HEADER, RFC822.TEXT, およびすべての BODY[...] フェッチデータ項目) は決して変更されてはならない. これにはメッセージ番号は含まれず, STORE コマンドで設定できる属性 (例えば FLAGS) も含まれない.

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

1 からメールボックス内のメッセージ数までの相対位置. この位置は, 一意識別子の昇順で並べられなければならない (MUST). 新しいメッセージが追加されるたびに, そのメッセージには, 新しいメッセージが追加される前のメールボックス内のメッセージ数より 1 大きいメッセージシーケンス番号が割り当てられる.

メッセージシーケンス番号はセッション中に再割り当てされることがある. 例えば, メッセージがメールボックスから完全に削除 (expunged) されると, 後続のすべてのメッセージのメッセージシーケンス番号が 1 減らされる. メールボックス内のメッセージ数も 1 減らされる. 同様に, 新しいメッセージには, 破棄 (expunge) の前に他のメッセージが保持していたメッセージシーケンス番号が割り当てられることがある.

メールボックス内の相対位置によるメッセージへのアクセスに加えて, メッセージシーケンス番号は数学的な計算に使用できる. 例えば, タグなし "11 EXISTS" を受信し, 以前にタグなし "8 EXISTS" を受信していた場合, メッセージシーケンス番号 9, 10, 11 を持つ 3 つの新しいメッセージが到着したことになる. 別の例として, 523 メッセージのメールボックス内のメッセージ 287 が UID 12345 を持つ場合, より小さい UID を持つメッセージがちょうど 286 個, より大きい UID を持つメッセージがちょうど 236 個存在する.

RFC 3501 IMAPv4 March 2003

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

メッセージに関連付けられた, ゼロ個以上の名前付きトークンのリスト. フラグはこのリストへの追加によって設定され, 削除によってクリアされる. IMAP4rev1 には 2 種類のフラグがある. どちらのタイプのフラグも, 永続的 (permanent) またはセッション限定 (session-only) のいずれかにできる.

システムフラグ (system flag) は, この仕様で事前定義されたフラグ名である. すべてのシステムフラグは "" で始まる. 特定のシステムフラグ (\Deleted と \Seen) には, 他の場所で説明されている特別なセマンティクスがある. 現在定義されているシステムフラグは次のとおりである:

 \Seen
    メッセージが読まれた

 \Answered
    メッセージに返信された

 \Flagged
    メッセージが緊急/特別な注意のために「フラグ付き」である

 \Deleted
    メッセージが後で EXPUNGE によって削除されるために「削除済み」である

 \Draft
    メッセージの作成が完了していない (下書きとしてマークされている).

 \Recent
    メッセージがこのメールボックスに「最近」到着した. このセッションは, このメッセージについて通知を受けた最初のセッションである. セッションが読み書き (read-write) の場合, 後続のセッションではこのメッセージに \Recent が設定されていないことが見える. このフラグはクライアントが変更できない.

    このセッションがメッセージについて通知を受けた最初のセッションであるかどうかを判断できない場合, そのメッセージは最近のもの (recent) と見なされるべきである (SHOULD).

    複数の接続が同時に同じメールボックスを選択している場合, これらの接続のうちどれが \Recent が設定された新着メッセージを表示し, どれが \Recent なしで表示するかは未定義である.

キーワード (keyword) はサーバー実装によって定義される. キーワードは "" で始まらない. サーバーは, クライアントがメールボックス内に新しいキーワードを定義することを許可してもよい (MAY) (詳細については, PERMANENTFLAGS レスポンスコードの説明を参照).

RFC 3501 IMAPv4 March 2003

フラグは, フラグごとに永続的またはセッション限定のいずれかにできる. 永続的フラグ (permanent flags) は, クライアントがメッセージフラグに永続的に追加または削除できるフラグである. つまり, 同時セッションと後続セッションの両方で, 永続的フラグの変更が表示される. セッションフラグの変更はそのセッション内でのみ有効である.

 注記: \Recent システムフラグは, セッションフラグの特別な場合である. \Recent は STORE または APPEND コマンドの引数として使用できないため, まったく変更できない.

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

サーバー上のメッセージの内部日時. これは [RFC-2822] ヘッダー内の日時ではなく, メッセージが受信された時刻を反映した日時である. [SMTP] 経由で配信されたメッセージの場合, これは [SMTP] で定義されているメッセージの最終配信日時であるべきである (SHOULD). IMAP4rev1 COPY コマンドによって配信されたメッセージの場合, これは送信元メッセージの内部日時であるべきである (SHOULD). IMAP4rev1 APPEND コマンドによって配信されたメッセージの場合, これは APPEND コマンドの説明で指定された日時であるべきである (SHOULD). その他すべての場合は実装定義である.

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

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

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

メッセージの [RFC-2822] ヘッダーの解析済み表現. IMAP エンベロープ構造は [SMTP] エンベロープと同じではないことに注意すること.

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

メッセージの [MIME-IMB] ボディ構造情報の解析済み表現.

RFC 3501 IMAPv4 March 2003

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

完全な [RFC-2822] メッセージテキストをフェッチできることに加えて, IMAP4rev1 は完全なメッセージテキストの一部をフェッチすることも許可する. 具体的には, [RFC-2822] メッセージヘッダー, [RFC-2822] メッセージボディ, [MIME-IMB] ボディパート, または [MIME-IMB] ヘッダーをフェッチできる.