rfc4466.txt

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

                        ;; Data for the returned search option.
                        ;; A single "nz-number"/"number" value
                        ;; can be returned as an atom (i.e., without
                        ;; quoting).  A sequence-set can be returned
                        ;; as an atom as well.

   search-modifier-name = tagged-ext-label

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


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

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

   select-param    = select-param-name [SP select-param-value]
                     ;; a parameter to SELECT may contain one or
                     ;; more atoms and/or strings and/or lists.

   select-param-name= tagged-ext-label

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


   status-att-list = status-att-val *(SP status-att-val)
                     ;; Redefines status-att-list from RFC 3501.



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


                     ;; status-att-val is defined in RFC 3501 errata

   status-att-val  = ("MESSAGES" SP number) /
                     ("RECENT" SP number) /
                     ("UIDNEXT" SP nz-number) /
                     ("UIDVALIDITY" SP nz-number) /
                     ("UNSEEN" SP number)
                     ;; Extensions to the STATUS responses
                     ;; should extend this production.
                     ;; Extensions should use the generic
                     ;; syntax defined by tagged-ext.

   store           = "STORE" SP sequence-set [store-modifiers]
                     SP store-att-flags
                     ;; extend [IMAP4] STORE command syntax
                     ;; to allow for optional store-modifiers

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

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

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

   store-modifier-name = tagged-ext-label

   tag-string         = string
                        ;; tag of the command that caused
                        ;; the ESEARCH response, sent as
                        ;; a string.

   tagged-ext          = tagged-ext-label SP tagged-ext-val
                          ;; recommended overarching syntax for
                          ;; extensions

   tagged-ext-label    = tagged-label-fchar *tagged-label-char
                         ;; Is a valid RFC 3501 "atom".

   tagged-label-fchar  = ALPHA / "-" / "_" / "."

   tagged-label-char   = tagged-label-fchar / DIGIT / ":"








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


   tagged-ext-comp     = astring /
                         tagged-ext-comp *(SP tagged-ext-comp) /
                         "(" tagged-ext-comp ")"
                          ;; Extensions that follow this general
                          ;; syntax should use nstring instead of
                          ;; astring when appropriate in the context
                          ;; of the extension.
                          ;; Note that a message set or a "number"
                          ;; can always be represented as an "atom".
                          ;; An URL should be represented as
                          ;; a "quoted" string.

   tagged-ext-simple   = sequence-set / number

   tagged-ext-val      = tagged-ext-simple /
                         "(" [tagged-ext-comp] ")"

4.  Security Considerations

   This document updates ABNF in RFCs 2088, 2342, 3501, 3502, and 3516.
   The updated documents must be consulted for security considerations
   for the extensions that they define.

   As a protocol gets more complex, parser bugs become more common
   including buffer overflow, denial of service, and other common
   security coding errors.  To the extent that this document makes the
   parser more complex, it makes this situation worse.  To the extent
   that this document makes the parser more consistent and thus simpler,
   the situation is improved.  The impact will depend on how many
   deployed IMAP extensions are consistent with this document.
   Implementers are encouraged to take care of these issues when
   extending existing implementations.  Future IMAP extensions should
   strive for consistency and simplicity to the greatest extent
   possible.

   Extensions to IMAP commands that are permitted in NOT AUTHENTICATED
   state are more sensitive to these security issues due to the larger
   possible attacker community prior to authentication, and the fact
   that some IMAP servers run with elevated privileges in that state.
   This document does not extend any commands permitted in NOT
   AUTHENTICATED state.  Future IMAP extensions to commands permitted in
   NOT AUTHENTICATED state should favor simplicity over consistency or
   extensibility.








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


5.  Normative References

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

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

   [ABNF]        Crocker, D., Ed., and P. Overell, "Augmented BNF for
                 Syntax Specifications: ABNF", RFC 4234, October 2005.

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

   [MULTIAPPEND] Crispin, M., "Internet Message Access Protocol (IMAP) -
                 MULTIAPPEND Extension", RFC 3502, March 2003.

   [NAMESPACE]   Gahrns, M. and C. Newman, "IMAP4 Namespace", RFC 2342,
                 May 1998.

   [LITERAL+]    Myers, J., "IMAP4 non-synchronizing literals", RFC
                 2088, January 1997.

   [BINARY]      Nerenberg, L., "IMAP4 Binary Content Extension", RFC
                 3516, April 2003.

6.  Acknowledgements

   This documents is based on ideas proposed by Pete Resnick, Mark
   Crispin, Ken Murchison, Philip Guenther, Randall Gellens, and Lyndon
   Nerenberg.

   However, all errors and omissions must be attributed to the authors
   of the document.

   Thanks to Philip Guenther, Dave Cridland, Mark Crispin, Chris Newman,
   Elwyn Davies, and Barry Leiba for comments and corrections.

   literal8 syntax was taken from RFC 3516.












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


Authors' Addresses

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

   EMail: [e-mail]


   Cyrus Daboo

   EMail: [e-mail]




































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


Full Copyright Statement

   Copyright (C) The Internet Society (2006).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   [e-mail].

Acknowledgement

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).







Melnikov & Daboo            Standards Track                    [Page 17]