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 RFC 1730 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: 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 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", RFC 2234, November 1997. [ANONYMOUS] Newman, C., "Anonymous SASL Mechanism", RFC 2245, November 1997. [CHARSET] Freed, N. and J. Postel, "IANA Character Set Registration Procedures", RFC 2978, October 2000. [DIGEST-MD5] Leach, P. and C. Newman, "Using Digest Authentication as a SASL Mechanism", RFC 2831, May 2000. [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, March 1997. [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, 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", 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, 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", 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, November 1997. [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, August 1982. [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 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 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 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 RFC822 (fetch item) ........................................ 57 RFC822 (fetch result) ...................................... 78 RFC822.HEADER (fetch item) ................................. 57 RFC822.HEADER (fetch result) ............................... 78 RFC822.SIZE (fetch item) ................................... 57 RFC822.SIZE (fetch result) ................................. 78 RFC822.TEXT (fetch item) ................................... 58 RFC822.TEXT (fetch result) ................................. 79 SEARCH (command) ........................................... 49 SEARCH (response) .......................................... 71 SEEN (search key) .......................................... 52 SELECT (command) ........................................... 31 SENTBEFORE <date> (search key) ............................. 52 SENTON <date> (search key) ................................. 52 SENTSINCE <date> (search key) .............................. 52 SHOULD (specification requirement term) .................... 4 SHOULD NOT (specification requirement term) ................ 4
SINCE <date> (search key) .................................. 52 SMALLER <n> (search key) ................................... 52 STARTTLS (command) ......................................... 27 STATUS (command) ........................................... 44 STATUS (response) .......................................... 70 STORE (command) ............................................ 58 SUBJECT <string> (search key) .............................. 53 SUBSCRIBE (command) ........................................ 38 Session Flag (class of flag) ............................... 12 System Flag (type of flag) ................................. 11 TEXT (part specifier) ...................................... 56 TEXT <string> (search key) ................................. 53 TO <string> (search key) ................................... 53 TRYCREATE (response code) .................................. 65 UID (command) .............................................. 60 UID (fetch item) ........................................... 58 UID (fetch result) ......................................... 79 UID <sequence set> (search key) ............................ 53 UIDNEXT (response code) .................................... 65 UIDNEXT (status item) ...................................... 45 UIDVALIDITY (response code) ................................ 65 UIDVALIDITY (status item) .................................. 45 UNANSWERED (search key) .................................... 53 UNDELETED (search key) ..................................... 53 UNDRAFT (search key) ....................................... 53 UNFLAGGED (search key) ..................................... 53 UNKEYWORD <flag> (search key) .............................. 53 UNSEEN (response code) ..................................... 65 UNSEEN (search key) ........................................ 53 UNSEEN (status item) ....................................... 45 UNSUBSCRIBE (command) ...................................... 39 Unique Identifier (UID) (message attribute) ................ 8 X<atom> (command) .......................................... 62 [RFC-2822] Size (message attribute) ........................ 12 \Answered (system flag) .................................... 11 \Deleted (system flag) ..................................... 11 \Draft (system flag) ....................................... 11 \Flagged (system flag) ..................................... 11 \Marked (mailbox name attribute) ........................... 69 \Noinferiors (mailbox name attribute) ...................... 69 \Noselect (mailbox name attribute) ......................... 69 \Recent (system flag) ...................................... 11 \Seen (system flag) ........................................ 11 \Unmarked (mailbox name attribute) ......................... 69
Author's Address
Mark R. Crispin Networks and Distributed Computing University of Washington 4545 15th Avenue NE Seattle, WA 98105-4527 Phone: (206) 543-5762 EMail: MRC@CAC.Washington.EDU
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 English. 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. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society.