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

8. Sample IMAP4rev1 Connection

TEXT タイプのボディタイプは, 基本フィールドの直後に, ボディのサイズをテキスト行数で含む. このサイズは, コンテンツ転送エンコーディングにおけるサイズであり, いかなるデコード後の結果サイズではないことに注意.

拡張データは, 基本フィールドと上記のタイプ固有フィールドに続く. 拡張データは, BODY フェッチでは決して返されないが, BODYSTRUCTURE フェッチでは返され得る. 拡張データが存在する場合, 定義された順序でなければならない (MUST).

非マルチパートボディパートの拡張データは次の順序である:

body MD5 [MD5] で定義されるボディ MD5 値を与える文字列.

RFC 3501 IMAPv4 March 2003

body disposition マルチパートボディパートのボディ配置と同じ内容および機能を持つ括弧付きリスト.

body language [LANGUAGE-TAGS] で定義されるボディ言語値を与える文字列または括弧付きリスト.

body location [LOCATION] で定義されるボディコンテンツ URI を与える文字列リスト.

これに続く拡張データは, このプロトコルのこのバージョンではまだ定義されておらず, マルチパート拡張データの項で上述したとおりである.

ENVELOPE メッセージのエンベロープ構造を記述する括弧付きリスト. これは, サーバーが [RFC-2822] ヘッダーを構成部分に解析し, 必要に応じてさまざまなフィールドをデフォルト設定することによって計算される.

  エンベロープ構造のフィールドは次の順序である: 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, host name.

  [RFC-2822] グループ構文は, host name フィールドが NIL である特別な形式のアドレス構造によって示される. mailbox name フィールドも NIL である場合, これはグループの終わりを示すマーカーである (RFC 822 構文のセミコロン). mailbox name フィールドが非 NIL である場合, これはグループの始まりを示すマーカーであり, mailbox name フィールドはグループ名フレーズを保持する.

  [RFC-2822] ヘッダーに Date, Subject, In-Reply-To, Message-ID の各ヘッダー行が存在しない場合, エンベロープの対応するメンバーは NIL である. これらのヘッダー行が存在するが空である場合, エンベロープの対応するメンバーは空文字列である.

RFC 3501 IMAPv4 March 2003

     注記: 「存在するが空」の場合に NIL のエンベロープメンバーを返すサーバーもある. クライアントは NIL と空文字列を同一として扱うべきである (SHOULD).

     注記: [RFC-2822] は, すべてのメッセージが有効な Date ヘッダーを持つことを要求する. したがって, エンベロープ内の date メンバーは NIL または空文字列にはなり得ない.

     注記: [RFC-2822] は, In-Reply-To および Message-ID ヘッダーが存在する場合, 空でない内容を持つことを要求する. したがって, エンベロープ内の in-reply-to および message-id メンバーは空文字列にはなり得ない.

  [RFC-2822] ヘッダーに From, To, cc, bcc の各ヘッダー行が存在しない場合, または存在するが空である場合, エンベロープの対応するメンバーは NIL である.

  [RFC-2822] ヘッダーに Sender または Reply-To 行が存在しない場合, または存在するが空である場合, サーバーはエンベロープの対応するメンバーを from メンバーと同じ値に設定する (クライアントはこれを行うことを期待されていない).

     注記: [RFC-2822] は, すべてのメッセージが有効な From ヘッダーを持つことを要求する. したがって, エンベロープ内の from, sender, reply-to の各メンバーは NIL にはなり得ない.

FLAGS このメッセージに設定されているフラグの括弧付きリスト.

INTERNALDATE メッセージの内部日付を表す文字列.

RFC822 BODY[] と同等.

RFC822.HEADER BODY[HEADER] と同等. これは \Seen が設定されなかったことに注意. なぜなら RFC822.HEADER レスポンスデータは RFC822.HEADER の FETCH の結果として発生するからである. BODY[HEADER] レスポンスデータは, BODY[HEADER] の FETCH ( \Seen を設定する) または BODY.PEEK[HEADER] ( \Seen を設定しない) の結果として発生する.

RFC822.SIZE メッセージの [RFC-2822] サイズを表す数値.

RFC 3501 IMAPv4 March 2003

RFC822.TEXT BODY[TEXT] と同等.

UID メッセージの一意識別子を表す数値.

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

7.5. サーバーレスポンス - コマンド継続リクエスト (Server Responses - Command Continuation Request)​

コマンド継続リクエストレスポンスは, タグの代わりに "+" トークンによって示される. この形式のレスポンスは, サーバーがクライアントからのコマンドの継続を受け入れる準備ができていることを示す. このレスポンスの残りの部分は 1 行のテキストである.

このレスポンスは, AUTHENTICATE コマンドにおいてサーバーデータをクライアントに送信し, 追加のクライアントデータを要求するために使用される. また, いずれかのコマンドの引数がリテラルである場合にも使用される.

クライアントは, サーバーが期待されることを示さない限り, リテラルのオクテットを送信してはならない (MUST NOT). これにより, サーバーはコマンドを処理し, 行ごとにエラーを拒否できる. コマンドを終端する 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"