9. Formal Syntax
The following syntax specification uses the Augmented Backus-Naur
Form (ABNF) notation as specified in [ABNF].
In the case of alternative or optional rules in which a later rule
overlaps an earlier rule, the rule which is listed earlier MUST take
priority. For example, "\Seen" when parsed as a flag is the \Seen
flag name and not a flag-extension, even though "\Seen" can be parsed
as a flag-extension. Some, but not all, instances of this rule are
Note: [ABNF] rules MUST be followed strictly; in
(1) Except as noted otherwise, all alphabetic characters
are case-insensitive. The use of upper or lower case
characters to define token strings is for editorial clarity
only. Implementations MUST accept these strings in a
(2) In all cases, SP refers to exactly one space. It is
NOT permitted to substitute TAB, insert additional spaces,
or otherwise treat SP as being equivalent to LWSP.
(3) The ASCII NUL character, %x00, MUST NOT be used at any
address = "(" addr-name SP addr-adl SP addr-mailbox SP
addr-adl = nstring
; Holds route from [RFC-2822] route-addr if
addr-host = nstring
; NIL indicates [RFC-2822] group syntax.
; Otherwise, holds [RFC-2822] domain name
addr-mailbox = nstring
; NIL indicates end of [RFC-2822] group; if
; non-NIL and addr-host is NIL, holds
; [RFC-2822] group name.
; Otherwise, holds [RFC-2822] local-part
; after removing [RFC-2822] quoting
mailbox = "INBOX" / astring
; INBOX is case-insensitive. All case variants of
; INBOX (e.g., "iNbOx") MUST be interpreted as INBOX
; not as an astring. An astring which consists of
; the case-insensitive sequence "I" "N" "B" "O" "X"
; is considered to be INBOX and not an astring.
; Refer to section 5.1 for further
; semantic details of mailbox names.
mailbox-data = "FLAGS" SP flag-list / "LIST" SP mailbox-list /
"LSUB" SP mailbox-list / "SEARCH" *(SP nz-number) /
"STATUS" SP mailbox SP "(" [status-att-list] ")" /
number SP "EXISTS" / number SP "RECENT"
mailbox-list = "(" [mbx-list-flags] ")" SP
(DQUOTE QUOTED-CHAR DQUOTE / nil) SP mailbox
mbx-list-flags = *(mbx-list-oflag SP) mbx-list-sflag
*(SP mbx-list-oflag) /
mbx-list-oflag *(SP mbx-list-oflag)
mbx-list-oflag = "\Noinferiors" / flag-extension
; Other flags; multiple possible per LIST response
mbx-list-sflag = "\Noselect" / "\Marked" / "\Unmarked"
; Selectability flags; only one per LIST response
media-basic = ((DQUOTE ("APPLICATION" / "AUDIO" / "IMAGE" /
"MESSAGE" / "VIDEO") DQUOTE) / string) SP
; Defined in [MIME-IMT]
media-message = DQUOTE "MESSAGE" DQUOTE SP DQUOTE "RFC822" DQUOTE
; Defined in [MIME-IMT]
media-subtype = string
; Defined in [MIME-IMT]
media-text = DQUOTE "TEXT" DQUOTE SP media-subtype
; Defined in [MIME-IMT]
message-data = nz-number SP ("EXPUNGE" / ("FETCH" SP msg-att))
msg-att = "(" (msg-att-dynamic / msg-att-static)
*(SP (msg-att-dynamic / msg-att-static)) ")"
msg-att-dynamic = "FLAGS" SP "(" [flag-fetch *(SP flag-fetch)] ")"
; MAY change for a message
section-spec = section-msgtext / (section-part ["." section-text])
section-text = section-msgtext / "MIME"
; text other than actual body part (headers, etc.)
select = "SELECT" SP mailbox
seq-number = nz-number / "*"
; message sequence number (COPY, FETCH, STORE
; commands) or unique identifier (UID COPY,
; UID FETCH, UID STORE commands).
; * represents the largest number in use. In
; the case of message sequence numbers, it is
; the number of messages in a non-empty mailbox.
; In the case of unique identifiers, it is the
; unique identifier of the last message in the
; mailbox or, if the mailbox is empty, the
; mailbox's current UIDNEXT value.
; The server should respond with a tagged BAD
; response to a command that uses a message
; sequence number greater than the number of
; messages in the selected mailbox. This
; includes "*" if the selected mailbox is empty.
seq-range = seq-number ":" seq-number
; two seq-number values and all values between
; these two regardless of order.
; Example: 2:4 and 4:2 are equivalent and indicate
; values 2, 3, and 4.
; Example: a unique identifier sequence range of
; 3291:* includes the UID of the last message in
; the mailbox, even if that value is less than 3291.
sequence-set = (seq-number / seq-range) *("," sequence-set)
; set of seq-number values, regardless of order.
; Servers MAY coalesce overlaps and/or execute the
; sequence in any order.
; 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.
status = "STATUS" SP mailbox SP
"(" status-att *(SP status-att) ")"
status-att = "MESSAGES" / "RECENT" / "UIDNEXT" / "UIDVALIDITY" /
status-att-list = status-att SP number *(SP status-att SP number)
store = "STORE" SP sequence-set SP store-att-flags
store-att-flags = (["+" / "-"] "FLAGS" [".SILENT"]) SP
(flag-list / (flag *(SP flag)))
string = quoted / literal
subscribe = "SUBSCRIBE" SP mailbox
tag = 1*<any ASTRING-CHAR except "+">
text = 1*TEXT-CHAR
TEXT-CHAR = <any CHAR except CR and LF>
time = 2DIGIT ":" 2DIGIT ":" 2DIGIT
; Hours minutes seconds
uid = "UID" SP (copy / fetch / search / store)
; Unique identifiers used instead of message
; sequence numbers
uniqueid = nz-number
; Strictly ascending
unsubscribe = "UNSUBSCRIBE" SP mailbox
userid = astring
x-command = "X" atom <experimental command arguments>
zone = ("+" / "-") 4DIGIT
; Signed four-digit value of hhmm representing
; hours and minutes east of Greenwich (that is,
; the amount that the given time differs from
; Universal Time). Subtracting the timezone
; from the given time will give the UT form.
; The Universal Time zone is "+0000".
10. Author's Note
This document is a revision or rewrite of earlier documents, and
supercedes the protocol specification in those documents: RFC 2060,
RFC 1730, unpublished IMAP2bis.TXT document, RFC 1176, and RFC 1064.
11. Security Considerations
IMAP4rev1 protocol transactions, including electronic mail data, are
sent in the clear over the network unless protection from snooping is
negotiated. This can be accomplished either by the use of STARTTLS,
negotiated privacy protection in the AUTHENTICATE command, or some
other protection mechanism.
11.1. STARTTLS Security Considerations
The specification of the STARTTLS command and LOGINDISABLED
capability in this document replaces that in [IMAP-TLS]. [IMAP-TLS]
remains normative for the PLAIN [SASL] authenticator.
IMAP client and server implementations MUST implement the
TLS_RSA_WITH_RC4_128_MD5 [TLS] cipher suite, and SHOULD implement the
TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA [TLS] cipher suite. This is
important as it assures that any two compliant implementations can be
configured to interoperate. All other cipher suites are OPTIONAL.
Note that this is a change from section 2.1 of [IMAP-TLS].
During the [TLS] negotiation, 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 man-in-the-middle
attacks. If the match fails, the client SHOULD either ask for
explicit user confirmation, or terminate the connection and indicate
that the server's identity is suspect. Matching is performed
according to these rules:
The client MUST use the server hostname it used to open the
connection as the value to compare against the server name
as expressed in the server certificate. The client MUST
NOT use any form of the server hostname derived from an
insecure remote source (e.g., insecure DNS lookup). CNAME
canonicalization is not done.
If a subjectAltName extension of type dNSName is present in
the certificate, it SHOULD be used as the source of the
Matching is case-insensitive.
A "*" wildcard character MAY be used as the left-most name
component in the certificate. For example, *.example.com
would match a.example.com, foo.example.com, etc. but would
not match example.com.
If the certificate contains multiple names (e.g., more than
one dNSName field), then a match with any one of the fields
is considered acceptable.
Both the client and server MUST check the result of the STARTTLS
command and subsequent [TLS] negotiation to see whether acceptable
authentication or privacy was achieved.
11.2. Other Security Considerations
A server error message for an AUTHENTICATE command which fails due to
invalid credentials SHOULD NOT detail why the credentials are
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.
(2) Some other mechanism that protects the session from password
snooping has been provided.
(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.
(b) The LOGIN command returns an error even if the password is
(c) The AUTHENTICATE command returns an error with all [SASL]
mechanisms that use plaintext passwords, even if the password
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
A. Normative References
The following documents contain definitions or specifications that
are necessary to understand this document properly:
[ABNF] Crocker, D. and P. Overell, "Augmented BNF for
Syntax Specifications: ABNF", RFC 2234,
[ANONYMOUS] Newman, C., "Anonymous SASL Mechanism", RFC
2245, November 1997.
[CHARSET] Freed, N. and J. Postel, "IANA Character Set
Registration Procedures", RFC 2978, October
[DIGEST-MD5] Leach, P. and C. Newman, "Using Digest
Authentication as a SASL Mechanism", RFC 2831,
[DISPOSITION] Troost, R., Dorner, S. and K. Moore,
"Communicating Presentation Information in
Internet Messages: The Content-Disposition
Header", RFC 2183, August 1997.
[IMAP-TLS] Newman, C., "Using TLS with IMAP, POP3 and
ACAP", RFC 2595, June 1999.
[KEYWORDS] Bradner, S., "Key words for use in RFCs to
Indicate Requirement Levels", BCP 14, RFC 2119,
[LANGUAGE-TAGS] Alvestrand, H., "Tags for the Identification of
Languages", BCP 47, RFC 3066, January 2001.
[LOCATION] Palme, J., Hopmann, A. and N. Shelness, "MIME
Encapsulation of Aggregate Documents, such as
HTML (MHTML)", RFC 2557, March 1999.
[MD5] Myers, J. and M. Rose, "The Content-MD5 Header
Field", RFC 1864, October 1995.
[MIME-HDRS] Moore, K., "MIME (Multipurpose Internet Mail
Extensions) Part Three: Message Header
Extensions for Non-ASCII Text", RFC 2047,
[MIME-IMB] Freed, N. and N. Borenstein, "MIME
(Multipurpose Internet Mail Extensions) Part
One: Format of Internet Message Bodies", RFC
2045, November 1996.
[MIME-IMT] Freed, N. and N. Borenstein, "MIME
(Multipurpose Internet Mail Extensions) Part
Two: Media Types", RFC 2046, November 1996.
[RFC-2822] Resnick, P., "Internet Message Format", RFC
2822, April 2001.
[SASL] Myers, J., "Simple Authentication and Security
Layer (SASL)", RFC 2222, October 1997.
[TLS] Dierks, T. and C. Allen, "The TLS Protocol
Version 1.0", RFC 2246, January 1999.
[UTF-7] Goldsmith, D. and M. Davis, "UTF-7: A Mail-Safe
Transformation Format of Unicode", RFC 2152,
The following documents describe quality-of-implementation issues
that should be carefully considered when implementing this protocol:
[IMAP-IMPLEMENTATION] Leiba, B., "IMAP Implementation
Recommendations", RFC 2683, September 1999.
[IMAP-MULTIACCESS] Gahrns, M., "IMAP4 Multi-Accessed Mailbox
Practice", RFC 2180, July 1997.
A.1 Informative References
The following documents describe related protocols:
[IMAP-DISC] Austein, R., "Synchronization Operations for
Disconnected IMAP4 Clients", Work in Progress.
[IMAP-MODEL] Crispin, M., "Distributed Electronic Mail
Models in IMAP4", RFC 1733, December 1994.
[ACAP] Newman, C. and J. Myers, "ACAP -- Application
Configuration Access Protocol", RFC 2244,
[SMTP] Klensin, J., "Simple Mail Transfer Protocol",
STD 10, RFC 2821, April 2001.
The following documents are historical or describe historical aspects
of this protocol:
[IMAP-COMPAT] Crispin, M., "IMAP4 Compatibility with
IMAP2bis", RFC 2061, December 1996.
[IMAP-HISTORICAL] Crispin, M., "IMAP4 Compatibility with IMAP2
and IMAP2bis", RFC 1732, December 1994.
[IMAP-OBSOLETE] Crispin, M., "Internet Message Access Protocol
- Obsolete Syntax", RFC 2062, December 1996.
[IMAP2] Crispin, M., "Interactive Mail Access Protocol
- Version 2", RFC 1176, August 1990.
[RFC-822] Crocker, D., "Standard for the Format of ARPA
Internet Text Messages", STD 11, RFC 822,
[RFC-821] Postel, J., "Simple Mail Transfer Protocol",
STD 10, RFC 821, August 1982.
B. Changes from RFC 2060
1) Clarify description of unique identifiers and their semantics.
2) Fix the SELECT description to clarify that UIDVALIDITY is required
in the SELECT and EXAMINE responses.
3) Added an example of a failing search.
4) Correct store-att-flags: "#flag" should be "1#flag".
5) Made search and section rules clearer.
6) Correct the STORE example.
7) Correct "BASE645" misspelling.
8) Remove extraneous close parenthesis in example of two-part message
with text and BASE64 attachment.
9) Remove obsolete "MAILBOX" response from mailbox-data.
10) A spurious "<" in the rule for mailbox-data was removed.
11) Add CRLF to continue-req.
12) Specifically exclude "]" from the atom in resp-text-code.
13) Clarify that clients and servers should adhere strictly to the
14) Emphasize in 5.2 that EXISTS can not be used to shrink a mailbox.
15) Add NEWNAME to resp-text-code.
16) Clarify that the empty string, not NIL, is used as arguments to
17) Clarify that NIL can be returned as a hierarchy delimiter for the
empty string mailbox name argument if the mailbox namespace is flat.
18) Clarify that addr-mailbox and addr-name have RFC-2822 quoting
19) Update UTF-7 reference.
20) Fix example in 6.3.11.
21) Clarify that non-existent UIDs are ignored.
22) Update DISPOSITION reference.
23) Expand state diagram.
24) Clarify that partial fetch responses are only returned in
response to a partial fetch command.
25) Add UIDNEXT response code. Correct UIDVALIDITY definition
26) Further clarification of "can" vs. "MAY".
27) Reference RFC-2119.
28) Clarify that superfluous shifts are not permitted in modified
29) Clarify that there are no implicit shifts in modified UTF-7.
30) Clarify that "INBOX" in a mailbox name is always INBOX, even if
it is given as a string.
31) Add missing open parenthesis in media-basic grammar rule.
32) Correct attribute syntax in mailbox-data.
33) Add UIDNEXT to EXAMINE responses.
34) Clarify UNSEEN, PERMANENTFLAGS, UIDVALIDITY, and UIDNEXT
responses in SELECT and EXAMINE. They are required now, but weren't
in older versions.
35) Update references with RFC numbers.
36) Flush text-mime2.
37) Clarify that modified UTF-7 names must be case-sensitive and that
violating the convention should be avoided.
38) Correct UID FETCH example.
39) Clarify UID FETCH, UID STORE, and UID SEARCH vs. untagged EXPUNGE
40) Clarify the use of the word "convention".
41) Clarify that a command is not "in progress" until it has been
fully received (specifically, that a command is not "in progress"
during command continuation negotiation).
42) Clarify envelope defaulting.
43) Clarify that SP means one and only one space character.
44) Forbid silly states in LIST response.
45) Clarify that the ENVELOPE, INTERNALDATE, RFC822*, BODY*, and UID
for a message is static.
46) Add BADCHARSET response code.
47) Update formal syntax to [ABNF] conventions.
48) Clarify trailing hierarchy delimiter in CREATE semantics.
49) Clarify that the "blank line" is the [RFC-2822] delimiting blank
50) Clarify that RENAME should also create hierarchy as needed for
the command to complete.
51) Fix body-ext-mpart to not require language if disposition
52) Clarify the RFC822.HEADER response.
53) Correct missing space after charset astring in search.
54) Correct missing quote for BADCHARSET in resp-text-code.
55) Clarify that ALL, FAST, and FULL preclude any other data items
56) Clarify semantics of reference argument in LIST.
57) Clarify that a null string for SEARCH HEADER X-FOO means any
message with a header line with a field-name of X-FOO regardless of
the text of the header.
58) Specifically reserve 8-bit mailbox names for future use as UTF-8.
59) It is not an error for the client to store a flag that is not in
the PERMANENTFLAGS list; however, the server will either ignore the
change or make the change in the session only.
60) Correct/clarify the text regarding superfluous shifts.
61) Correct typographic errors in the "Changes" section.
62) Clarify that STATUS must not be used to check for new messages in
the selected mailbox
63) Clarify LSUB behavior with "%" wildcard.
64) Change AUTHORIZATION to AUTHENTICATE in section 7.5.
65) Clarify description of multipart body type.
66) Clarify that STORE FLAGS does not affect \Recent.
67) Change "west" to "east" in description of timezone.
68) Clarify that commands which break command pipelining must wait
for a completion result response.
69) Clarify that EXAMINE does not affect \Recent.
70) Make description of MIME structure consistent.
71) Clarify that date searches disregard the time and timezone of the
INTERNALDATE or Date: header. In other words, "ON 13-APR-2000" means
messages with an INTERNALDATE text which starts with "13-APR-2000",
even if timezone differential from the local timezone is sufficient
to move that INTERNALDATE into the previous or next day.
72) Clarify that the header fetches don't add a blank line if one
isn't in the [RFC-2822] message.
73) Clarify (in discussion of UIDs) that messages are immutable.
74) Add an example of CHARSET searching.
75) Clarify in SEARCH that keywords are a type of flag.
76) Clarify the mandatory nature of the SELECT data responses.
77) Add optional CAPABILITY response code in the initial OK or
78) Add note that server can send an untagged CAPABILITY command as
part of the responses to AUTHENTICATE and LOGIN.
79) Remove statement about it being unnecessary to issue a CAPABILITY
command more than once in a connection. That statement is no longer
80) Clarify that untagged EXPUNGE decrements the number of messages
in the mailbox.
81) Fix definition of "body" (concatenation has tighter binding than
82) Add a new "Special Notes to Implementors" section with reference
83) Clarify that an untagged CAPABILITY response to an AUTHENTICATE
command should only be done if a security layer was not negotiated.
84) Change the definition of atom to exclude "]". Update astring to
include "]" for compatibility with the past. Remove resp-text-atom.
85) Remove NEWNAME. It can't work because mailbox names can be
literals and can include "]". Functionality can be addressed via
86) Move modified UTF-7 rationale in order to have more logical
87) Clarify UID uniqueness guarantees with the use of MUST.
88) Note that clients should read response data until the connection
is closed instead of immediately closing on a BYE.
89) Change RFC-822 references to RFC-2822.
90) Clarify that RFC-2822 should be followed instead of RFC-822.
91) Change recommendation of optional automatic capabilities in LOGIN
and AUTHENTICATE to use the CAPABILITY response code in the tagged
OK. This is more interoperable than an unsolicited untagged
92) STARTTLS and AUTH=PLAIN are mandatory to implement; add
recommendations for other [SASL] mechanisms.
93) Clarify that a "connection" (as opposed to "server" or "command")
is in one of the four states.
94) Clarify that a failed or rejected command does not change state.
95) Split references between normative and informative.
96) Discuss authentication failure issues in security section.
97) Clarify that a data item is not necessarily of only one data
98) Clarify that sequence ranges are independent of order.
99) Change an example to clarify that superfluous shifts in
Modified-UTF7 can not be fixed just by omitting the shift. The
entire string must be recalculated.
100) Change Envelope Structure definition since [RFC-2822] uses
"envelope" to refer to the [SMTP] envelope and not the envelope data
that appears in the [RFC-2822] header.
101) Expand on RFC822.HEADER response data vs. BODY[HEADER].
102) Clarify Logout state semantics, change ASCII art.
103) Security changes to comply with IESG requirements.
104) Add definition for body URI.
105) Break sequence range definition into three rules, with rewritten
descriptions for each.
106) Move STARTTLS and LOGINDISABLED here from [IMAP-TLS].
107) Add IANA Considerations section.
108) Clarify valid client assumptions for new message UIDs vs.
109) Clarify that changes to permanentflags affect concurrent
sessions as well as subsequent sessions.
110) Clarify that authenticated state can be entered by the CLOSE
111) Emphasize that SELECT and EXAMINE are the exceptions to the rule
that a failing command does not change state.
112) Clarify that newly-appended messages have the Recent flag set.
113) Clarify that newly-copied messages SHOULD have the Recent flag
114) Clarify that UID commands always return the UID in FETCH
C. Key Word Index
+FLAGS <flag list> (store command data item) ............... 59
+FLAGS.SILENT <flag list> (store command data item) ........ 59
-FLAGS <flag list> (store command data item) ............... 59
-FLAGS.SILENT <flag list> (store command data item) ........ 59
ALERT (response code) ...................................... 64
ALL (fetch item) ........................................... 55
ALL (search key) ........................................... 50
ANSWERED (search key) ...................................... 50
APPEND (command) ........................................... 45
AUTHENTICATE (command) ..................................... 27
BAD (response) ............................................. 66
BADCHARSET (response code) ................................. 64
BCC <string> (search key) .................................. 51
BEFORE <date> (search key) ................................. 51
BODY (fetch item) .......................................... 55
BODY (fetch result) ........................................ 73
BODY <string> (search key) ................................. 51
Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns. v This
document and the information contained herein is provided on an "AS
IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK
FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT
LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL
NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY
OR FITNESS FOR A PARTICULAR PURPOSE.
Funding for the RFC Editor function is currently provided by the