rfc4466.txt

广泛使用的邮件服务器！同时

   Arguments:  message set
               OPTIONAL store modifiers
               message data item name
               value for message data item

   Responses:  untagged responses: FETCH

   Result:     OK - store completed
               NO - store error: cannot store that data
               BAD - command unknown or arguments invalid

   This document extends the syntax of the STORE and UID STORE commands
   (see section 6.4.6 of [IMAP4]) to include optional STORE modifiers.
   No store modifiers are defined in this document.




Melnikov & Daboo            Standards Track                     [Page 6]

RFC 4466           Collected Extensions to IMAP4 ABNF         April 2006


   The order of individual modifiers is arbitrary.  Each modifier is an
   attribute/value pair.  A modifier value is optional and may consist
   of atoms and/or strings and/or lists in a specific order.  If the
   modifier value is present, it always appears in parentheses (*).  Any
   modifiers not defined by extensions that the server supports must be
   rejected with a BAD response.

   (*) - if a modifier has a mandatory value, which can always be
   represented as a number or a sequence-set, the modifier value does
   not need the enclosing ().  See ABNF for more details.

2.6.  Extensions to SEARCH Command

2.6.1.  Extended SEARCH Command

   Arguments:  OPTIONAL result specifier
               OPTIONAL [CHARSET] specification
               searching criteria (one or more)

   Responses:  REQUIRED untagged response: SEARCH (*)

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

   This section updates definition of the SEARCH command described in
   section 6.4.4 of [IMAP4].

   The SEARCH command is extended to allow for result options.  This
   document does not define any result options.

   The order of individual options is arbitrary.  Individual options may
   contain parameters enclosed in parentheses (**).  If an option has
   parameters, they consist of atoms and/or strings and/or lists in a
   specific order.  Any options not defined by extensions that the
   server supports must be rejected with a BAD response.

   (*) - An extension to the SEARCH command may require another untagged
   response, or no untagged response to be returned.  Section 2.6.2
   defines a new ESEARCH untagged response that replaces the SEARCH
   untagged response.  Note that for a given extended SEARCH command the
   SEARCH and ESEARCH responses SHOULD be mutually exclusive, i.e., only
   one of them should be returned.

   (**) - if an option has a mandatory parameter, which can always be
   represented as a number or a sequence-set, the option parameter does
   not need the enclosing ().  See ABNF for more details.



Melnikov & Daboo            Standards Track                     [Page 7]

RFC 4466           Collected Extensions to IMAP4 ABNF         April 2006


2.6.2.  ESEARCH untagged response

   Contents:   one or more search-return-data pairs

   The ESEARCH response SHOULD be sent as a result of an extended SEARCH
   or UID SEARCH command specified in section 2.6.1.

   The ESEARCH response starts with an optional search correlator.  If
   it is missing, then the response was not caused by a particular IMAP
   command, whereas if it is present, it contains the tag of the command
   that caused the response to be returned.

   The search correlator is followed by an optional UID indicator.  If
   this indicator is present, all data in the ESEARCH response refers to
   UIDs, otherwise all returned data refers to message numbers.

   The rest of the ESEARCH response contains one or more search data
   pairs.  Each pair starts with unique return item name, followed by a
   space and the corresponding data.  Search data pairs may be returned
   in any order.  Unless specified otherwise by an extension, any return
   item name SHOULD appear only once in an ESEARCH response.

   Example:    S: * ESEARCH UID COUNT 5 ALL 4:19,21,28

   Example:    S: * ESEARCH (TAG "a567") UID COUNT 5 ALL 4:19,21,28

   Example:    S: * ESEARCH COUNT 5 ALL 1:17,21

2.7.  Extensions to APPEND Command

   The IMAP BINARY extension [BINARY] extends the APPEND command to
   allow a client to append data containing NULs by using the <literal8>
   syntax.  The ABNF was rewritten to allow for easier extensibility by
   IMAP extensions.  This document hasn't specified any semantical
   changes to the [BINARY] extension.

   In addition, the non-terminal "literal8" defined in [BINARY] got
   extended to allow for non-synchronizing literals if both [BINARY] and
   [LITERAL+] extensions are supported by the server.

   The IMAP MULTIAPPEND extension [MULTIAPPEND] extends the APPEND
   command to allow a client to append multiple messages atomically.
   This document defines a common syntax for the APPEND command that
   takes into consideration syntactic extensions defined by both
   [BINARY] and [MULTIAPPEND] extensions.






Melnikov & Daboo            Standards Track                     [Page 8]

RFC 4466           Collected Extensions to IMAP4 ABNF         April 2006


3.  Formal Syntax

   The following syntax specification uses the Augmented Backus-Naur
   Form (ABNF) notation as specified in [ABNF].

   Non-terminals referenced but not defined below are as defined by
   [IMAP4].

   Except as noted otherwise, all alphabetic characters are case-
   insensitive.  The use of uppercase or lowercase characters to define
   token strings is for editorial clarity only.  Implementations MUST
   accept these strings in a case-insensitive fashion.

   append          = "APPEND" SP mailbox 1*append-message
                     ;; only a single append-message may appear
                     ;; if MULTIAPPEND [MULTIAPPEND] capability
                     ;; is not present

   append-message  = append-opts SP append-data

   append-ext      = append-ext-name SP append-ext-value
                     ;; This non-terminal define extensions to
                     ;; to message metadata.

   append-ext-name = tagged-ext-label

   append-ext-value= tagged-ext-val
                     ;; This non-terminal shows recommended syntax
                     ;; for future extensions.


   append-data     = literal / literal8 / append-data-ext

   append-data-ext = tagged-ext
                     ;; This non-terminal shows recommended syntax
                     ;; for future extensions,
                     ;; i.e., a mandatory label followed
                     ;; by parameters.

   append-opts     = [SP flag-list] [SP date-time] *(SP append-ext)
                     ;; message metadata

   charset         = atom / quoted
                     ;; Exact syntax is defined in [CHARSET].

   create          = "CREATE" SP mailbox
                     [create-params]
                     ;; Use of INBOX gives a NO error.



Melnikov & Daboo            Standards Track                     [Page 9]

RFC 4466           Collected Extensions to IMAP4 ABNF         April 2006


   create-params   = SP "(" create-param *( SP create-param) ")"

   create-param-name = tagged-ext-label

   create-param      = create-param-name [SP create-param-value]

   create-param-value= tagged-ext-val
                     ;; This non-terminal shows recommended syntax
                     ;; for future extensions.


   esearch-response  = "ESEARCH" [search-correlator] [SP "UID"]
                        *(SP search-return-data)
                      ;; Note that SEARCH and ESEARCH responses
                      ;; SHOULD be mutually exclusive,
                      ;; i.e., only one of the response types
                      ;; should be
                      ;; returned as a result of a command.


   examine         = "EXAMINE" SP mailbox [select-params]
                     ;; modifies the original IMAP EXAMINE command
                     ;; to accept optional parameters

   fetch           = "FETCH" SP sequence-set SP ("ALL" / "FULL" /
                     "FAST" / fetch-att /
                     "(" fetch-att *(SP fetch-att) ")")
                     [fetch-modifiers]
                     ;; modifies the original IMAP4 FETCH command to
                     ;; accept optional modifiers

   fetch-modifiers = SP "(" fetch-modifier *(SP fetch-modifier) ")"

   fetch-modifier  = fetch-modifier-name [ SP fetch-modif-params ]

   fetch-modif-params  = tagged-ext-val
                     ;; This non-terminal shows recommended syntax
                     ;; for future extensions.

   fetch-modifier-name = tagged-ext-label

   literal8        = "~{" number ["+"] "}" CRLF *OCTET
                      ;; A string that might contain NULs.
                      ;; <number> represents the number of OCTETs
                      ;; in the response string.
                      ;; The "+" is only allowed when both LITERAL+ and
                      ;; BINARY extensions are supported by the server.




Melnikov & Daboo            Standards Track                    [Page 10]

RFC 4466           Collected Extensions to IMAP4 ABNF         April 2006


   mailbox-data      =/ Namespace-Response /
                        esearch-response

   Namespace         = nil / "(" 1*Namespace-Descr ")"

   Namespace-Command = "NAMESPACE"

   Namespace-Descr   = "(" string SP
                          (DQUOTE QUOTED-CHAR DQUOTE / nil)
                           *(Namespace-Response-Extension) ")"

   Namespace-Response-Extension = SP string SP
                     "(" string *(SP string) ")"

   Namespace-Response = "NAMESPACE" SP Namespace
                        SP Namespace SP Namespace
         ;; This response is currently only allowed
         ;; if the IMAP server supports [NAMESPACE].
         ;; The first Namespace is the Personal Namespace(s)
         ;; The second Namespace is the Other Users' Namespace(s)
         ;; The third Namespace is the Shared Namespace(s)

   rename          = "RENAME" SP mailbox SP mailbox
                     [rename-params]
                     ;; Use of INBOX as a destination gives
                     ;; a NO error, unless rename-params
                     ;; is not empty.

   rename-params     = SP "(" rename-param *( SP rename-param) ")"

   rename-param      = rename-param-name [SP rename-param-value]

   rename-param-name = tagged-ext-label

   rename-param-value= tagged-ext-val
                     ;; This non-terminal shows recommended syntax
                     ;; for future extensions.


   response-data   = "*" SP response-payload CRLF

   response-payload= resp-cond-state / resp-cond-bye /
                     mailbox-data / message-data / capability-data

   search          = "SEARCH" [search-return-opts]
                     SP search-program

   search-correlator  = SP "(" "TAG" SP tag-string ")"



Melnikov & Daboo            Standards Track                    [Page 11]

RFC 4466           Collected Extensions to IMAP4 ABNF         April 2006


   search-program     = ["CHARSET" SP charset SP]
                        search-key *(SP search-key)
                        ;; CHARSET argument to SEARCH MUST be
                        ;; registered with IANA.

   search-return-data = search-modifier-name SP search-return-value
                        ;; Note that not every SEARCH return option
                        ;; is required to have the corresponding
                        ;; ESEARCH return data.

   search-return-opts = SP "RETURN" SP "(" [search-return-opt
                        *(SP search-return-opt)] ")"

   search-return-opt = search-modifier-name [SP search-mod-params]

   search-return-value = tagged-ext-val