6. クライアントコマンド (Client Commands)
RFC 3501 IMAPv4 March 2003
例えば, 以下の非待機コマンドシーケンスは無効である:
FETCH + NOOP + STORE
STORE + COPY + FETCH
COPY + COPY
CHECK + FETCH
以下は有効な非待機コマンドシーケンスの例である:
FETCH + STORE + SEARCH + CHECK
STORE + COPY + EXPUNGE
UID SEARCH + UID SEARCH は, 2 番目の UID SEARCH がメッセージシーケンス番号を含むかどうかに応じて, 非待機コマンドシーケンスとして有効な場合も無効な場合もある.
6. クライアントコマンド (Client Commands)
IMAP4rev1 コマンドはこのセクションで説明される. コマンドは, コマンドが許可される状態によって整理される. 複数の状態で許可されるコマンドは, 最小の許可状態にリストされる (例えば, 認証済み状態と選択済み状態で有効なコマンドは, 認証済み状態のコマンドにリストされる).
以下のコマンド説明で「引数 (Arguments:)」によって識別されるコマンド引数は, 構文ではなく機能によって説明される. コマンド引数の正確な構文は, 正式構文 (Formal Syntax) セクションで説明される.
一部のコマンドは特定のサーバーレスポンスを返させる. これらは, 以下のコマンド説明で「レスポンス (Responses:)」によって識別される. これらのレスポンスの情報については, レスポンス (Responses) セクションのレスポンスの説明を, これらのレスポンスの正確な構文については正式構文 (Formal Syntax) セクションを参照のこと. サーバーデータは任意のコマンドの結果として送信される可能性がある. したがって, サーバーデータを特に要求しないコマンドは, 「このコマンドに対する特定のレスポンスはない (no specific responses for this command)」と「なし (none)」の代わりに指定する.
コマンド説明の「結果 (Result:)」は, コマンドに対する可能なタグ付きステータスレスポンスと, これらのステータスレスポンスの特別な解釈を指す.
接続の状態は, 状態を変更すると文書化されている成功したコマンドによってのみ変更される. 拒否されたコマンド (BAD レスポンス) は, 接続または選択されたメールボックスの状態を決して変更しない. 失敗したコマンド (NO レスポンス) は, 一般的に接続または選択されたメールボックスの状態を変更しない. 例外は SELECT と EXAMINE コマンドである.
RFC 3501 IMAPv4 March 2003
6.1. クライアントコマンド - 任意の状態 (Client Commands - Any State)
以下のコマンドは任意の状態で有効である: CAPABILITY, NOOP, LOGOUT.
6.1.1. CAPABILITY コマンド
引数 (Arguments): なし
レスポンス (Responses): 必須タグなしレスポンス: CAPABILITY
結果 (Result): OK - 機能確認完了 (capability completed) BAD - コマンド不明または引数が無効
CAPABILITY コマンドは, サーバーがサポートする機能のリストを要求する. サーバーは, (タグ付き) OK レスポンスの前に, リストされた機能の 1 つとして "IMAP4rev1" を含む単一のタグなし CAPABILITY レスポンスを送信しなければならない (MUST).
"AUTH=" で始まる機能名は, サーバーがその特定の認証メカニズムをサポートすることを示す. そのような名前はすべて, 定義上, この仕様の一部である. 例えば, 実験的な "blurdybloop" オーセンティケータの認可機能は, "XAUTH=BLURDYBLOOP" や "XAUTH=XBLURDYBLOOP" ではなく "AUTH=XBLURDYBLOOP" になる.
他の機能名は, この仕様への拡張, 改訂, または修正を参照する. 追加情報については, CAPABILITY レスポンスの文書を参照のこと. この仕様で定義された基本の IMAP4rev1 セットを超える機能は, クライアントがその機能を呼び出す明示的なアクションなしには有効にならない.
クライアントとサーバーの実装は, STARTTLS, LOGINDISABLED, AUTH=PLAIN ([IMAP-TLS] で説明) の機能を実装しなければならない (MUST). 重要な情報については, セキュリティ考慮事項 (Security Considerations) セクションを参照のこと.
サイトまたは実装固有の機能の形式については, 「クライアントコマンド - 実験的/拡張 (Client Commands - Experimental/Expansion)」というタイトルのセクションを参照のこと.
RFC 3501 IMAPv4 March 2003
例: C: abcd CAPABILITY
S: * CAPABILITY IMAP4rev1 STARTTLS AUTH=GSSAPI
LOGINDISABLED
S: abcd OK CAPABILITY completed
C: efgh STARTTLS
S: efgh OK STARTLS completed
<TLS negotiation, further commands are under [TLS] layer>
C: ijkl CAPABILITY
S: * CAPABILITY IMAP4rev1 AUTH=GSSAPI AUTH=PLAIN
S: ijkl OK CAPABILITY completed
6.1.2. NOOP コマンド
引数 (Arguments): なし
レスポンス (Responses): このコマンドに対する特定のレスポンスはない (ただし下記参照)
結果 (Result): OK - noop 完了 BAD - コマンド不明または引数が無効
NOOP コマンドは常に成功する. それは何もしない.
任意のコマンドがステータス更新をタグなしデータとして返すことができるため, 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
RFC 3501 IMAPv4 March 2003
6.1.3. LOGOUT コマンド
引数 (Arguments): なし
レスポンス (Responses): 必須タグなしレスポンス: BYE
結果 (Result): OK - ログアウト完了 (logout completed) BAD - コマンド不明または引数が無効
LOGOUT コマンドは, クライアントが接続を終了したことをサーバーに通知する. サーバーは, (タグ付き) OK レスポンスの前に BYE タグなしレスポンスを送信し, その後ネットワーク接続を閉じなければならない (MUST).
例: C: A023 LOGOUT S: * BYE IMAP4rev1 Server logging out S: A023 OK LOGOUT completed (サーバーとクライアントはその後接続を閉じる)
6.2. クライアントコマンド - 未認証状態 (Client Commands - Not Authenticated State)
未認証状態では, AUTHENTICATE または LOGIN コマンドが認証を確立し, 認証済み状態に入る. AUTHENTICATE コマンドは, さまざまな認証技術, プライバシー保護, 整合性チェックのための一般的なメカニズムを提供する. 一方, LOGIN コマンドは従来のユーザー名と平文パスワードのペアを使用し, プライバシー保護や整合性チェックを確立する手段がない.
STARTTLS コマンドは, セッションのプライバシー保護と整合性チェックを確立する代替形式であるが, 認証を確立したり, 認証済み状態に入ったりはしない.
サーバー実装は, 認証を確立せずに特定のメールボックスへのアクセスを許可してもよい (MAY). これは, [ANONYMOUS] で説明されている ANONYMOUS [SASL] オーセンティケータによって行うことができる. 古い慣例は, ユーザー ID "anonymous" を使用する LOGIN コマンドである. この場合, サーバーが任意のパスワードを受け入れることを選択してもよいが, パスワードが必要である. 匿名ユーザーに課される制限は実装依存である.
一度認証されると (匿名としても), 未認証状態に再入することはできない.
RFC 3501 IMAPv4 March 2003
汎用コマンド (CAPABILITY, NOOP, LOGOUT) に加えて, 以下のコマンドが未認証状態で有効である: STARTTLS, AUTHENTICATE, LOGIN. これらのコマンドに関する重要な情報については, セキュリティ考慮事項 (Security Considerations) セクションを参照のこと.
6.2.1. STARTTLS コマンド
引数 (Arguments): なし
レスポンス (Responses): このコマンドに対する特定のレスポンスはない
結果 (Result): OK - starttls 完了, TLS ネゴシエーションを開始 BAD - コマンド不明または引数が無効
[TLS] ネゴシエーションは, サーバーからのタグ付き OK レスポンスの末尾の CRLF の直後に開始される. クライアントが STARTTLS コマンドを発行すると, サーバーレスポンスが確認され, [TLS] ネゴシエーションが完了するまで, それ以上のコマンドを発行してはならない (MUST NOT).
サーバーは, [TLS] ネゴシエーション中にクライアント資格情報が提供された場合でも, 非認証状態のままである. これは, [SASL] で定義されている EXTERNAL などの認証メカニズムが, [TLS] ネゴシエーションによって決定されたクライアント ID を使用することを妨げない.
[TLS] が開始されたら, クライアントはサーバー機能に関するキャッシュされた情報を破棄しなければならず (MUST), CAPABILITY コマンドを再発行すべきである (SHOULD). これは, STARTTLS の前に機能リストを変更する中間者攻撃から保護するために必要である. サーバーは STARTTLS の後に異なる機能を宣伝してもよい (MAY).
例: C: a001 CAPABILITY
S: * CAPABILITY IMAP4rev1 STARTTLS LOGINDISABLED
S: a001 OK CAPABILITY completed
C: a002 STARTTLS
S: a002 OK Begin TLS negotiation now
<TLS negotiation, further commands are under [TLS] layer>
C: a003 CAPABILITY
S: * CAPABILITY IMAP4rev1 AUTH=PLAIN
S: a003 OK CAPABILITY completed
C: a004 LOGIN joe password
S: a004 OK LOGIN completed
RFC 3501 IMAPv4 March 2003
6.2.2. AUTHENTICATE コマンド
引数 (Arguments): 認証メカニズム名
レスポンス (Responses): 継続データを要求できる
結果 (Result): OK - 認証完了, 現在認証済み状態 NO - 認証失敗: サポートされていない認証メカニズム, 資格情報が拒否された BAD - コマンド不明または引数が無効, 認証交換がキャンセルされた
AUTHENTICATE コマンドは, サーバーに [SASL] 認証メカニズムを示す. サーバーが要求された認証メカニズムをサポートする場合, クライアントを認証して識別するための認証プロトコル交換を実行する. また, 後続のプロトコル対話のためにオプションのセキュリティレイヤをネゴシエーションしてもよい (MAY). 要求された認証メカニズムがサポートされていない場合, サーバーはタグ付き NO レスポンスを送信して AUTHENTICATE コマンドを拒否すべきである (SHOULD).
AUTHENTICATE コマンドは, [SASL] のオプションの「初期レスポンス (initial response)」機能をサポートしない. 初期レスポンスを使用する認証メカニズムの処理方法は, [SASL] のセクション 5.1 で指定されている.
このプロトコルの [SASL] プロファイルによって指定されるサービス名は "imap" である.
認証プロトコル交換は, 認証メカニズムに固有の一連のサーバーチャレンジとクライアントレスポンスで構成される. サーバーチャレンジは, "+" トークンの後に BASE64 エンコードされた文字列が続くコマンド継続リクエストレスポンスで構成される. クライアントレスポンスは, BASE64 エンコードされた文字列で構成される単一の行で構成される. クライアントが認証交換をキャンセルしたい場合, 単一の "*" で構成される行を発行する. サーバーがそのようなレスポンスを受信した場合, タグ付き BAD レスポンスを送信して AUTHENTICATE コマンドを拒否しなければならない (MUST).
セキュリティレイヤが [SASL] 認証交換を通じてネゴシエーションされた場合, それはクライアントの認証交換を締めくくる CRLF の直後, およびサーバーのタグ付き OK レスポンスの CRLF で有効になる.
クライアントとサーバーの実装は AUTHENTICATE コマンド自体を実装しなければならない (MUST) が, [IMAP-TLS] で説明されている PLAIN メカニズム以外の認証メカニズムを実装する必要はない. また, 認証メカニズムがセキュリティレイヤをサポートする必要はない.
RFC 3501 IMAPv4 March 2003
注記: サーバー実装は, STARTTLS コマンドがネゴシエーションされたか, パスワードの盗聴からセッションを保護する他のメカニズムが提供されない限り, 平文パスワードメカニズムを許可しない構成を実装しなければならない (MUST). サーバーサイトは, パスワードの盗聴に対するそのような保護メカニズムなしに平文パスワードメカニズムを許可する構成を使用すべきではない (SHOULD NOT). クライアントとサーバーの実装は, [SASL] で説明されている GSSAPI メカニズムや [DIGEST-MD5] メカニズムなど, 平文パスワードを使用しない追加の [SASL] メカニズムを実装すべきである (SHOULD).
サーバーとクライアントは複数の認証メカニズムをサポートできる. サーバーは, クライアントがどの認証メカニズムを使用するかを知ることができるように, サポートする認証メカニズムを CAPABILITY コマンドへのレスポンスにリストすべきである (SHOULD).
サーバーは, 機能を自動的に送信するために, 成功した AUTHENTICATE コマンドのタグ付き OK レスポンスに CAPABILITY レスポンスコードを含めてもよい (MAY). クライアントがこれらの自動機能を認識する場合, 個別の CAPABILITY コマンドを送信する必要はない. これは, AUTHENTICATE コマンドの一部としてのタグ付き OK レスポンスが暗号化/整合性チェックによって保護されていないため, AUTHENTICATE コマンドによってセキュリティレイヤがネゴシエーションされなかった場合にのみ行うべきである. [SASL] はこの場合, クライアントに CAPABILITY コマンドを再発行することを要求する.
AUTHENTICATE コマンドが NO レスポンスで失敗した場合, クライアントは別の AUTHENTICATE コマンドを発行して別の認証メカニズムを試してもよい (MAY). また, LOGIN コマンドを使用して認証を試みてもよい (MAY) (詳細はセクション 6.2.3 を参照). 言い換えると, クライアントは, LOGIN コマンドを最後の手段として, 優先度の降順で認証タイプを要求してもよい (MAY).
認証交換中にクライアントからサーバーに渡される認可 ID は, クライアントが特権を要求しているユーザー名としてサーバーによって解釈される.
RFC 3501 IMAPv4 March 2003
例: S: * OK IMAP4rev1 Server C: A001 AUTHENTICATE GSSAPI S: + C: YIIB+wYJKoZIhvcSAQICAQBuggHqMIIB5qADAgEFoQMCAQ6iBw MFACAAAACjggEmYYIBIjCCAR6gAwIBBaESGxB1Lndhc2hpbmd0 b24uZWR1oi0wK6ADAgEDoSQwIhsEaW1hcBsac2hpdmFtcy5jYW Mud2FzaGluZ3Rvbi5lZHWjgdMwgdCgAwIBAaEDAgEDooHDBIHA cS1GSa5b+fXnPZNmXB9SjL8Ollj2SKyb+3S0iXMljen/jNkpJX AleKTz6BQPzj8duz8EtoOuNfKgweViyn/9B9bccy1uuAE2HI0y C/PHXNNU9ZrBziJ8Lm0tTNc98kUpjXnHZhsMcz5Mx2GR6dGknb I0iaGcRerMUsWOuBmKKKRmVMMdR9T3EZdpqsBd7jZCNMWotjhi vd5zovQlFqQ2Wjc2+y46vKP/iXxWIuQJuDiisyXF0Y8+5GTpAL pHDc1/pIGmMIGjoAMCAQGigZsEgZg2on5mSuxoDHEA1w9bcW9n FdFxDKpdrQhVGVRDIzcCMCTzvUboqb5KjY1NJKJsfjRQiBYBdE NKfzK+g5DlV8nrw81uOcP8NOQCLR5XkoMHC0Dr/80ziQzbNqhx O6652Npft0LQwJvenwDI13YxpwOdMXzkWZN/XrEqOWp6GCgXTB vCyLWLlWnbaUkZdEYbKHBPjd8t/1x5Yg== S: + YGgGCSqGSIb3EgECAgIAb1kwV6ADAgEFoQMCAQ+iSzBJoAMC AQGiQgRAtHTEuOP2BXb9sBYFR4SJlDZxmg39IxmRBOhXRKdDA0 uHTCOT9Bq3OsUTXUlk0CsFLoa8j+gvGDlgHuqzWHPSQg== C: S: + YDMGCSqGSIb3EgECAgIBAAD/////6jcyG4GE3KkTzBeBiVHe ceP2CWY0SR0fAQAgAAQEBAQ= C: YDMGCSqGSIb3EgECAgIBAAD/////3LQBHXTpFfZgrejpLlLImP wkhbfa2QteAQAgAG1yYwE= S: A001 OK GSSAPI authentication successful
注記: サーバーチャレンジとクライアントレスポンス内の改行は, 編集上の明瞭さのためであり, 実際のオーセンティケータにはない.
6.2.3. LOGIN コマンド
引数 (Arguments): ユーザー名 パスワード
レスポンス (Responses): このコマンドに対する特定のレスポンスはない
結果 (Result): OK - ログイン完了, 現在認証済み状態 NO - ログイン失敗: ユーザー名またはパスワードが拒否された BAD - コマンド不明または引数が無効
LOGIN コマンドは, クライアントをサーバーに識別させ, このユーザーを認証する平文パスワードを運ぶ.
RFC 3501 IMAPv4 March 2003
サーバーは, 機能を自動的に送信するために, 成功した LOGIN コマンドへのタグ付き OK レスポンスに CAPABILITY レスポンスコードを含めてもよい (MAY). クライアントがこれらの自動機能を認識する場合, 個別の CAPABILITY コマンドを送信する必要はない.
例: C: a001 LOGIN SMITH SESAME S: a001 OK LOGIN completed
注記: 安全でないネットワーク (インターネットなど) 上の LOGIN コマンドの使用は, ネットワークトラフィックを監視する誰もが平文パスワードを取得できるため, セキュリティリスクである. LOGIN コマンドは最後の手段としてのみ使用すべきであり (SHOULD NOT 以外の使用は避けるべき), クライアント実装が LOGIN コマンドの自動使用を無効にする手段を持つことが推奨される.
STARTTLS コマンドがネゴシエーションされたか, パスワードの盗聴からセッションを保護する他のメカニズムが提供されない限り, サーバー実装は LOGINDISABLED 機能を宣伝し, LOGIN コマンドを許可しない構成を実装しなければならない (MUST). サーバーサイトは, パスワードの盗聴に対するそのような保護メカニズムなしに LOGIN コマンドを許可する構成を使用すべきではない (SHOULD NOT). クライアント実装は, LOGINDISABLED 機能が宣伝されている場合, LOGIN コマンドを送信してはならない (MUST NOT).
6.3. クライアントコマンド - 認証済み状態 (Client Commands - Authenticated State)
認証済み状態では, メールボックスを原子的なエンティティとして操作するコマンドが許可される. これらのコマンドのうち, SELECT と EXAMINE コマンドはアクセスするメールボックスを選択し, 選択済み状態に入る.
汎用コマンド (CAPABILITY, NOOP, LOGOUT) に加えて, 以下のコマンドが認証済み状態で有効である: SELECT, EXAMINE, CREATE, DELETE, RENAME, SUBSCRIBE, UNSUBSCRIBE, LIST, LSUB, STATUS, APPEND.
RFC 3501 IMAPv4 March 2003
6.3.1. SELECT コマンド
引数 (Arguments): メールボックス名
レスポンス (Responses): 必須タグなしレスポンス: FLAGS, EXISTS, RECENT 必須 OK タグなしレスポンス: UNSEEN, PERMANENTFLAGS, UIDNEXT, UIDVALIDITY
結果 (Result): OK - 選択完了, 現在選択済み状態 NO - 選択失敗, 現在認証済み状態: そのようなメールボックスがない, メールボックスにアクセスできない BAD - コマンド不明または引数が無効
SELECT コマンドは, メールボックス内のメッセージにアクセスできるようにメールボックスを選択する. クライアントに OK を返す前に, サーバーは以下のタグなしデータをクライアントに送信しなければならない (MUST). このプロトコルの以前のバージョンでは FLAGS, EXISTS, RECENT のタグなしデータのみが必要だったことに注意すること. したがって, クライアント実装は, 個々の項目で説明されているように, 欠落データのデフォルト動作を実装すべきである (SHOULD).
FLAGS メールボックス内の定義済みフラグ. 詳細については, FLAGS レスポンスの説明を参照のこと.
`<n>` EXISTS メールボックス内のメッセージ数. 詳細については, EXISTS レスポンスの説明を参照のこと.
`<n>` RECENT \Recent フラグが設定されたメッセージの数. 詳細については, RECENT レスポンスの説明を参照のこと.
OK [UNSEEN `<n>`]
メールボックス内の最初の未読メッセージのメッセージシーケンス番号. これが欠落している場合, クライアントはメールボックス内の最初の未読メッセージについて仮定を立てることができず, それを見つけたい場合は SEARCH コマンドを発行する必要がある.
OK [PERMANENTFLAGS (`<list of flags>`)]
クライアントが永続的に変更できるメッセージフラグのリスト. これが欠落している場合, クライアントはすべてのフラグを永続的に変更できると想定すべきである.
OK [UIDNEXT `<n>`]
次の一意識別子値. 詳細についてはセクション 2.3.1.1 を参照のこと. これが欠落している場合, クライアントは次の一意識別子値について仮定を立てることができない.
RFC 3501 IMAPv4 March 2003
OK [UIDVALIDITY `<n>`]
一意識別子有効性値. 詳細についてはセクション 2.3.1.1 を参照のこと. これが欠落している場合, サーバーは一意識別子をサポートしていない.
接続内で一度に選択できるメールボックスは 1 つだけである. 複数のメールボックスへの同時アクセスには複数の接続が必要である. SELECT コマンドは, 新しい選択を試みる前に, 現在選択されているメールボックスを自動的に選択解除する. したがって, メールボックスが選択されており, 失敗する SELECT コマンドが試行された場合, どのメールボックスも選択されない.
クライアントがメールボックスを変更することを許可されている場合, サーバーはタグ付き OK レスポンスのテキストに "[READ-WRITE]" レスポンスコードを前置すべきである (SHOULD).
クライアントがメールボックスを変更することを許可されていないが, 読み取りアクセスが許可されている場合, メールボックスは読み取り専用として選択され, サーバーは SELECT へのタグ付き OK レスポンスのテキストに "[READ-ONLY]" レスポンスコードを前置しなければならない (MUST). SELECT による読み取り専用アクセスは, 特定の読み取り専用メールボックスがユーザーごと (グローバルではなく) のベースで永続状態の変更を許可する場合があるという点で, EXAMINE コマンドとは異なる. サーバーベースの .newsrc ファイルでマークされた Netnews メッセージは, 読み取り専用メールボックスで変更できるそのようなユーザーごとの永続状態の例である.
例: 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: * OK [UIDNEXT 4392] Predicted next UID S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft) S: * OK [PERMANENTFLAGS (\Deleted \Seen *)] Limited S: A142 OK [READ-WRITE] SELECT completed
6.3.2. EXAMINE コマンド
引数 (Arguments): メールボックス名
レスポンス (Responses): 必須タグなしレスポンス: FLAGS, EXISTS, RECENT 必須 OK タグなしレスポンス: UNSEEN, PERMANENTFLAGS, UIDNEXT, UIDVALIDITY
結果 (Result): OK - examine 完了, 現在選択済み状態 NO - examine 失敗, 現在認証済み状態: そのようなメールボックスがない, メールボックスにアクセスできない BAD - コマンド不明または引数が無効
EXAMINE コマンドは SELECT と同一であり, 同じ出力を返す. ただし, 選択されたメールボックスは読み取り専用として識別される. ユーザーごとの状態を含む, メールボックスの永続状態への変更は許可されない. 特に, EXAMINE はメッセージが \Recent フラグを失う原因となってはならない (MUST NOT).
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: * OK [UIDNEXT 4392] Predicted next UID 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 コマンド
引数 (Arguments): メールボックス名
レスポンス (Responses): このコマンドに対する特定のレスポンスはない
結果 (Result): OK - create 完了 NO - create 失敗: その名前でメールボックスを作成できない BAD - コマンド不明または引数が無効
CREATE コマンドは, 指定された名前のメールボックスを作成する. OK レスポンスは, その名前の新しいメールボックスが作成された場合にのみ返される. INBOX や, 既存のメールボックスを参照する名前のメールボックスを作成しようとすることはエラーである. 作成中のエラーは, タグ付き NO レスポンスを返す.
RFC 3501 IMAPv4 March 2003
メールボックス名がサーバーの階層区切り文字 (LIST コマンドでサーバーから返されたもの) で接尾辞されている場合, これは, クライアントがこの名前の下の階層にメールボックス名を作成する意図があるという宣言である. この宣言を必要としないサーバー実装は, この宣言を無視しなければならない (MUST). いずれの場合も, 作成される名前には末尾の階層区切り文字は含まれない.
名前の他の場所にサーバーの階層区切り文字が現れる場合, サーバーは, CREATE コマンドが正常に完了するために必要な上位の階層名を作成すべきである (SHOULD). 言い換えると, "/" が階層区切り文字であるサーバー上で "foo/bar/zap" を作成しようとする場合, foo/ と foo/bar/ がまだ存在しなければ作成すべきである (SHOULD).
削除されたメールボックスと同じ名前で新しいメールボックスが作成された場合, その一意識別子は, 前のメールボックスの前回の実装で使用された一意識別子より大きくなければならない (MUST). ただし, 新しい実装が異なる一意識別子有効性値を持つ場合を除く. 詳細については, UID コマンドの説明を参照のこと.
例: C: A003 CREATE owatagusiam/ S: A003 OK CREATE completed C: A004 CREATE owatagusiam/blurdybloop S: A004 OK CREATE completed
注記: この例の解釈は, LIST から "/" が階層区切り文字として返されたかどうかに依存する. "/" が階層区切り文字の場合, "owatagusiam" という名前の新しい階層レベルが "blurdybloop" というメンバーとともに作成される. そうでない場合, 同じ階層レベルに 2 つのメールボックスが作成される.
6.3.4. DELETE コマンド
引数 (Arguments): メールボックス名
レスポンス (Responses): このコマンドに対する特定のレスポンスはない
結果 (Result): OK - delete 完了 NO - delete 失敗: その名前のメールボックスを削除できない BAD - コマンド不明または引数が無効
RFC 3501 IMAPv4 March 2003
DELETE コマンドは, 指定された名前のメールボックスを完全に削除する. タグ付き OK レスポンスは, メールボックスが削除された場合にのみ返される. INBOX や存在しないメールボックス名を削除しようとすることはエラーである.
DELETE コマンドは, 下位の階層名を削除してはならない (MUST NOT). 例えば, メールボックス "foo" に下位の "foo.bar" がある場合 ("." が階層区切り文字であると仮定), "foo" を削除しても "foo.bar" を削除してはならない (MUST NOT). 下位の階層名を持ち, かつ \Noselect メールボックス名属性も持つ名前を削除しようとすることはエラーである (詳細については, LIST レスポンスの説明を参照).
下位の階層名を持ち, \Noselect メールボックス名属性を持たない名前を削除することは許可されている. この場合, そのメールボックス内のすべてのメッセージが削除され, その名前は \Noselect メールボックス名属性を取得する.
削除されたメールボックスの最高使用一意識別子の値は, 同じ名前で作成された新しいメールボックスが前の実装の識別子を再利用しないように保存されなければならない (MUST). ただし, 新しい実装が異なる一意識別子有効性値を持つ場合を除く. 詳細については, UID コマンドの説明を参照のこと.
例: C: A682 LIST "" * S: * LIST () "/" blurdybloop S: * LIST (\Noselect) "/" foo S: * LIST () "/" foo/bar S: A682 OK LIST completed C: A683 DELETE blurdybloop S: A683 OK DELETE completed C: A684 DELETE foo S: A684 NO Name "foo" has inferior hierarchical names C: A685 DELETE foo/bar S: A685 OK DELETE Completed C: A686 LIST "" * S: * LIST (\Noselect) "/" foo S: A686 OK LIST completed C: A687 DELETE foo S: A687 OK DELETE Completed
RFC 3501 IMAPv4 March 2003
C: A82 LIST "" *
S: * LIST () "." blurdybloop
S: * LIST () "." foo
S: * LIST () "." foo.bar
S: A82 OK LIST completed
C: A83 DELETE blurdybloop
S: A83 OK DELETE completed
C: A84 DELETE foo
S: A84 OK DELETE Completed
C: A85 LIST "" *
S: * LIST () "." foo.bar
S: A85 OK LIST completed
C: A86 LIST "" %
S: * LIST (\Noselect) "." foo
S: A86 OK LIST completed
6.3.5. RENAME コマンド
引数 (Arguments): 既存のメールボックス名 新しいメールボックス名
レスポンス (Responses): このコマンドに対する特定のレスポンスはない
結果 (Result): OK - rename 完了 NO - rename 失敗: その名前のメールボックスを名前変更できない, その名前のメールボックスに名前変更できない BAD - コマンド不明または引数が無効
RENAME コマンドは, メールボックスの名前を変更する. タグ付き OK レスポンスは, メールボックスが名前変更された場合にのみ返される. 存在しないメールボックス名からの名前変更や, 既に存在するメールボックス名への名前変更を試みることはエラーである. 名前変更中のエラーは, タグ付き NO レスポンスを返す.
名前が下位の階層名を持つ場合, 下位の階層名も名前変更されなければならない (MUST). 例えば, "foo" の "zap" への名前変更は, "foo/bar" ("/" が階層区切り文字であると仮定) を "zap/bar" に名前変更する.
RFC 3501 IMAPv4 March 2003
名前の他の場所にサーバーの階層区切り文字が現れる場合, サーバーは, RENAME コマンドが正常に完了するために必要な上位の階層名を作成すべきである (SHOULD). 言い換えると, "/" が階層区切り文字であるサーバー上で "foo/bar/zap" を "baz/rag/zowie" に名前変更しようとする場合, baz/ と baz/rag/ がまだ存在しなければ作成すべきである (SHOULD).
古いメールボックス名の最高使用一意識別子の値は, 同じ名前で作成された新しいメールボックスが前の実装の識別子を再利用しないように保存されなければならない (MUST). ただし, 新しい実装が異なる一意識別子有効性値を持つ場合を除く. 詳細については, UID コマンドの説明を参照のこと.
INBOX の名前変更は許可されており, 特別な動作を持つ. これは, INBOX 内のすべてのメッセージを指定された名前の新しいメールボックスに移動し, INBOX を空のままにする. サーバー実装が INBOX の下位の階層名をサポートする場合, これらは INBOX の名前変更の影響を受けない.
例: C: A682 LIST "" * S: * LIST () "/" blurdybloop S: * LIST (\Noselect) "/" foo S: * LIST () "/" foo/bar S: A682 OK LIST completed C: A683 RENAME blurdybloop sarasoop S: A683 OK RENAME completed C: A684 RENAME foo zowie S: A684 OK RENAME Completed C: A685 LIST "" * S: * LIST () "/" sarasoop S: * LIST (\Noselect) "/" zowie S: * LIST () "/" zowie/bar S: A685 OK LIST completed
C: Z432 LIST "" *
S: * LIST () "." INBOX
S: * LIST () "." INBOX.bar
S: Z432 OK LIST completed
C: Z433 RENAME INBOX old-mail
S: Z433 OK RENAME completed
C: Z434 LIST "" *
S: * LIST () "." INBOX
S: * LIST () "." INBOX.bar
S: * LIST () "." old-mail
S: Z434 OK LIST completed
RFC 3501 IMAPv4 March 2003
6.3.6. SUBSCRIBE コマンド
引数 (Arguments): メールボックス
レスポンス (Responses): このコマンドに対する特定のレスポンスはない
結果 (Result): OK - subscribe 完了 NO - subscribe 失敗: その名前を購読できない BAD - コマンド不明または引数が無効
SUBSCRIBE コマンドは, 指定されたメールボックス名を, LSUB コマンドによって返されるサーバーの「アクティブ」または「購読済み」メールボックスのセットに追加する. このコマンドは, 購読が成功した場合にのみタグ付き OK レスポンスを返す.
サーバーは, SUBSCRIBE のメールボックス引数を検証して, それが存在することを確認してもよい (MAY). ただし, その名前のメールボックスがもう存在しない場合でも, 既存のメールボックス名を購読リストから一方的に削除してはならない (MUST NOT).
注記: この要件は, サーバーサイトが, よく知られた名前 (例えば "system-alerts") のメールボックスを, その内容が期限切れになった後に定期的に削除し, 新しい内容が適切なときに再作成することを選択できるためである.
例: C: A002 SUBSCRIBE #news.comp.mail.mime S: A002 OK SUBSCRIBE completed
6.3.7. UNSUBSCRIBE コマンド
引数 (Arguments): メールボックス名
レスポンス (Responses): このコマンドに対する特定のレスポンスはない
結果 (Result): OK - unsubscribe 完了 NO - unsubscribe 失敗: その名前を購読解除できない BAD - コマンド不明または引数が無効
UNSUBSCRIBE コマンドは, 指定されたメールボックス名を, LSUB コマンドによって返されるサーバーの「アクティブ」または「購読済み」メールボックスのセットから削除する. このコマンドは, 購読解除が成功した場合にのみタグ付き OK レスポンスを返す.
例: C: A002 UNSUBSCRIBE #news.comp.mail.mime S: A002 OK UNSUBSCRIBE completed
RFC 3501 IMAPv4 March 2003
6.3.8. LIST コマンド
引数 (Arguments): 参照名 ワイルドカードの可能性があるメールボックス名
レスポンス (Responses): タグなしレスポンス: LIST
結果 (Result): OK - list 完了 NO - list 失敗: その参照または名前をリストできない BAD - コマンド不明または引数が無効
LIST コマンドは, クライアントが利用できるすべての名前の完全なセットから, 名前のサブセットを返す. 名前属性, 階層区切り文字, 名前を含むゼロ個以上のタグなし LIST 応答が返される. 詳細については, LIST 応答の説明を参照のこと.
LIST コマンドは, 過度な遅延なしにデータをすばやく返すべきである (SHOULD). 例えば, \Marked または \Unmarked のステータスを計算したり, 他の処理を実行したりするために過度の手間をかけるべきではない (SHOULD NOT). 各名前に 1 秒の処理が必要な場合, 1200 個の名前のリストには 20 分かかることになる!
空 ("") の参照名引数は, メールボックス名が SELECT によるものと同様に解釈されることを示す. 返されるメールボックス名は, 指定されたメールボックス名パターンと一致しなければならない (MUST). 空でない参照名引数は, メールボックスまたはメールボックス階層のレベルの名前であり, メールボックス名が解釈されるコンテキストを示す.
空 ("") のメールボックス名引数は, 参照で指定された名前の階層区切り文字とルート名を返すための特別なリクエストである. ルートとして返される値は, 参照がルートでない場合または空文字列の場合, 空文字列にできる (MAY). すべての場合において, 階層区切り文字 (または階層がない場合は NIL) が返される. これにより, クライアントは, その名前のメールボックスが現在存在しない場合でも, 階層区切り文字を取得できる (またはメールボックス名がフラットであることを確認できる).
参照引数とメールボックス名引数は, あいまいさのない左から右への階層を表す正規形式に解釈される. 返されるメールボックス名は解釈された形式になる.
RFC 3501 IMAPv4 March 2003
注記: 参照引数の解釈は実装定義である. それは, サーバー実装が「現在の作業ディレクトリ」と, 現在の作業ディレクトリを上書きする先頭の「ブレイクアウト文字」の概念を持つかどうかに依存する.
例えば, UNIX または NT ファイルシステムをエクスポートするサーバーでは, 参照引数に現在の作業ディレクトリが含まれ, メールボックス名引数には現在の作業ディレクトリで解釈された名前が含まれる.
サーバー実装にブレイクアウト文字の概念がない場合, 正規形式は通常, 参照名にメールボックス名を追加したものになる. サーバーが名前空間の慣例 (セクション 5.1.2) を実装する場合, "#" はブレイクアウト文字であり, そのように扱われなければならないことに注意すること.
参照引数がメールボックス階層のレベルでない場合 (つまり \NoInferiors 名である場合), および/または参照引数が階層区切り文字で終わっていない場合, これがどのように解釈されるかは実装依存である. 例えば, 参照 "foo/bar" とメールボックス名 "rag/baz" は, "foo/bar/rag/baz", "foo/barrag/baz", または "foo/rag/baz" として解釈できる. クライアントは, ユーザーの明示的な要求がある場合を除き, そのような参照引数を使用すべきではない (SHOULD NOT). 階層ブラウザは, 参照がメールボックス階層のレベルであり, かつ階層区切り文字で終わる場合を除き, 参照のサーバー解釈について仮定を立ててはならない (MUST NOT).
解釈された形式に含まれる参照引数の部分は, 解釈された形式の接頭辞になるべきである (SHOULD). また, 参照名引数と同じ形式であるべきである (SHOULD). この規則により, クライアントは, 返されたメールボックス名が参照引数のコンテキストにあるのか, それともメールボックス引数の何かが参照引数を上書きしたのかを判断できる. この規則がないと, クライアントは, 名前付けコンテキストを上書きする「ブレイクアウト」文字を含む, サーバーの名前付けセマンティクスの知識を持たなければならない.
RFC 3501 IMAPv4 March 2003
例えば, UNIX ベースのサーバーで参照とメールボックス名がどのように解釈されるかの例をいくつか示す:
Reference Mailbox Name Interpretation
------------ ------------ --------------
~smith/Mail/ foo.* ~smith/Mail/foo.*
archive/ % archive/%
#news. comp.mail.* #news.comp.mail.*
~smith/Mail/ /usr/doc/foo /usr/doc/foo
archive/ ~fred/Mail/* ~fred/Mail/*
最初の 3 つの例は, 参照引数のコンテキストでの解釈を示している. "~smith/Mail" は "/u2/users/smith/Mail" のようなものに変換されるべきではない (SHOULD NOT) ことに注意すること. そうでないと, クライアントが解釈が参照のコンテキストにあることを判断できなくなるためである.
文字 "*" はワイルドカードであり, この位置でゼロ個以上の文字と一致する. 文字 "%" は "*" に似ているが, 階層区切り文字とは一致しない. "%" ワイルドカードがメールボックス名引数の最後の文字である場合, 一致する階層レベルも返される. これらの階層レベルが選択可能なメールボックスでもない場合, それらは \Noselect メールボックス名属性とともに返される (詳細については, LIST レスポンスの説明を参照).
サーバー実装は, 特定の状況で特定の文字や名前がワイルドカードと一致しないようにすることにより, ワイルドカード文字から「隠す」ことを許可されている. 例えば, UNIX ベースのサーバーは, 先頭の "/" 文字が一致しないように "*" の解釈を制限する場合がある.
特別な名前 INBOX は, このサーバーがこのユーザーに対して INBOX をサポートし, 大文字の文字列 "INBOX" が, 上記のようにワイルドカード付きの解釈された参照引数とメールボックス名引数と一致する場合, LIST の出力に含まれる. INBOX を省略する基準は, SELECT INBOX が失敗を返すかどうかであり, ユーザーの実際の INBOX がこのサーバーか他のサーバーにあるかは関係ない.
RFC 3501 IMAPv4 March 2003
例: C: A101 LIST "" "" S: * LIST (\Noselect) "/" "" S: A101 OK LIST Completed C: A102 LIST #news.comp.mail.misc "" S: * LIST (\Noselect) "." #news. S: A102 OK LIST Completed C: A103 LIST /usr/staff/jones "" S: * LIST (\Noselect) "/" / S: A103 OK LIST Completed C: A202 LIST ~/Mail/ % S: * LIST (\Noselect) "/" ~/Mail/foo S: * LIST () "/" ~/Mail/meetings S: A202 OK LIST completed
6.3.9. LSUB コマンド
引数 (Arguments): 参照名 ワイルドカードの可能性があるメールボックス名
レスポンス (Responses): タグなしレスポンス: LSUB
結果 (Result): OK - lsub 完了 NO - lsub 失敗: その参照または名前をリストできない BAD - コマンド不明または引数が無効
LSUB コマンドは, ユーザーが「アクティブ」または「購読済み」として宣言した名前のセットから, 名前のサブセットを返す. ゼロ個以上のタグなし LSUB 応答が返される. LSUB の引数は LIST のものと同じ形式である.
返されるタグなし LSUB レスポンスは, LIST タグなしレスポンスとは異なるメールボックスフラグを含む場合がある. このような場合, タグなし LIST のフラグの方がより権威があると見なされる.
特殊な状況は, % ワイルドカードで LSUB を使用する場合に発生する. "foo/bar" (階層区切り文字 "/" を使用) が購読されているが "foo" が購読されていない場合に何が起こるかを考えてみる. LSUB への "%" ワイルドカードは, LSUB レスポンスで foo/bar ではなく foo を返さなければならず, \Noselect 属性でフラグ付けされなければならない (MUST).
サーバーは, その名前のメールボックスがもう存在しない場合でも, 既存のメールボックス名を購読リストから一方的に削除してはならない (MUST NOT).
RFC 3501 IMAPv4 March 2003
例: C: A002 LSUB "#news." "comp.mail.*" S: * LSUB () "." #news.comp.mail.mime S: * LSUB () "." #news.comp.mail.misc S: A002 OK LSUB completed C: A003 LSUB "#news." "comp.%" S: * LSUB (\NoSelect) "." #news.comp.mail S: A003 OK LSUB completed
6.3.10. STATUS コマンド
引数 (Arguments): メールボックス名 ステータスデータ項目名
レスポンス (Responses): タグなしレスポンス: STATUS
結果 (Result): OK - status 完了 NO - status 失敗: その名前のステータスがない BAD - コマンド不明または引数が無効
STATUS コマンドは, 指定されたメールボックスのステータスを要求する. これは, 現在選択されているメールボックスを変更せず, 照会されたメールボックス内のメッセージの状態にも影響を与えない (特に, STATUS はメッセージが \Recent フラグを失う原因となってはならない (MUST NOT)).
STATUS コマンドは, 2 番目の IMAP4rev1 接続を開いてメールボックスで EXAMINE コマンドを実行する代わりに, 最初の IMAP4rev1 接続で現在のメールボックスを選択解除せずにメールボックスのステータスを照会する代替手段を提供する.
LIST コマンドとは異なり, STATUS コマンドはレスポンスが高速であることは保証されない. 特定の状況では, かなり遅くなる可能性がある. 一部の実装では, サーバーは特定のステータス情報を取得するために内部でメールボックスを読み取り専用で開く義務がある. また, LIST コマンドとは異なり, STATUS コマンドはワイルドカードを受け入れない.
注記: STATUS コマンドは, 選択されたメールボックス内の新しいメッセージを「チェックする」操作として使用してはならない (MUST NOT) (新しいメッセージチェックの適切な方法の詳細については, セクション 7, 7.3.1, 7.3.2 を参照).
STATUS コマンドはその結果が高速であることが保証されていないため, クライアントは, 多くの連続した STATUS コマンドを発行して妥当なパフォーマンスを得られることを期待すべきではない (SHOULD NOT).
現在定義されている, 要求できるステータスデータ項目は以下のとおりである:
MESSAGES メールボックス内のメッセージ数.
RECENT \Recent フラグが設定されたメッセージの数.
UIDNEXT メールボックスの次の一意識別子値. 詳細についてはセクション 2.3.1.1 を参照のこと.
UIDVALIDITY メールボックスの一意識別子有効性値. 詳細についてはセクション 2.3.1.1 を参照のこと.
UNSEEN \Seen フラグが設定されていないメッセージの数.
例: C: A042 STATUS blurdybloop (UIDNEXT MESSAGES) S: * STATUS blurdybloop (MESSAGES 231 UIDNEXT 44292) S: A042 OK STATUS completed
RFC 3501 IMAPv4 March 2003
6.3.11. APPEND コマンド
引数 (Arguments): メールボックス名 オプションのフラグ括弧付きリスト オプションの日時文字列 メッセージリテラル
レスポンス (Responses): このコマンドに対する特定のレスポンスはない
結果 (Result): OK - append 完了 NO - append エラー: そのメールボックスに追加できない, フラグ/日時/メッセージテキストのエラー BAD - コマンド不明または引数が無効
APPEND コマンドは, リテラル引数を新しいメッセージとして指定された宛先メールボックスの末尾に追加する. この引数は [RFC-2822] メッセージの形式であるべきである (SHOULD). メッセージ内の 8-bit 文字は許可されている. 8-bit データを適切に保持できないサーバー実装は, [MIME-IMB] コンテンツ転送エンコーディングを使用して 8-bit APPEND データを 7-bit に可逆変換できなければならない (MUST).
注記: 必須の [RFC-2822] ヘッダー行が APPEND へのメッセージリテラル引数に省略される場合 (下書きメッセージなど) が存在する場合がある (MAY). そのような省略の完全な影響を理解し, 慎重に検討しなければならない (MUST).
フラグ括弧付きリストが指定された場合, フラグは結果のメッセージに設定されるべきである (SHOULD). それ以外の場合, 結果のメッセージのフラグリストはデフォルトで空に設定される. どちらの場合も, Recent フラグも設定される.
日時が指定された場合, 内部日付は結果のメッセージに設定されるべきである (SHOULD). それ以外の場合, 結果のメッセージの内部日付はデフォルトで現在の日時に設定される.
何らかの理由で追加が失敗した場合, メールボックスは APPEND 試行前の状態に復元されなければならない (MUST). 部分的な追加は許可されない.
宛先メールボックスが存在しない場合, サーバーはエラーを返さなければならず (MUST), メールボックスを自動的に作成してはならない (MUST NOT). 宛先メールボックスを作成できないことが確実でない限り, サーバーはタグ付き NO レスポンスのテキストの接頭辞としてレスポンスコード "[TRYCREATE]" を送信しなければならない (MUST). これにより, クライアントは CREATE コマンドを試み, CREATE が成功した場合に APPEND を再試行できるというヒントが得られる.
RFC 3501 IMAPv4 March 2003
メールボックスが現在選択されている場合, 通常の新しいメッセージアクションが発生すべきである (SHOULD). 具体的には, サーバーはタグなし EXISTS レスポンスでクライアントに即座に通知すべきである (SHOULD). サーバーがそうしない場合, クライアントは 1 つ以上の APPEND コマンドの後に NOOP コマンド (またはそれが失敗した場合 CHECK コマンド) を発行してもよい (MAY).
例: C: A003 APPEND saved-messages (\Seen) \{310\}
S: + Ready for literal data
C: Date: Mon, 7 Feb 1994 21:52:25 -0800 (PST)
C: From: Fred Foobar <[email protected]>
C: Subject: afternoon meeting
C: To: [email protected]
C: Message-Id: <[email protected]>
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. クライアントコマンド - 選択済み状態 (Client Commands - Selected State)
選択済み状態では, メールボックス内のメッセージを操作するコマンドが許可される.
汎用コマンド (CAPABILITY, NOOP, LOGOUT) と認証済み状態コマンド (SELECT, EXAMINE, CREATE, DELETE, RENAME, SUBSCRIBE, UNSUBSCRIBE, LIST, LSUB, STATUS, APPEND) に加えて, 以下のコマンドが選択済み状態で有効である: CHECK, CLOSE, EXPUNGE, SEARCH, FETCH, STORE, COPY, UID.
6.4.1. CHECK コマンド
引数 (Arguments): なし
レスポンス (Responses): このコマンドに対する特定のレスポンスはない
結果 (Result): OK - check 完了 BAD - コマンド不明または引数が無効
CHECK コマンドは, 現在選択されているメールボックスのチェックポイントを要求する. チェックポイントとは, 各コマンドの一部として通常は実行されない, メールボックスに関連する実装依存のハウスキーピング (例えば, メールボックスのサーバーのメモリ内状態をそのディスク上の状態と整合させること) を指す.
RFC 3501 IMAPv4 March 2003
チェックポイントは, 完了するまでに瞬時ではない実時間を要する場合がある (MAY). サーバー実装にそのようなハウスキーピングの考慮事項がない場合, CHECK は NOOP と同等である.
CHECK の結果として EXISTS タグなしレスポンスが発生することは保証されない. 新しいメッセージのポーリングには NOOP を使用すべきであり (SHOULD), CHECK ではない.
例: C: FXXZ CHECK S: FXXZ OK CHECK Completed
6.4.2. CLOSE コマンド
引数 (Arguments): なし
レスポンス (Responses): このコマンドに対する特定のレスポンスはない
結果 (Result): OK - close 完了, 現在認証済み状態 BAD - コマンド不明または引数が無効
CLOSE コマンドは, \Deleted フラグが設定されたすべてのメッセージを現在選択されているメールボックスから完全に削除し, 選択済み状態から認証済み状態に戻る. タグなし EXPUNGE レスポンスは送信されない.
メールボックスが EXAMINE コマンドによって選択された場合, またはその他の方法で読み取り専用として選択された場合, メッセージは削除されず, エラーも与えられない.
メールボックスが選択されていても, 事前に CLOSE コマンドを発行せずに SELECT, EXAMINE, または LOGOUT コマンドを発行してもよい (MAY). SELECT, EXAMINE, LOGOUT コマンドは, expunge を行わずに現在選択されているメールボックスを暗黙的に閉じる. ただし, 多くのメッセージが削除された場合, CLOSE-LOGOUT または CLOSE-SELECT シーケンスは, タグなし EXPUNGE レスポンス (クライアントがおそらく無視する) が送信されないため, EXPUNGE-LOGOUT または EXPUNGE-SELECT よりもかなり高速である.
例: C: A341 CLOSE S: A341 OK CLOSE completed
RFC 3501 IMAPv4 March 2003
6.4.3. EXPUNGE コマンド
引数 (Arguments): なし
レスポンス (Responses): タグなしレスポンス: EXPUNGE
結果 (Result): OK - expunge 完了 NO - expunge 失敗: expunge できない (例えば, 権限が拒否された) 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 コマンド
引数 (Arguments): オプションの [CHARSET] 指定 検索基準 (1 つ以上)
レスポンス (Responses): 必須タグなしレスポンス: SEARCH
結果 (Result): OK - search 完了 NO - search エラー: その [CHARSET] または基準を検索できない BAD - コマンド不明または引数が無効
SEARCH コマンドは, 指定された検索基準に一致するメッセージをメールボックス内で検索する. 検索基準は 1 つ以上の検索キーで構成される. サーバーからのタグなし SEARCH レスポンスには, 検索基準に一致するメッセージに対応するメッセージシーケンス番号のリストが含まれる.
RFC 3501 IMAPv4 March 2003
複数のキーが指定された場合, 結果はそれらのキーに一致するすべてのメッセージの共通部分 (AND 関数) になる. 例えば, 基準 DELETED FROM "SMITH" SINCE 1-Feb-1994 は, 1994 年 2 月 1 日以降にメールボックスに配置された Smith からのすべての削除済みメッセージを参照する. 検索キーは, 1 つ以上の検索キーの括弧付きリストにすることもできる (例えば, OR キーと NOT キーでの使用のため).
サーバー実装は, TEXT と MESSAGE 以外の終端コンテンツメディアタイプを持つ [MIME-IMB] ボディパートを SEARCH マッチングの考慮から除外してもよい (MAY).
オプションの [CHARSET] 指定は, 単語 "CHARSET" の後に登録済み [CHARSET] が続くものである. これは, 検索基準に現れる文字列の [CHARSET] を示す. [MIME-IMB] コンテンツ転送エンコーディングと [RFC-2822]/[MIME-IMB] ヘッダー内の [MIME-HDRS] 文字列は, US-ASCII 以外の [CHARSET] でテキストを比較する前にデコードされなければならない (MUST). US-ASCII はサポートされなければならない (MUST). 他の [CHARSET] はサポートされてもよい (MAY).
サーバーが指定された [CHARSET] をサポートしない場合, タグ付き NO レスポンス (BAD ではない) を返さなければならない (MUST). このレスポンスには, サーバーがサポートする [CHARSET] をリストする BADCHARSET レスポンスコードが含まれるべきである (SHOULD).
文字列を使用するすべての検索キーで, 文字列がフィールドの部分文字列である場合, メッセージはキーと一致する. マッチングは大文字と小文字を区別しない.
定義されている検索キーは以下のとおりである. 引数の正確な構文定義については, 正式構文 (Formal Syntax) セクションを参照のこと.
<sequence set>
指定されたメッセージシーケンス番号セットに対応するメッセージシーケンス番号を持つメッセージ.
ALL メールボックス内のすべてのメッセージ. AND のデフォルトの初期キー.
ANSWERED \Answered フラグが設定されたメッセージ.
RFC 3501 IMAPv4 March 2003
BCC <string>
エンベロープ構造の BCC フィールドに指定された文字列を含むメッセージ.
BEFORE <date>
内部日付 (時刻とタイムゾーンを無視) が指定された日付より前のメッセージ.
BODY <string>
メッセージのボディに指定された文字列を含むメッセージ.
CC <string>
エンベロープ構造の CC フィールドに指定された文字列を含むメッセージ.
DELETED \Deleted フラグが設定されたメッセージ.
DRAFT \Draft フラグが設定されたメッセージ.
FLAGGED \Flagged フラグが設定されたメッセージ.
FROM <string>
エンベロープ構造の FROM フィールドに指定された文字列を含むメッセージ.
HEADER <field-name> <string>
指定されたフィールド名 ([RFC-2822] で定義) を持つヘッダーがあり, ヘッダーのテキスト (コロンの後) に指定された文字列を含むメッセージ. 検索する文字列がゼロ長の場合, これは内容に関係なく指定されたフィールド名のヘッダー行を持つすべてのメッセージと一致する.
KEYWORD <flag>
指定されたキーワードフラグが設定されたメッセージ.
LARGER <n>
指定されたオクテット数より大きい [RFC-2822] サイズのメッセージ.
NEW \Recent フラグが設定されているが \Seen フラグが設定されていないメッセージ. これは機能的に "(RECENT UNSEEN)" と同等である.
RFC 3501 IMAPv4 March 2003
NOT <search-key>
指定された検索キーに一致しないメッセージ.
OLD \Recent フラグが設定されていないメッセージ. これは機能的に "NOT RECENT" と同等である ("NOT NEW" とは対照的).
ON <date>
内部日付 (時刻とタイムゾーンを無視) が指定された日付内のメッセージ.
OR <search-key1> <search-key2>
いずれかの検索キーに一致するメッセージ.
RECENT \Recent フラグが設定されたメッセージ.
SEEN \Seen フラグが設定されたメッセージ.
SENTBEFORE <date>
[RFC-2822] Date: ヘッダー (時刻とタイムゾーンを無視) が指定された日付より前のメッセージ.
SENTON <date>
[RFC-2822] Date: ヘッダー (時刻とタイムゾーンを無視) が指定された日付内のメッセージ.
SENTSINCE <date>
[RFC-2822] Date: ヘッダー (時刻とタイムゾーンを無視) が指定された日付以降のメッセージ.
SINCE <date>
内部日付 (時刻とタイムゾーンを無視) が指定された日付以降のメッセージ.
SMALLER <n>
指定されたオクテット数より小さい [RFC-2822] サイズのメッセージ.
RFC 3501 IMAPv4 March 2003
SUBJECT <string>
エンベロープ構造の SUBJECT フィールドに指定された文字列を含むメッセージ.
TEXT <string>
メッセージのヘッダーまたはボディに指定された文字列を含むメッセージ.
TO <string>
エンベロープ構造の TO フィールドに指定された文字列を含むメッセージ.
UID <sequence set>
指定された一意識別子セットに対応する一意識別子を持つメッセージ. シーケンスセットの範囲は許可されている.
UNANSWERED \Answered フラグが設定されていないメッセージ.
UNDELETED \Deleted フラグが設定されていないメッセージ.
UNDRAFT \Draft フラグが設定されていないメッセージ.
UNFLAGGED \Flagged フラグが設定されていないメッセージ.
UNKEYWORD <flag>
指定されたキーワードフラグが設定されていないメッセージ.
UNSEEN \Seen フラグが設定されていないメッセージ.
RFC 3501 IMAPv4 March 2003
例: C: A282 SEARCH FLAGGED SINCE 1-Feb-1994 NOT FROM "Smith" S: * SEARCH 2 84 882 S: A282 OK SEARCH completed C: A283 SEARCH TEXT "string not in mailbox" S: * SEARCH S: A283 OK SEARCH completed C: A284 SEARCH CHARSET UTF-8 TEXT \{6\} C: XXXXXX S: * SEARCH 43 S: A284 OK SEARCH completed
注記: この文書は 7-bit ASCII テキストに制限されているため, 実際の UTF-8 データを示すことはできない. "XXXXXX" は, 実際のトランザクションで 6 オクテットの 8-bit データになるもののプレースホルダである.
6.4.5. FETCH コマンド
引数 (Arguments): シーケンスセット メッセージデータ項目名またはマクロ
レスポンス (Responses): タグなしレスポンス: FETCH
結果 (Result): OK - fetch 完了 NO - fetch エラー: そのデータをフェッチできない BAD - コマンド不明または引数が無効
FETCH コマンドは, メールボックス内のメッセージに関連付けられたデータを取得する. フェッチされるデータ項目は, 単一のアトムまたは括弧付きリストのいずれかである.
正式構文の msg-att-static 規則で識別されるほとんどのデータ項目は静的であり, 特定のメッセージに対して変更されてはならない (MUST NOT). 正式構文の msg-att-dynamic 規則で識別される他のデータ項目は, STORE コマンドの結果または外部イベントによって変更される場合がある (MAY).
例えば, クライアントがメッセージのエンベロープを既に知っているときに ENVELOPE を受信した場合, 新しく送信されたエンベロープを安全に無視できる.
一般的に使用されるデータ項目のセットを指定する 3 つのマクロがあり, データ項目の代わりに使用できる. マクロは単独で使用しなければならず, 他のマクロやデータ項目と併用してはならない.
RFC 3501 IMAPv4 March 2003
ALL (FLAGS INTERNALDATE RFC822.SIZE ENVELOPE) と同等のマクロ.
FAST (FLAGS INTERNALDATE RFC822.SIZE) と同等のマクロ.
FULL (FLAGS INTERNALDATE RFC822.SIZE ENVELOPE BODY) と同等のマクロ.
現在定義されている, フェッチできるデータ項目は以下のとおりである:
BODY BODYSTRUCTURE の非拡張形式.
BODY[<section>]<\\<partial>>
特定のボディセクションのテキスト. セクション指定は, ピリオドで区切られたゼロ個以上のパート指定子のセットである. パート指定子は, パート番号または次のいずれかである: HEADER, HEADER.FIELDS, HEADER.FIELDS.NOT, MIME, TEXT. 空のセクション指定は, ヘッダーを含むメッセージ全体を参照する.
すべてのメッセージには少なくとも 1 つのパート番号がある. 非 [MIME-IMB] メッセージと, カプセル化されたメッセージのない非マルチパート [MIME-IMB] メッセージは, パート 1 のみを持つ.
マルチパートメッセージには, メッセージ内に現れる順に連続したパート番号が割り当てられる. 特定のパートがメッセージタイプまたはマルチパートタイプの場合, そのパートは, ピリオドの後にそのネストされたマルチパートパート内のパート番号が続く形式で示されなければならない (MUST).
MESSAGE/RFC822 タイプのパートには, MESSAGE パートのボディのパートを参照するネストされたパート番号もある.
HEADER, HEADER.FIELDS, HEADER.FIELDS.NOT, TEXT パート指定子は, 単独のパート指定子にできるか, 1 つ以上の数値パート指定子の接頭辞を付けることができる. ただし, 数値パート指定子が MESSAGE/RFC822 タイプのパートを参照する場合に限る. MIME パート指定子には, 1 つ以上の数値パート指定子の接頭辞を付けなければならない (MUST).
HEADER, HEADER.FIELDS, HEADER.FIELDS.NOT パート指定子は, メッセージの [RFC-2822] ヘッダー, またはカプセル化された [MIME-IMT] MESSAGE/RFC822 メッセージのヘッダーを参照する.
RFC 3501 IMAPv4 March 2003
HEADER.FIELDS と HEADER.FIELDS.NOT の後には, フィールド名 ([RFC-2822] で定義) のリストが続き, ヘッダーのサブセットを返す.
RFC 3501 IMAPv4 March 2003
HEADER.FIELDS によって返されるサブセットには, リスト内の名前の 1 つと一致するフィールド名を持つヘッダーフィールドのみが含まれる