Internet Engineering Task Force (IETF)                          B. Leiba
Request for Comments: 6237                           Huawei Technologies
Updates: 4466                                                A. Melnikov
Category: Experimental                                     Isode Limited
ISSN: 2070-1721                                                 May 2011
                  IMAP4 Multimailbox SEARCH Extension



The IMAP4 specification allows the searching of only the selected mailbox. A user often wants to search multiple mailboxes, and a client that wishes to support this must issue a series of SELECT and SEARCH commands, waiting for each to complete before moving on to the next. This extension allows a client to search multiple mailboxes with one command, limiting the round trips and waiting for various searches to complete, and not requiring disruption of the currently selected mailbox. This extension also uses MAILBOX and TAG fields in ESEARCH responses, allowing a client to pipeline the searches if it chooses. This document updates RFC 4466.

IMAP4の仕様は、選択されたメールボックスの検索を可能にします。ユーザーは、多くの場合、複数のメールボックスを検索したい、とこれをサポートすることを希望するクライアントは、それぞれ次に移動する前に完了するのを待って、SELECTおよびSEARCH一連のコマンドを発行する必要があります。この拡張は、クライアントがラウンドトリップを制限し、様々な検索が完了するのを待って、現在選択されているメールボックスの中断を必要としない、1つのコマンドで複数のメールボックスを検索することができます。この拡張モジュールはまた、選択した場合に検索パイプラインにクライアントを許可する、ESEARCH応答のMAILBOXおよびTAGフィールドを使用しています。この文書は、RFC 4466に更新します。

Status of This Memo


This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.


This document defines an Experimental Protocol for the Internet community. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.

この文書は、インターネットコミュニティのためにExperimentalプロトコルを定義します。このドキュメントはインターネットエンジニアリングタスクフォース(IETF)の製品です。これは、IETFコミュニティの総意を表しています。これは、公開レビューを受けており、インターネットエンジニアリング運営グループ(IESG)によって公表のために承認されています。 IESGによって承認されていないすべての文書がインターネットStandardのどんなレベルの候補です。 RFC 5741のセクション2を参照してください。

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at


Copyright Notice


Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.

著作権(C)2011 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents ( in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント(に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明4.eおよび簡体BSDライセンスで説明したように、保証なしで提供されているよう簡体BSDライセンスのテキストを含める必要があり、この文書から抽出されました。

Table of Contents


   1. Introduction ....................................................2
      1.1. Conventions Used in This Document ..........................3
   2. New ESEARCH Command .............................................3
      2.1. The ESEARCH Response .......................................4
      2.2. Source Options: Specifying Mailboxes to Search .............5
   3. Examples ........................................................6
   4. Formal Syntax ...................................................7
   5. Security Considerations .........................................8
   6. IANA Considerations .............................................9
   7. Acknowledgements ................................................9
   8. Normative References ............................................9
1. Introduction
1. はじめに

The IMAP4 specification allows the searching of only the selected mailbox. A user often wants to search multiple mailboxes, and a client that wishes to support this must issue a series of SELECT and SEARCH commands, waiting for each to complete before moving on to the next. The commands can't be pipelined, because the server might run them in parallel, and the untagged SEARCH responses could not then be distinguished from each other.


This extension allows a client to search multiple mailboxes with one command, and includes MAILBOX and TAG fields in the ESEARCH response, yielding the following advantages:


o A single command limits the number of round trips needed to search a set of mailboxes.


o A single command eliminates the need to wait for one search to complete before starting the next.


o A single command allows the server to optimize the search, if it can.


o A command that is not dependent upon the selected mailbox eliminates the need to disrupt the selection state or to open another IMAP connection.


o The MAILBOX, UIDVALIDITY, and TAG fields in the responses allow a client to distinguish which responses go with which search (and which mailbox). A client can safely pipeline these search commands without danger of confusion. The addition of the MAILBOX and UIDVALIDITY fields updates the search-correlator item defined in [RFC4466].


1.1. Conventions Used in This Document
1.1. このドキュメントの表記規則

In examples, "C:" indicates lines sent by a client that is connected to a server. "S:" indicates lines sent by the server to the client.

実施例では、「C:」はサーバに接続されているクライアントから送信されたラインを示します。 「S:」はサーバからクライアントに送られた行を示します。

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].

この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はRFC 2119 [RFC2119]に記載されているように解釈されます。

2. New ESEARCH Command

Arguments: OPTIONAL source options OPTIONAL result options OPTIONAL charset specification (see [RFC2978]) searching criteria (one or more)


Responses: REQUIRED untagged response: ESEARCH


Result: OK -- search completed NO -- error: cannot search that charset or criteria BAD -- command unknown or arguments invalid

結果:OK - 検索がNOを完了 - エラー:BADその文字セットまたは基準を検索することはできません - 無効なコマンド不明または引数

This section defines a new ESEARCH command, which works similarly to the UID SEARCH command described in Section 2.6.1 of [RFC4466] (initially described in Section 6.4.4 of [RFC3501] and extended by [RFC4731]).

このセクションでは、(最初​​に[RFC3501]のセクション6.4.4に記載し、[RFC4731]によって拡張)[RFC4466]のセクション2.6.1に記載のUID SEARCHコマンドと同様に機能新しいESEARCHコマンドを定義します。

The ESEARCH command further extends searching by allowing for optional source and result options. This document does not define any new result options (see Section 3.1 of [RFC4731]). A server that supports this extension includes "MULTISEARCH" in its IMAP capability string.


Because there has been confusion about this, it is worth pointing out that with ESEARCH, as with *any* SEARCH or UID SEARCH command, it MUST NOT be considered an error if the search terms include a range of message numbers that extends (or, in fact, starts) beyond the end of the mailbox. For example, a client might want to establish a rolling window through the search results this way:

このことについて混乱があったので、それは検索用語が延びて(またはメッセージ番号の範囲を含む場合ESEARCHで、任意の* SEARCHまたはUID SEARCHコマンド*のように、それは誤りと考えてはならないことを、指摘する価値があります実際には、メールボックスの端部を越えて)を開始します。例えば、クライアントが検索結果をこのようにローリング・ウィンドウを確立することがあります:

C: tag1 UID ESEARCH FROM "frobozz" 1:100

C:TAG1 UID ESEARCH "frobozz" 1 FROM:100

...followed later by this:


C: tag1 UID ESEARCH FROM "frobozz" 101:200

C:TAG1 UID ESEARCH "frobozz" 101 FROM:200

...and so on. This tells the server to match only the first hundred messages in the mailbox the first time, the second hundred the second time, etc. In fact, it might likely allow the server to optimize the search significantly. In the above example, whether the mailbox contains 50 or 150 or 250 messages, neither of the search commands shown will result in an error. It is up to the client to know when to stop moving its search window.


2.1. The ESEARCH Response
2.1. ESEARCHレスポンス

In response to an ESEARCH command, the server MUST return ESEARCH responses [RFC4731] (that is, not SEARCH responses). Because message numbers are not useful for mailboxes that are not selected, the responses MUST contain information about UIDs, not message numbers. This is true even if the source options specify that only the selected mailbox be searched.


Presence of a source option in the absence of a result option implies the "ALL" result option (see Section 3.1 of [RFC4731]). Note that this is not the same as the result from the SEARCH command described in the IMAP base protocol [RFC3501].


Source options describe which mailboxes must be searched for messages. An ESEARCH command with source options does not affect which mailbox, if any, is currently selected, regardless of which mailboxes are searched.


For each mailbox satisfying the source options, a single ESEARCH response MUST be returned if any messages in that mailbox match the search criteria. An ESEARCH response MUST NOT be returned for mailboxes that contain no matching messages. This is true even when result options such as MIN, MAX, and COUNT are specified (see Section 3.1 of [RFC4731]), and the values returned (lowest UID matched, highest UID matched, and number of messages matched, respectively) apply to the mailbox reported in that ESEARCH response.

そのメールボックス内のすべてのメッセージは、検索条件に一致する場合は、ソースオプションを満たす各メールボックスについて、単一ESEARCH応答が返されなければなりません。 ESEARCH応答が一致するメッセージが含まれていないメールボックスに返されてはなりません。そのようなMIN、MAX、およびCOUNTなどの結果オプションが指定されている場合でも、これが真であるに適用([RFC4731]のセクション3.1を参照)、および値(それぞれ、最低UID一致し、最高UIDが一致し、一致したメッセージの数)を返しますそのESEARCH応答で報告されたメールボックス。

Note that it is possible for an ESEARCH command to return *no* untagged responses (no ESEARCH responses at all), in the case that there are no matches to the search in any of the mailboxes that satisfy the source options. Clients can detect this situation by finding the tagged OK response without having received any matching untagged ESEARCH responses.

場合には*タグなしの応答(全くESEARCH応答)は、ソースオプションを満たすのメールボックスのいずれかでの検索に一致がないこと* ESEARCHコマンドが返すすることが可能であることに注意してください。クライアントは、任意のマッチングタグなしESEARCH応答を受けなくても、タグ付きOK応答を見つけることによって、この状況を検出することができます。

Each ESEARCH response MUST contain the MAILBOX, TAG, and UIDVALIDITY correlators. Correlators allow clients to issue several ESEARCH commands at once (pipelined). If the SEARCHRES [RFC5182] extension is used in an ESEARCH command, that ESEARCH command MUST be executed by the server after all previous SEARCH/ESEARCH commands have completed and before any subsequent SEARCH/ESEARCH commands are executed. The server MAY perform consecutive ESEARCH commands in parallel as long as none of them use the SEARCHRES extension.

各ESEARCH応答は、メールボックス、TAG、およびUIDVALIDITY相関器を含まなければなりません。相関器は、クライアントが複数のESEARCHが一度に(パイプライン化)コマンドを発行することができます。 SEARCHRES [RFC5182]拡張子がESEARCHコマンドで使用されている場合は、すべての前の検索/ ESEARCHコマンドが完了した後、そのESEARCHコマンドは、サーバーで実行されなければならないし、任意の後続の検索の前に/ ESEARCHコマンドが実行されます。サーバーは限りそれらのどれもSEARCHRES拡張機能を使用しないように並列に連続しESEARCHのコマンドを実行してもよいです。

2.2. Source Options: Specifying Mailboxes to Search
2.2. ソースオプション:指定のメールボックス検索します

The source options, if present, MUST contain a mailbox specifier as defined in the IMAP NOTIFY extension [RFC5465], Section 6 (using the "filter-mailboxes" ABNF item), with the following differences:


1. The "selected-delayed" specifier is not valid here.

2. A "subtree-one" specifier is added. The "subtree" specifier results in a search of the specified mailbox and all selectable mailboxes that are subordinate to it, through an indefinitely deep hierarchy. The "subtree-one" specifier results in a search of the specified mailbox and all selectable child mailboxes, one hierarchy level down.

2. A「サブツリー・ワン」指定子を添加します。指定したメールボックスの検索では、「サブツリー」指定子結果と無限に深い階層を、それに従属するすべてのメールボックス選択可能。指定したメールボックスの検索では、「サブツリー-1」指定子結果とすべての選択可能な子メールボックス、1つの階層下のレベル。

If "subtree" is specified, the server MUST defend against loops in the hierarchy (for example, those caused by recursive file-system links within the message store). The server SHOULD do this by keeping track of the mailboxes that have been searched, and terminating the hierarchy traversal when a repeat is found. If it cannot do that, it MAY do it by limiting the hierarchy depth.


If the source options are not present, the value "selected" is assumed -- that is, only the currently selected mailbox is searched.

ソースオプションが存在しない場合は、「選択」の値が想定される - つまり、唯一の現在選択されているメールボックスが検索されます。

The "personal" source option is a particularly convenient way to search all of the current user's mailboxes. Note that there is no way to use wildcard characters to search all mailboxes; the "mailboxes" source option does not do wildcard expansion.

「個人的な」ソースオプションは、現在のユーザーのメールボックスのすべてを検索する特に便利な方法です。すべてのメールボックスを検索するには、ワイルドカード文字を使用する方法がないことに注意してください。 「メールボックス」のソースオプションは、ワイルドカードの展開を行いません。

If the source options include (or default to) "selected", the IMAP session MUST be in "selected" state. If the source options specify other mailboxes and NOT "selected", then the IMAP session MUST be in either "selected" or "authenticated" state. If the session is not in a correct state, the ESEARCH command MUST return a "BAD" result.


If the server supports the SEARCHRES [RFC5182] extension, then the "SAVE" result option is valid *only* if "selected" is specified or defaulted as the sole mailbox to be searched. If any source option other than "selected" is specified, the ESEARCH command MUST return a "BAD" result.

サーバがSEARCHRES [RFC5182]の拡張をサポートしている場合は、「SAVE」の結果オプションは、唯一のメールボックスが検索されるように指定またはデフォルト設定され、「選択」のみ*場合*有効です。 「選択」以外の任意のソースオプションを指定した場合、ESEARCHコマンドが「BAD」の結果を返さなければなりません。

If the server supports the CONTEXT=SEARCH and/or CONTEXT=SORT extension [RFC5267], then the following additional rules apply:

サーバがCONTEXT = SEARCHおよび/またはCONTEXT = SORT拡張[RFC5267]をサポートしている場合は、次の追加規則が適用されます。

o The CONTEXT return option (Section 4.2 of [RFC5267]) can be used with an ESEARCH command.

O CONTEXTリターンオプションESEARCHコマンドで使用することができる([RFC5267]のセクション4.2)。

o If the UPDATE return option is used (Section 4.3 of [RFC5267]), it MUST apply ONLY to the currently selected mailbox. If UPDATE is used and there is no mailbox currently selected, the ESEARCH command MUST return a "BAD" result.

UPDATEリターンオプションは([RFC5267]の4.3節)で使用されている場合は、O、それだけで現在選択されているメールボックスに適用する必要があります。 UPDATEを使用して、現在選択されていないメールボックスが存在していない場合は、ESEARCHコマンドが「BAD」の結果を返さなければなりません。

o The PARTIAL search return option (Section 4.4 of [RFC5267]) can be used and applies to each mailbox searched by the ESEARCH command.


If the server supports the Access Control List (ACL) [RFC4314] extension, then the logged-in user is required to have the "r" right for each mailbox she wants to search. In addition, any mailboxes that are not explicitly named (accessed through "personal" or "subtree", for example) are required to have the "l" right. Mailboxes matching the source options for which the logged-in user lacks sufficient rights MUST be ignored by the ESEARCH command processing. In particular, ESEARCH responses MUST NOT be returned for those mailboxes.


3. Examples

In the following example, note that two ESEARCH commands are pipelined, and that the server is running them in parallel, interleaving a response to the second search amid the responses to the first (watch the tags).


C: tag1 ESEARCH IN (mailboxes "folder1" subtree "folder2") unseen C: tag2 ESEARCH IN (mailboxes "folder1" subtree-one "folder2") subject "chad" S: * ESEARCH (TAG "tag1" MAILBOX "folder1" UIDVALIDITY 1) UID ALL 4001,4003,4005,4007,4009

C:TAG1 ESEARCH IN(メールボックス "のfolder1" サブツリー "フォルダ2")目に見えないC:TAG2 ESEARCH IN(メールボックス "のfolder1" サブツリーオン "フォルダ2")被験者 "チャド" S * ESEARCH(TAG "TAG1" メールボックス "のfolder1" UIDVALIDITY 1)UID ALL 4001,4003,4005,4007,4009

S: * ESEARCH (TAG "tag2" MAILBOX "folder1" UIDVALIDITY 1) UID ALL 3001:3004,3788 S: * ESEARCH (TAG "tag1" MAILBOX "folder2/banana" UIDVALIDITY 503) UID ALL 3002,4004 S: * ESEARCH (TAG "tag1" MAILBOX "folder2/peach" UIDVALIDITY 3) UID ALL 921691 S: tag1 OK done S: * ESEARCH (TAG "tag2" MAILBOX "folder2/salmon" UIDVALIDITY 1111111) UID ALL 50003,50006,50009,50012 S: tag2 OK done

S:* ESEARCH(TAG "TAG2" MAILBOX "folder1の" UIDVALIDITY 1)UID ALL 3001:3004,3788 S:* ESEARCH(TAG "TAG1" MAILBOX "フォルダ2 /バナナ" UIDVALIDITY 503)UID ALL 3002,4004 S:* ESEARCH (TAG "TAG1" MAILBOX "フォルダ2 /桃" UIDVALIDITY 3)UID ALL 921691 S:S行わTAG1のOK:* ESEARCH(TAG "TAG2" MAILBOX "フォルダ2 /サーモン" UIDVALIDITY 1111111)UID ALL 50003,50006,50009,50012 S :完了TAG2のOK

4. Formal Syntax

The following syntax specification uses the Augmented Backus-Naur Form (ABNF) as described in [RFC5234]. Terms not defined here are taken from [RFC3501], [RFC5465], or [RFC4466].


command-auth =/ esearch ; Update definition from IMAP base [RFC3501]. ; Add new "esearch" command.

コマンド-AUTH = / esearch。 IMAPベース[RFC3501]の定義を更新します。 ;新しい「esearch」コマンドを追加します。

command-select =/ esearch ; Update definition from IMAP base [RFC3501]. ; Add new "esearch" command.

コマンド選択= / esearch。 IMAPベース[RFC3501]の定義を更新します。 ;新しい「esearch」コマンドを追加します。

filter-mailboxes-other =/ ("subtree-one" SP one-or-more-mailbox) ; Update definition from IMAP Notify [RFC5465]. ; Add new "subtree-one" selector.

フィルタ・メールボックス・他= /(「サブツリー・ワン」SP一又は、それ以上メールボックス)。 IMAPからの更新定義は、[RFC5465]を通知します。 ;新しい「サブツリー-1」のセレクタを追加します。

filter-mailboxes-selected = "selected" ; Update definition from IMAP Notify [RFC5465]. ; We forbid the use of "selected-delayed".

=「選択」フィルタメールボックス選択。 IMAPからの更新定義は、[RFC5465]を通知します。 ;私たちは、「選択遅延」の使用を禁止しています。

one-correlator = ("TAG" SP tag-string) / ("MAILBOX" SP astring) / ("UIDVALIDITY" SP nz-number) ; Each correlator MUST appear exactly once.

一相関=( "TAG" SPタグの文字列)/( "メールボックス" のSPのAString)/( "UIDVALIDITY" SP NZ-数)。各相関器は正確に一度出現しなければなりません。

scope-option = scope-option-name [SP scope-option-value] ; No options defined here. Syntax for future extensions.


scope-option-name = tagged-ext-label ; No options defined here. Syntax for future extensions.


scope-option-value = tagged-ext-val ; No options defined here. Syntax for future extensions.


scope-options = scope-option *(SP scope-option) ; A given option may only appear once. ; No options defined here. Syntax for future extensions.

スコープオプション=スコープ・オプション*(SPスコープ・オプション)。与えられたオプションは一度だけ表示されることがあります。 ;ここで定義されたオプションなし。将来の拡張のための構文。

esearch = "ESEARCH" [SP esearch-source-opts] [SP search-return-opts] SP search-program

esearch = "ESEARCH" [SPのesearchソース-optsの] [SP検索リターン-optsの] SP検索プログラム

search-correlator = SP "(" one-correlator *(SP one-correlator) ")" ; Updates definition in IMAP4 ABNF [RFC4466].

検索相関器= SP "(" 1-相関器*(SP 1相関器) ")"。 IMAP4 ABNF [RFC4466]でアップデートの定義。

esearch-source-opts = "IN" SP "(" source-mbox [SP "(" scope-options ")"] ")"

esearchソース-OPTS = "IN" SP "(" ソースMBOX [SP "(" スコープオプション ")"] ")"

source-mbox = filter-mailboxes *(SP filter-mailboxes) ; "filter-mailboxes" is defined in IMAP Notify [RFC5465]. ; See updated definition of filter-mailboxes-other, above. ; See updated definition of filter-mailboxes-selected, above.

ソースMBOX =フィルタメールボックス*(SPフィルタ・メールボックス)。 「フィルタ・メールボックスは」[RFC5465]を通知IMAPで定義されています。 ;上記、フィルタ - メールボックス - その他の更新定義を参照してください。 ;フィルタ - メールボックスが選択し、上記の更新定義を参照してください。

5. Security Considerations

This new IMAP ESEARCH command allows a single command to search many mailboxes at once. On the one hand, a client could do that by sending many IMAP SEARCH commands. On the other hand, this makes it easier for a client to overwork a server, by sending a single command that results in an expensive search of tens of thousands of mailboxes. Server implementations need to be aware of that, and provide mechanisms that prevent a client from adversely affecting other users. Limitations on the number of mailboxes that may be searched in one command, and/or on the server resources that will be devoted to responding to a single client, are reasonable limitations for an implementation to impose.

この新しいIMAPのESEARCHのコマンドは、1つのコマンドは、一度に多数のメールボックスを検索することができます。一方では、クライアントは多くのIMAPの検索コマンドを送信することによって、それを行うことができます。一方、これは数十のメールボックスの何千ものの、高価な検索結果に単一のコマンドを送信することにより、サーバーを酷使するクライアントのためにそれが容易になります。サーバ実装はそれを認識して、そして悪他のユーザーに影響を与えることからクライアントを防ぐメカニズムを提供する必要があります。 1つのコマンドで検索することができるメールボックスの数に、および/または単一のクライアントへの対応に専念されるサーバリソースの制限は、課す実装のための合理的な制限があります。

Implementations MUST, of course, apply access controls appropriately, limiting a user's access to ESEARCH in the same way its access is limited for any other IMAP commands. This extension has no data-access risks beyond what may be there in the unextended IMAP implementation.


Mailboxes matching the source options for which the logged-in user lacks sufficient rights MUST be ignored by the ESEARCH command processing (see the paragraph about this in Section 2.2). In particular, any attempt to distinguish insufficient access from non-existent mailboxes may expose information about the mailbox hierarchy that isn't otherwise available to the client.


If "subtree" is specified, the server MUST defend against loops in the hierarchy (see the paragraph about this in Section 2.2).


6. IANA Considerations
6. IANAの考慮事項

IMAP4 capabilities are registered by publishing a Standards Track or IESG-approved Experimental RFC. The "IMAP 4 Capabilities" registry is currently located here:

IMAP4機能は標準化過程かIESGが承認した実験的RFCを公開することにより、登録されています。 「IMAP 4つの機能」レジストリは、現在の場所にあります。


This document defines the IMAP capability "MULTISEARCH", and IANA has added it to the registry.


7. Acknowledgements

The authors gratefully acknowledge feedback provided by Timo Sirainen, Peter Coates, and Arnt Gulbrandsen.

作者は感謝しティモ・シレーヌン、ピーター・コーツ、およびARNT Gulbrandsenのによって提供されるフィードバックを認めます。

8. Normative References

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。

[RFC2978] Freed, N. and J. Postel, "IANA Charset Registration Procedures", BCP 19, RFC 2978, October 2000.

[RFC2978]フリード、N.とJ.ポステル、 "IANA文字セット登録手順"、BCP 19、RFC 2978、2000年10月。

[RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", RFC 3501, March 2003.

[RFC3501]のCrispin、M.、 "インターネットメッセージアクセスプロトコル - VERSION 4rev1"、RFC 3501、2003年3月。

[RFC4314] Melnikov, A., "IMAP4 Access Control List (ACL) Extension", RFC 4314, December 2005.

[RFC4314]メルニコフ、A.、 "IMAP4アクセス制御リスト(ACL)拡張"、RFC 4314、2005年12月。

[RFC4466] Melnikov, A. and C. Daboo, "Collected Extensions to IMAP4 ABNF", RFC 4466, April 2006.

[RFC4466]メルニコフ、A.およびC. Daboo、 "IMAP4 ABNFに収集された拡張機能"、RFC 4466、2006年4月。

[RFC4731] Melnikov, A. and D. Cridland, "IMAP4 Extension to SEARCH Command for Controlling What Kind of Information Is Returned", RFC 4731, November 2006.

[RFC4731]メルニコフ、A.とD. Cridland、RFC 4731、2006年11月の「IMAP4拡張は、情報の種類が返されるどのような制御するためのコマンドを検索するために」。

[RFC5182] Melnikov, A., "IMAP Extension for Referencing the Last SEARCH Result", RFC 5182, March 2008.

[RFC5182]メルニコフ、A.、 "最後の検索結果を参照するためのIMAP拡張"、RFC 5182、2008年3月。

[RFC5234] Crocker, D., Ed., and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.

"構文仕様のための増大しているBNF:ABNF" [RFC5234]クロッカー、D.、エド、およびP. Overell、。、STD 68、RFC 5234、2008年1月。

[RFC5267] Cridland, D. and C. King, "Contexts for IMAP4", RFC 5267, July 2008.

[RFC5267] Cridland、D.およびC.王、 "IMAP4のためのコンテキスト"、RFC 5267、2008年7月。

[RFC5465] Gulbrandsen, A., King, C., and A. Melnikov, "The IMAP NOTIFY Extension", RFC 5465, February 2009.

[RFC5465] Gulbrandsenの、A.、キング、C.、およびA.メルニコフ、 "IMAPエクステンションをNOTIFY"、RFC 5465、2009年2月。

Authors' Addresses


Barry Leiba Huawei Technologies


Phone: +1 646 827 0648 EMail: URI:

電話:+1 646 827 0648 Eメール URI:

Alexey Melnikov Isode Limited 5 Castle Business Village 36 Station Road Hampton, Middlesex TW12 2BX UK

アレクセイ・メルニコフISODE限定5キャッスルビジネス村の36の駅道ハンプトン、ミドルTW12 2BX英国

EMail: URI:

電子メール URI: