Tech-invite3GPPspaceIETFspace
96959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 3501

INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1

Pages: 108
Obsoletes:  2060
Obsoleted by:  9051
Updated by:  4466446945515032518257386186685878178314843784748996
Part 4 of 4 – Pages 80 to 108
First   Prev   None

Top   ToC   RFC3501 - Page 80   prevText

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
Top   ToC   RFC3501 - Page 81

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
Top   ToC   RFC3501 - Page 82
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
Top   ToC   RFC3501 - Page 83
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
Top   ToC   RFC3501 - Page 84
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
Top   ToC   RFC3501 - Page 85
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 ">"]
Top   ToC   RFC3501 - Page 86
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
Top   ToC   RFC3501 - Page 87
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
Top   ToC   RFC3501 - Page 88
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
Top   ToC   RFC3501 - Page 89
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
Top   ToC   RFC3501 - Page 90
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) ")"
Top   ToC   RFC3501 - Page 91
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".
Top   ToC   RFC3501 - Page 92

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.
Top   ToC   RFC3501 - Page 93
        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.
Top   ToC   RFC3501 - Page 94
   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.
Top   ToC   RFC3501 - Page 95

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.
Top   ToC   RFC3501 - Page 96
   [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.
Top   ToC   RFC3501 - Page 97
   [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.
Top   ToC   RFC3501 - Page 98
   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.
Top   ToC   RFC3501 - Page 99
   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.
Top   ToC   RFC3501 - Page 100
   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.
Top   ToC   RFC3501 - Page 101
   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.
Top   ToC   RFC3501 - Page 102
   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.
Top   ToC   RFC3501 - Page 103
   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
Top   ToC   RFC3501 - Page 104
       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
Top   ToC   RFC3501 - Page 105
       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
Top   ToC   RFC3501 - Page 106
       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
Top   ToC   RFC3501 - Page 107

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
Top   ToC   RFC3501 - Page 108
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.