RFC 9051 Proposed Standard Submission and access

Internet Message Access Protocol (IMAP) - Version 4rev2

The Internet Message Access Protocol Version 4rev2 (IMAP4rev2) allows a client to access and manipulate electronic mail messages on a server. IMAP4rev2 permits manipulation of mailboxes (remote message folders) in a way that is functionally equivalent to local folders. IMAP4rev2 also provides the capability for an offline client to resynchronize with the server. IMAP4rev2 includes operations for creating, deleting, and renaming mailboxes; checking for new messages; removing messages permanently; setting and clearin

Status
Proposed Standard. On the standards track and stable enough to implement against. Most of the email stack stays at this level permanently.
Published
August 2021
Authors
A. Melnikov, B. Leiba
Read it
rfc-editor.org · errata · DOI

Replaces RFC 1730: Internet Message Access Protocol - Version 4, RFC 2060: Internet Message Access Protocol - Version 4rev1, RFC 3501: INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1.

Normative requirements

Every sentence in this RFC carrying an RFC 2119 keyword, with the section it came from. 233 must, 101 should, 79 may.

2.2.1 Client Protocol Sender and Server Protocol Receiver

  • SHOULDMore formally: the client SHOULD generate a unique tag for every command, but a server MUST accept tag reuse.
  • MUSTClients MUST follow the syntax outlined in this specification strictly.
  • MUSTIn all cases, the client MUST send a complete command (including receiving all command continuation request responses and sending command continuations for the command) before initiating a new command.

2.2.2 Server Protocol Sender and Client Protocol Receiver

  • MAYServer data MAY be sent as a result of a client command or MAY be sent unilaterally by the server.
  • SHOULDServers SHOULD strictly enforce the syntax outlined in this specification.
  • SHOULDAny client command with a protocol syntax error, including (but not limited to) missing or extraneous spaces or arguments, SHOULD be rejected and the client given a BAD server completion response.
  • MUSTA client MUST be prepared to accept any server response at all times.
  • SHOULDServer data SHOULD be remembered (cached), so that the client can reference its remembered copy rather than sending a command to the server to request the data.
  • MUSTIn the case of certain server data, the data MUST be remembered, as specified elsewhere in this document.

2.3.1.1 Unique Identifier (UID) Message Attribute

  • MUST NOTA UID is an unsigned non-zero 32-bit value assigned to each message, which when used with the unique identifier validity value (see below) forms a 64-bit value that MUST NOT refer to any other message in the mailbox or any subsequent mailbox with the same name forever.
  • MUST NOTThe unique identifier of a message MUST NOT change during the session and SHOULD NOT change between sessions.
  • MUSTAny change of unique identifiers between sessions MUST be detectable using the UIDVALIDITY mechanism discussed below.
  • MUSTUnless the unique identifier validity also changes (see below), the next unique identifier value MUST have the following two characteristics.
  • MUST NOTFirst, the next unique identifier value MUST NOT change unless new messages are added to the mailbox; and second, the next unique identifier value MUST change whenever new messages are added to the mailbox, even if those new messages are subsequently expunged.
  • MUSTIf unique identifiers from an earlier session fail to persist in this session, the unique identifier validity value MUST be greater than the one used in the earlier session.
  • SHOULDNote: Ideally, unique identifiers SHOULD persist at all times.
  • MUSTUnique identifiers MUST be strictly ascending in the mailbox at all times.
  • MUSTIf the physical message store is reordered by a non- IMAP agent, the unique identifiers in the mailbox MUST be regenerated, since the former unique identifiers are no longer strictly ascending as a result of the reordering.
  • MUSTIn particular, the internal date, RFC822.SIZE, envelope, body structure, and message texts (all BODY[...] fetch data items) MUST never change.
  • MUST NOTWhen a message is expunged, its UID MUST NOT be reused under the same UIDVALIDITY value.

2.3.1.2 Message Sequence Number Message Attribute

  • MUSTThis position MUST be ordered by ascending unique identifiers.

2.3.2 Flags Message Attribute

  • MAYServers MAY permit the client to define new keywords in the mailbox (see the description of the PERMANENTFLAGS response code for more information).
  • SHOULDThese keywords SHOULD be supported (allowed in SEARCH and allowed and preserved in APPEND, COPY, and MOVE commands) by server implementations:
  • SHOULD NOTOnce set, the flag SHOULD NOT be cleared.
  • MUSTIf more than one of these is set for a message, the client MUST treat it as if none are set, and it SHOULD unset both of them on the IMAP server.
  • SHOULDNew keywords SHOULD be registered in this registry using the procedure specified in [RFC5788].

2.3.3 Internal Date Message Attribute

  • SHOULDIn the case of messages created by the IMAP4rev2 COPY or MOVE command, this SHOULD be the same as the Internal Date attribute of the source message.
  • SHOULDIn the case of messages created by the IMAP4rev2 APPEND command, this SHOULD be the date and time as specified in the APPEND command description.

2.3.4 RFC822.SIZE Message Attribute

  • SHOULDThis size SHOULD match the result of a "FETCH BODY[]" command.

3.1 Not Authenticated State

  • MUSTIn the not authenticated state, the client MUST supply authentication credentials before most commands will be permitted.

3.2 Authenticated State

  • MUSTIn the authenticated state, the client is authenticated and MUST select a mailbox to access before commands that affect messages will be permitted.

3.4 Logout State

  • MUSTIf the client requests the logout state, the server MUST send an untagged BYE response and a tagged OK response to the LOGOUT command before the server closes the connection; and the client MUST read the tagged OK response to the LOGOUT command before the client closes the connection.
  • SHOULD NOTA server SHOULD NOT unilaterally close the connection without first sending an untagged BYE response that contains the reason for doing so.
  • SHOULD NOTA client SHOULD NOT unilaterally close the connection; instead, it SHOULD issue a LOGOUT command.
  • MAYIf the server detects that the client has unilaterally closed the connection, the server MAY omit the untagged BYE response and simply close its connection.

4.3 String

  • MUSTIn the case of synchronizing literals transmitted from client to server, the client MUST wait to receive a command continuation request (described later in this document) before sending the octet data (and the remainder of the command).
  • MUST NOTThe non-synchronizing literal form MUST NOT be sent from server to client.
  • MUST NOTUnless otherwise specified in an IMAP extension, non-synchronizing literals MUST NOT be larger than 4096 octets.
  • MUSTAny literal larger than 4096 bytes MUST be sent as a synchronizing literal.
  • MUSTNote: Even if the octet count is 0, a client transmitting a synchronizing literal MUST wait to receive a command continuation request.
  • MAYIMAP4rev2 implementations MAY transmit 8-bit or multi-octet characters in literals but SHOULD do so only when the [CHARSET] is identified.
  • MUSTIMAP4rev2 implementations MUST accept and MAY transmit [UTF-8] text in quoted-strings as long as the string does not contain NUL, CR, or LF.
  • MAYA string with an excessive amount of CTL characters MAY also be considered to be binary.
  • MUSTUnless returned in response to BINARY.PEEK[...]/BINARY[...] FETCH, client and server implementations MUST encode binary data into a textual form, such as base64, before transmitting the data.

5.1 Mailbox Naming

  • MAYClient implementations MAY attempt to create Net-Unicode mailbox names and MUST interpret any 8-bit mailbox names returned by LIST as [NET-UNICODE].
  • MUSTServer implementations MUST prohibit the creation of 8-bit mailbox names that do not comply with Net-Unicode.
  • MAYHowever, servers MAY accept a denormalized UTF-8 mailbox name and convert it to Unicode Normalization Form C (NFC) (as per Net-Unicode requirements) prior to mailbox creation.
  • MUSTServers that choose to accept such denormalized UTF-8 mailbox names MUST accept them in all IMAP commands that have a mailbox name parameter.
  • MAYServers MAY refuse to create mailbox names containing Unicode CTL characters.

5.1.1 Mailbox Hierarchy Naming

  • MUSTIf it is desired to export hierarchical mailbox names, mailbox names MUST be left-to-right hierarchical, using a single ASCII character to separate levels of hierarchy.

5.1.2 Namespaces

  • MUSTIf an INBOX exists for a user, it MUST appear within the user's Personal Namespace.
  • SHOULDIn the typical case, there SHOULD be only one Personal Namespace per user on a server.
  • MUSTTo access mailboxes in the Other Users' Namespace, the currently authenticated user MUST be explicitly granted access rights.
  • SHOULDIn the typical case, there SHOULD be only one Other Users' Namespace per user on a server.
  • MAYThe namespaces a server uses MAY differ on a per-user basis.

5.1.2.1 Historic Mailbox Namespace Naming Convention

  • MAYFor example, implementations that offer access to USENET newsgroups MAY use the "#news" namespace to partition the USENET newsgroup namespace from that of other mailboxes.
  • MAYAs such, server implementors MAY instead consider using namespace prefixes that do not contain the "#" character.

5.2 Mailbox Size and Message Status Updates

  • MUSTA server MUST send mailbox size updates automatically if a mailbox size change is observed during the processing of a command.
  • SHOULDA server SHOULD send message flag updates automatically, without requiring the client to request such updates explicitly.
  • MUSTRegardless of what implementation decisions a client makes on remembering data from the server, a client implementation MUST remember mailbox size updates.
  • MUST NOTIt MUST NOT assume that any command after the initial mailbox selection will return the size of the mailbox.

5.3 Response When No Command in Progress

  • MUSTServer implementations that send such responses MUST deal with flow control considerations.
  • MUSTSpecifically, they MUST either (1) verify that the size of the data does not exceed the underlying transport's available window size or (2) use non-blocking writes.

5.4 Autologout Timer

  • MUSTIf a server has an inactivity autologout timer that applies to sessions after authentication, the duration of that timer MUST be at least 30 minutes.

5.5 Multiple Commands in Progress (Command Pipelining)

  • MAYThe client MAY send another command without waiting for the completion result response of a command, subject to ambiguity rules (see below) and flow control constraints on the underlying data stream.
  • MAYSimilarly, a server MAY begin processing another command before processing the current command to completion, subject to ambiguity rules.
  • MUSTHowever, any command continuation request responses and command continuations MUST be negotiated before any subsequent command is initiated.
  • MUSTIf the server detects a possible ambiguity, it MUST execute commands to completion in the order given by the client.
  • MUSTTherefore, if the client sends any command other than FETCH, STORE, or SEARCH, it MUST wait for the completion result response before sending a command with message sequence numbers.
  • MUSTIf the client sends a UID command, it MUST wait for a completion result response before sending a command that uses message sequence numbers (this may include UID SEARCH).

6.1.1 CAPABILITY Command

  • REQUIREDResponses: REQUIRED untagged response: CAPABILITY
  • MUSTThe server MUST send a single untagged CAPABILITY response with "IMAP4rev2" as one of the listed capabilities before the (tagged) OK response.
  • MUSTClient and server implementations MUST implement the STARTTLS (Section 6.2.1) and LOGINDISABLED capabilities on cleartext ports.
  • MUSTClient and server implementations MUST also implement AUTH=PLAIN (described in [PLAIN]) capability on both cleartext and Implicit TLS ports.

6.1.3 LOGOUT Command

  • REQUIREDResponses: REQUIRED untagged response: BYE
  • MUSTThe server MUST send a BYE untagged response before the (tagged) OK response, and then close the network connection.

6.2 Client Commands - Not Authenticated State

  • MAYServer implementations MAY allow access to certain mailboxes without establishing authentication.

6.2.1 STARTTLS Command

  • MUSTThe server MUST always respond with a tagged BAD response when the STARTTLS command is received on an Implicit TLS port.
  • MUST NOTOnce a client issues a STARTTLS command, it MUST NOT issue further commands until a server response is seen and the TLS negotiation is complete.
  • MUSTIn order to avoid this vulnerability, server implementations MUST do one of the following if any data is received in the same TCP buffer after the CRLF that starts the STARTTLS command:
  • MUSTOnce TLS has been started, the client MUST discard cached information about server capabilities and SHOULD reissue the CAPABILITY command.
  • MAYThe server MAY advertise different capabilities and, in particular, SHOULD NOT advertise the STARTTLS capability, after a successful STARTTLS command.

6.2.2 AUTHENTICATE Command

  • OPTIONALOPTIONAL initial response
  • MAYIt MAY also negotiate an OPTIONAL security layer for subsequent protocol interactions.
  • SHOULDIf the requested authentication mechanism is not supported, the server SHOULD reject the AUTHENTICATE command by sending a tagged NO response.
  • MUSTIf the server receives such a response, or if it receives an invalid base64 string (e.g., characters outside the base64 alphabet or non-terminal "="), it MUST reject the AUTHENTICATE command by sending a tagged BAD response.
  • MUSTAs with any other client response, the initial response MUST be encoded as base64.
  • MUSTIt also MUST be transmitted outside of a quoted string or literal.
  • MUSTTo send a zero-length initial response, the client MUST send a single pad character ("=").
  • MUSTWhen decoding the base64 data in the initial response, decoding errors MUST be treated as in any normal SASL client response, i.e., with a tagged BAD response.
  • MUSTIf the client uses an initial response with a SASL mechanism that does not support an initial response, the server MUST reject the command with a tagged BAD response.
  • MUSTWhile client and server implementations MUST implement the AUTHENTICATE command itself, it is not required to implement any authentication mechanisms other than the PLAIN mechanism described in [PLAIN].
  • MUSTNote: a server implementation MUST implement a configuration in which it does NOT permit any plaintext password mechanisms, unless the STARTTLS command has been negotiated, TLS has been negotiated on an Implicit TLS port, or some other mechanism that protects the session from password snooping has been provided.
  • SHOULD NOTServer sites SHOULD NOT use any configuration that permits a plaintext password mechanism without such a protection mechanism against password snooping.
  • SHOULDClient and server implementations SHOULD implement additional [SASL] mechanisms that do not use plaintext passwords, such as the GSSAPI mechanism described in [RFC4752], the SCRAM- SHA-256/SCRAM-SHA-256-PLUS [SCRAM-SHA-256] mechanisms, and/or the EXTERNAL [SASL] mechanism for mutual TLS authentication.
  • SHOULDThe server SHOULD list its supported authentication mechanisms in the response to the CAPABILITY command so that the client knows which authentication mechanisms to use.
  • MAYA server MAY include a CAPABILITY response code in the tagged OK response of a successful AUTHENTICATE command in order to send capabilities automatically.
  • MAYThe server MAY advertise different capabilities after a successful AUTHENTICATE command.
  • MAYIf an AUTHENTICATE command fails with a NO response, the client MAY try another authentication mechanism by issuing another AUTHENTICATE command.
  • MAYIt MAY also attempt to authenticate by using the LOGIN command (see Section 6.2.3 for more detail).
  • MAYIn other words, the client MAY request authentication types in decreasing order of preference, with the LOGIN command as a last resort.
  • MUSTNote that because the initial response is optional, the following negotiation (which does not use the initial response) is still valid and MUST be supported by the server:

6.2.3 LOGIN Command

  • SHOULD NOTThe LOGIN command SHOULD NOT be used except as a last resort (after attempting and failing to authenticate using the AUTHENTICATE command one or more times), and it is recommended that client implementations have a means to disable any automatic use of the LOGIN command.
  • MAYA server MAY include a CAPABILITY response code in the tagged OK response to a successful LOGIN command in order to send capabilities automatically.
  • MUST NOTFor that reason, clients MUST NOT use LOGIN on unsecure networks.
  • MUSTUnless the client is accessing IMAP service on an Implicit TLS port [RFC8314], the STARTTLS command has been negotiated, or some other mechanism that protects the session from password snooping has been provided, a server implementation MUST implement a configuration in which it advertises the LOGINDISABLED capability and does NOT permit the LOGIN command.
  • SHOULD NOTServer sites SHOULD NOT use any configuration that permits the LOGIN command without such a protection mechanism against password snooping.
  • MUST NOTA client implementation MUST NOT send a LOGIN command if the LOGINDISABLED capability is advertised.

6.3.1 ENABLE Command

  • MUST* If the argument is not an extension known to the server, the server MUST ignore the argument.
  • MUST* If the argument is an extension known to the server, and it is not specifically permitted to be enabled using ENABLE, the server MUST ignore the argument.
  • MUST* If the argument is an extension that is supported by the server and that needs to be enabled, the server MUST enable the extension for the duration of the connection.
  • MUSTIf the ENABLE command is successful, the server MUST send an untagged ENABLED response (Section 7.2.1), which includes all enabled extensions as specified above.
  • SHOULDClients SHOULD only include extensions that need to be enabled by the server.
  • MUST NOTClients MUST NOT issue ENABLE once they SELECT/EXAMINE a mailbox; however, server implementations don't have to check that no mailbox is selected or was previously selected during the duration of a connection.
  • SHOULDWhen multiple ENABLE commands are issued, each corresponding ENABLED response SHOULD only contain extensions enabled by the corresponding ENABLE command, i.e., for the above example, the ENABLED response to "ENABLE c" should not contain "a" or "b".
  • MUST NOTThe server MUST NOT change the CAPABILITY list as a result of executing ENABLE; that is, a CAPABILITY command issued right after an ENABLE command MUST list the same capabilities as a CAPABILITY command issued before the ENABLE command.

6.3.2 SELECT Command

  • REQUIREDResponses: REQUIRED untagged responses: FLAGS, EXISTS, LIST REQUIRED OK untagged responses: PERMANENTFLAGS, UIDNEXT, UIDVALIDITY
  • MUSTBefore returning an OK to the client, the server MUST send the following untagged data to the client.
  • MUSTLIST The server MUST return a LIST response with the mailbox name.
  • MUSTThe list of mailbox attributes MUST be accurate.
  • MUSTIf the server allows denormalized UTF-8 mailbox names (see Section 5.1) and the supplied mailbox name differs from the normalized version, the server MUST return LIST with the OLDNAME extended data item.
  • MUSTWhen deselecting a selected mailbox, the server MUST return an untagged OK response with the "[CLOSED]" response code when the currently selected mailbox is closed (see Section 7.1).
  • SHOULDIf the client is permitted to modify the mailbox, the server SHOULD prefix the text of the tagged OK response with the "[READ-WRITE]" response code.
  • MUSTIf the client is not permitted to modify the mailbox but is permitted read access, the mailbox is selected as read-only, and the server MUST prefix the text of the tagged OK response to SELECT with the "[READ-ONLY]" response code.
  • MAYRead-only access through SELECT differs from the EXAMINE command in that certain read-only mailboxes MAY permit the change of permanent state on a per-user (as opposed to global) basis.

6.3.3 EXAMINE Command

  • MUSTThe text of the tagged OK response to the EXAMINE command MUST begin with the "[READ-ONLY]" response code.

6.3.4 CREATE Command

  • OPTIONALResponses: OPTIONAL untagged response: LIST
  • MUSTIf a client attempts to create a UTF-8 mailbox name that is not a valid Net-Unicode name, the server MUST reject the creation or convert the name to Net-Unicode prior to creating the mailbox.
  • SHOULDIf the server decides to convert (normalize) the name, it SHOULD return an untagged LIST with an OLDNAME extended data item, with the OLDNAME value being the supplied mailbox name and the name parameter being the normalized mailbox name.
  • MAYMailboxes created in one IMAP session MAY be announced to other IMAP sessions using an unsolicited LIST response.
  • MUSTIf the server automatically subscribes a mailbox when it is created, then the unsolicited LIST response for each affected subscribed mailbox name MUST include the \Subscribed attribute.
  • MUSTServer implementations that do not require this declaration MUST ignore the declaration.
  • SHOULDIf the server's hierarchy separator character appears elsewhere in the name, the server SHOULD create any superior hierarchical names that are needed for the CREATE command to be successfully completed.
  • SHOULDIn other words, an attempt to create "foo/bar/zap" on a server in which "/" is the hierarchy separator character SHOULD create foo/ and foo/bar/ if they do not already exist.
  • MUSTIf a new mailbox is created with the same name as a mailbox that was deleted, its unique identifiers MUST be greater than any unique identifiers used in the previous incarnation of the mailbox unless the new incarnation has a different unique identifier validity value.

6.3.5 DELETE Command

  • MUST NOTThe DELETE command MUST NOT remove inferior hierarchical names.
  • MUST NOTFor example, if a mailbox "foo" has an inferior "foo.bar" (assuming "." is the hierarchy delimiter character), removing "foo" MUST NOT remove "foo.bar".
  • SHOULDIf the server implementation does not permit deleting the name while inferior hierarchical names exist, then it SHOULD disallow the DELETE command by returning a tagged NO response.
  • SHOULDThe NO response SHOULD include the HASCHILDREN response code.
  • MAYAlternatively, the server MAY allow the DELETE command, but it sets the \Noselect mailbox name attribute for that name.
  • MUSTThe value of the highest-used unique identifier of the deleted mailbox MUST be preserved so that a new mailbox created with the same name will not reuse the identifiers of the former incarnation, unless the new incarnation has a different unique identifier validity value.
  • SHOULDIf the server decides to convert (normalize) the mailbox name, it SHOULD return an untagged LIST with the "\NonExistent" attribute and OLDNAME extended data item, with the OLDNAME value being the supplied mailbox name and the name parameter being the normalized mailbox name.
  • MAYMailboxes deleted in one IMAP session MAY be announced to other IMAP sessions using an unsolicited LIST response, containing the "\NonExistent" attribute.

6.3.6 RENAME Command

  • MUSTIf the name has inferior hierarchical names, then the inferior hierarchical names MUST also be renamed.
  • SHOULDIf the server's hierarchy separator character appears in the new mailbox name, the server SHOULD create any superior hierarchical names that are needed for the RENAME command to complete successfully.
  • SHOULDIn other words, an attempt to rename "foo/bar/zap" to "baz/rag/zowie" on a server in which "/" is the hierarchy separator character in the corresponding namespace SHOULD create "baz/" and "baz/rag/" if they do not already exist.
  • MUSTThe value of the highest-used unique identifier of the old mailbox name MUST be preserved so that a new mailbox created with the same name will not reuse the identifiers of the former incarnation, unless the new incarnation has a different unique identifier validity value.
  • SHOULDIf the normalized version of any of these 2 parameters differs from the corresponding supplied version, the server SHOULD return an untagged LIST response with an OLDNAME extended data item, with the OLDNAME value being the supplied existing mailbox name and the name parameter being the normalized new mailbox name (see Section 6.3.9.7).
  • MAYMailboxes renamed in one IMAP session MAY be announced to other IMAP sessions using an unsolicited LIST response with an OLDNAME extended data item.
  • MUSTIn both of the above cases, if the server automatically subscribes a mailbox when it is renamed, then the unsolicited LIST response for each affected subscribed mailbox name MUST include the \Subscribed attribute.

6.3.7 SUBSCRIBE Command

  • MAYA server MAY validate the mailbox argument to SUBSCRIBE to verify that it exists.
  • SHOULD NOTHowever, it SHOULD NOT unilaterally remove an existing mailbox name from the subscription list even if a mailbox by that name no longer exists.

6.3.9 LIST Command

  • OPTIONALArguments (extended): selection options (OPTIONAL) reference name mailbox patterns return options (OPTIONAL)
  • SHOULDThe LIST command SHOULD return its data quickly, without undue delay.
  • MUSTThe returned mailbox names MUST match the supplied mailbox name pattern(s).
  • SHOULDClients SHOULD use the empty reference argument.
  • MAYThe value returned as the root MAY be the empty string if the reference is non-rooted or is an empty string.
  • SHOULD NOTA client SHOULD NOT use such a reference argument except at the explicit request of the user.
  • MUST NOTA hierarchical browser MUST NOT make any assumptions about server interpretation of the reference unless the reference is a level of mailbox hierarchy AND ends with the hierarchy delimiter.
  • SHOULDAny part of the reference argument that is included in the interpreted form SHOULD prefix the interpreted form.
  • SHOULDIt SHOULD also be in the same form as the reference name argument.
  • SHOULD NOTNote that "~smith/Mail" SHOULD NOT be transformed into something like "/u2/users/smith/Mail", or it would be impossible for the client to determine that the interpretation was in the context of the reference.
  • MUSTAny syntactically valid pattern that is not accepted by a server for any reason MUST be silently ignored, i.e., it results in no LIST responses, and the LIST command still returns a tagged OK response.
  • MUST NOTReturn options MUST NOT cause the server to report information about additional mailbox names other than those that match the canonical LIST patterns and selection options.
  • MAYThe server MAY return other information about the matched mailboxes, and clients MUST be able to handle that situation.
  • MUSTInitial options defined in this document MUST be supported.
  • MUST NOTEach non-initial option will be enabled by a capability string (one capability may enable multiple options), and a client MUST NOT send an option for which the server has not advertised support.
  • MUSTA server MUST respond to options it does not recognize with a BAD response.
  • SHOULD NOTThe client SHOULD NOT specify any option more than once; however, if the client does this, the server MUST act as if it received the option only once.

6.3.9.1 LIST Selection Options

  • MUSTIn any case, the list MUST include exactly those mailbox names that match the canonical list pattern and are subscribed to.
  • MUSTThe "\Subscribed" attribute MUST be supported and MUST be accurately computed when the SUBSCRIBED selection option is specified.
  • MUSTThe "\Remote" attribute MUST be accurately computed when the REMOTE option is specified.
  • MUST NOTThe RECURSIVEMATCH option MUST NOT occur as the only selection option (or only with REMOTE), as it only makes sense when other selection options are also used.
  • MUSTThe server MUST return a BAD tagged response in such case.
  • MUSTNote that even if the RECURSIVEMATCH option is specified, the client MUST still be able to handle cases when a CHILDINFO extended data item is returned and there are no submailboxes that meet the selection criteria of the subsequent LIST command, as they can be deleted/renamed after the LIST response was sent but before the client had a chance to access them.

6.3.9.2 LIST Return Options

  • MUSTThe "\Subscribed" attribute MUST be supported and MUST be accurately computed when the SUBSCRIBED return option is specified.
  • MUSTFurthermore, all other mailbox attributes MUST be accurately computed (this differs from the behavior of the obsolete LSUB command from [RFC3501]).
  • MUSTFor each selectable mailbox matching the list pattern and selection options, the server MUST return an untagged LIST response followed by an untagged STATUS response containing the information requested in the STATUS return option, except for some cases described below.
  • MUST NOTIf an attempted STATUS for a listed mailbox fails because the mailbox can't be selected (e.g., if the "l" Access Control List (ACL) right [RFC4314] is granted to the mailbox and the "r" right is not granted, or is due to a race condition between LIST and STATUS changing the mailbox to \NoSelect), the STATUS response MUST NOT be returned, and the LIST response MUST include the \NoSelect attribute.
  • MAYIf the server runs into unexpected problems while trying to look up the STATUS information, it MAY drop the corresponding STATUS reply.

6.3.9.4 Additional LIST-Related Requirements on Clients

  • MUSTAll clients MUST treat a LIST attribute with a stronger meaning as implying any attribute that can be inferred from it.

6.3.9.5 The CHILDREN Return Option

  • MAYThe CHILDREN return option is simply an indication that the client wants information about whether or not mailboxes contain child mailboxes; a server MAY provide it even if the option is not specified.
  • MUSTThe CHILDREN return option defines two new attributes that MUST be returned within a LIST response: \HasChildren and \HasNoChildren.
  • MAYAlthough these attributes MAY be returned in response to any LIST command, the CHILDREN return option is provided to indicate that the client particularly wants this information.
  • MUSTIf the CHILDREN return option is present, the server MUST return these attributes even if their computation is expensive.
  • SHOULD NOTA server SHOULD NOT set this attribute if there are child mailboxes and the user does not have permission to access any of them.
  • SHOULDIn this case, \HasNoChildren SHOULD be used.

6.3.9.6 CHILDINFO Extended Data Item

  • MUST NOTThe CHILDINFO extended data item MUST NOT be returned unless the client has specified the RECURSIVEMATCH selection option.
  • SHOULDAs the CHILDINFO extended data item is not allowed if the RECURSIVEMATCH selection option is not specified, such servers SHOULD use the "\NonExistent \HasChildren" attribute pair to signal to the client that there is a descendant mailbox that matches the selection criteria.
  • SHOULDServers SHOULD only return a non-matching mailbox name along with CHILDINFO if at least one matching child is not also being returned.
  • SHOULDThat is, servers SHOULD suppress redundant CHILDINFO responses.

6.3.9.7 OLDNAME Extended Data Item

  • SHOULDIf the server allows denormalized mailbox names (see Section 5.1) in SELECT/EXAMINE, CREATE, RENAME, or DELETE, it SHOULD return an unsolicited LIST response that includes the OLDNAME extended data item, whenever the supplied mailbox name differs from the resulting normalized mailbox name.

6.3.10 NAMESPACE Command

  • REQUIREDResponses: REQUIRED untagged responses: NAMESPACE
  • MAYThe namespace-response-extensions ABNF non- terminal is defined for extensibility and MAY be included in the NAMESPACE response.
  • MAYAlthough a server will typically support only a single Personal Namespace, and a single Other User's Namespace, circumstances exist where there MAY be multiples of these, and a client MUST be prepared for them.
  • SHOULDIn these situations, a client SHOULD let the user select which namespaces to create the mailbox in, or just use the first Personal Namespace.
  • SHOULDThe next level of hierarchy following the Other Users' Namespace prefix SHOULD consist of <username>, where <username> is a user name as per the LOGIN or AUTHENTICATE command.
  • SHOULD NOTIn response to such a LIST command, a server SHOULD NOT return user names that have not granted access to their personal mailboxes to the user in question.
  • MAYA server MAY return a LIST response containing only the names of users that have explicitly granted access to the user in question.
  • MAYAlternatively, a server MAY return NO to such a LIST command, requiring that a user name be included with the Other Users' Namespace prefix before listing any other user's mailboxes.

6.3.11 STATUS Command

  • REQUIREDResponses: REQUIRED untagged responses: STATUS
  • SHOULD NOTBecause the STATUS command can cause the mailbox to be opened internally, and because this information is available by other means on the selected mailbox, the STATUS command SHOULD NOT be used on the currently selected mailbox.
  • MUSTHowever, servers MUST be able to execute the STATUS command on the selected mailbox.
  • MUST NOTThe STATUS command MUST NOT be used as a "check for new messages in the selected mailbox" operation (refer to Sections 7 and 7.4.1 for more information about the proper method for new message checking).
  • MUSTThis is not strictly required to be an exact value, but it MUST be equal to or greater than the sum of the values of the RFC822.SIZE FETCH message data items (see Section 6.4.5) of all messages in the mailbox.

6.3.12 APPEND Command

  • OPTIONALOPTIONAL flag parenthesized list
  • OPTIONALOPTIONAL date/time string
  • SHOULDThis argument SHOULD be in the format of an [RFC5322] or [I18N-HDRS] message.
  • MUSTA server implementation that is unable to preserve 8-bit data properly MUST be able to reversibly convert 8-bit APPEND data to 7 bits using a [MIME-IMB] content transfer encoding.
  • SHOULDIf a flag parenthesized list is specified, the flags SHOULD be set in the resulting message; otherwise, the flag list of the resulting message is set to "empty" by default.
  • SHOULDIf a date-time is specified, the internal date SHOULD be set in the resulting message; otherwise, the internal date of the resulting message is set to the current date and time by default.
  • MUSTIf the append is unsuccessful for any reason, the mailbox MUST be restored to its state before the APPEND attempt (other than possibly keeping the changed mailbox's UIDNEXT value); no partial appending is permitted.
  • MUSTIf the destination mailbox does not exist, a server MUST return an error and MUST NOT automatically create the mailbox.
  • MUSTUnless it is certain that the destination mailbox cannot be created, the server MUST send the response code "[TRYCREATE]" as the prefix of the text of the tagged NO response.
  • MUST NOTIn the case of a mailbox that has permissions set so that the client can APPEND to the mailbox, but not SELECT or EXAMINE it, the server MUST NOT send an APPENDUID response code as it would disclose information about the mailbox.
  • MAYIn the case of a mailbox that has UIDNOTSTICKY status (see Section 7.1), the server MAY omit the APPENDUID response code as it is not meaningful.
  • SHOULDIf the mailbox is currently selected, normal new message actions SHOULD occur.
  • SHOULDSpecifically, the server SHOULD notify the client immediately via an untagged EXISTS response.
  • MAYIf the server does not do so, the client MAY issue a NOOP command after one or more APPEND commands.
  • SHOULDIf the server decides to convert (normalize) the mailbox name, it SHOULD return an untagged LIST with an OLDNAME extended data item, with the OLDNAME value being the supplied mailbox name and the name parameter being the normalized mailbox name.

6.3.13 IDLE Command

  • MUSTIf the server chooses to send unsolicited FETCH responses, they MUST include a UID FETCH item.
  • MAYAt that point, the server MAY send any remaining queued untagged responses and then MUST immediately send the tagged response to the IDLE command and prepare to process other commands.
  • MUST NOTThe client MUST NOT send a command while the server is waiting for the DONE, since the server will not be able to distinguish a command from a continuation.
  • MAYThe server MAY consider a client inactive if it has an IDLE command running, and if such a server has an inactivity timeout, it MAY log the client off implicitly at the end of its timeout period.

6.4.1 CLOSE Command

  • MAYEven if a mailbox is selected, a SELECT, EXAMINE, or LOGOUT command MAY be issued without previously issuing a CLOSE command.

6.4.4 SEARCH Command

  • OPTIONALArguments: OPTIONAL result specifier
  • OPTIONALOPTIONAL [CHARSET] specification
  • OPTIONALResponses: OPTIONAL untagged response: ESEARCH
  • MUSTAny options not defined by extensions that the server supports MUST be rejected with a BAD response.
  • MUSTClients that support only IMAP4rev2 MUST ignore SEARCH responses.
  • MUST NOTIf the SEARCH results in no matches, the server MUST NOT include the MIN result option in the ESEARCH response; however, it still MUST send the ESEARCH response.
  • MUST NOTIf the SEARCH results in no matches, the server MUST NOT include the MAX result option in the ESEARCH response; however, it still MUST send the ESEARCH response.
  • MUST NOTNote that the client MUST NOT assume that messages/UIDs will be listed in any particular order.
  • MUST NOTIf the SEARCH results in no matches, the server MUST NOT include the ALL result option in the ESEARCH response; however, it still MUST send the ESEARCH response.
  • MUSTThis result option MUST always be included in the ESEARCH response.
  • MUSTHowever, all options specified above MUST result in a single ESEARCH response if used by themselves or in combination.
  • MAYServer implementations MAY exclude [MIME-IMB] body parts with terminal content media types other than TEXT and MESSAGE from consideration in SEARCH matching.
  • OPTIONALThe OPTIONAL [CHARSET] specification consists of the word "CHARSET" followed by the name of a character set from the registry [CHARSET-REG].
  • MUST[MIME-IMB] content transfer encodings and [MIME-HDRS] strings in [RFC5322]/[MIME-IMB] headers MUST be decoded before comparing text.
  • MUSTServers MUST support US-ASCII and UTF-8 charsets; other CHARSETs MAY be supported.
  • SHOULDClients SHOULD use UTF-8.
  • MUSTNote that if CHARSET is not provided, IMAP4rev2 servers MUST assume UTF-8, so selecting CHARSET UTF-8 is redundant.
  • MUSTIf the server does not support the specified [CHARSET], it MUST return a tagged NO response (not a BAD).
  • SHOULDThis response SHOULD contain the BADCHARSET response code, which MAY list the CHARSETs supported by the server.
  • SHOULDThe matching SHOULD be case insensitive for characters within the ASCII range.

6.4.4.1 SAVE Result Option and SEARCH Result Variable

  • MUST NOTAny of the following SEARCH commands MUST NOT change the search result variable:
  • MUSTImplementors are reminded that if the server stores the list as a list of message numbers, it MUST automatically adjust them when notifying the client about expunged messages, as described in Section 7.5.1.

6.4.4.2 Multiple Commands in Progress

  • MUSTAs directed by Section 5.5, a server MUST execute the two commands in the order they were received.
  • MAYA client MAY pipeline a SEARCH RETURN (SAVE) command with one or more commands using the "$" marker, as long as this doesn't create an ambiguity, as described in Section 5.5.

6.4.4.3 Refusing to Save Search Results

  • MAYIn some cases, the server MAY refuse to save a SEARCH (SAVE) result, for example, if an internal limit on the number of saved results is reached.
  • MUSTIn this case, the server MUST return a tagged NO response containing the NOTSAVED response code and set the search result variable to the empty sequence, as described in Section 6.4.4.1.

6.4.5 FETCH Command

  • MUST NOTMost data items, identified in the formal syntax (Section 9) under the msg-att-static rule, are static and MUST NOT change for any particular message.
  • MAYOther data items, identified in the formal syntax under the msg-att-dynamic rule, MAY change either as a result of a STORE command or due to external events.
  • SHOULDThe \Seen flag is implicitly set; if this causes the flags to change, they SHOULD be included as part of the FETCH responses.

6.4.5.1 FETCH Section Specification

  • MUSTIf a particular part is of type message or multipart, its parts MUST be indicated by a period followed by the part number within that nested multipart part.
  • MUSTThe MIME part specifier MUST be prefixed by one or more numeric part specifiers.

6.4.6 STORE Command

  • SHOULDA suffix of ".SILENT" in the data item name prevents the untagged FETCH, and the server SHOULD assume that the client has determined the updated value itself or does not care about the updated value.
  • SHOULDNote: Regardless of whether or not the ".SILENT" suffix was used, the server SHOULD send an untagged FETCH response if a change to a message's flags from an external source is observed.

6.4.7 COPY Command

  • SHOULDThe flags and internal date of the message(s) SHOULD be preserved in the copy.
  • MUSTIf the destination mailbox does not exist, a server MUST return an error.
  • MUST NOTIt MUST NOT automatically create the mailbox.
  • MUSTUnless it is certain that the destination mailbox can not be created, the server MUST send the response code "[TRYCREATE]" as the prefix of the text of the tagged NO response.
  • MUSTIf the COPY command is unsuccessful for any reason, server implementations MUST restore the destination mailbox to its state before the COPY attempt (other than possibly incrementing UIDNEXT), i.e., partial copy MUST NOT be done.
  • MUST NOTIn the case of a mailbox that has permissions set so that the client can COPY to the mailbox, but not SELECT or EXAMINE it, the server MUST NOT send a COPYUID response code as it would disclose information about the mailbox.
  • MAYIn the case of a mailbox that has UIDNOTSTICKY status (see Section 7.1), the server MAY omit the COPYUID response code as it is not meaningful.

6.4.8 MOVE Command

  • SHOULDThe flags and internal date of the message(s) SHOULD be preserved.
  • MUST NOTIn particular, though the COPY and EXPUNGE response codes will be returned, response codes for a STORE MUST NOT be generated, and the \Deleted flag MUST NOT be set for any message.
  • MUSTRegardless of whether the command is successful in moving the entire set, each individual message MUST be either moved or unaffected.
  • MUSTThe server MUST leave each message in a state where it is in at least one of the source or target mailboxes (no message can be lost or orphaned).
  • SHOULD NOTThe server SHOULD NOT leave any message in both mailboxes (it would be bad for a partial failure to result in a bunch of duplicate messages).
  • REQUIREDServers are also REQUIRED to send the COPYUID response code in an untagged OK before sending EXPUNGE or similar responses.

6.4.9 UID Command

  • MUSTAlso, the corresponding ESEARCH response MUST include the UID indicator.
  • MUSTHowever, server implementations MUST implicitly include the UID message data item as part of any FETCH response caused by a UID command, regardless of whether a UID was specified as a message data item to the FETCH.

6.5 Client Commands - Experimental/Expansion

  • MUSTEach command that is not part of this specification MUST have at least one capability name (see Section 6.1.1) associated with it.
  • MUST NOTServer implementations MUST NOT send any added untagged responses (not specified in this specification), unless the client requested it by issuing the associated experimental command (specified in an extension document) or the ENABLE command (Section 6.3.1).

7 Server Responses

  • MUSTThe client MUST be prepared to accept any response at all times.
  • MUSTCertain server data MUST be remembered by the client when it is received; this is noted in the description of that data.
  • SHOULDOther server data SHOULD be remembered for later reference; if the client does not need to remember the data, or if remembering the data has no obvious purpose (e.g., a SEARCH response when no SEARCH command is in progress), the data can be ignored.
  • SHOULDServer implementations that offer multiple simultaneous access to the same mailbox SHOULD also send appropriate unilateral untagged FETCH and EXPUNGE responses if another agent changes the state of any message flags or expunges any messages.

7.1 Server Responses - Generic Status Responses

  • MAYStatus responses MAY include an OPTIONAL "response code".
  • SHOULDContent of ALERT response codes received on a connection without TLS or SASL security-layer confidentiality SHOULD be ignored by clients.
  • MUSTIf displayed, such alerts MUST be clearly marked as potentially suspicious.
  • MUST(Note that some existing clients are known to hyperlink returned text, which make them very dangerous.) Alerts received after successful establishment of a TLS/SASL confidentiality layer MUST be presented to the user.
  • MUST NOTNote: the UID set form of the APPENDUID response code MUST NOT be used if only a single message was appended.
  • MUST NOTIn particular, a server MUST NOT send a range such as 123:123.
  • MUSTHowever, if the server has a limit on the number of different keywords that can be stored in a mailbox and that limit is reached, the server MUST send a new PERMANENTFLAGS response code without the special flag \*.
  • SHOULD NOTNote: servers SHOULD NOT have any UIDNOTSTICKY mail stores.
  • MUSTClient implementations MUST ignore response codes that they do not recognize.

7.1.1 OK Response

  • OPTIONALContents: OPTIONAL response code human-readable text
  • MAYThe human-readable text MAY be presented to the user as an information message.
  • MAYThe untagged form indicates an information-only message; the nature of the information MAY be indicated by a response code.

7.1.4 PREAUTH Response

  • SHOULDFor this reason, the PREAUTH response SHOULD only be returned by servers on connections that are protected by TLS (such as on an Implicit TLS port [RFC8314]) or protected through other means such as IPsec.
  • MUSTClients that require mandatory TLS MUST close the connection after receiving the PREAUTH response on a non-protected port.

7.1.5 BYE Response

  • MAYThe human-readable text MAY be displayed to the user in a status report by the client.
  • SHOULDIn all cases, the client SHOULD continue to read response data from the server until the connection is closed; this will ensure that any pending untagged or completion responses are read and processed.

7.2.2 CAPABILITY Response

  • MUSTThe capability listing MUST include the atom "IMAP4rev2", but note that it doesn't have to be the first capability listed.
  • MUSTClient and server implementations MUST implement the capabilities "AUTH=PLAIN" (described in [PLAIN]), and MUST implement "STARTTLS" and "LOGINDISABLED" on the cleartext port.
  • MUST NOTAn IMAP client MUST NOT issue the LOGIN command if the server advertises the LOGINDISABLED capability.
  • MUSTIf IMAP4rev1 capability is not advertised, server responses MUST conform to this document until the client issues a command that uses an additional capability.
  • MUSTIf both IMAP4rev1 and IMAP4rev2 capabilities are advertised, server responses MUST conform to [RFC3501] until the client issues a command that uses an additional capability.
  • SHOULDCapability names SHOULD be registered with IANA using the RFC Required policy [RFC8126].
  • SHOULD NOTA server SHOULD NOT offer unregistered capability names.
  • SHOULD NOTClient implementations SHOULD NOT require any capability name other than "IMAP4rev2", and possibly "STARTTLS" and "LOGINDISABLED" (on a cleartext port).
  • MUSTClient implementations MUST ignore any unknown capability names.
  • MAYA server MAY send capabilities automatically, by using the CAPABILITY response code in the initial PREAUTH or OK responses and by sending an updated CAPABILITY response code in the tagged OK response as part of a successful authentication.
  • MAYThe list of capabilities returned by a server MAY change during the connection.

7.3.1 LIST Response

  • OPTIONALContents: name attributes hierarchy delimiter name OPTIONAL extension data
  • SHOULD NOTIf it is not feasible for the server to determine whether or not the mailbox is "interesting", the server SHOULD NOT send either \Marked or \Unmarked.
  • MUST NOTThe server MUST NOT send more than one of \Marked, \Unmarked, and \Noselect for a single mailbox, and it MAY send none of these.
  • MAYIn addition to the base mailbox name attributes defined above, an IMAP server MAY also include any or all of the following attributes that denote "role" (or "special-use") of a mailbox.
  • MAYImplementations MAY omit some messages, such as, perhaps, those in \Trash and \Junk.
  • OPTIONALAll special-use attributes are OPTIONAL, and any given server or message store may support any combination of the attributes, or none at all.
  • MUSTAll children of a top-level hierarchy node MUST use the same separator character.
  • MUSTThe name represents an unambiguous left-to-right hierarchy and MUST be valid for use as a reference in LIST command.
  • MUSTUnless \Noselect or \NonExistent is indicated, the name MUST also be valid as an argument for commands, such as SELECT, that accept mailbox names.
  • OPTIONALThe name might be followed by an OPTIONAL series of extended fields, a parenthesized list of tagged data (also referred to as an "extended data item").
  • MUST[RFC5258] specifies requirements on string registration (which are called "tags"; such tags are not to be confused with IMAP command tags); in particular, it states that "Tags MUST be registered with IANA".
  • MAYThe server MAY return data in the extended fields that was not directly solicited by the client in the corresponding LIST command.
  • MUSTThe client MUST ignore all extended fields it doesn't recognize.

7.3.2 NAMESPACE Response

  • MAYThe Namespace-Response- Extensions ABNF non-terminal is defined for extensibility and MAY be included in the response.

7.3.4 ESEARCH Response

  • SHOULDUnless otherwise specified by an extension, any return item name SHOULD appear only once in an ESEARCH response.
  • MUST NOTIf the SEARCH results in no matches, the server MUST NOT include the MIN return item in the ESEARCH response; however, it still MUST send the ESEARCH response.
  • MUST NOTIf the SEARCH results in no matches, the server MUST NOT include the MAX return item in the ESEARCH response; however, it still MUST send the ESEARCH response.
  • MUSTEach set MUST be complete; in particular, a UID set is returned in an ESEARCH response only when each number in the range corresponds to an existing (matching) message.
  • MUST NOTThe client MUST NOT assume that messages/UIDs will be listed in any particular order.
  • MUST NOTIf the SEARCH results in no matches, the server MUST NOT include the ALL return item in the ESEARCH response; however, it still MUST send the ESEARCH response.
  • MUSTThis return item MUST always be included in the ESEARCH response.

7.3.5 FLAGS Response

  • MUSTThe update from the FLAGS response MUST be remembered by the client.

7.4.1 EXISTS Response

  • MUSTThe update from the EXISTS response MUST be remembered by the client.

7.5.1 EXPUNGE Response

  • MUST NOTAn EXPUNGE response MUST NOT be sent when no command is in progress, nor while responding to a FETCH, STORE, or SEARCH command.
  • MAYAn EXPUNGE response MAY be sent during a UID command.
  • MUSTThe update from the EXPUNGE response MUST be remembered by the client.

7.5.2 FETCH Response

  • SHOULDIf the domain of the decoded data is "8bit" and the data does not contain the NUL octet, the server SHOULD return the data in a <string> instead of a <literal8>; this allows the client to determine if the "8bit" data contains the NUL octet without having to explicitly scan the data stream for NULs.
  • MUSTWhen sending data in a BINARY[...] FETCH data item, servers MUST ensure that textual line-oriented sections are always transmitted using the IMAP CRLF line termination syntax, regardless of the underlying storage representation of the data on the server.
  • MUSTIf the server does not know how to decode the section's Content- Transfer-Encoding, it MUST fail the request and issue a "NO" response that contains the "UNKNOWN-CTE" response code.
  • MUSTThe value returned MUST match the size of the <nstring> or <literal8> that will be returned by the corresponding FETCH BINARY request.
  • SHOULDThe string SHOULD be interpreted by the client according to the content transfer encoding, body type, and subtype.
  • MAYThis means that BODY[]<0> MAY be truncated, but BODY[] is NEVER truncated.
  • MUST NOTNote: The origin octet facility MUST NOT be used by a server in a FETCH response unless the client specifically requested it by means of a FETCH of a BODY[<section>]<<partial>> data item.
  • MAYNote that headers (part specifiers HEADER or MIME, or the header portion of a MESSAGE/RFC822 or MESSAGE/GLOBAL part) MAY be in UTF- 8.
  • MUSTNon-textual data such as binary data MUST be transfer encoded into a textual form, such as base64, prior to being sent to the client.
  • MUSTTo derive the original binary data, the client MUST decode the transfer-encoded string.
  • MUSTExtension data, if present, MUST be in the defined order.
  • SHOULDServers SHOULD decode parameter-value continuations and parameter-value character sets as described in [RFC2231], for example, if the message contains parameters "baz*0", "baz*1", and "baz*2", the server should decode them per [RFC2231], concatenate, and return the resulting value as a parameter "baz".
  • SHOULDServers SHOULD decode parameter-value continuations as described in [RFC2231].
  • MUSTClient implementations that do a BODYSTRUCTURE fetch MUST be prepared to accept such extension data.
  • MUST NOTServer implementations MUST NOT send such extension data until it has been defined by a revision of this protocol.
  • SHOULDClients SHOULD treat NIL and the empty string as identical.
  • MUSTIf the server chooses to send unsolicited FETCH responses, they MUST include UID FETCH item.

9 Formal Syntax

  • MUSTIn the case of alternative or optional rules in which a later rule overlaps an earlier rule, the rule that is listed earlier MUST take priority.
  • MUSTNote: [ABNF] rules MUST be followed strictly; in particular:
  • MUSTImplementations MUST accept these strings in a case-insensitive fashion.
  • MUST NOTThe ASCII NUL character, %x00, MUST NOT be used anywhere, with the exception of the OCTET production.
  • MUSTClient implementations ; MUST accept body-extension fields.
  • MUST NOTServer ; implementations MUST NOT generate ; body-extension fields except as defined by ; future Standard or Standards Track ; revisions of this specification.
  • MUST NOTbody-ext-1part = body-fld-md5 [SP body-fld-dsp [SP body-fld-lang [SP body-fld-loc *(SP body-extension)]]] ; MUST NOT be returned on non-extensible ; "BODY" fetch
  • MUST NOTbody-ext-mpart = body-fld-param [SP body-fld-dsp [SP body-fld-lang [SP body-fld-loc *(SP body-extension)]]] ; MUST NOT be returned on non-extensible ; "BODY" fetch
  • MUST NOTbody-type-basic = media-basic SP body-fields ; MESSAGE subtype MUST NOT be "RFC822" or ; "GLOBAL"
  • SHOULDcapability = ("AUTH=" auth-type) / atom ; New capabilities SHOULD be ; registered with IANA using the ; RFC Required policy, i.e., in ; a Standards Track, an Experimental, ; or an Informational RFC.
  • MUST; Servers that offer RFC 1730 compatibility MUST ; list "IMAP4" as the first capability.
  • MUST; Servers that offer RFC 3501 compatibility MUST ; list "IMAP4rev1" as one of the capabilities.
  • MUSTClient implementations ; MUST accept flag-extension flags.
  • MUST NOTServer ; implementations MUST NOT generate ; flag-extension flags except as defined by ; a future Standard or Standards Track ; revisions of this specification.
  • MUSTAll case variants ; of INBOX (e.g., "iNbOx") MUST be interpreted as ; INBOX, not as an astring.
  • MUSTmbox-list-extended-item-tag = astring ; The content MUST conform to either ; "eitem-vendor-tag" or "eitem-standard-tag" ; ABNF productions.
  • MAYmsg-att-dynamic = "FLAGS" SP "(" [flag-fetch *(SP flag-fetch)] ")" ; MAY change for a message
  • MUST NOTmsg-att-static = "ENVELOPE" SP envelope / "INTERNALDATE" SP date-time / "RFC822.SIZE" SP number64 / "BODY" ["STRUCTURE"] SP body / "BODY" section ["<" number ">"] SP nstring / "BINARY" section-binary SP (nstring / literal8) / "BINARY.SIZE" section-binary SP number / "UID" SP uniqueid ; MUST NOT change for a message
  • MUST NOTname-component = 1*UTF8-CHAR ; MUST NOT contain ".", "/", "%", or "*"
  • MUSTsearch-program = ["CHARSET" SP charset SP] search-key *(SP search-key) ; CHARSET argument to SEARCH MUST be ; registered with IANA.
  • MAY; Servers MAY coalesce overlaps and/or execute ; the sequence in any order.
  • MAY; Example: a message sequence number set of ; 2,4:7,9,12:* for a mailbox with 15 messages is ; equivalent to 2,4,5,6,7,9,12,13,14,15 ; Example: a message sequence number set of ; *:4,5:7 for a mailbox with 10 messages is ; equivalent to 10,9,8,7,6,5,4,5,6,7 and MAY ; be reordered and overlap coalesced to be ; 4,5,6,7,8,9,10.
  • MUST; MUST be registered with IANA

11.1 TLS-Related Security Considerations

  • MUSTIMAP client and server implementations MUST comply with relevant TLS recommendations from [RFC8314].
  • MUSTClients and servers MUST implement TLS 1.2 [TLS-1.2] or newer.
  • RECOMMENDEDUse of TLS 1.3 [TLS-1.3] is RECOMMENDED.
  • MUSTAdditionally, when using TLS 1.2, IMAP implementations MUST implement the TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 cipher suite.
  • RECOMMENDEDOther 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.
  • OPTIONALAll other cipher suites are OPTIONAL.
  • MUSTDuring 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.
  • MUSTBoth 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

  • MUSTFor 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.
  • MUSTThe server MUST implement TLS negotiation on an Implicit TLS port.
  • SHOULDThe server SHOULD also implement IMAP on a cleartext port.
  • MUSTIf the server listens on a cleartext port, it MUST allow the STARTTLS command on it.
  • SHOULDFor 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].

11.3 Client Handling of Unsolicited Responses Not Suitable for the

  • SHOULDBefore 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.
  • SHOULD(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.
  • MUSTUnless 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

  • SHOULD NOTConsequently, 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

  • MUST NOTIn 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.

11.7 Other Security Considerations

  • SHOULD NOTA server error message for an AUTHENTICATE command that fails due to invalid credentials SHOULD NOT detail why the credentials are invalid.
  • MUSTA server implementation MUST implement a configuration that, at the time of authentication, requires:
  • SHOULD NOTA server error message for a failing LOGIN command SHOULD NOT specify that the user name, as opposed to the password, is invalid.
  • SHOULDA server SHOULD have mechanisms in place to limit or delay failed AUTHENTICATE/LOGIN attempts.
  • SHOULDA 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].
  • MUSTAccounts 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.
  • SHOULDOnly a password with significant strength SHOULD be accepted.

13.2.2 Historical Aspects of IMAP and Related Protocols

  • MUSTIf both IMAP4rev1 and IMAP4rev2 are advertised, an IMAP client that wants to use IMAP4rev2 MUST issue an "ENABLE IMAP4rev2" command.
  • MUST NOTServers advertising both IMAP4rev1 and IMAP4rev2 MUST NOT generate UTF-8-quoted strings unless the client has issued "ENABLE IMAP4rev2".
  • MUSTServers 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.
  • MUST NOTModified base64 MUST NOT be used to represent any printing of a US-ASCII character that can represent itself.
  • MUSTHowever, 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 "-".
  • MUSTIn 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.
  • SHOULDServer 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.
  • MUST NOTHowever, 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.
  • MUSTServer 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.
  • SHOULDAdded SHOULD level requirement on IMAP servers to support $MDNSent, $Forwarded, $Junk, $NonJunk, and $Phishing keywords.
  • MUSTClarified that client implementations MUST ignore response codes that they do not recognize.
  • SHOULD(Changed from a SHOULD to a MUST.)
  • MAYMAX (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
  • NOT RECOMMENDEDNAMESPACE (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
  • OPTIONALOK (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
  • RECOMMENDEDREAD-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

Every current email RFC