\Seen being set, because RFC822.HEADER response data occurs as
a result of a FETCH of RFC822.HEADER. BODY[HEADER] response
data occurs as a result of a FETCH of BODY[HEADER] (which sets
\Seen) or BODY.PEEK[HEADER] (which does not set \Seen).
RFC822.SIZE
A number expressing the [RFC-2822] size of the message.
RFC822.TEXT
Equivalent to BODY[TEXT].
UID
A number expressing the unique identifier of the message.
Example: S: * 23 FETCH (FLAGS (\Seen) RFC822.SIZE 44827)
7.5. Server Responses - Command Continuation Request
The command continuation request response is indicated by a "+" token
instead of a tag. This form of response indicates that the server is
ready to accept the continuation of a command from the client. The
remainder of this response is a line of text.
This response is used in the AUTHENTICATE command to transmit server
data to the client, and request additional client data. This
response is also used if an argument to any command is a literal.
The client is not permitted to send the octets of the literal unless
the server indicates that it is expected. This permits the server to
process commands and reject errors on a line-by-line basis. The
remainder of the command, including the CRLF that terminates a
command, follows the octets of the literal. If there are any
additional command arguments, the literal octets are followed by a
space and those arguments.
Example: C: A001 LOGIN {11}
S: + Ready for additional command text
C: FRED FOOBAR {7}
S: + Ready for additional command text
C: fat man
S: A001 OK LOGIN completed
C: A044 BLURDYBLOOP {102856}
S: A044 BAD No such command as "BLURDYBLOOP"
8. Sample IMAP4rev1 connection
The following is a transcript of an IMAP4rev1 connection. A long
line in this sample is broken for editorial clarity.
S: * OK IMAP4rev1 Service Ready
C: a001 login mrc secret
S: a001 OK LOGIN completed
C: a002 select inbox
S: * 18 EXISTS
S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
S: * 2 RECENT
S: * OK [UNSEEN 17] Message 17 is the first unseen message
S: * OK [UIDVALIDITY 3857529045] UIDs valid
S: a002 OK [READ-WRITE] SELECT completed
C: a003 fetch 12 full
S: * 12 FETCH (FLAGS (\Seen) INTERNALDATE "17-Jul-1996 02:44:25 -0700"
RFC822.SIZE 4286 ENVELOPE ("Wed, 17 Jul 1996 02:23:25 -0700 (PDT)"
"IMAP4rev1 WG mtg summary and minutes"
(("Terry Gray" NIL "gray" "cac.washington.edu"))
(("Terry Gray" NIL "gray" "cac.washington.edu"))
(("Terry Gray" NIL "gray" "cac.washington.edu"))
((NIL NIL "imap" "cac.washington.edu"))
((NIL NIL "minutes" "CNRI.Reston.VA.US")
("John Klensin" NIL "KLENSIN" "MIT.EDU")) NIL NIL
"<B27397-0100000@cac.washington.edu>")
BODY ("TEXT" "PLAIN" ("CHARSET" "US-ASCII") NIL NIL "7BIT" 3028
92))
S: a003 OK FETCH completed
C: a004 fetch 12 body[header]
S: * 12 FETCH (BODY[HEADER] {342}
S: Date: Wed, 17 Jul 1996 02:23:25 -0700 (PDT)
S: From: Terry Gray <gray@cac.washington.edu>
S: Subject: IMAP4rev1 WG mtg summary and minutes
S: To: imap@cac.washington.edu
S: cc: minutes@CNRI.Reston.VA.US, John Klensin <KLENSIN@MIT.EDU>
S: Message-Id: <B27397-0100000@cac.washington.edu>
S: MIME-Version: 1.0
S: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
S:
S: )
S: a004 OK FETCH completed
C: a005 store 12 +flags \deleted
S: * 12 FETCH (FLAGS (\Seen \Deleted))
S: a005 OK +FLAGS completed
C: a006 logout
S: * BYE IMAP4rev1 server terminating connection
S: a006 OK LOGOUT completed
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
noted below.
Note: [ABNF] rules MUST be followed strictly; in
particular:
(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
case-insensitive fashion.
(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
time.
address = "(" addr-name SP addr-adl SP addr-mailbox SP
addr-host ")"
addr-adl = nstring
; Holds route from [RFC-2822] route-addr if
; non-NIL
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
addr-name = nstring
; If non-NIL, holds phrase from [RFC-2822]
; mailbox after removing [RFC-2822] quoting
append = "APPEND" SP mailbox [SP flag-list] [SP date-time] SP
literal
astring = 1*ASTRING-CHAR / string
ASTRING-CHAR = ATOM-CHAR / resp-specials
atom = 1*ATOM-CHAR
ATOM-CHAR = <any CHAR except atom-specials>
atom-specials = "(" / ")" / "{" / SP / CTL / list-wildcards /
quoted-specials / resp-specials
authenticate = "AUTHENTICATE" SP auth-type *(CRLF base64)
auth-type = atom
; Defined by [SASL]
base64 = *(4base64-char) [base64-terminal]
base64-char = ALPHA / DIGIT / "+" / "/"
; Case-sensitive
base64-terminal = (2base64-char "==") / (3base64-char "=")
body = "(" (body-type-1part / body-type-mpart) ")"
body-extension = nstring / number /
"(" body-extension *(SP body-extension) ")"
; Future expansion. Client implementations
; MUST accept body-extension fields. Server
; implementations MUST NOT generate
; body-extension fields except as defined by
; future standard or standards-track
; revisions of this specification.
body-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
body-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
body-fields = body-fld-param SP body-fld-id SP body-fld-desc SP
body-fld-enc SP body-fld-octets
body-fld-desc = nstring
body-fld-dsp = "(" string SP body-fld-param ")" / nil
body-fld-enc = (DQUOTE ("7BIT" / "8BIT" / "BINARY" / "BASE64"/
"QUOTED-PRINTABLE") DQUOTE) / string
body-fld-id = nstring
body-fld-lang = nstring / "(" string *(SP string) ")"
body-fld-loc = nstring
body-fld-lines = number
body-fld-md5 = nstring
body-fld-octets = number
body-fld-param = "(" string SP string *(SP string SP string) ")" / nil
body-type-1part = (body-type-basic / body-type-msg / body-type-text)
[SP body-ext-1part]
body-type-basic = media-basic SP body-fields
; MESSAGE subtype MUST NOT be "RFC822"
body-type-mpart = 1*body SP media-subtype
[SP body-ext-mpart]
body-type-msg = media-message SP body-fields SP envelope
SP body SP body-fld-lines
body-type-text = media-text SP body-fields SP body-fld-lines
capability = ("AUTH=" auth-type) / atom
; New capabilities MUST begin with "X" or be
; registered with IANA as standard or
; standards-track
capability-data = "CAPABILITY" *(SP capability) SP "IMAP4rev1"
*(SP capability)
; Servers MUST implement the STARTTLS, AUTH=PLAIN,
; and LOGINDISABLED capabilities
; Servers which offer RFC1730 compatibility MUST
; list "IMAP4" as the first capability.
CHAR8 = %x01-ff
; any OCTET except NUL, %x00
command = tag SP (command-any / command-auth / command-nonauth /
command-select) CRLF
; Modal based on state
command-any = "CAPABILITY" / "LOGOUT" / "NOOP" / x-command
; Valid in all states
command-auth = append / create / delete / examine / list / lsub /
rename / select / status / subscribe / unsubscribe
; Valid only in Authenticated or Selected state
command-nonauth = login / authenticate / "STARTTLS"
; Valid only when in Not Authenticated state
command-select = "CHECK" / "CLOSE" / "EXPUNGE" / copy / fetch / store /
uid / search
; Valid only when in Selected state
continue-req = "+" SP (resp-text / base64) CRLF
copy = "COPY" SP sequence-set SP mailbox
create = "CREATE" SP mailbox
; Use of INBOX gives a NO error
date = date-text / DQUOTE date-text DQUOTE
date-day = 1*2DIGIT
; Day of month
date-day-fixed = (SP DIGIT) / 2DIGIT
; Fixed-format version of date-day
date-month = "Jan" / "Feb" / "Mar" / "Apr" / "May" / "Jun" /
"Jul" / "Aug" / "Sep" / "Oct" / "Nov" / "Dec"
date-text = date-day "-" date-month "-" date-year
date-year = 4DIGIT
date-time = DQUOTE date-day-fixed "-" date-month "-" date-year
SP time SP zone DQUOTE
delete = "DELETE" SP mailbox
; Use of INBOX gives a NO error
digit-nz = %x31-39
; 1-9
envelope = "(" env-date SP env-subject SP env-from SP
env-sender SP env-reply-to SP env-to SP env-cc SP
env-bcc SP env-in-reply-to SP env-message-id ")"
env-bcc = "(" 1*address ")" / nil
env-cc = "(" 1*address ")" / nil
env-date = nstring
env-from = "(" 1*address ")" / nil
env-in-reply-to = nstring
env-message-id = nstring
env-reply-to = "(" 1*address ")" / nil
env-sender = "(" 1*address ")" / nil
env-subject = nstring
env-to = "(" 1*address ")" / nil
examine = "EXAMINE" SP mailbox
fetch = "FETCH" SP sequence-set SP ("ALL" / "FULL" / "FAST" /
fetch-att / "(" fetch-att *(SP fetch-att) ")")
fetch-att = "ENVELOPE" / "FLAGS" / "INTERNALDATE" /
"RFC822" [".HEADER" / ".SIZE" / ".TEXT"] /
"BODY" ["STRUCTURE"] / "UID" /
"BODY" section ["<" number "." nz-number ">"] /
"BODY.PEEK" section ["<" number "." nz-number ">"]
flag = "\Answered" / "\Flagged" / "\Deleted" /
"\Seen" / "\Draft" / flag-keyword / flag-extension
; Does not include "\Recent"
flag-extension = "\" atom
; Future expansion. Client implementations
; MUST accept flag-extension flags. Server
; implementations MUST NOT generate
; flag-extension flags except as defined by
; future standard or standards-track
; revisions of this specification.
flag-fetch = flag / "\Recent"
flag-keyword = atom
flag-list = "(" [flag *(SP flag)] ")"
flag-perm = flag / "\*"
greeting = "*" SP (resp-cond-auth / resp-cond-bye) CRLF
header-fld-name = astring
header-list = "(" header-fld-name *(SP header-fld-name) ")"
list = "LIST" SP mailbox SP list-mailbox
list-mailbox = 1*list-char / string
list-char = ATOM-CHAR / list-wildcards / resp-specials
list-wildcards = "%" / "*"
literal = "{" number "}" CRLF *CHAR8
; Number represents the number of CHAR8s
login = "LOGIN" SP userid SP password
lsub = "LSUB" SP mailbox SP list-mailbox
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
media-subtype
; 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
msg-att-static = "ENVELOPE" SP envelope / "INTERNALDATE" SP date-time /
"RFC822" [".HEADER" / ".TEXT"] SP nstring /
"RFC822.SIZE" SP number /
"BODY" ["STRUCTURE"] SP body /
"BODY" section ["<" number ">"] SP nstring /
"UID" SP uniqueid
; MUST NOT change for a message
nil = "NIL"
nstring = string / nil
number = 1*DIGIT
; Unsigned 32-bit integer
; (0 <= n < 4,294,967,296)
nz-number = digit-nz *DIGIT
; Non-zero unsigned 32-bit integer
; (0 < n < 4,294,967,296)
password = astring
quoted = DQUOTE *QUOTED-CHAR DQUOTE
QUOTED-CHAR = <any TEXT-CHAR except quoted-specials> /
"\" quoted-specials
quoted-specials = DQUOTE / "\"
rename = "RENAME" SP mailbox SP mailbox
; Use of INBOX as a destination gives a NO error
response = *(continue-req / response-data) response-done
response-data = "*" SP (resp-cond-state / resp-cond-bye /
mailbox-data / message-data / capability-data) CRLF
response-done = response-tagged / response-fatal
response-fatal = "*" SP resp-cond-bye CRLF
; Server closes connection immediately
response-tagged = tag SP resp-cond-state CRLF
resp-cond-auth = ("OK" / "PREAUTH") SP resp-text
; Authentication condition
resp-cond-bye = "BYE" SP resp-text
resp-cond-state = ("OK" / "NO" / "BAD") SP resp-text
; Status condition
resp-specials = "]"
resp-text = ["[" resp-text-code "]" SP] text
resp-text-code = "ALERT" /
"BADCHARSET" [SP "(" astring *(SP astring) ")" ] /
capability-data / "PARSE" /
"PERMANENTFLAGS" SP "("
[flag-perm *(SP flag-perm)] ")" /
"READ-ONLY" / "READ-WRITE" / "TRYCREATE" /
"UIDNEXT" SP nz-number / "UIDVALIDITY" SP nz-number /
"UNSEEN" SP nz-number /
atom [SP 1*<any TEXT-CHAR except "]">]
search = "SEARCH" [SP "CHARSET" SP astring] 1*(SP search-key)
; CHARSET argument to MUST be registered with IANA
search-key = "ALL" / "ANSWERED" / "BCC" SP astring /
"BEFORE" SP date / "BODY" SP astring /
"CC" SP astring / "DELETED" / "FLAGGED" /
"FROM" SP astring / "KEYWORD" SP flag-keyword /
"NEW" / "OLD" / "ON" SP date / "RECENT" / "SEEN" /
"SINCE" SP date / "SUBJECT" SP astring /
"TEXT" SP astring / "TO" SP astring /
"UNANSWERED" / "UNDELETED" / "UNFLAGGED" /
"UNKEYWORD" SP flag-keyword / "UNSEEN" /
; Above this line were in [IMAP2]
"DRAFT" / "HEADER" SP header-fld-name SP astring /
"LARGER" SP number / "NOT" SP search-key /
"OR" SP search-key SP search-key /
"SENTBEFORE" SP date / "SENTON" SP date /
"SENTSINCE" SP date / "SMALLER" SP number /
"UID" SP sequence-set / "UNDRAFT" / sequence-set /
"(" search-key *(SP search-key) ")"
section = "[" [section-spec] "]"
section-msgtext = "HEADER" / "HEADER.FIELDS" [".NOT"] SP header-list /
"TEXT"
; top-level or MESSAGE/RFC822 part
section-part = nz-number *("." nz-number)
; body part nesting
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" /
"UNSEEN"
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: RFC2060,
RFC1730, unpublished IMAP2bis.TXT document, RFC1176, and RFC1064.
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
server's identity.
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
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
(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.
Additional security considerations are discussed in the section
discussing the AUTHENTICATE and LOGIN commands.
12. IANA Considerations
IMAP4 capabilities are registered by publishing a standards track or
IESG approved experimental RFC. The registry is currently located
at:
http://www.iana.org/assignments/imap4-capabilities
As this specification revises the STARTTLS and LOGINDISABLED
extensions previously defined in [IMAP-TLS], the registry will be
updated accordingly.
Appendices
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", RFC2234,
November 1997.
[ANONYMOUS] Newman, C., "Anonymous SASL Mechanism", RFC
2245, November 1997.
[CHARSET] Freed, N. and J. Postel, "IANA Character Set
Registration Procedures", RFC2978, October
2000.
[DIGEST-MD5] Leach, P. and C. Newman, "Using Digest
Authentication as a SASL Mechanism", RFC2831,
May 2000.
[DISPOSITION] Troost, R., Dorner, S. and K. Moore,
"Communicating Presentation Information in
Internet Messages: The Content-Disposition
Header", RFC2183, August 1997.
[IMAP-TLS] Newman, C., "Using TLS with IMAP, POP3 and
ACAP", RFC2595, June 1999.
[KEYWORDS] Bradner, S., "Key words for use in RFCs to
Indicate Requirement Levels", BCP 14, RFC2119,
March 1997.
[LANGUAGE-TAGS] Alvestrand, H., "Tags for the Identification of
Languages", BCP 47, RFC3066, January 2001.
[LOCATION] Palme, J., Hopmann, A. and N. Shelness, "MIME
Encapsulation of Aggregate Documents, such as
HTML (MHTML)", RFC2557, March 1999.
[MD5] Myers, J. and M. Rose, "The Content-MD5 Header
Field", RFC1864, October 1995.
[MIME-HDRS] Moore, K., "MIME (Multipurpose Internet Mail
Extensions) Part Three: Message Header
Extensions for Non-ASCII Text", RFC2047,
November 1996.
[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", RFC2046, November 1996.
[RFC-2822] Resnick, P., "Internet Message Format", RFC
2822, April 2001.
[SASL] Myers, J., "Simple Authentication and Security
Layer (SASL)", RFC2222, October 1997.
[TLS] Dierks, T. and C. Allen, "The TLS Protocol
Version 1.0", RFC2246, January 1999.
[UTF-7] Goldsmith, D. and M. Davis, "UTF-7: A Mail-Safe
Transformation Format of Unicode", RFC2152,
May 1997.
The following documents describe quality-of-implementation issues
that should be carefully considered when implementing this protocol:
[IMAP-IMPLEMENTATION] Leiba, B., "IMAP Implementation
Recommendations", RFC2683, September 1999.
[IMAP-MULTIACCESS] Gahrns, M., "IMAP4 Multi-Accessed Mailbox
Practice", RFC2180, 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", RFC1733, December 1994.
[ACAP] Newman, C. and J. Myers, "ACAP -- Application
Configuration Access Protocol", RFC2244,
November 1997.
[SMTP] Klensin, J., "Simple Mail Transfer Protocol",
STD 10, RFC2821, April 2001.
The following documents are historical or describe historical aspects
of this protocol:
[IMAP-COMPAT] Crispin, M., "IMAP4 Compatibility with
IMAP2bis", RFC2061, December 1996.
[IMAP-HISTORICAL] Crispin, M., "IMAP4 Compatibility with IMAP2
and IMAP2bis", RFC1732, December 1994.
[IMAP-OBSOLETE] Crispin, M., "Internet Message Access Protocol
- Obsolete Syntax", RFC2062, December 1996.
[IMAP2] Crispin, M., "Interactive Mail Access Protocol
- Version 2", RFC1176, August 1990.
[RFC-822] Crocker, D., "Standard for the Format of ARPA
Internet Text Messages", STD 11, RFC822,
August 1982.
[RFC-821] Postel, J., "Simple Mail Transfer Protocol",
STD 10, RFC821, August 1982.
B. Changes from RFC2060
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
protocol syntax.
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
LIST.
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
removed.
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
reference.
26) Further clarification of "can" vs. "MAY".
27) Reference RFC-2119.
28) Clarify that superfluous shifts are not permitted in modified
UTF-7.
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 RFCnumbers.
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
responses.
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
line.
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
present.
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
appearing.
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
PREAUTH.
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
true.
80) Clarify that untagged EXPUNGE decrements the number of messages
in the mailbox.
81) Fix definition of "body" (concatenation has tighter binding than
alternation).
82) Add a new "Special Notes to Implementors" section with reference
to [IMAP-IMPLEMENTATION].
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
referrals.
86) Move modified UTF-7 rationale in order to have more logical
paragraph flow.
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
CAPABILITY response.
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
type.
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.
UIDNEXT.
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
command.
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
set.
114) Clarify that UID commands always return the UID in FETCH
responses.
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
BODY.PEEK[<section>]<<partial>> (fetch item) ............... 57
BODYSTRUCTURE (fetch item) ................................. 57
BODYSTRUCTURE (fetch result) ............................... 74
BODY[<section>]<<origin octet>> (fetch result) ............. 74
BODY[<section>]<<partial>> (fetch item) .................... 55
BYE (response) ............................................. 67
Body Structure (message attribute) ......................... 12
CAPABILITY (command) ....................................... 24
CAPABILITY (response code) ................................. 64
CAPABILITY (response) ...................................... 68
CC <string> (search key) ................................... 51
CHECK (command) ............................................ 47
CLOSE (command) ............................................ 48
COPY (command) ............................................. 59
CREATE (command) ........................................... 34
DELETE (command) ........................................... 35
DELETED (search key) ....................................... 51
DRAFT (search key) ......................................... 51
ENVELOPE (fetch item) ...................................... 57
ENVELOPE (fetch result) .................................... 77
EXAMINE (command) .......................................... 33
EXISTS (response) .......................................... 71
EXPUNGE (command) .......................................... 48
EXPUNGE (response) ......................................... 72
Envelope Structure (message attribute) ..................... 12
FAST (fetch item) .......................................... 55
FETCH (command) ............................................ 54
FETCH (response) ........................................... 73
FLAGGED (search key) ....................................... 51
FLAGS (fetch item) ......................................... 57
FLAGS (fetch result) ....................................... 78
FLAGS (response) ........................................... 71
FLAGS <flag list> (store command data item) ................ 59
FLAGS.SILENT <flag list> (store command data item) ......... 59
FROM <string> (search key) ................................. 51
FULL (fetch item) .......................................... 55
Flags (message attribute) .................................. 11
HEADER (part specifier) .................................... 55
HEADER <field-name> <string> (search key) .................. 51
HEADER.FIELDS <header-list> (part specifier) ............... 55
HEADER.FIELDS.NOT <header-list> (part specifier) ........... 55
INTERNALDATE (fetch item) .................................. 57
INTERNALDATE (fetch result) ................................ 78
Internal Date (message attribute) .......................... 12
KEYWORD <flag> (search key) ................................ 51
Keyword (type of flag) ..................................... 11
LARGER <n> (search key) .................................... 51
LIST (command) ............................................. 40
LIST (response) ............................................ 69
LOGIN (command) ............................................ 30
LOGOUT (command) ........................................... 25
LSUB (command) ............................................. 43
LSUB (response) ............................................ 70
MAY (specification requirement term) ....................... 4
MESSAGES (status item) ..................................... 45
MIME (part specifier) ...................................... 56
MUST (specification requirement term) ...................... 4
MUST NOT (specification requirement term) .................. 4
Message Sequence Number (message attribute) ................ 10
NEW (search key) ........................................... 51
NO (response) .............................................. 66
NOOP (command) ............................................. 25
NOT <search-key> (search key) .............................. 52
OK (response) .............................................. 65
OLD (search key) ........................................... 52
ON <date> (search key) ..................................... 52
OPTIONAL (specification requirement term) .................. 4
OR <search-key1> <search-key2> (search key) ................ 52
PARSE (response code) ...................................... 64
PERMANENTFLAGS (response code) ............................. 64
PREAUTH (response) ......................................... 67
Permanent Flag (class of flag) ............................. 12
READ-ONLY (response code) .................................. 65
READ-WRITE (response code) ................................. 65
RECENT (response) .......................................... 72
RECENT (search key) ........................................ 52
RECENT (status item) ....................................... 45
RENAME (command) ........................................... 37
REQUIRED (specification requirement term) .................. 4