< draft-ietf-extra-imap4rev2-20.txt   draft-ietf-extra-imap4rev2-21.txt >
Network Working Group A. Melnikov, Ed. Network Working Group A. Melnikov, Ed.
Internet-Draft Isode Ltd Internet-Draft Isode Ltd
Obsoletes: 3501 (if approved) B. Leiba, Ed. Obsoletes: 3501 (if approved) B. Leiba, Ed.
Intended status: Standards Track Futurewei Technologies Intended status: Standards Track Futurewei Technologies
Expires: April 30, 2021 October 27, 2020 Expires: May 27, 2021 November 23, 2020
Internet Message Access Protocol (IMAP) - Version 4rev2 Internet Message Access Protocol (IMAP) - Version 4rev2
draft-ietf-extra-imap4rev2-20 draft-ietf-extra-imap4rev2-21
Abstract Abstract
The Internet Message Access Protocol, Version 4rev2 (IMAP4rev2) The Internet Message Access Protocol, Version 4rev2 (IMAP4rev2)
allows a client to access and manipulate electronic mail messages on allows a client to access and manipulate electronic mail messages on
a server. IMAP4rev2 permits manipulation of mailboxes (remote a server. IMAP4rev2 permits manipulation of mailboxes (remote
message folders) in a way that is functionally equivalent to local message folders) in a way that is functionally equivalent to local
folders. IMAP4rev2 also provides the capability for an offline folders. IMAP4rev2 also provides the capability for an offline
client to resynchronize with the server. client to resynchronize with the server.
skipping to change at page 1, line 48 skipping to change at page 1, line 48
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 30, 2021. This Internet-Draft will expire on May 27, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 4, line 38 skipping to change at page 4, line 38
7.4.1. EXPUNGE Response . . . . . . . . . . . . . . . . . . 117 7.4.1. EXPUNGE Response . . . . . . . . . . . . . . . . . . 117
7.4.2. FETCH Response . . . . . . . . . . . . . . . . . . . 118 7.4.2. FETCH Response . . . . . . . . . . . . . . . . . . . 118
7.5. Server Responses - Command Continuation Request . . . . . 124 7.5. Server Responses - Command Continuation Request . . . . . 124
8. Sample IMAP4rev2 connection . . . . . . . . . . . . . . . . . 124 8. Sample IMAP4rev2 connection . . . . . . . . . . . . . . . . . 124
9. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 125 9. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 125
10. Author's Note . . . . . . . . . . . . . . . . . . . . . . . . 143 10. Author's Note . . . . . . . . . . . . . . . . . . . . . . . . 143
11. Security Considerations . . . . . . . . . . . . . . . . . . . 143 11. Security Considerations . . . . . . . . . . . . . . . . . . . 143
11.1. STARTTLS Security Considerations . . . . . . . . . . . . 143 11.1. STARTTLS Security Considerations . . . . . . . . . . . . 143
11.2. COPYUID and APPENDUID response codes . . . . . . . . . . 144 11.2. COPYUID and APPENDUID response codes . . . . . . . . . . 144
11.3. LIST command and Other Users' namespace . . . . . . . . 144 11.3. LIST command and Other Users' namespace . . . . . . . . 144
11.4. Other Security Considerations . . . . . . . . . . . . . 144 11.4. Other Security Considerations . . . . . . . . . . . . . 145
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 145 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 145
12.1. Updates to IMAP4 Capabilities registry . . . . . . . . . 146 12.1. Updates to IMAP4 Capabilities registry . . . . . . . . . 146
12.2. GSSAPI/SASL service name . . . . . . . . . . . . . . . . 146 12.2. GSSAPI/SASL service name . . . . . . . . . . . . . . . . 146
12.3. LIST Selection Options, LIST Return Options, LIST 12.3. LIST Selection Options, LIST Return Options, LIST
extended data items . . . . . . . . . . . . . . . . . . 146 extended data items . . . . . . . . . . . . . . . . . . 146
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 146 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 147
13.1. Normative References . . . . . . . . . . . . . . . . . . 146 13.1. Normative References . . . . . . . . . . . . . . . . . . 147
13.2. Informative References (related protocols) . . . . . . . 150 13.2. Informative References (related protocols) . . . . . . . 150
13.3. Informative References (historical aspects of IMAP and 13.3. Informative References (historical aspects of IMAP and
related protocols) . . . . . . . . . . . . . . . . . . . 152 related protocols) . . . . . . . . . . . . . . . . . . . 152
Appendix A. Backward compatibility with IMAP4rev1 . . . . . . . 152 Appendix A. Backward compatibility with IMAP4rev1 . . . . . . . 152
A.1. Mailbox International Naming Convention for compatibility A.1. Mailbox International Naming Convention for compatibility
with IMAP4rev1 . . . . . . . . . . . . . . . . . . . . . 153 with IMAP4rev1 . . . . . . . . . . . . . . . . . . . . . 153
Appendix B. Backward compatibility with BINARY extension . . . . 154 Appendix B. Backward compatibility with BINARY extension . . . . 155
Appendix C. Backward compatibility with LIST-EXTENDED extension 155 Appendix C. Backward compatibility with LIST-EXTENDED extension 155
Appendix D. Changes from RFC 3501 / IMAP4rev1 . . . . . . . . . 155 Appendix D. 63 bit body part and message sizes . . . . . . . . . 155
Appendix E. Other Recommended IMAP Extensions . . . . . . . . . 156 Appendix E. Changes from RFC 3501 / IMAP4rev1 . . . . . . . . . 155
Appendix F. Acknowledgement . . . . . . . . . . . . . . . . . . 157 Appendix F. Other Recommended IMAP Extensions . . . . . . . . . 157
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157 Appendix G. Acknowledgement . . . . . . . . . . . . . . . . . . 157
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 163 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 163
1. How to Read This Document 1. How to Read This Document
1.1. Organization of This Document 1.1. Organization of This Document
This document is written from the point of view of the implementor of This document is written from the point of view of the implementor of
an IMAP4rev2 client or server. Beyond the protocol overview in an IMAP4rev2 client or server. Beyond the protocol overview in
section 2, it is not optimized for someone trying to understand the section 2, it is not optimized for someone trying to understand the
operation of the protocol. The material in sections 3 through 5 operation of the protocol. The material in sections 3 through 5
skipping to change at page 6, line 36 skipping to change at page 6, line 36
International Naming Convention, and other uses of "&" in mailbox International Naming Convention, and other uses of "&" in mailbox
names are impacted as well. names are impacted as well.
1.3. Special Notes to Implementors 1.3. Special Notes to Implementors
Implementors of the IMAP protocol are strongly encouraged to read the Implementors of the IMAP protocol are strongly encouraged to read the
IMAP implementation recommendations document [IMAP-IMPLEMENTATION] in IMAP implementation recommendations document [IMAP-IMPLEMENTATION] in
conjunction with this document, to help understand the intricacies of conjunction with this document, to help understand the intricacies of
this protocol and how best to build an interoperable product. this protocol and how best to build an interoperable product.
IMAP4rev2 is designed to be upwards compatible from the [IMAP2] and IMAP4rev2 is designed to be upwards compatible from the IMAP4rev1,
unpublished IMAP2bis protocols. IMAP4rev2 is largely compatible with the [IMAP2] and unpublished IMAP2bis protocols. IMAP4rev2 is largely
the IMAP4rev1 protocol described in RFC 3501 and the IMAP4 protocol compatible with the IMAP4rev1 protocol described in RFC 3501 and the
described in RFC 1730; the exception being in certain facilities IMAP4 protocol described in RFC 1730; the exception being in certain
added in RFC 1730 and RFC 3501 that proved problematic and were facilities added in RFC 1730 and RFC 3501 that proved problematic and
subsequently removed or replaced by better alternatives. In the were subsequently removed or replaced by better alternatives. In the
course of the evolution of IMAP4rev2, some aspects in the earlier course of the evolution of IMAP4rev2, some aspects in the earlier
protocols have become obsolete. Obsolete commands, responses, and protocols have become obsolete. Obsolete commands, responses, and
data formats which an IMAP4rev2 implementation can encounter when data formats which an IMAP4rev2 implementation can encounter when
used with an earlier implementation are described in Appendix D, used with an earlier implementation are described in Appendix E,
Appendix A and [IMAP-OBSOLETE]. IMAP4rev2 compatibility with BINARY Appendix A and [IMAP-OBSOLETE]. IMAP4rev2 supports 63bit body part
and LIST-EXTENDED IMAP extensions are described in Appendix B and and message sizes. IMAP4rev2 compatibility with BINARY and LIST-
Appendix C respectively. EXTENDED IMAP extensions are described in Appendix B and Appendix C
respectively.
Other compatibility issues with IMAP2bis, the most common variant of Other compatibility issues with IMAP2bis, the most common variant of
the earlier protocol, are discussed in [IMAP-COMPAT]. A full the earlier protocol, are discussed in [IMAP-COMPAT]. A full
discussion of compatibility issues with rare (and presumed extinct) discussion of compatibility issues with rare (and presumed extinct)
variants of [IMAP2] is in [IMAP-HISTORICAL]; this document is variants of [IMAP2] is in [IMAP-HISTORICAL]; this document is
primarily of historical interest. primarily of historical interest.
IMAP was originally developed for the older [RFC-822] standard, and IMAP was originally developed for the older [RFC-822] standard, and
as a consequence several fetch items in IMAP incorporate "RFC822" in as a consequence several fetch items in IMAP incorporate "RFC822" in
their name. In all cases, "RFC822" should be interpreted as a their name. In all cases, "RFC822" should be interpreted as a
skipping to change at page 26, line 29 skipping to change at page 26, line 29
Other capability names refer to extensions, revisions, or amendments Other capability names refer to extensions, revisions, or amendments
to this specification. See the documentation of the CAPABILITY to this specification. See the documentation of the CAPABILITY
response for additional information. No capabilities, beyond the response for additional information. No capabilities, beyond the
base IMAP4rev2 set defined in this specification, are enabled without base IMAP4rev2 set defined in this specification, are enabled without
explicit client action to invoke the capability. explicit client action to invoke the capability.
Client and server implementations MUST implement the STARTTLS, Client and server implementations MUST implement the STARTTLS,
LOGINDISABLED, and AUTH=PLAIN (described in [PLAIN]) capabilities. LOGINDISABLED, and AUTH=PLAIN (described in [PLAIN]) capabilities.
See the Security Considerations section for important information. See the Security Considerations section for important information.
Unless specified otherwise, all registered extensions to IMAP4rev1
are also valid extensions to IMAP4rev2.
See the section entitled "Client Commands - Experimental/Expansion" See the section entitled "Client Commands - Experimental/Expansion"
for information about the form of site or implementation-specific for information about the form of site or implementation-specific
capabilities. capabilities.
Example: C: abcd CAPABILITY Example: C: abcd CAPABILITY
S: * CAPABILITY IMAP4rev2 STARTTLS AUTH=GSSAPI S: * CAPABILITY IMAP4rev2 STARTTLS AUTH=GSSAPI
LOGINDISABLED LOGINDISABLED
S: abcd OK CAPABILITY completed S: abcd OK CAPABILITY completed
C: efgh STARTTLS C: efgh STARTTLS
S: efgh OK STARTLS completed S: efgh OK STARTLS completed
skipping to change at page 127, line 28 skipping to change at page 127, line 28
base64 = *(4base64-char) [base64-terminal] base64 = *(4base64-char) [base64-terminal]
base64-char = ALPHA / DIGIT / "+" / "/" base64-char = ALPHA / DIGIT / "+" / "/"
; Case-sensitive ; Case-sensitive
base64-terminal = (2base64-char "==") / (3base64-char "=") base64-terminal = (2base64-char "==") / (3base64-char "=")
body = "(" (body-type-1part / body-type-mpart) ")" body = "(" (body-type-1part / body-type-mpart) ")"
body-extension = nstring / number / body-extension = nstring / number / number64 /
"(" body-extension *(SP body-extension) ")" "(" body-extension *(SP body-extension) ")"
; Future expansion. Client implementations ; Future expansion. Client implementations
; MUST accept body-extension fields. Server ; MUST accept body-extension fields. Server
; implementations MUST NOT generate ; implementations MUST NOT generate
; body-extension fields except as defined by ; body-extension fields except as defined by
; future standard or standards-track ; future standard or standards-track
; revisions of this specification. ; revisions of this specification.
body-ext-1part = body-fld-md5 [SP body-fld-dsp [SP body-fld-lang body-ext-1part = body-fld-md5 [SP body-fld-dsp [SP body-fld-lang
[SP body-fld-loc *(SP body-extension)]]] [SP body-fld-loc *(SP body-extension)]]]
skipping to change at page 128, line 18 skipping to change at page 128, line 18
; Content-Transfer-Encoding header field value. ; Content-Transfer-Encoding header field value.
; Defaults to "7BIT" (as per RFC 2045) ; Defaults to "7BIT" (as per RFC 2045)
; if not present in the body part. ; if not present in the body part.
body-fld-id = nstring body-fld-id = nstring
body-fld-lang = nstring / "(" string *(SP string) ")" body-fld-lang = nstring / "(" string *(SP string) ")"
body-fld-loc = nstring body-fld-loc = nstring
body-fld-lines = number body-fld-lines = number64
body-fld-md5 = nstring body-fld-md5 = nstring
body-fld-octets = number body-fld-octets = number
body-fld-param = "(" string SP string *(SP string SP string) ")" / nil body-fld-param = "(" string SP string *(SP string SP string) ")" / nil
body-type-1part = (body-type-basic / body-type-msg / body-type-text) body-type-1part = (body-type-basic / body-type-msg / body-type-text)
[SP body-ext-1part] [SP body-ext-1part]
skipping to change at page 133, line 32 skipping to change at page 133, line 32
; (SUBSCRIBED) ; (SUBSCRIBED)
; (SUBSCRIBED REMOTE) ; (SUBSCRIBED REMOTE)
; (SUBSCRIBED RECURSIVEMATCH) ; (SUBSCRIBED RECURSIVEMATCH)
; (SUBSCRIBED REMOTE RECURSIVEMATCH) ; (SUBSCRIBED REMOTE RECURSIVEMATCH)
; But does NOT allow these: ; But does NOT allow these:
; (RECURSIVEMATCH) ; (RECURSIVEMATCH)
; (REMOTE RECURSIVEMATCH) ; (REMOTE RECURSIVEMATCH)
list-wildcards = "%" / "*" list-wildcards = "%" / "*"
literal = "{" number ["+"] "}" CRLF *CHAR8 literal = "{" number64 ["+"] "}" CRLF *CHAR8
; <number> represents the number of CHAR8s. ; <number64> represents the number of CHAR8s.
; A non-synchronizing literal is distinguished from ; A non-synchronizing literal is distinguished from
; a synchronizing literal by presence of the "+" ; a synchronizing literal by presence of the "+"
; before the closing "}". ; before the closing "}".
; Non synchronizing literals are not allowed when ; Non synchronizing literals are not allowed when
; sent from server to the client. ; sent from server to the client.
literal8 = "~{" number "}" CRLF *OCTET literal8 = "~{" number64 "}" CRLF *OCTET
; <number> represents the number of OCTETs ; <number64> represents the number of OCTETs
; in the response string. ; in the response string.
login = "LOGIN" SP userid SP password login = "LOGIN" SP userid SP password
mailbox = "INBOX" / astring mailbox = "INBOX" / astring
; INBOX is case-insensitive. All case variants of ; INBOX is case-insensitive. All case variants of
; INBOX (e.g., "iNbOx") MUST be interpreted as INBOX ; INBOX (e.g., "iNbOx") MUST be interpreted as INBOX
; not as an astring. An astring which consists of ; not as an astring. An astring which consists of
; the case-insensitive sequence "I" "N" "B" "O" "X" ; the case-insensitive sequence "I" "N" "B" "O" "X"
; is considered to be INBOX and not an astring. ; is considered to be INBOX and not an astring.
skipping to change at page 135, line 20 skipping to change at page 135, line 20
move = "MOVE" SP sequence-set SP mailbox move = "MOVE" SP sequence-set SP mailbox
msg-att = "(" (msg-att-dynamic / msg-att-static) msg-att = "(" (msg-att-dynamic / msg-att-static)
*(SP (msg-att-dynamic / msg-att-static)) ")" *(SP (msg-att-dynamic / msg-att-static)) ")"
msg-att-dynamic = "FLAGS" SP "(" [flag-fetch *(SP flag-fetch)] ")" msg-att-dynamic = "FLAGS" SP "(" [flag-fetch *(SP flag-fetch)] ")"
; MAY change for a message ; MAY change for a message
msg-att-static = "ENVELOPE" SP envelope / "INTERNALDATE" SP date-time / msg-att-static = "ENVELOPE" SP envelope / "INTERNALDATE" SP date-time /
"RFC822.SIZE" SP number / "RFC822.SIZE" SP number64 /
"BODY" ["STRUCTURE"] SP body / "BODY" ["STRUCTURE"] SP body /
"BODY" section ["<" number ">"] SP nstring / "BODY" section ["<" number ">"] SP nstring /
"BINARY" section-binary SP (nstring / literal8) / "BINARY" section-binary SP (nstring / literal8) /
"BINARY.SIZE" section-binary SP number / "BINARY.SIZE" section-binary SP number /
"UID" SP uniqueid "UID" SP uniqueid
; MUST NOT change for a message ; MUST NOT change for a message
name-component = 1*UTF8-CHAR name-component = 1*UTF8-CHAR
; MUST NOT contain ".", "/", "%", or "*" ; MUST NOT contain ".", "/", "%", or "*"
skipping to change at page 136, line 10 skipping to change at page 136, line 10
; Namespace(s). ; Namespace(s).
; The third Namespace is the Shared Namespace(s). ; The third Namespace is the Shared Namespace(s).
nil = "NIL" nil = "NIL"
nstring = string / nil nstring = string / nil
number = 1*DIGIT number = 1*DIGIT
; Unsigned 32-bit integer ; Unsigned 32-bit integer
; (0 <= n < 4,294,967,296) ; (0 <= n < 4,294,967,296)
number64 = 1*DIGIT number64 = 1*DIGIT
; Unsigned 63-bit integer ; Unsigned 63-bit integer
; (0 <= n <= 9,223,372,036,854,775,807) ; (0 <= n <= 9,223,372,036,854,775,807)
nz-number = digit-nz *DIGIT nz-number = digit-nz *DIGIT
; Non-zero unsigned 32-bit integer ; Non-zero unsigned 32-bit integer
; (0 < n < 4,294,967,296) ; (0 < n < 4,294,967,296)
nz-number64 = digit-nz *DIGIT
; Unsigned 63-bit integer
; (0 < n <= 9,223,372,036,854,775,807)
oldname-extended-item = "OLDNAME" SP "(" mailbox ")" oldname-extended-item = "OLDNAME" SP "(" mailbox ")"
; Extended data item (mbox-list-extended-item) ; Extended data item (mbox-list-extended-item)
; returned in a LIST response when a mailbox is ; returned in a LIST response when a mailbox is
; renamed or deleted. Also returned when ; renamed or deleted. Also returned when
; the server canonicalized the provided mailbox ; the server canonicalized the provided mailbox
; name. ; name.
; Note 1: the OLDNAME tag can be returned ; Note 1: the OLDNAME tag can be returned
; with or without surrounding quotes, as per ; with or without surrounding quotes, as per
; mbox-list-extended-item-tag production. ; mbox-list-extended-item-tag production.
skipping to change at page 136, line 44 skipping to change at page 136, line 48
option-val-comp = astring / option-val-comp = astring /
option-val-comp *(SP option-val-comp) / option-val-comp *(SP option-val-comp) /
"(" option-val-comp ")" "(" option-val-comp ")"
option-value = "(" option-val-comp ")" option-value = "(" option-val-comp ")"
option-vendor-tag = vendor-token "-" atom option-vendor-tag = vendor-token "-" atom
; a vendor-specific option, non-standard ; a vendor-specific option, non-standard
partial-range = number ["." nz-number] partial-range = number64 ["." nz-number64]
; Copied from RFC 5092 (IMAP URL) ; Copied from RFC 5092 (IMAP URL)
; and updated to support 64bit sizes.
partial = "<" number "." nz-number ">" partial = "<" number64 "." nz-number64 ">"
; Partial FETCH request. 0-based offset of ; Partial FETCH request. 0-based offset of
; the first octet, followed by the number of octets ; the first octet, followed by the number of octets
; in the fragment. ; in the fragment.
password = astring password = astring
patterns = "(" list-mailbox ")" patterns = "(" list-mailbox ")"
; [RFC5258] supports multiple patterns, ; [RFC5258] supports multiple patterns,
; but this document only requires one ; but this document only requires one
; to be supported. ; to be supported.
skipping to change at page 138, line 42 skipping to change at page 138, line 48
"BEFORE" SP date / "BODY" SP astring / "BEFORE" SP date / "BODY" SP astring /
"CC" SP astring / "DELETED" / "FLAGGED" / "CC" SP astring / "DELETED" / "FLAGGED" /
"FROM" SP astring / "KEYWORD" SP flag-keyword / "FROM" SP astring / "KEYWORD" SP flag-keyword /
"ON" SP date / "SEEN" / "ON" SP date / "SEEN" /
"SINCE" SP date / "SUBJECT" SP astring / "SINCE" SP date / "SUBJECT" SP astring /
"TEXT" SP astring / "TO" SP astring / "TEXT" SP astring / "TO" SP astring /
"UNANSWERED" / "UNDELETED" / "UNFLAGGED" / "UNANSWERED" / "UNDELETED" / "UNFLAGGED" /
"UNKEYWORD" SP flag-keyword / "UNSEEN" / "UNKEYWORD" SP flag-keyword / "UNSEEN" /
; Above this line were in [IMAP2] ; Above this line were in [IMAP2]
"DRAFT" / "HEADER" SP header-fld-name SP astring / "DRAFT" / "HEADER" SP header-fld-name SP astring /
"LARGER" SP number / "NOT" SP search-key / "LARGER" SP number64 / "NOT" SP search-key /
"OR" SP search-key SP search-key / "OR" SP search-key SP search-key /
"SENTBEFORE" SP date / "SENTON" SP date / "SENTBEFORE" SP date / "SENTON" SP date /
"SENTSINCE" SP date / "SMALLER" SP number / "SENTSINCE" SP date / "SMALLER" SP number64 /
"UID" SP sequence-set / "UNDRAFT" / sequence-set / "UID" SP sequence-set / "UNDRAFT" / sequence-set /
"(" search-key *(SP search-key) ")" "(" search-key *(SP search-key) ")"
search-modifier-name = tagged-ext-label search-modifier-name = tagged-ext-label
search-mod-params = tagged-ext-val search-mod-params = tagged-ext-val
; This non-terminal shows recommended syntax ; This non-terminal shows recommended syntax
; for future extensions. ; for future extensions.
search-program = ["CHARSET" SP charset SP] search-program = ["CHARSET" SP charset SP]
skipping to change at page 142, line 4 skipping to change at page 142, line 11
tag-string = astring tag-string = astring
; <tag> represented as <astring> ; <tag> represented as <astring>
tagged-ext-label = tagged-label-fchar *tagged-label-char tagged-ext-label = tagged-label-fchar *tagged-label-char
; Is a valid RFC 3501 "atom". ; Is a valid RFC 3501 "atom".
tagged-label-fchar = ALPHA / "-" / "_" / "." tagged-label-fchar = ALPHA / "-" / "_" / "."
tagged-label-char = tagged-label-fchar / DIGIT / ":" tagged-label-char = tagged-label-fchar / DIGIT / ":"
tagged-ext-comp = astring / tagged-ext-comp = astring /
tagged-ext-comp *(SP tagged-ext-comp) / tagged-ext-comp *(SP tagged-ext-comp) /
"(" tagged-ext-comp ")" "(" tagged-ext-comp ")"
; Extensions that follow this general ; Extensions that follow this general
; syntax should use nstring instead of ; syntax should use nstring instead of
; astring when appropriate in the context ; astring when appropriate in the context
; of the extension. ; of the extension.
; Note that a message set or a "number" ; Note that a message set or a "number"
; can always be represented as an "atom". ; can always be represented as an "atom".
; An URL should be represented as ; An URL should be represented as
; a "quoted" string. ; a "quoted" string.
tagged-ext-simple = sequence-set / number / number64 tagged-ext-simple = sequence-set / number / number64
tagged-ext-val = tagged-ext-simple / tagged-ext-val = tagged-ext-simple /
"(" [tagged-ext-comp] ")" "(" [tagged-ext-comp] ")"
text = 1*(TEXT-CHAR / UTF8-2 / UTF8-3 / UTF8-4) text = 1*(TEXT-CHAR / UTF8-2 / UTF8-3 / UTF8-4)
; Non ASCII text can only be returned ; Non ASCII text can only be returned
; after ENABLE IMAP4rev2 command ; after ENABLE IMAP4rev2 command
TEXT-CHAR = <any CHAR except CR and LF> TEXT-CHAR = <any CHAR except CR and LF>
time = 2DIGIT ":" 2DIGIT ":" 2DIGIT time = 2DIGIT ":" 2DIGIT ":" 2DIGIT
; Hours minutes seconds ; Hours minutes seconds
uid = "UID" SP uid = "UID" SP
(copy / move / fetch / search / store / uid-expunge) (copy / move / fetch / search / store / uid-expunge)
; Unique identifiers used instead of message ; Unique identifiers used instead of message
; sequence numbers ; sequence numbers
uid-expunge = "EXPUNGE" SP sequence-set uid-expunge = "EXPUNGE" SP sequence-set
; Unique identifiers used instead of message ; Unique identifiers used instead of message
; sequence numbers ; sequence numbers
uid-set = (uniqueid / uid-range) *("," uid-set) uid-set = (uniqueid / uid-range) *("," uid-set)
uid-range = (uniqueid ":" uniqueid) uid-range = (uniqueid ":" uniqueid)
; two uniqueid values and all values ; two uniqueid values and all values
; between these two regards of order. ; between these two regards of order.
; Example: 2:4 and 4:2 are equivalent. ; Example: 2:4 and 4:2 are equivalent.
uniqueid = nz-number uniqueid = nz-number
; Strictly ascending ; Strictly ascending
unsubscribe = "UNSUBSCRIBE" SP mailbox unsubscribe = "UNSUBSCRIBE" SP mailbox
userid = astring userid = astring
UTF8-2 = <Defined in Section 4 of RFC 3629> UTF8-2 = <Defined in Section 4 of RFC 3629>
UTF8-3 = <Defined in Section 4 of RFC 3629> UTF8-3 = <Defined in Section 4 of RFC 3629>
UTF8-4 = <Defined in Section 4 of RFC 3629> UTF8-4 = <Defined in Section 4 of RFC 3629>
vendor-token = "vendor." name-component vendor-token = "vendor." name-component
; Definition copied from RFC 2244. ; Definition copied from RFC 2244.
; MUST be registered with IANA ; MUST be registered with IANA
skipping to change at page 153, line 4 skipping to change at page 153, line 10
An implementation that wants to remain compatible with IMAP4rev1 can An implementation that wants to remain compatible with IMAP4rev1 can
advertise both IMAP4rev1 and IMAP4rev2 in its CAPABILITY response/ advertise both IMAP4rev1 and IMAP4rev2 in its CAPABILITY response/
response code. While some IMAP4rev1 responses were removed in response code. While some IMAP4rev1 responses were removed in
IMAP4rev2, their presence will not break IMAP4rev2-only clients. IMAP4rev2, their presence will not break IMAP4rev2-only clients.
If both IMAP4rev1 and IMAP4rev2 are advertised, an IMAP client that If both IMAP4rev1 and IMAP4rev2 are advertised, an IMAP client that
wants to use IMAP4rev2 MUST issue an "ENABLE IMAP4rev2" command. wants to use IMAP4rev2 MUST issue an "ENABLE IMAP4rev2" command.
Servers advertising both IMAP4rev1 and IMAP4rev2 MUST NOT generate Servers advertising both IMAP4rev1 and IMAP4rev2 MUST NOT generate
UTF-8 quoted strings unless the client has issued "ENABLE IMAP4rev2". UTF-8 quoted strings unless the client has issued "ENABLE IMAP4rev2".
Consider implementation of mechanisms described or referenced in Consider implementation of mechanisms described or referenced in
[IMAP-UTF-8] to achieve this goal. [IMAP-UTF-8] to achieve this goal.
Servers advertising both IMAP4rev1 and IMAP4rev2, and clients Servers advertising both IMAP4rev1 and IMAP4rev2, and clients
intending to be compatible with IMAP4rev1 servers MUST be compatible intending to be compatible with IMAP4rev1 servers MUST be compatible
with the international mailbox naming convention described in the with the international mailbox naming convention described in the
following subsection. following subsection.
Also see Appendix D for special considerations for servers that
support 63 bit body part/message sizes and want to advertise support
for both IMAP4rev1 and IMAP4rev2.
A.1. Mailbox International Naming Convention for compatibility with A.1. Mailbox International Naming Convention for compatibility with
IMAP4rev1 IMAP4rev1
Support for the Mailbox International Naming Convention described in Support for the Mailbox International Naming Convention described in
this section is not required for IMAP4rev2-only clients and servers. this section is not required for IMAP4rev2-only clients and servers.
It is only used for backward compatibility with IMAP4rev1 It is only used for backward compatibility with IMAP4rev1
implementations. implementations.
By convention, international mailbox names in IMAP4rev1 are specified By convention, international mailbox names in IMAP4rev1 are specified
using a modified version of the UTF-7 encoding described in [UTF-7]. using a modified version of the UTF-7 encoding described in [UTF-7].
skipping to change at page 154, line 50 skipping to change at page 155, line 9
and Japanese text: ~peter/mail/&U,BTFw-/&ZeVnLIqe- and Japanese text: ~peter/mail/&U,BTFw-/&ZeVnLIqe-
For example, the string "&Jjo!" is not a valid mailbox name For example, the string "&Jjo!" is not a valid mailbox name
because it does not contain a shift to US-ASCII before the "!". because it does not contain a shift to US-ASCII before the "!".
The correct form is "&Jjo-!". The string "&U,BTFw-&ZeVnLIqe-" is The correct form is "&Jjo-!". The string "&U,BTFw-&ZeVnLIqe-" is
not permitted because it contains a superfluous shift. The not permitted because it contains a superfluous shift. The
correct form is "&U,BTF2XlZyyKng-". correct form is "&U,BTF2XlZyyKng-".
Appendix B. Backward compatibility with BINARY extension Appendix B. Backward compatibility with BINARY extension
IMAP4rev2 is incorporates subset of functionality provided by the IMAP4rev2 incorporates subset of functionality provided by the BINARY
BINARY extension [RFC3516], in particular it includes additional extension [RFC3516], in particular it includes additional FETCH items
FETCH items (BINARY, BINARY.PEEK and BINARY.SIZE), but not extensions (BINARY, BINARY.PEEK and BINARY.SIZE), but not extensions to the
to the APPEND command. IMAP4rev2 implementations that supports full APPEND command. IMAP4rev2 implementations that supports full RFC
RFC 3516 functionality need to also advertise the BINARY token in the 3516 functionality need to also advertise the BINARY capability in
CAPABILITY response. the CAPABILITY response/response code.
Appendix C. Backward compatibility with LIST-EXTENDED extension Appendix C. Backward compatibility with LIST-EXTENDED extension
IMAP4rev2 is incorporates most of functionality provided by the LIST- IMAP4rev2 incorporates most of functionality provided by the LIST-
EXTENDED extension [RFC5258]. In particular, multiple mailbox EXTENDED extension [RFC5258]. In particular, multiple mailbox
patterns syntax is not supported in IMAP4rev2, unless LIST-EXTENDED patterns syntax is not supported in IMAP4rev2, unless LIST-EXTENDED
capability is also advertised in CAPABILITY response/response code. capability is also advertised in the CAPABILITY response/response
code.
Appendix D. Changes from RFC 3501 / IMAP4rev1 Appendix D. 63 bit body part and message sizes
IMAP4rev2 increases allowed body part and message sizes that servers
can support from 32 to 63 bits. Server implementations don't have to
support 63 bit long body parts/message sizes, however client
implementations have to expect them.
As IMAP4rev1 didn't support 63 bit long body part/message sizes,
there is an interoperability issue exposed by 63 bit capable servers
that are accessible by both IMAP4rev1 and IMAP4rev2 email clients.
As IMAP4rev1 would be unable to retrieve full content of messages
bigger than 4Gb, it is RECOMMENDED that such servers hide messages
bigger than 4Gb from IMAP4rev1 clients.
For example, image that a mailbox has 3 messages with UIDs 1, 17, 21.
These messages have the following sizes (respectively): 32Kb, 5Gb,
60Mb. When such mailbox is accessed by an IMAP4rev2 client that
issued "ENABLE IMAP4rev2", it will see all 3 messages. When such
mailbox is accessed by an IMAP4rev1 client, it will only see messages
with UIDs 1 and 21.
Appendix E. Changes from RFC 3501 / IMAP4rev1
Below is the summary of changes since RFC 3501: Below is the summary of changes since RFC 3501:
1. Folded in IMAP NAMESPACE (RFC 2342), UNSELECT (RFC 3691), 1. Support for 64bit message and body part sizes.
2. Folded in IMAP NAMESPACE (RFC 2342), UNSELECT (RFC 3691),
UIDPLUS (RFC 4315), ESEARCH (RFC 4731), SEARCHRES (RFC 5182), UIDPLUS (RFC 4315), ESEARCH (RFC 4731), SEARCHRES (RFC 5182),
ENABLE (RFC 5161), IDLE (RFC 2177), SASL-IR (RFC 4959), LIST- ENABLE (RFC 5161), IDLE (RFC 2177), SASL-IR (RFC 4959), LIST-
EXTENDED (RFC 5258), LIST-STATUS (RFC 5819), MOVE (RFC 6851) and EXTENDED (RFC 5258), LIST-STATUS (RFC 5819), MOVE (RFC 6851) and
LITERAL- (RFC 7888) extensions. Also folded RFC 4466 (IMAP ABNF LITERAL- (RFC 7888) extensions. Also folded RFC 4466 (IMAP ABNF
extensions), RFC 5530 (response codes), the FETCH side of the extensions), RFC 5530 (response codes), the FETCH side of the
BINARY extension (RFC 3516) and the list of new mailbox BINARY extension (RFC 3516) and the list of new mailbox
attributes from SPECIAL-USE (RFC 6154). attributes from SPECIAL-USE (RFC 6154).
2. Added STATUS SIZE (RFC 8438) and STATUS DELETED. 3. Added STATUS SIZE (RFC 8438) and STATUS DELETED.
3. SEARCH command now requires to return ESEARCH response (SEARCH 4. SEARCH command now requires to return ESEARCH response (SEARCH
response is now deprecated). response is now deprecated).
4. Clarified which SEARCH keys has to use substring match and which 5. Clarified which SEARCH keys has to use substring match and which
don't. don't.
5. Clarified that server should decode parameter value 6. Clarified that server should decode parameter value
continuations as described in [RFC2231]. This requirement was continuations as described in [RFC2231]. This requirement was
hidden in RFC 2231 itself. hidden in RFC 2231 itself.
6. Added CLOSED response code from RFC 7162. SELECT/EXAMINE when a 7. Added CLOSED response code from RFC 7162. SELECT/EXAMINE when a
mailbox is already selected now require for the CLOSED response mailbox is already selected now require for the CLOSED response
code to be returned. code to be returned.
7. SELECT/EXAMINE are now required to return untagged LIST 8. SELECT/EXAMINE are now required to return untagged LIST
response. response.
8. UNSEEN response code on SELECT/EXAMINE is now deprecated. 9. UNSEEN response code on SELECT/EXAMINE is now deprecated.
9. RECENT response on SELECT/EXAMINE, \Recent flag, RECENT STATUS, 10. RECENT response on SELECT/EXAMINE, \Recent flag, RECENT STATUS,
SEARCH NEW items are now deprecated. SEARCH NEW items are now deprecated.
10. Clarified that the server doesn't need to send a new 11. Clarified that the server doesn't need to send a new
PERMANENTFLAGS response code when a new keyword was successfully PERMANENTFLAGS response code when a new keyword was successfully
added and the server advertised \* earlier for the same mailbox. added and the server advertised \* earlier for the same mailbox.
11. For future extensibility extended ABNF for tagged-ext-simple to 12. For future extensibility extended ABNF for tagged-ext-simple to
allow for bare number64. allow for bare number64.
12. Added SHOULD level requirement on IMAP servers to support 13. Added SHOULD level requirement on IMAP servers to support
$MDNSent, $Forwarded, $Junk, $NonJunk and $Phishing keywords. $MDNSent, $Forwarded, $Junk, $NonJunk and $Phishing keywords.
13. Mailbox names and message headers now allow for UTF-8. Support 14. Mailbox names and message headers now allow for UTF-8. Support
for Modified UTF-7 in mailbox names is not required, unless for Modified UTF-7 in mailbox names is not required, unless
compatibility with IMAP4rev1 is desired. compatibility with IMAP4rev1 is desired.
14. Removed the CHECK command. Clients should use NOOP instead. 15. Removed the CHECK command. Clients should use NOOP instead.
15. RFC822, RFC822.HEADER and RFC822.TEXT FETCH data items were 16. RFC822, RFC822.HEADER and RFC822.TEXT FETCH data items were
deprecated. Clients should use the corresponding BODY[] deprecated. Clients should use the corresponding BODY[]
variants instead. variants instead.
16. LSUB command was deprecated. Clients should use LIST 17. LSUB command was deprecated. Clients should use LIST
(SUBSCRIBED) instead. (SUBSCRIBED) instead.
17. IDLE command can now return updates not related to the currently 18. IDLE command can now return updates not related to the currently
selected mailbox state. selected mailbox state.
18. All unsolicited FETCH updates are required to include UID. 19. All unsolicited FETCH updates are required to include UID.
19. Clarified that client implementations MUST ignore response codes 20. Clarified that client implementations MUST ignore response codes
that they do not recognize. (Change from a SHOULD to a MUST.) that they do not recognize. (Change from a SHOULD to a MUST.)
20. resp-text ABNF non terminal was updated to allow for empty text. 21. resp-text ABNF non terminal was updated to allow for empty text.
21. After ENABLE IMAP4rev2 human readable response text can include 22. After ENABLE IMAP4rev2 human readable response text can include
non ASCII encoded in UTF-8. non ASCII encoded in UTF-8.
22. Updated to use modern TLS-related recommendations as per RFC 23. Updated to use modern TLS-related recommendations as per RFC
8314, RFC 7817, RFC 7525. 8314, RFC 7817, RFC 7525.
23. Replaced DIGEST-MD5 SASL mechanism with SCRAM-SHA-256. DIGEST- 24. Replaced DIGEST-MD5 SASL mechanism with SCRAM-SHA-256. DIGEST-
MD5 was deprecated. MD5 was deprecated.
Appendix E. Other Recommended IMAP Extensions Appendix F. Other Recommended IMAP Extensions
Support for the following extensions is recommended for all IMAP Support for the following extensions is recommended for all IMAP
client and servers. Why they significantly reduce bandwidth and/or client and servers. Why they significantly reduce bandwidth and/or
number of round trips used by IMAP in certain situations, the EXTRA number of round trips used by IMAP in certain situations, the EXTRA
WG decided that requiring them as a part of IMAP4rev2 would push the WG decided that requiring them as a part of IMAP4rev2 would push the
bar to implement too high for new implementations. Also note that bar to implement too high for new implementations. Also note that
absence of any IMAP extension from this list doesn't make it somehow absence of any IMAP extension from this list doesn't make it somehow
deficient or not recommended for use with IMAP4rev2. deficient or not recommended for use with IMAP4rev2.
1. QRESYNC and CONDSTORE extensions (RFC 7162). They make 1. QRESYNC and CONDSTORE extensions (RFC 7162). They make
discovering changes to IMAP mailboxes more efficient, at the discovering changes to IMAP mailboxes more efficient, at the
expense of storing a bit more state. expense of storing a bit more state.
2. OBJECTID extension (RFC 8474) helps with preserving IMAP client 2. OBJECTID extension (RFC 8474) helps with preserving IMAP client
cache when messages moved/copied or mailboxes are renamed. cache when messages moved/copied or mailboxes are renamed.
Appendix F. Acknowledgement Appendix G. Acknowledgement
Earlier versions of this document were edited by Mark Crispin. Earlier versions of this document were edited by Mark Crispin.
Sadly, he is no longer available to help with this work. Editors of Sadly, he is no longer available to help with this work. Editors of
this revisions are hoping that Mark would have approved. this revisions are hoping that Mark would have approved.
Chris Newman has contributed text on I18N and use of UTF-8 in Chris Newman has contributed text on I18N and use of UTF-8 in
messages and mailbox names. messages and mailbox names.
Thank you to Tony Hansen for helping with the index generation. Thank you to Tony Hansen for helping with the index generation.
Thank you to Timo Sirainen, Bron Gondwana, Stephan Bosch and Arnt Thank you to Timo Sirainen, Bron Gondwana, Stephan Bosch and Arnt
 End of changes. 57 change blocks. 
73 lines changed or deleted 112 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/