Section 11. Security Considerations

IMAP4rev2 protocol transactions, including electronic mail data, are
   sent in the clear over the network, exposing them to possible
   eavesdropping and manipulation unless protection is negotiated.  This
   can be accomplished by use of the Implicit TLS port, the STARTTLS
   command, negotiated confidentiality protection in the AUTHENTICATE
   command, or some other protection mechanism.
11.1.  TLS-Related Security Considerations
   This section applies to use of both the STARTTLS command and the
   Implicit TLS port.
   IMAP client and server implementations MUST comply with relevant TLS
   recommendations from [RFC8314].  If recommendations/requirements in
   this document conflict with recommendations from [RFC8314], for
   example in regards to TLS ciphersuites, recommendations from this
   document take precedence.
   Clients and servers MUST implement TLS 1.2 [TLS-1.2] or newer.  Use
   of TLS 1.3 [TLS-1.3] is RECOMMENDED.  TLS 1.2 may be used only in
   cases where the other party has not yet implemented TLS 1.3.
   Additionally, when using TLS 1.2, IMAP implementations MUST implement
   the TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 cipher suite.  This is
   important as it ensures that any two compliant implementations can be
   configured to interoperate.  Other TLS cipher suites recommended in
   RFC 7525 [RFC7525] are RECOMMENDED:
   TLS_DHE_RSA_WITH_AES_128_GCM_SHA256,
   TLS_DHE_RSA_WITH_AES_256_GCM_SHA384, and
   TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384.  All other cipher suites are
   OPTIONAL.  Note that this is a change from Section 2.1 of [IMAP-TLS].
   The list of mandatory-to-implement TLS 1.3 cipher suites is described
   in Section 9.1 of [TLS-1.3].
   During the TLS negotiation [TLS-1.3] [TLS-1.2], the client MUST check
   its understanding of the server hostname against the server's
   identity as presented in the server Certificate message, in order to
   prevent on-path attackers attempting to masquerade as the server.
   This procedure is described in [RFC7817].
   Both the client and server MUST check the result of the STARTTLS
   command and subsequent TLS [TLS-1.3] [TLS-1.2] negotiation to see
   whether acceptable authentication and/or privacy was achieved.
11.2.  STARTTLS Command versus Use of Implicit TLS Port
   For maximum backward compatibility, the client MUST implement both
   TLS negotiation on an Implicit TLS port and TLS negotiation using the
   STARTTLS command on a cleartext port.
   The server MUST implement TLS negotiation on an Implicit TLS port.
   The server SHOULD also implement IMAP on a cleartext port.  If the
   server listens on a cleartext port, it MUST allow the STARTTLS
   command on it.
   Some site/firewall maintainers insist on TLS site-wide and prefer not
   to rely on a configuration option in each higher-level protocol.  For
   this reason, IMAP4rev2 clients SHOULD try both ports 993 and 143 (and
   both IPv4 and IPv6) concurrently by default, unless overridden by
   either user configuration or DNS SRV records [RFC6186].  A good
   algorithm for implementing such concurrent connect is described in
   [RFC8305].
11.3.  Client Handling of Unsolicited Responses Not Suitable for the
       Current Connection State
   Cleartext mail transmission (whether caused by firewall configuration
   errors that result in TLS stripping or weak security policies in
   email clients that choose not to negotiate TLS in the first place)
   can enable injection of responses that can confuse or even cause
   crashes in email clients.  The following measures are recommended to
   minimize damage from them.
   *  See Section 7.1.4 for special security considerations related to
      the PREAUTH response.
   *  Many server responses and response codes are only meaningful in
      authenticated or even selected state.  However, nothing prevents a
      server (or an on-path attacker) from sending such invalid
      responses in cleartext before STARTTLS/AUTHENTICATE commands are
      issued.  Before authentication, clients SHOULD ignore any
      responses other than CAPABILITY and server status responses
      (Section 7.1), as well as any response codes other than
      CAPABILITY.  (In particular, some email clients are known to
      incorrectly process LIST responses received before authentication,
      or FETCH responses when no mailbox is selected.)  Clients SHOULD
      ignore the ALERT response code until after TLS (whether using
      STARTTLS or TLS negotiation on an Implicit TLS port) or a SASL
      security layer with confidentiality protection has been
      successfully negotiated.  Unless explicitly allowed by an IMAP
      extension, when not in selected state, clients MUST ignore
      responses / response codes related to message and mailbox status
      such as FLAGS, EXIST, EXPUNGE, and FETCH.
11.4.  COPYUID and APPENDUID Response Codes
   The COPYUID and APPENDUID response codes return information about the
   mailbox, which may be considered sensitive if the mailbox has
   permissions set that permit the client to COPY or APPEND to the
   mailbox, but not SELECT or EXAMINE it.
   Consequently, these response codes SHOULD NOT be issued if the client
   does not have access to SELECT or EXAMINE the mailbox.
11.5.  LIST Command and Other Users' Namespace
   In response to a LIST command containing an argument of the Other
   Users' Namespace prefix, a server MUST NOT list users that have not
   granted list access to their personal mailboxes to the currently
   authenticated user.  Providing such a list could compromise security
   by potentially disclosing confidential information of who is located
   on the server or providing a starting point for a list of user
   accounts to attack.
11.6.  Use of MD5
   The BODYSTRUCTURE FETCH data item can contain the MD5 digest of the
   message body in the "body MD5" field (body-fld-md5 ABNF production).
   While MD5 is no longer considered a secure cryptographic hash
   [RFC6151], this field is used solely to expose the value of the
   Content-MD5 header field (if present in the original message), which
   is just a message integrity check and is not used for cryptographic
   purposes.  Also note that other mechanisms that provide message
   integrity checks were defined since RFC 1864 [MD5] was published and
   are now more commonly used than Content-MD5.  Two such mechanisms are
   the DKIM-Signature header field [RFC6376] and S/MIME signing
   [RFC8550] [RFC8551].
11.7.  Other Security Considerations
   A server error message for an AUTHENTICATE command that fails due to
   invalid credentials SHOULD NOT detail why the credentials are
   invalid.
   Use of the LOGIN command sends passwords in the clear.  This can be
   avoided by using the AUTHENTICATE command with a [SASL] mechanism
   that does not use plaintext passwords, by first negotiating
   encryption via STARTTLS or some other protection mechanism.
   A server implementation MUST implement a configuration that, at the
   time of authentication, requires:
   1.  The STARTTLS command has been negotiated or TLS negotiated on an
       Implicit TLS port
       OR
   2.  Some other mechanism that protects the session from password
       snooping has been provided
       OR
   3.  The following measures are in place:
       a)  The LOGINDISABLED capability is advertised, and [SASL]
           mechanisms (such as PLAIN) using plaintext passwords are NOT
           advertised in the CAPABILITY list.
           AND
       b)  The LOGIN command returns an error even if the password is
           correct
           AND
       c)  The AUTHENTICATE command returns an error with all [SASL]
           mechanisms that use plaintext passwords, even if the password
           is correct.
   A server error message for a failing LOGIN command SHOULD NOT specify
   that the user name, as opposed to the password, is invalid.
   A server SHOULD have mechanisms in place to limit or delay failed
   AUTHENTICATE/LOGIN attempts.
   A server SHOULD report any authentication failure and analyze such
   authentication failure attempts with regard to a password brute-force
   attack as well as a password spraying attack [NCSC].  Accounts with
   passwords that match well-known passwords from spraying attacks MUST
   be blocked, and users associated with such accounts must be requested
   to change their passwords.  Only a password with significant strength
   SHOULD be accepted.
   Additional security considerations are discussed in the sections that
   define the AUTHENTICATE and LOGIN commands (see Sections 6.2.2 and
   6.2.3, respectively).
12.  IANA Considerations
   IANA has updated the "Service Names and Transport Protocol Port
   Numbers" registry as follows:
   1.  Registration for TCP port 143 and the corresponding "imap"
       service name have been updated to point to this document and
       [RFC3501].
   2.  Registration for TCP port 993 and the corresponding "imaps"
       service name have been updated to point to this document,
       [RFC8314], and [RFC3501].
   3.  UDP ports 143 and 993 have both been marked as "Reserved" in the
       registry.
   Additional IANA actions are specified in the subsections that follow.
12.1.  Updates to IMAP Capabilities Registry
   IMAP4 capabilities are registered by publishing a Standards Track or
   IESG-approved Informational or Experimental RFC.  The registry is
   currently located at: <https://www.iana.org/assignments/
   imap4-capabilities>
   As this specification revises the AUTH= prefix, STARTTLS, and
   LOGINDISABLED extensions, IANA has updated registry entries for these
   3 extensions to point to this document and [RFC3501].
12.2.  GSSAPI/SASL Service Name
   GSSAPI/Kerberos/SASL service names are registered by publishing a
   Standards Track or IESG-approved Experimental RFC.  The registry is
   currently located at: <https://www.iana.org/assignments/gssapi-
   service-names>
   IANA has updated the "imap" service name previously registered in
   [RFC3501] to point to both this document and [RFC3501].
12.3.  LIST Selection Options, LIST Return Options, and LIST Extended
       Data Items
   [RFC5258] specifies IANA registration procedures for LIST selection
   options, LIST return options, and LIST extended data items.  This
   document doesn't change these registration procedures.  In
   particular, LIST selection options (Section 6.3.9.1) and LIST return
   options (Section 6.3.9.2) are registered using the procedure
   specified in Section 9 of [RFC5258] (and using the registration
   template from Section 9.3 of [RFC5258]).  LIST extended data items
   are registered using the registration template from Section 9.6 of
   [RFC5258]).
   IANA has added a reference to RFC 9051 for the "OLDNAME" LIST-
   EXTENDED extended data item entry.  This is in addition to the
   existing reference to [RFC5465].
12.4.  IMAP Mailbox Name Attributes and IMAP Response Codes
   IANA has updated the "IMAP Mailbox Name Attributes" registry to point
   to this document in addition to [RFC3501].
   IANA has updated the "IMAP Response Codes" registry to point to this
   document in addition to [RFC3501].
13.  References
13.1.  Normative References
   [ABNF]     Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
              Specifications: ABNF", STD 68, RFC 5234,
              <https://www.rfc-editor.org/info/rfc5234>.
   [BCP178]   Saint-Andre, P., Crocker, D., and M. Nottingham,
              "Deprecating the "X-" Prefix and Similar Constructs in
              <https://www.rfc-editor.org/info/bcp178>
   [CHARSET]  Freed, N. and J. Postel, "IANA Charset Registration
              Procedures", BCP 19, RFC 2978, DOI 10.17487/RFC2978,
   [DISPOSITION]
              Troost, R., Dorner, S., and K. Moore, Ed., "Communicating
              Presentation Information in Internet Messages: The
              Content-Disposition Header Field", RFC 2183,
              <https://www.rfc-editor.org/info/rfc2183>.
   [I18N-HDRS]
              Yang, A., Steele, S., and N. Freed, "Internationalized
              Email Headers", RFC 6532, DOI 10.17487/RFC6532, February
              2012, <https://www.rfc-editor.org/info/rfc6532>.
   [IMAP-IMPLEMENTATION]
              Leiba, B., "IMAP4 Implementation Recommendations",
              <https://www.rfc-editor.org/info/rfc2683>.
   [IMAP-MULTIACCESS]
              Gahrns, M., "IMAP4 Multi-Accessed Mailbox Practice",
              <https://www.rfc-editor.org/info/rfc2180>.
   [LANGUAGE-TAGS]
              Alvestrand, H., "Content Language Headers", RFC 3282,
              <https://www.rfc-editor.org/info/rfc3282>.
   [LOCATION] Palme, J., Hopmann, A., and N. Shelness, "MIME
              Encapsulation of Aggregate Documents, such as HTML
              <https://www.rfc-editor.org/info/rfc2557>.
   [MD5]      Myers, J. and M. Rose, "The Content-MD5 Header Field",
              <https://www.rfc-editor.org/info/rfc1864>.
   [MIME-HDRS]
              Moore, K., "MIME (Multipurpose Internet Mail Extensions)
              Part Three: Message Header Extensions for Non-ASCII Text",
              <https://www.rfc-editor.org/info/rfc2047>.
   [MIME-IMB] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
              Extensions (MIME) Part One: Format of Internet Message
              <https://www.rfc-editor.org/info/rfc2045>.
   [MIME-IMT] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
              Extensions (MIME) Part Two: Media Types", RFC 2046,
              <https://www.rfc-editor.org/info/rfc2046>.
   [MULTIAPPEND]
              Crispin, M., "Internet Message Access Protocol (IMAP) -
              MULTIAPPEND Extension", RFC 3502, DOI 10.17487/RFC3502,
   [NET-UNICODE]
              Klensin, J. and M. Padlipsky, "Unicode Format for Network
              <https://www.rfc-editor.org/info/rfc5198>.
   [PLAIN]    Zeilenga, K., Ed., "The PLAIN Simple Authentication and
              Security Layer (SASL) Mechanism", RFC 4616,
              <https://www.rfc-editor.org/info/rfc4616>.
   [RFC2077]  Nelson, S., Parks, C., and , "The Model Primary Content
              Type for Multipurpose Internet Mail Extensions", RFC 2077,
              <https://www.rfc-editor.org/info/rfc2077>.
   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              <https://www.rfc-editor.org/info/rfc2119>.
   [RFC2231]  Freed, N. and K. Moore, "MIME Parameter Value and Encoded
              Word Extensions: Character Sets, Languages, and
              Continuations", RFC 2231, DOI 10.17487/RFC2231, November
              1997, <https://www.rfc-editor.org/info/rfc2231>.
   [RFC3503]  Melnikov, A., "Message Disposition Notification (MDN)
              profile for Internet Message Access Protocol (IMAP)",
              <https://www.rfc-editor.org/info/rfc3503>.
   [RFC4648]  Josefsson, S., "The Base16, Base32, and Base64 Data
              <https://www.rfc-editor.org/info/rfc4648>.
   [RFC4752]  Melnikov, A., Ed., "The Kerberos V5 ("GSSAPI") Simple
              Authentication and Security Layer (SASL) Mechanism",
              <https://www.rfc-editor.org/info/rfc4752>.
   [RFC5258]  Leiba, B. and A. Melnikov, "Internet Message Access
              Protocol version 4 - LIST Command Extensions", RFC 5258,
              <https://www.rfc-editor.org/info/rfc5258>.
   [RFC5322]  Resnick, P., Ed., "Internet Message Format", RFC 5322,
              <https://www.rfc-editor.org/info/rfc5322>.
   [RFC5788]  Melnikov, A. and D. Cridland, "IMAP4 Keyword Registry",
              <https://www.rfc-editor.org/info/rfc5788>.
   [RFC7525]  Sheffer, Y., Holz, R., and P. Saint-Andre,
              "Recommendations for Secure Use of Transport Layer
              Security (TLS) and Datagram Transport Layer Security
              (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May
              2015, <https://www.rfc-editor.org/info/rfc7525>.
   [RFC7817]  Melnikov, A., "Updated Transport Layer Security (TLS)
              Server Identity Check Procedure for Email-Related
              <https://www.rfc-editor.org/info/rfc7817>.
   [RFC8081]  Lilley, C., "The "font" Top-Level Media Type", RFC 8081,
              <https://www.rfc-editor.org/info/rfc8081>.
   [RFC8098]  Hansen, T., Ed. and A. Melnikov, Ed., "Message Disposition
              Notification", STD 85, RFC 8098, DOI 10.17487/RFC8098,
   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
   [RFC8314]  Moore, K. and C. Newman, "Cleartext Considered Obsolete:
              Use of Transport Layer Security (TLS) for Email Submission
              <https://www.rfc-editor.org/info/rfc8314>.
   [SASL]     Melnikov, A., Ed. and K. Zeilenga, Ed., "Simple
              Authentication and Security Layer (SASL)", RFC 4422,
              <https://www.rfc-editor.org/info/rfc4422>.
   [SCRAM-SHA-256]
              Hansen, T., "SCRAM-SHA-256 and SCRAM-SHA-256-PLUS Simple
              Authentication and Security Layer (SASL) Mechanisms",
              <https://www.rfc-editor.org/info/rfc7677>.
   [TLS-1.2]  Dierks, T. and E. Rescorla, "The Transport Layer Security
              (TLS) Protocol Version 1.2", RFC 5246,
              <https://www.rfc-editor.org/info/rfc5246>.
   [TLS-1.3]  Rescorla, E., "The Transport Layer Security (TLS) Protocol
              <https://www.rfc-editor.org/info/rfc8446>.
   [UTF-7]    Goldsmith, D. and M. Davis, "UTF-7 A Mail-Safe
              Transformation Format of Unicode", RFC 2152,
              <https://www.rfc-editor.org/info/rfc2152>.
   [UTF-8]    Yergeau, F., "UTF-8, a transformation format of ISO
              10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November
              2003, <https://www.rfc-editor.org/info/rfc3629>.
13.2.  Informative References
13.2.1.  Related Protocols
   [ANONYMOUS]
              Zeilenga, K., "Anonymous Simple Authentication and
              Security Layer (SASL) Mechanism", RFC 4505,
              <https://www.rfc-editor.org/info/rfc4505>.
   [CERT-555316]
              Carnegie Mellon University, "STARTTLS plaintext command
              injection vulnerability", Software Engineering Institute,
              CERT Coordination Center, Vulnerability Note VU#555316,
              September 2011, <https://www.kb.cert.org/vuls/id/555316>.
   [CHARSET-REG]
              IANA, "Character Set Registrations",
              <https://www.iana.org/assignments/charset-reg/>.
   [IMAP-DISC]
              Melnikov, A., Ed., "Synchronization Operations for
              Disconnected IMAP4 Clients", RFC 4549,
              <https://www.rfc-editor.org/info/rfc4549>.
   [IMAP-I18N]
              Newman, C., Gulbrandsen, A., and A. Melnikov, "Internet
              Message Access Protocol Internationalization", RFC 5255,
              <https://www.rfc-editor.org/info/rfc5255>.
   [IMAP-KEYWORDS-REG]
              IANA, "IMAP and JMAP Keywords",
              <https://www.iana.org/assignments/imap-jmap-keywords/>.
   [IMAP-MAILBOX-NAME-ATTRS-REG]
              IANA, "IMAP Mailbox Name Attributes",
              <https://www.iana.org/assignments/imap-mailbox-name-
              attributes/>.
   [IMAP-MODEL]
              Crispin, M., "Distributed Electronic Mail Models in
              <https://www.rfc-editor.org/info/rfc1733>.
   [IMAP-URL] Melnikov, A., Ed. and C. Newman, "IMAP URL Scheme",
              <https://www.rfc-editor.org/info/rfc5092>.
   [IMAP-UTF-8]
              Resnick, P., Ed., Newman, C., Ed., and S. Shen, Ed., "IMAP
              Support for UTF-8", RFC 6855, DOI 10.17487/RFC6855, March
              2013, <https://www.rfc-editor.org/info/rfc6855>.
   [NCSC]     NCSC, "Spray you, spray me: defending against password
              spraying attacks", May 2018, <https://www.ncsc.gov.uk/
              blog-post/spray-you-spray-me-defending-against-password-
              spraying-attacks>.
   [RFC2087]  Myers, J., "IMAP4 QUOTA extension", RFC 2087,
              <https://www.rfc-editor.org/info/rfc2087>.
   [RFC2177]  Leiba, B., "IMAP4 IDLE command", RFC 2177,
              <https://www.rfc-editor.org/info/rfc2177>.
   [RFC2193]  Gahrns, M., "IMAP4 Mailbox Referrals", RFC 2193,
              <https://www.rfc-editor.org/info/rfc2193>.
   [RFC2342]  Gahrns, M. and C. Newman, "IMAP4 Namespace", RFC 2342,
              <https://www.rfc-editor.org/info/rfc2342>.
   [RFC3348]  Gahrns, M. and R. Cheng, "The Internet Message Action
              Protocol (IMAP4) Child Mailbox Extension", RFC 3348,
              <https://www.rfc-editor.org/info/rfc3348>.
   [RFC3516]  Nerenberg, L., "IMAP4 Binary Content Extension", RFC 3516,
              <https://www.rfc-editor.org/info/rfc3516>.
   [RFC3691]  Melnikov, A., "Internet Message Access Protocol (IMAP)
              UNSELECT command", RFC 3691, DOI 10.17487/RFC3691,
   [RFC4314]  Melnikov, A., "IMAP4 Access Control List (ACL) Extension",
              <https://www.rfc-editor.org/info/rfc4314>.
   [RFC4315]  Crispin, M., "Internet Message Access Protocol (IMAP) -
              UIDPLUS extension", RFC 4315, DOI 10.17487/RFC4315,
   [RFC4466]  Melnikov, A. and C. Daboo, "Collected Extensions to IMAP4
              <https://www.rfc-editor.org/info/rfc4466>.
   [RFC4731]  Melnikov, A. and D. Cridland, "IMAP4 Extension to SEARCH
              Command for Controlling What Kind of Information Is
              <https://www.rfc-editor.org/info/rfc4731>.
   [RFC4959]  Siemborski, R. and A. Gulbrandsen, "IMAP Extension for
              Simple Authentication and Security Layer (SASL) Initial
              Client Response", RFC 4959, DOI 10.17487/RFC4959,
   [RFC5161]  Gulbrandsen, A., Ed. and A. Melnikov, Ed., "The IMAP
              ENABLE Extension", RFC 5161, DOI 10.17487/RFC5161, March
              2008, <https://www.rfc-editor.org/info/rfc5161>.
   [RFC5182]  Melnikov, A., "IMAP Extension for Referencing the Last
              SEARCH Result", RFC 5182, DOI 10.17487/RFC5182, March
              2008, <https://www.rfc-editor.org/info/rfc5182>.
   [RFC5256]  Crispin, M. and K. Murchison, "Internet Message Access
              Protocol - SORT and THREAD Extensions", RFC 5256,
              <https://www.rfc-editor.org/info/rfc5256>.
   [RFC5465]  Gulbrandsen, A., King, C., and A. Melnikov, "The IMAP
              NOTIFY Extension", RFC 5465, DOI 10.17487/RFC5465,
   [RFC5530]  Gulbrandsen, A., "IMAP Response Codes", RFC 5530,
              <https://www.rfc-editor.org/info/rfc5530>.
   [RFC5819]  Melnikov, A. and T. Sirainen, "IMAP4 Extension for
              Returning STATUS Information in Extended LIST", RFC 5819,
              <https://www.rfc-editor.org/info/rfc5819>.
   [RFC6151]  Turner, S. and L. Chen, "Updated Security Considerations
              for the MD5 Message-Digest and the HMAC-MD5 Algorithms",
              <https://www.rfc-editor.org/info/rfc6151>.
   [RFC6154]  Leiba, B. and J. Nicolson, "IMAP LIST Extension for
              Special-Use Mailboxes", RFC 6154, DOI 10.17487/RFC6154,
   [RFC6186]  Daboo, C., "Use of SRV Records for Locating Email
              Submission/Access Services", RFC 6186,
              <https://www.rfc-editor.org/info/rfc6186>.
   [RFC6376]  Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed.,
              "DomainKeys Identified Mail (DKIM) Signatures", STD 76,
              <https://www.rfc-editor.org/info/rfc6376>.
   [RFC6409]  Gellens, R. and J. Klensin, "Message Submission for Mail",
              <https://www.rfc-editor.org/info/rfc6409>.
   [RFC6851]  Gulbrandsen, A. and N. Freed, Ed., "Internet Message
              Access Protocol (IMAP) - MOVE Extension", RFC 6851,
              <https://www.rfc-editor.org/info/rfc6851>.
   [RFC7162]  Melnikov, A. and D. Cridland, "IMAP Extensions: Quick Flag
              Changes Resynchronization (CONDSTORE) and Quick Mailbox
              Resynchronization (QRESYNC)", RFC 7162,
              <https://www.rfc-editor.org/info/rfc7162>.
   [RFC7888]  Melnikov, A., Ed., "IMAP4 Non-synchronizing Literals",
              <https://www.rfc-editor.org/info/rfc7888>.
   [RFC8126]  Cotton, M., Leiba, B., and T. Narten, "Guidelines for
              Writing an IANA Considerations Section in RFCs", BCP 26,
              <https://www.rfc-editor.org/info/rfc8126>.
   [RFC8305]  Schinazi, D. and T. Pauly, "Happy Eyeballs Version 2:
              Better Connectivity Using Concurrency", RFC 8305,
              <https://www.rfc-editor.org/info/rfc8305>.
   [RFC8438]  Bosch, S., "IMAP Extension for STATUS=SIZE", RFC 8438,
              <https://www.rfc-editor.org/info/rfc8438>.
   [RFC8474]  Gondwana, B., Ed., "IMAP Extension for Object
              Identifiers", RFC 8474, DOI 10.17487/RFC8474, September
              2018, <https://www.rfc-editor.org/info/rfc8474>.
   [RFC8550]  Schaad, J., Ramsdell, B., and S. Turner, "Secure/
              Multipurpose Internet Mail Extensions (S/MIME) Version 4.0
              Certificate Handling", RFC 8550, DOI 10.17487/RFC8550,
   [RFC8551]  Schaad, J., Ramsdell, B., and S. Turner, "Secure/
              Multipurpose Internet Mail Extensions (S/MIME) Version 4.0
              Message Specification", RFC 8551, DOI 10.17487/RFC8551,
   [SMTP]     Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
              <https://www.rfc-editor.org/info/rfc5321>.
13.2.2.  Historical Aspects of IMAP and Related Protocols
   [IMAP-COMPAT]
              Crispin, M., "IMAP4 Compatibility with IMAP2bis",
              <https://www.rfc-editor.org/info/rfc2061>.
   [IMAP-HISTORICAL]
              Crispin, M., "IMAP4 Compatibility with IMAP2 and
              <https://www.rfc-editor.org/info/rfc1732>.
   [IMAP-OBSOLETE]
              Crispin, M., "Internet Message Access Protocol - Obsolete
              <https://www.rfc-editor.org/info/rfc2062>.
   [IMAP-TLS] Newman, C., "Using TLS with IMAP, POP3 and ACAP",
              <https://www.rfc-editor.org/info/rfc2595>.
   [IMAP2]    Crispin, M., "Interactive Mail Access Protocol: Version
              <https://www.rfc-editor.org/info/rfc1176>.
   [IMAP2BIS] Crispin, M., "INTERACTIVE MAIL ACCESS PROTOCOL - VERSION
              2bis", Work in Progress, Internet-Draft, draft-ietf-imap-
              imap2bis-02, 29 October 1993,
              <https://datatracker.ietf.org/doc/html/draft-ietf-imap-
              imap2bis-02>.
   [RFC1064]  Crispin, M., "Interactive Mail Access Protocol: Version
              <https://www.rfc-editor.org/info/rfc1064>.
   [RFC1730]  Crispin, M., "Internet Message Access Protocol - Version
              <https://www.rfc-editor.org/info/rfc1730>.
   [RFC2060]  Crispin, M., "Internet Message Access Protocol - Version
              <https://www.rfc-editor.org/info/rfc2060>.
   [RFC3501]  Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
              <https://www.rfc-editor.org/info/rfc3501>.
   [RFC822]   Crocker, D., "STANDARD FOR THE FORMAT OF ARPA INTERNET
              TEXT MESSAGES", STD 11, RFC 822, DOI 10.17487/RFC0822,
Appendix A.  Backward Compatibility with IMAP4rev1
   An implementation that wants to remain compatible with IMAP4rev1 can
   advertise both IMAP4rev1 and IMAP4rev2 in its CAPABILITY response /
   response code.  (Such server implementation is likely to also want to
   advertise other IMAP4rev1 extensions that were folded into IMAP4rev2;
   see Appendix E.)  While some IMAP4rev1 responses were removed in
   IMAP4rev2, their presence will not break IMAP4rev2-only clients.
   If both IMAP4rev1 and IMAP4rev2 are advertised, an IMAP client that
   wants to use IMAP4rev2 MUST issue an "ENABLE IMAP4rev2" command.
   When compared to IMAP4rev1, some request data items, corresponding
   response data items, and responses were removed in IMAP4rev2.  See
   Appendix E for more details.  With the exception of obsolete SEARCH
   and RECENT responses, servers advertising both IMAP4rev1 and
   IMAP4rev2 would never return such removed response data items/
   responses unless explicitly requested by an IMAPrev1 client.
   Servers advertising both IMAP4rev1 and IMAP4rev2 MUST NOT generate
   UTF-8-quoted strings unless the client has issued "ENABLE IMAP4rev2".
   Consider implementation of mechanisms described or referenced in
   [IMAP-UTF-8] to achieve this goal.
   Servers advertising both IMAP4rev1 and IMAP4rev2, and clients
   intending to be compatible with IMAP4rev1 servers, MUST be compatible
   with the Mailbox International Naming Convention described in
   Appendix A.1.
   Also see Appendix D for special considerations for servers that
   support 63-bit body part / message sizes and want to advertise
   support for both IMAP4rev1 and IMAP4rev2.
A.1.  Mailbox International Naming Convention for Compatibility with
      IMAP4rev1
   Support for the Mailbox International Naming Convention described in
   this section is not required for IMAP4rev2-only clients and servers.
   It is only used for backward compatibility with IMAP4rev1
   implementations.
   By convention, international mailbox names in IMAP4rev1 are specified
   using a modified version of the UTF-7 encoding described in [UTF-7].
   Modified UTF-7 may also be usable in servers that implement an
   earlier version of this protocol.
   In modified UTF-7, printable US-ASCII characters, except for "&",
   represent themselves; that is, characters with octet values 0x20-0x25
   and 0x27-0x7e.  The character "&" (0x26) is represented by the
   2-octet sequence "&-".
   All other characters (octet values 0x00-0x1f and 0x7f-0xff) are
   represented in modified base64, with a further modification from
   [UTF-7] that "," is used instead of "/".  Modified base64 MUST NOT be
   used to represent any printing of a US-ASCII character that can
   represent itself.  Only characters inside the modified base64
   alphabet are permitted in modified base64 text.
   "&" is used to shift to modified base64 and "-" to shift back to US-
   ASCII.  There is no implicit shift from base64 to US-ASCII, and null
   shifts ("-&" while in base64; note that "&-" while in US-ASCII means
   "&") are not permitted.  However, all names start in US-ASCII and
   MUST end in US-ASCII; that is, a name that ends with a non-ASCII
   ISO-10646 character MUST end with a "-".
   The purpose of these modifications is to correct the following
   problems with UTF-7:
   1.  UTF-7 uses the "+" character for shifting; this conflicts with
       the common use of "+" in mailbox names, in particular USENET
       newsgroup names.
   2.  UTF-7's encoding is base64, which uses the "/" character; this
       conflicts with the use of "/" as a popular hierarchy delimiter.
   3.  UTF-7 prohibits the unencoded usage of "\"; this conflicts with
       the use of "\" as a popular hierarchy delimiter.
   4.  UTF-7 prohibits the unencoded usage of "~"; this conflicts with
       the use of "~" in some servers as a home directory indicator.
   5.  UTF-7 permits multiple alternate forms to represent the same
       string; in particular, printable US-ASCII characters can be
       represented in encoded form.
   Although modified UTF-7 is a convention, it establishes certain
   requirements on the server handling of any mailbox name with an
   embedded "&" character.  In particular, server implementations MUST
   preserve the exact form of the modified base64 portion of a modified
   UTF-7 name and treat that text as case sensitive, even if names are
   otherwise case insensitive or case folded.
   Server implementations SHOULD verify that any mailbox name with an
   embedded "&" character, used as an argument to CREATE, is: in the
   correctly modified UTF-7 syntax; has no superfluous shifts; and has
   no encoding in modified base64 of any printing US-ASCII character
   that can represent itself.  However, client implementations MUST NOT
   depend upon the server doing this and SHOULD NOT attempt to create a
   mailbox name with an embedded "&" character unless it complies with
   the modified UTF-7 syntax.
   Server implementations that export a mail store that does not follow
   the modified UTF-7 convention MUST convert any mailbox name that
   contains either non-ASCII characters or the "&" character to modified
   UTF-7.
      For example, here is a mailbox name that mixes English, Chinese,
      and Japanese text: ~peter/mail/&U,BTFw-/&ZeVnLIqe-
      For example, the string "&Jjo!" is not a valid mailbox name
      because it does not contain a shift to US-ASCII before the "!".
      The correct form is "&Jjo-!".  The string "&U,BTFw-&ZeVnLIqe-" is
      not permitted because it contains a superfluous shift.  The
      correct form is "&U,BTF2XlZyyKng-".
Appendix B.  Backward Compatibility with BINARY Extension
   IMAP4rev2 incorporates a subset of functionality provided by the
   BINARY extension [RFC3516]; in particular, it includes additional
   FETCH items (BINARY, BINARY.PEEK, and BINARY.SIZE) but not extensions
   to the APPEND command.  IMAP4rev2 implementations that support full
   [RFC3516] functionality need to also advertise the BINARY capability
   in the CAPABILITY response / response code.
Appendix C.  Backward Compatibility with LIST-EXTENDED Extension
   IMAP4rev2 incorporates most of the functionality provided by the
   LIST-EXTENDED extension [RFC5258].  In particular, the syntax for
   multiple mailbox patterns is not supported in IMAP4rev2, unless LIST-
   EXTENDED capability is also advertised in the CAPABILITY response /
   response code.
Appendix D.  63-Bit Body Part and Message Sizes
   IMAP4rev2 increases allowed body part and message sizes that servers
   can support from 32 to 63 bits.  Server implementations don't have to
   support 63-bit-long body parts/message sizes; however, client
   implementations have to expect them.
   As IMAP4rev1 didn't support 63-bit-long body part / message sizes,
   there is an interoperability issue exposed by 63-bit-capable servers/
   mailboxes that are accessible by both IMAP4rev1 and IMAP4rev2 email
   clients.  As IMAP4rev1 would be unable to retrieve the full content
   of messages bigger than 4 Gb, such servers either need to replace
   messages bigger that 4 Gb with messages under 4 Gb or hide them from
   IMAP4rev1 clients.  This document doesn't prescribe any
   implementation strategy to address this issue.
Appendix E.  Changes from RFC 3501 / IMAP4rev1
   Below is the summary of changes since RFC 3501:
   1.   Support for 64-bit message and body part sizes.
   2.   Folded in IMAP NAMESPACE [RFC2342], UNSELECT [RFC3691], UIDPLUS
        [RFC4315], ESEARCH [RFC4731], SEARCHRES [RFC5182], ENABLE
        [RFC5161], IDLE [RFC2177], SASL-IR [RFC4959], LIST-EXTENDED
        [RFC5258], LIST-STATUS [RFC5819], MOVE [RFC6851], and LITERAL-
        extensions [RFC7888].  Also folded in IMAP ABNF extensions
        [RFC4466], response codes [RFC5530], the FETCH side of the
        BINARY extension [RFC3516], and the list of new mailbox
        attributes from SPECIAL-USE [RFC6154].
   3.   Added STATUS SIZE [RFC8438] and STATUS DELETED.
   4.   SEARCH command now requires to return the ESEARCH response
        (SEARCH response is now deprecated).
   5.   Clarified which SEARCH keys have to use substring match and
        which don't.
   6.   Clarified that the server should decode parameter value
        continuations as described in [RFC2231].  This requirement was
        hidden in [RFC2231] itself.
   7.   Clarified that the COPYUID response code is returned for both
        MOVE and UID MOVE.
   8.   Tightened requirements about COPY/MOVE commands not creating a
        target mailbox.  Also required them to return the TRYCREATE
        response code, if the target mailbox doesn't exist and can be
        created.
   9.   Added the CLOSED response code from [RFC7162].  SELECT/EXAMINE
        when a mailbox is already selected now requires a CLOSED
        response code to be returned.
   10.  SELECT/EXAMINE are now required to return an untagged LIST
        response.
   11.  UNSEEN response code on SELECT/EXAMINE is now deprecated.
   12.  RECENT response on SELECT/EXAMINE, \Recent flag, RECENT STATUS,
        and SEARCH NEW items are now deprecated.
   13.  Clarified that the server doesn't need to send a new
        PERMANENTFLAGS response code when a new keyword was successfully
        added and the server advertised \* earlier for the same mailbox.
   14.  For future extensibility, extended ABNF for tagged-ext-simple to
        allow for bare number64.
   15.  Added SHOULD level requirement on IMAP servers to support
        $MDNSent, $Forwarded, $Junk, $NonJunk, and $Phishing keywords.
   16.  Mailbox names and message headers now allow for UTF-8.  Support
        for modified UTF-7 in mailbox names is not required, unless
        compatibility with IMAP4rev1 is desired.
   17.  Removed the CHECK command.  Clients should use NOOP instead.
   18.  RFC822, RFC822.HEADER, and RFC822.TEXT FETCH data items were
        deprecated.  Clients should use the corresponding BODY[]
        variants instead.
   19.  LSUB command was deprecated.  Clients should use LIST
        (SUBSCRIBED) instead.
   20.  IDLE command can now return updates not related to the currently
        selected mailbox state.
   21.  All unsolicited FETCH updates are required to include UID.
   22.  Clarified that client implementations MUST ignore response codes
        that they do not recognize.  (Changed from a SHOULD to a MUST.)
   23.  resp-text ABNF non-terminal was updated to allow for empty text.
   24.  After ENABLE, IMAP4rev2 human-readable response text can include
        non-ASCII encoded in UTF-8.
   25.  Updated to use modern TLS-related recommendations as per
        [RFC7525], [RFC7817], and [RFC8314].
   26.  Added warnings about use of ALERT response codes and PREAUTH
        response.
   27.  Replaced DIGEST-MD5 SASL mechanism with SCRAM-SHA-256.  DIGEST-
        MD5 was deprecated.
   28.  Clarified that any command received from the client resets
        server autologout timer.
   29.  Revised IANA registration procedure for IMAP extensions and
        removed "X" convention in accordance with [BCP178].
   30.  Loosened requirements on servers when closing connections to be
        more aligned with existing practices.
Appendix F.  Other Recommended IMAP Extensions
   Support for the following extensions is recommended for all IMAP
   clients and servers.  While they significantly reduce bandwidth and/
   or number of round trips used by IMAP in certain situations, the
   EXTRA WG decided that requiring them as a part of IMAP4rev2 would
   push the bar to implement too high for new implementations.  Also
   note that the absence of any IMAP extension from this list doesn't
   make it somehow deficient or not recommended for use with IMAP4rev2.
   1.  Quick Mailbox Resynchronization (QRESYNC) and CONDSTORE
       extensions [RFC7162].  They make discovering changes to IMAP
       mailboxes more efficient, at the expense of storing a bit more
       state.
   2.  OBJECTID extension [RFC8474] helps with preserving the IMAP
       client cache when messages are moved/copied or mailboxes are
       renamed.
Acknowledgements
   Earlier draft versions of this document were edited by Mark Crispin.
   Sadly, he is no longer available to help with this work.  Editors of
   this revision are hoping that Mark would have approved.
   Chris Newman has contributed text on I18N and use of UTF-8 in
   messages and mailbox names.
   Thank you to Tony Hansen for helping with the index generation.
   Thank you to Murray Kucherawy, Timo Sirainen, Bron Gondwana, Stephan
   Bosch, Robert Sparks, Arnt Gulbrandsen, Benjamin Kaduk, Daniel
   Migaul, Roman Danyliw, and Éric Vyncke for extensive feedback.
   This document incorporates text from [RFC2342] (by Mike Gahrns and
   Chris Newman), [RFC3516] (by Lyndon Nerenberg), [RFC4315] (by Mark
   Crispin), [RFC4466] (by Cyrus Daboo), [RFC4731] (by Dave Cridland),
   [RFC4959] (by Rob Siemborski and Arnt Gulbrandsen), [RFC5161] (by
   Arnt Gulbrandsen), [RFC5465] (by Arnt Gulbrandsen and Curtis King),
   [RFC5530] (by Arnt Gulbrandsen), [RFC5819] (by Timo Sirainen),
   [RFC6154] (by Jamie Nicolson), [RFC6851] (by Arnt Gulbrandsen and Ned
   Freed), and [RFC8438] (by Stephan Bosch), so work done by authors/
   editors of these documents is appreciated.  Note that editors of this
   document were redacted from the above list.
   The CHILDREN return option was originally proposed by Mike Gahrns and
   Raymond Cheng in [RFC3348].  Most of the information in
   Section 6.3.9.5 is taken directly from their original specification
   [RFC3348].
   Thank you to Damian Poddebniak, Fabian Ising, Hanno Boeck, and
   Sebastian Schinzel for pointing out that the ENABLE command should be
   a member of "command-auth" and not "command-any" ABNF production, as
   well as pointing out security issues associated with ALERT, PREAUTH,
   and other responses received before authentication.
Index
   $ + - \ A B C D E F H I K L M N O P R S T U
      $
         $Forwarded (predefined flag)
            Section 2.3.2
         $Junk (predefined flag)
            Section 2.3.2
         $MDNSent (predefined flag)
            Section 2.3.2
         $NotJunk (predefined flag)
            Section 2.3.2
         $Phishing (predefined flag)
            Section 2.3.2, Paragraph 6.10.1
      +
         +FLAGS <flag list>
            Section 6.4.6
         +FLAGS.SILENT <flag list>
            Section 6.4.6
      -
         -FLAGS <flag list>
            Section 6.4.6
         -FLAGS.SILENT <flag list>
            Section 6.4.6
      \
         \All (mailbox name attribute)
            Section 7.3.1
         \Answered (system flag)
            Section 2.3.2
         \Archive (mailbox name attribute)
            Section 7.3.1
         \Deleted (system flag)
            Section 2.3.2
         \Draft (system flag)
            Section 2.3.2
         \Drafts (mailbox name attribute)
            Section 7.3.1
         \Flagged (mailbox name attribute)
            Section 7.3.1
         \Flagged (system flag)
            Section 2.3.2
         \HasChildren (mailbox name attribute)
            Section 7.3.1
         \HasNoChildren (mailbox name attribute)
            Section 7.3.1
         \Junk (mailbox name attribute)
            Section 7.3.1
         \Marked (mailbox name attribute)
            Section 7.3.1
         \Noinferiors (mailbox name attribute)
            Section 7.3.1
         \NonExistent (mailbox name attribute)
            Section 7.3.1, Paragraph 4.2.1
         \Noselect (mailbox name attribute)
            Section 7.3.1
         \Recent (system flag)
            Section 2.3.2
         \Remote (mailbox name attribute)
            Section 7.3.1
         \Seen (system flag)
            Section 2.3.2
         \Sent (mailbox name attribute)
            Section 7.3.1
         \Subscribed (mailbox name attribute)
            Section 7.3.1
         \Trash (mailbox name attribute)
            Section 7.3.1
         \Unmarked (mailbox name attribute)
            Section 7.3.1
      A
         ALERT (response code)
            Section 7.1
         ALL (fetch item)
            Section 6.4.5
         ALL (search key)
            Section 6.4.4
         ALL (search result option)
            Section 6.4.4, Paragraph 6.6.1
         ALL (search return item name)
            Section 7.3.4, Paragraph 7.6.1
         ALREADYEXISTS (response code)
            Section 7.1, Paragraph 4.4.1
         ANSWERED (search key)
            Section 6.4.4
         APPEND (command)
            Section 6.3.12
         APPENDUID (response code)
            Section 7.1, Paragraph 4.6.1
         AUTHENTICATE (command)
            Section 6.2.2
         AUTHENTICATIONFAILED (response code)
            Section 7.1, Paragraph 4.8.1
         AUTHORIZATIONFAILED (response code)
            Section 7.1, Paragraph 4.10.1
      B
         BAD (response)
            Section 7.1.3
         BADCHARSET (response code)
            Section 7.1
         BCC <string> (search key)
            Section 6.4.4
         BEFORE <date> (search key)
            Section 6.4.4
         BINARY.PEEK[<section-binary>]<<partial>> (fetch item)
            Section 6.4.5
         BINARY.SIZE[<section-binary>] (fetch item)
            Section 6.4.5, Paragraph 9.6.1
         BINARY.SIZE[<section-binary>] (fetch result)
            Section 7.5.2, Paragraph 4.4.1
         BINARY[<section-binary>]<<number>> (fetch result)
            Section 7.5.2, Paragraph 4.2.1
         BINARY[<section-binary>]<<partial>> (fetch item)
            Section 6.4.5, Paragraph 9.2.1
         BODY (fetch item)
            Section 6.4.5
         BODY (fetch result)
            Section 7.5.2
         BODY <string> (search key)
            Section 6.4.4
         BODY.PEEK[<section>]<<partial>> (fetch item)
            Section 6.4.5
         BODYSTRUCTURE (fetch item)
            Section 6.4.5
         BODYSTRUCTURE (fetch result)
            Section 7.5.2, Paragraph 4.10.1
         BODY[<section>]<<origin octet>> (fetch result)
            Section 7.5.2, Paragraph 4.8.1
         BODY[<section>]<<partial>> (fetch item)
            Section 6.4.5, Paragraph 9.10.1
         BYE (response)
            Section 7.1.5
         Body Structure (message attribute)
            Section 2.3.6
      C
         CANNOT (response code)
            Section 7.1, Paragraph 4.14.1
         CAPABILITY (command)
            Section 6.1.1
         CAPABILITY (response code)
            Section 7.1
         CAPABILITY (response)
            Section 7.2.2
         CC <string> (search key)
            Section 6.4.4
         CLIENTBUG (response code)
            Section 7.1, Paragraph 4.18.1
         CLOSE (command)
            Section 6.4.1
         CLOSED (response code)
            Section 7.1, Paragraph 4.20.1
         CONTACTADMIN (response code)
            Section 7.1, Paragraph 4.22.1
         COPY (command)
            Section 6.4.7
         COPYUID (response code)
            Section 7.1, Paragraph 4.24.1
         CORRUPTION (response code)
            Section 7.1, Paragraph 4.26.1
         COUNT (search result option)
            Section 6.4.4
         COUNT (search return item name)
            Section 7.3.4
         CREATE (command)
            Section 6.3.4
      D
         DELETE (command)
            Section 6.3.5
         DELETED (search key)
            Section 6.4.4
         DELETED (status item)
            Section 6.3.11
         DRAFT (search key)
            Section 6.4.4
      E
         ENABLE (command)
            Section 6.3.1
         ENVELOPE (fetch item)
            Section 6.4.5
         ENVELOPE (fetch result)
            Section 7.5.2, Paragraph 4.42.1
         ESEARCH (response)
            Section 7.3.4
         EXAMINE (command)
            Section 6.3.3
         EXPIRED (response code)
            Section 7.1, Paragraph 4.28.1
         EXPUNGE (command)
            Section 6.4.3
         EXPUNGE (response)
            Section 7.5.1
         EXPUNGEISSUED (response code)
            Section 7.1, Paragraph 4.30.1
         Envelope Structure (message attribute)
            Section 2.3.5
      F
         FAST (fetch item)
            Section 6.4.5
         FETCH (command)
            Section 6.4.5
         FETCH (response)
            Section 7.5.2
         FLAGGED (search key)
            Section 6.4.4
         FLAGS (fetch item)
            Section 6.4.5
         FLAGS (fetch result)
            Section 7.5.2
         FLAGS (response)
            Section 7.3.5
         FLAGS <flag list> (store command data item)
            Section 6.4.6
         FLAGS.SILENT <flag list> (store command data item)
            Section 6.4.6
         FROM <string> (search key)
            Section 6.4.4
         FULL (fetch item)
            Section 6.4.5
         Flags (message attribute)
            Section 2.3.2
      H
         HASCHILDREN (response code)
            Section 7.1, Paragraph 4.32.1
         HEADER (part specifier)
            Section 6.4.5.1, Paragraph 5
         HEADER <field-name> <string> (search key)
            Section 6.4.4
         HEADER.FIELDS (part specifier)
            Section 6.4.5.1, Paragraph 5
         HEADER.FIELDS.NOT (part specifier)
            Section 6.4.5.1, Paragraph 5
      I
         IDLE (command)
            Section 6.3.13
         INTERNALDATE ( fetch item)
            Section 6.4.5
         INTERNALDATE (fetch result)
            Section 7.5.2
         INUSE (response code)
            Section 7.1, Paragraph 4.34.1
         Internal Date (message attribute)
            Section 2.3.3
      K
         KEYWORD <flag> (search key)
            Section 6.4.4
         Keyword (type of flag)
            Section 2.3.2, Paragraph 4
      L
         LARGER <n> (search key)
            Section 6.4.4
         LIMIT (response code)
            Section 7.1, Paragraph 4.36.1
         LIST (command)
            Section 6.3.9
         LIST (response)
            Section 7.3.1
         LOGOUT (command)
            Section 6.1.3
      M
         MAX (search result option)
            Section 6.4.4, Paragraph 6.4.1
         MAX (search return item name)
            Section 7.3.4, Paragraph 7.4.1
         MAY (specification requirement term)
            Section 1.2
         MESSAGES (status item)
            Section 6.3.11
         MIME (part specifier)
            Section 6.4.5.1, Paragraph 7
         MIN (search result option)
            Section 6.4.4, Paragraph 6.2.1
         MIN (search return item name)
            Section 7.3.4, Paragraph 7.2.1
         MOVE (command)
            Section 6.4.8
         MUST (specification requirement term)
            Section 1.2
         MUST NOT (specification requirement term)
            Section 1.2
         Message Sequence Number (message attribute)
            Section 2.3.1.2
      N
         NAMESPACE (command)
            Section 6.3.10
         NAMESPACE (response)
            Section 7.3.2
         NO (response)
            Section 7.1.2
         NONEXISTENT (response code)
            Section 7.1, Paragraph 4.38.1
         NOOP (command)
            Section 6.1.2
         NOPERM (response code)
            Section 7.1, Paragraph 4.40.1
         NOT <search-key> (search key)
            Section 6.4.4
         NOT RECOMMENDED (specification requirement term)
            Section 1.2
      O
         OK (response)
            Section 7.1.1
         ON <date> (search key)
            Section 6.4.4
         OPTIONAL (specification requirement term)
            Section 1.2; Section 1.2
         OR <search-key1> <search-key2> (search key)
            Section 6.4.4
         OVERQUOTA (response code)
            Section 7.1, Paragraph 4.42.1
      P
         PARSE (response code)
            Section 7.1
         PERMANENTFLAGS (response code)
            Section 7.1, Paragraph 4.46.1
         PREAUTH (response)
            Section 7.1.4
         PRIVACYREQUIRED (response code)
            Section 7.1, Paragraph 4.48.1
         Permanent Flag (class of flag)
            Section 2.3.2, Paragraph 9
         Predefined keywords
            Section 2.3.2, Paragraph 5
      R
         READ-ONLY (response code)
            Section 7.1
         READ-WRITE (response code)
            Section 7.1
         RECOMMENDED (specification requirement term)
            Section 1.2
         RENAME (command)
            Section 6.3.6
         REQUIRED (specification requirement term)
            Section 1.2
         RFC822.SIZE (fetch item)
            Section 6.4.5
         RFC822.SIZE (fetch result)
            Section 7.5.2
         RFC822.SIZE (message attribute)
            Section 2.3.4
      S
         SAVE (search result option)
            Section 6.4.4, Paragraph 6.10.1
         SEARCH (command)
            Section 6.4.4
         SEEN (search key)
            Section 6.4.4
         SELECT (command)
            Section 6.3.2
         SENTBEFORE <date> (search key)
            Section 6.4.4
         SENTON <date> (search key)
            Section 6.4.4
         SENTSINCE <date> (search key)
            Section 6.4.4
         SERVERBUG (response code)
            Section 7.1, Paragraph 4.54.1
         SHOULD (specification requirement term)
            Section 1.2
         SHOULD NOT (specification requirement term)
            Section 1.2
         SINCE <date> (search key)
            Section 6.4.4
         SIZE (status item)
            Section 6.3.11
         SMALLER <n> (search key)
            Section 6.4.4
         STARTTLS (command)
            Section 6.2.1
         STATUS (command)
            Section 6.3.11
         STATUS (response)
            Section 7.3.3
         STORE (command)
            Section 6.4.6
         SUBJECT <string> (search key)
            Section 6.4.4
         SUBSCRIBE (command)
            Section 6.3.7
         Session Flag (class of flag)
            Section 2.3.2, Paragraph 9
         System Flag (type of flag)
            Section 2.3.2, Paragraph 2
      T
         TEXT (part specifier)
            Section 6.4.5.1, Paragraph 5
         TEXT <string> (search key)
            Section 6.4.4
         TO <string> (search key)
            Section 6.4.4
         TRYCREATE (response code)
            Section 7.1
      U
         UID (command)
            Section 6.4.9
         UID (fetch item)
            Section 6.4.5
         UID (fetch result)
            Section 7.5.2
         UID <sequence set> (search key)
            Section 6.4.4
         UIDNEXT (response code)
            Section 7.1
         UIDNEXT (status item)
            Section 6.3.11
         UIDNOTSTICKY (response code)
            Section 7.1, Paragraph 4.60.1
         UIDVALIDITY (response code)
            Section 7.1
         UIDVALIDITY (status item)
            Section 6.3.11
         UNANSWERED (search key)
            Section 6.4.4
         UNAVAILABLE (response code)
            Section 7.1, Paragraph 4.64.1
         UNDELETED (search key)
            Section 6.4.4
         UNDRAFT (search key)
            Section 6.4.4
         UNFLAGGED (search key)
            Section 6.4.4
         UNKEYWORD <flag> (search key)
            Section 6.4.4
         UNKNOWN-CTE (response code)
            Section 7.1
         UNSEEN (search key)
            Section 6.4.4
         UNSEEN (status item)
            Section 6.3.11
         UNSELECT (command)
            Section 6.4.2
         UNSUBSCRIBE (command)
            Section 6.3.8
         Unique Identifier (UID) (message attribute)
            Section 2.3.1.1
Authors' Addresses
   Alexey Melnikov (editor)
   Isode Ltd
   14 Castle Mews
   Hampton, Middlesex
   TW12 2NP
   United Kingdom
   Email: Alexey.Melnikov@isode.com
   Barry Leiba (editor)
   Futurewei Technologies
   Email: barryleiba@computer.org
   URI:   http://internetmessagingtechnology.org/