< draft-ietf-extra-imap4rev2-26.txt   draft-ietf-extra-imap4rev2-27.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: July 28, 2021 January 24, 2021 Expires: August 6, 2021 February 2, 2021
Internet Message Access Protocol (IMAP) - Version 4rev2 Internet Message Access Protocol (IMAP) - Version 4rev2
draft-ietf-extra-imap4rev2-26 draft-ietf-extra-imap4rev2-27
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 July 28, 2021. This Internet-Draft will expire on August 6, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2021 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 3, line 32 skipping to change at page 3, line 32
5.5. Multiple Commands in Progress (Command Pipelining) . . . 24 5.5. Multiple Commands in Progress (Command Pipelining) . . . 24
6. Client Commands . . . . . . . . . . . . . . . . . . . . . . . 25 6. Client Commands . . . . . . . . . . . . . . . . . . . . . . . 25
6.1. Client Commands - Any State . . . . . . . . . . . . . . . 26 6.1. Client Commands - Any State . . . . . . . . . . . . . . . 26
6.1.1. CAPABILITY Command . . . . . . . . . . . . . . . . . 26 6.1.1. CAPABILITY Command . . . . . . . . . . . . . . . . . 26
6.1.2. NOOP Command . . . . . . . . . . . . . . . . . . . . 27 6.1.2. NOOP Command . . . . . . . . . . . . . . . . . . . . 27
6.1.3. LOGOUT Command . . . . . . . . . . . . . . . . . . . 27 6.1.3. LOGOUT Command . . . . . . . . . . . . . . . . . . . 27
6.2. Client Commands - Not Authenticated State . . . . . . . . 28 6.2. Client Commands - Not Authenticated State . . . . . . . . 28
6.2.1. STARTTLS Command . . . . . . . . . . . . . . . . . . 28 6.2.1. STARTTLS Command . . . . . . . . . . . . . . . . . . 28
6.2.2. AUTHENTICATE Command . . . . . . . . . . . . . . . . 30 6.2.2. AUTHENTICATE Command . . . . . . . . . . . . . . . . 30
6.2.3. LOGIN Command . . . . . . . . . . . . . . . . . . . . 33 6.2.3. LOGIN Command . . . . . . . . . . . . . . . . . . . . 33
6.3. Client Commands - Authenticated State . . . . . . . . . . 33 6.3. Client Commands - Authenticated State . . . . . . . . . . 34
6.3.1. ENABLE Command . . . . . . . . . . . . . . . . . . . 34 6.3.1. ENABLE Command . . . . . . . . . . . . . . . . . . . 34
6.3.2. SELECT Command . . . . . . . . . . . . . . . . . . . 36 6.3.2. SELECT Command . . . . . . . . . . . . . . . . . . . 36
6.3.3. EXAMINE Command . . . . . . . . . . . . . . . . . . . 38 6.3.3. EXAMINE Command . . . . . . . . . . . . . . . . . . . 38
6.3.4. CREATE Command . . . . . . . . . . . . . . . . . . . 39 6.3.4. CREATE Command . . . . . . . . . . . . . . . . . . . 39
6.3.5. DELETE Command . . . . . . . . . . . . . . . . . . . 40 6.3.5. DELETE Command . . . . . . . . . . . . . . . . . . . 40
6.3.6. RENAME Command . . . . . . . . . . . . . . . . . . . 42 6.3.6. RENAME Command . . . . . . . . . . . . . . . . . . . 42
6.3.7. SUBSCRIBE Command . . . . . . . . . . . . . . . . . . 44 6.3.7. SUBSCRIBE Command . . . . . . . . . . . . . . . . . . 44
6.3.8. UNSUBSCRIBE Command . . . . . . . . . . . . . . . . . 45 6.3.8. UNSUBSCRIBE Command . . . . . . . . . . . . . . . . . 45
6.3.9. LIST Command . . . . . . . . . . . . . . . . . . . . 45 6.3.9. LIST Command . . . . . . . . . . . . . . . . . . . . 45
6.3.10. NAMESPACE Command . . . . . . . . . . . . . . . . . . 64 6.3.10. NAMESPACE Command . . . . . . . . . . . . . . . . . . 64
skipping to change at page 4, line 34 skipping to change at page 4, line 34
7.3.5. FLAGS Response . . . . . . . . . . . . . . . . . . . 117 7.3.5. FLAGS Response . . . . . . . . . . . . . . . . . . . 117
7.4. Server Responses - Mailbox Size . . . . . . . . . . . . . 118 7.4. Server Responses - Mailbox Size . . . . . . . . . . . . . 118
7.4.1. EXISTS Response . . . . . . . . . . . . . . . . . . . 118 7.4.1. EXISTS Response . . . . . . . . . . . . . . . . . . . 118
7.5. Server Responses - Message Status . . . . . . . . . . . . 118 7.5. Server Responses - Message Status . . . . . . . . . . . . 118
7.5.1. EXPUNGE Response . . . . . . . . . . . . . . . . . . 118 7.5.1. EXPUNGE Response . . . . . . . . . . . . . . . . . . 118
7.5.2. FETCH Response . . . . . . . . . . . . . . . . . . . 119 7.5.2. FETCH Response . . . . . . . . . . . . . . . . . . . 119
7.6. Server Responses - Command Continuation Request . . . . . 125 7.6. Server Responses - Command Continuation Request . . . . . 125
8. Sample IMAP4rev2 connection . . . . . . . . . . . . . . . . . 126 8. Sample IMAP4rev2 connection . . . . . . . . . . . . . . . . . 126
9. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 127 9. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 127
10. Author's Note . . . . . . . . . . . . . . . . . . . . . . . . 145 10. Author's Note . . . . . . . . . . . . . . . . . . . . . . . . 145
11. Security Considerations . . . . . . . . . . . . . . . . . . . 146 11. Security Considerations . . . . . . . . . . . . . . . . . . . 145
11.1. TLS related Security Considerations . . . . . . . . . . 146 11.1. TLS related Security Considerations . . . . . . . . . . 145
11.2. STARTTLS command versa use of Implicit TLS port . . . . 146 11.2. STARTTLS command versa use of Implicit TLS port . . . . 146
11.3. Client handling of unsolicited responses not suitable 11.3. Client handling of unsolicited responses not suitable
for the current connection state . . . . . . . . . . . . 147 for the current connection state . . . . . . . . . . . . 146
11.4. COPYUID and APPENDUID response codes . . . . . . . . . . 147 11.4. COPYUID and APPENDUID response codes . . . . . . . . . . 147
11.5. LIST command and Other Users' namespace . . . . . . . . 148 11.5. LIST command and Other Users' namespace . . . . . . . . 147
11.6. Other Security Considerations . . . . . . . . . . . . . 148 11.6. Other Security Considerations . . . . . . . . . . . . . 147
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 149 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 148
12.1. Updates to IMAP4 Capabilities registry . . . . . . . . . 149 12.1. Updates to IMAP4 Capabilities registry . . . . . . . . . 149
12.2. GSSAPI/SASL service name . . . . . . . . . . . . . . . . 149 12.2. GSSAPI/SASL service name . . . . . . . . . . . . . . . . 149
12.3. LIST Selection Options, LIST Return Options, LIST 12.3. LIST Selection Options, LIST Return Options, LIST
extended data items . . . . . . . . . . . . . . . . . . 150 extended data items . . . . . . . . . . . . . . . . . . 149
12.4. IMAP Mailbox Name Attributes and IMAP Response Codes . . 150 12.4. IMAP Mailbox Name Attributes and IMAP Response Codes . . 150
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 150 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 150
13.1. Normative References . . . . . . . . . . . . . . . . . . 150 13.1. Normative References . . . . . . . . . . . . . . . . . . 150
13.2. Informative References (related protocols) . . . . . . . 153 13.2. Informative References (related protocols) . . . . . . . 153
13.3. Informative References (historical aspects of IMAP and 13.3. Informative References (historical aspects of IMAP and
related protocols) . . . . . . . . . . . . . . . . . . . 156 related protocols) . . . . . . . . . . . . . . . . . . . 155
Appendix A. Backward compatibility with IMAP4rev1 . . . . . . . 156 Appendix A. Backward compatibility with IMAP4rev1 . . . . . . . 156
A.1. Mailbox International Naming Convention for compatibility A.1. Mailbox International Naming Convention for compatibility
with IMAP4rev1 . . . . . . . . . . . . . . . . . . . . . 157 with IMAP4rev1 . . . . . . . . . . . . . . . . . . . . . 157
Appendix B. Backward compatibility with BINARY extension . . . . 159 Appendix B. Backward compatibility with BINARY extension . . . . 158
Appendix C. Backward compatibility with LIST-EXTENDED extension 159 Appendix C. Backward compatibility with LIST-EXTENDED extension 159
Appendix D. 63 bit body part and message sizes . . . . . . . . . 159 Appendix D. 63 bit body part and message sizes . . . . . . . . . 159
Appendix E. Changes from RFC 3501 / IMAP4rev1 . . . . . . . . . 159 Appendix E. Changes from RFC 3501 / IMAP4rev1 . . . . . . . . . 159
Appendix F. Other Recommended IMAP Extensions . . . . . . . . . 161 Appendix F. Other Recommended IMAP Extensions . . . . . . . . . 161
Appendix G. Acknowledgement . . . . . . . . . . . . . . . . . . 162 Appendix G. Acknowledgement . . . . . . . . . . . . . . . . . . 162
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 168 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 167
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
provides the general context and definitions with which IMAP4rev2 provides the general context and definitions with which IMAP4rev2
skipping to change at page 6, line 46 skipping to change at page 6, line 46
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 IMAP4rev1, IMAP4rev2 is designed to be upwards compatible from the IMAP4rev1
the [IMAP2] and unpublished IMAP2bis protocols. IMAP4rev2 is largely [RFC3501], the [IMAP2] and unpublished IMAP2bis [IMAP2BIS] protocols.
compatible with the IMAP4rev1 protocol described in RFC 3501 and the IMAP4rev2 is largely compatible with the IMAP4rev1 protocol described
IMAP4 protocol described in RFC 1730; the exception being in certain in RFC 3501 and the IMAP4 protocol described in RFC 1730; the
facilities added in RFC 1730 and RFC 3501 that proved problematic and exception being in certain facilities added in RFC 1730 and RFC 3501
were subsequently removed or replaced by better alternatives. In the that proved problematic and were subsequently removed or replaced by
course of the evolution of IMAP4rev2, some aspects in the earlier better alternatives. In the course of the evolution of IMAP4rev2,
protocols have become obsolete. Obsolete commands, responses, and some aspects in the earlier protocols have become obsolete. Obsolete
data formats which an IMAP4rev2 implementation can encounter when commands, responses, and data formats which an IMAP4rev2
used with an earlier implementation are described in Appendix E, implementation can encounter when used with an earlier implementation
Appendix A and [IMAP-OBSOLETE]. IMAP4rev2 supports 63bit body part are described in Appendix E, Appendix A and [IMAP-OBSOLETE].
and message sizes. IMAP4rev2 compatibility with BINARY and LIST- IMAP4rev2 supports 63bit body part and message sizes. IMAP4rev2
EXTENDED IMAP extensions are described in Appendix B and Appendix C compatibility with BINARY and LIST-EXTENDED IMAP extensions are
respectively. 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 9, line 36 skipping to change at page 9, line 36
2.3. Message Attributes 2.3. Message Attributes
In addition to message text, each message has several attributes In addition to message text, each message has several attributes
associated with it. These attributes can be retrieved individually associated with it. These attributes can be retrieved individually
or in conjunction with other attributes or message texts. or in conjunction with other attributes or message texts.
2.3.1. Message Numbers 2.3.1. Message Numbers
Messages in IMAP4rev2 are accessed by one of two numbers; the unique Messages in IMAP4rev2 are accessed by one of two numbers; the unique
identifier or the message sequence number. identifier (UID) or the message sequence number.
2.3.1.1. Unique Identifier (UID) Message Attribute 2.3.1.1. Unique Identifier (UID) Message Attribute
A UID is an unsigned non-zero 32-bit value assigned to each message, A UID is an unsigned non-zero 32-bit value assigned to each message,
which when used with the unique identifier validity value (see below) which when used with the unique identifier validity value (see below)
forms a 64-bit value that MUST NOT refer to any other message in the forms a 64-bit value that MUST NOT refer to any other message in the
mailbox or any subsequent mailbox with the same name forever. Unique mailbox or any subsequent mailbox with the same name forever. Unique
identifiers are assigned in a strictly ascending fashion in the identifiers are assigned in a strictly ascending fashion in the
mailbox; as each message is added to the mailbox it is assigned a mailbox; as each message is added to the mailbox it is assigned a
higher UID than the message(s) which were added previously. Unlike higher UID than the message(s) which were added previously. Unlike
skipping to change at page 11, line 23 skipping to change at page 11, line 23
3. If the mailbox is deleted/renamed and a new mailbox with the 3. If the mailbox is deleted/renamed and a new mailbox with the
same name is created at a later date, the server must either same name is created at a later date, the server must either
keep track of unique identifiers from the previous instance of keep track of unique identifiers from the previous instance of
the mailbox, or it must assign a new UIDVALIDITY value to the the mailbox, or it must assign a new UIDVALIDITY value to the
new instance of the mailbox. new instance of the mailbox.
4. The combination of mailbox name, UIDVALIDITY, and UID must 4. The combination of mailbox name, UIDVALIDITY, and UID must
refer to a single immutable (or expunged) message on that refer to a single immutable (or expunged) message on that
server forever. In particular, the internal date, [RFC-5322] server forever. In particular, the internal date, [RFC-5322]
size, envelope, body structure, and message texts (all size, envelope, body structure, and message texts (all
BODY[...] fetch data items) must never change. This does not BODY[...] fetch data items) MUST never change. This does not
include message numbers, nor does it include attributes that include message numbers, nor does it include attributes that
can be set by a STORE command (e.g., FLAGS). When a message can be set by a STORE command (e.g., FLAGS). When a message
is expunged, its UID MUST NOT be reused under the same is expunged, its UID MUST NOT be reused under the same
UIDVALIDITY value. UIDVALIDITY value.
2.3.1.2. Message Sequence Number Message Attribute 2.3.1.2. Message Sequence Number Message Attribute
A Message Sequence Number is a relative position from 1 to the number A Message Sequence Number is a relative position from 1 to the number
of messages in the mailbox. This position MUST be ordered by of messages in the mailbox. This position MUST be ordered by
ascending unique identifier. As each new message is added, it is ascending unique identifier. As each new message is added, it is
skipping to change at page 13, line 36 skipping to change at page 13, line 36
junk filtering applied, including setting the $Junk flag and junk filtering applied, including setting the $Junk flag and
placing in the \Junk special-use mailbox (see Section 7.3.1) if placing in the \Junk special-use mailbox (see Section 7.3.1) if
available. available.
If both the $Phishing flag and the $Junk flag are set, the user If both the $Phishing flag and the $Junk flag are set, the user
agent should display an additional warning message to the user. agent should display an additional warning message to the user.
Additionally the user agent may display a warning when clicking on Additionally the user agent may display a warning when clicking on
any hyperlinks within the message. any hyperlinks within the message.
The requirement for both $Phishing and $Junk to be set before a The requirement for both $Phishing and $Junk to be set before a
user agent displays a warning is for better backwards user agent displays a warning is for better backwards
compatibility with existing clients that understand the $Junk flag compatibility with existing clients that understand the $Junk flag
but not the $Phishing flag. This so that when an unextended but not the $Phishing flag. This is so that when an unextended
client removes the $Junk flag, an extended client will also show client removes the $Junk flag, an extended client will also show
the correct state. See [IMAP-KEYWORDS-REG] for more information. the correct state. See [IMAP-KEYWORDS-REG] for more information.
$Junk and $NotJunk are mutually exclusive. If more than one of them $Junk and $NotJunk are mutually exclusive. If more than one of them
is set for a message, the client MUST treat this as if none of them is set for a message, the client MUST treat this as if none of them
is set and SHOULD unset both of them on the IMAP server. is set and SHOULD unset both of them on the IMAP server.
Other registered keywords can be found in the "IMAP and JMAP Other registered keywords can be found in the "IMAP and JMAP
Keywords" registry [IMAP-KEYWORDS-REG]. New keywords SHOULD be Keywords" registry [IMAP-KEYWORDS-REG]. New keywords SHOULD be
registered in this registry using the procedure specified in registered in this registry using the procedure specified in
skipping to change at page 17, line 22 skipping to change at page 17, line 22
4.1. Atom 4.1. Atom
An atom consists of one or more non-special characters. An atom consists of one or more non-special characters.
4.1.1. Sequence set and UID set 4.1.1. Sequence set and UID set
A set of messages can be referenced by a sequence set containing A set of messages can be referenced by a sequence set containing
either message sequence numbers or unique identifiers. See Section 9 either message sequence numbers or unique identifiers. See Section 9
for details. Sequence sets can contain ranges (e.g. "5:50"), an for details. Sequence sets can contain ranges (e.g. "5:50"), an
enumeration of specific message/UID numbers, a special symbol "*", or enumeration of specific message sequence numbers/unique identifiers,
a combination of the above. a special symbol "*", or a combination of the above. Note that a
sequence set never mixes message sequence numbers and unique
identifiers in the same representation.
A "UID set" is similar to the sequence set of unique identifiers; A "UID set" is similar to the sequence set of unique identifiers;
however, the "*" value for a sequence number is not permitted. however, the "*" value for a sequence number is not permitted.
4.2. Number 4.2. Number
A number consists of one or more digit characters, and represents a A number consists of one or more digit characters, and represents a
numeric value. numeric value.
4.3. String 4.3. String
A string is in one of three forms: synchonizing literal, non- A string is in one of three forms: synchronizing literal, non-
synchronizing literal or quoted string. The synchronizing literal synchronizing literal or quoted string. The synchronizing literal
form is the general form of string. The non-synchronizing literal form is the general form of string. The non-synchronizing literal
form is also the general form, but has length limitation. The quoted form is also the general form, but has length limitation. The quoted
string form is an alternative that avoids the overhead of processing string form is an alternative that avoids the overhead of processing
a literal at the cost of limitations of characters which may be used. a literal at the cost of limitations of characters which may be used.
When the distinction between synchronizing and non-synchronizing When the distinction between synchronizing and non-synchronizing
literals is not important, this document just uses the term literals is not important, this document just uses the term
"literal". "literal".
skipping to change at page 22, line 11 skipping to change at page 22, line 11
their Personal Namespace. It is the part of the namespace that their Personal Namespace. It is the part of the namespace that
belongs to the user that is allocated for mailboxes. If an INBOX belongs to the user that is allocated for mailboxes. If an INBOX
exists for a user, it MUST appear within the user's personal exists for a user, it MUST appear within the user's personal
namespace. In the typical case, there SHOULD be only one Personal namespace. In the typical case, there SHOULD be only one Personal
Namespace per user on a server. Namespace per user on a server.
Other Users' Namespace: A namespace that consists of mailboxes from Other Users' Namespace: A namespace that consists of mailboxes from
the Personal Namespaces of other users. To access mailboxes in the the Personal Namespaces of other users. To access mailboxes in the
Other Users' Namespace, the currently authenticated user MUST be Other Users' Namespace, the currently authenticated user MUST be
explicitly granted access rights. For example, it is common for a explicitly granted access rights. For example, it is common for a
manager to grant to their secretary access rights to their mailbox. manager to grant to their administrative support staff access rights
In the typical case, there SHOULD be only one Other Users' Namespace to their mailbox. In the typical case, there SHOULD be only one
per user on a server. Other Users' Namespace per user on a server.
Shared Namespace: A namespace that consists of mailboxes that are Shared Namespace: A namespace that consists of mailboxes that are
intended to be shared amongst users and do not exist within a user's intended to be shared amongst users and do not exist within a user's
Personal Namespace. Personal Namespace.
The namespaces a server uses MAY differ on a per-user basis. The namespaces a server uses MAY differ on a per-user basis.
5.1.2.1. Historic Mailbox Namespace Naming Convention 5.1.2.1. Historic Mailbox Namespace Naming Convention
By convention, the first hierarchical element of any mailbox name By convention, the first hierarchical element of any mailbox name
skipping to change at page 32, line 22 skipping to change at page 32, line 22
try another authentication mechanism by issuing another AUTHENTICATE try another authentication mechanism by issuing another AUTHENTICATE
command. It MAY also attempt to authenticate by using the LOGIN command. It MAY also attempt to authenticate by using the LOGIN
command (see Section 6.2.3 for more detail). In other words, the command (see Section 6.2.3 for more detail). In other words, the
client MAY request authentication types in decreasing order of client MAY request authentication types in decreasing order of
preference, with the LOGIN command as a last resort. preference, with the LOGIN command as a last resort.
The authorization identity passed from the client to the server The authorization identity passed from the client to the server
during the authentication exchange is interpreted by the server as during the authentication exchange is interpreted by the server as
the user name whose privileges the client is requesting. the user name whose privileges the client is requesting.
Example: S: * OK IMAP4rev2 Server Example: S: * OK [CAPABILITY IMAP4rev2 STARTTLS AUTH=GSSAPI]
Capabilities
C: A001 AUTHENTICATE GSSAPI C: A001 AUTHENTICATE GSSAPI
S: + S: +
C: YIIB+wYJKoZIhvcSAQICAQBuggHqMIIB5qADAgEFoQMCAQ6iBw C: YIIB+wYJKoZIhvcSAQICAQBuggHqMIIB5qADAgEFoQMCAQ6iBw
MFACAAAACjggEmYYIBIjCCAR6gAwIBBaESGxB1Lndhc2hpbmd0 MFACAAAACjggEmYYIBIjCCAR6gAwIBBaESGxB1Lndhc2hpbmd0
b24uZWR1oi0wK6ADAgEDoSQwIhsEaW1hcBsac2hpdmFtcy5jYW b24uZWR1oi0wK6ADAgEDoSQwIhsEaW1hcBsac2hpdmFtcy5jYW
Mud2FzaGluZ3Rvbi5lZHWjgdMwgdCgAwIBAaEDAgEDooHDBIHA Mud2FzaGluZ3Rvbi5lZHWjgdMwgdCgAwIBAaEDAgEDooHDBIHA
cS1GSa5b+fXnPZNmXB9SjL8Ollj2SKyb+3S0iXMljen/jNkpJX cS1GSa5b+fXnPZNmXB9SjL8Ollj2SKyb+3S0iXMljen/jNkpJX
AleKTz6BQPzj8duz8EtoOuNfKgweViyn/9B9bccy1uuAE2HI0y AleKTz6BQPzj8duz8EtoOuNfKgweViyn/9B9bccy1uuAE2HI0y
C/PHXNNU9ZrBziJ8Lm0tTNc98kUpjXnHZhsMcz5Mx2GR6dGknb C/PHXNNU9ZrBziJ8Lm0tTNc98kUpjXnHZhsMcz5Mx2GR6dGknb
I0iaGcRerMUsWOuBmKKKRmVMMdR9T3EZdpqsBd7jZCNMWotjhi I0iaGcRerMUsWOuBmKKKRmVMMdR9T3EZdpqsBd7jZCNMWotjhi
skipping to change at page 32, line 49 skipping to change at page 33, line 5
S: + YGgGCSqGSIb3EgECAgIAb1kwV6ADAgEFoQMCAQ+iSzBJoAMC S: + YGgGCSqGSIb3EgECAgIAb1kwV6ADAgEFoQMCAQ+iSzBJoAMC
AQGiQgRAtHTEuOP2BXb9sBYFR4SJlDZxmg39IxmRBOhXRKdDA0 AQGiQgRAtHTEuOP2BXb9sBYFR4SJlDZxmg39IxmRBOhXRKdDA0
uHTCOT9Bq3OsUTXUlk0CsFLoa8j+gvGDlgHuqzWHPSQg== uHTCOT9Bq3OsUTXUlk0CsFLoa8j+gvGDlgHuqzWHPSQg==
C: C:
S: + YDMGCSqGSIb3EgECAgIBAAD/////6jcyG4GE3KkTzBeBiVHe S: + YDMGCSqGSIb3EgECAgIBAAD/////6jcyG4GE3KkTzBeBiVHe
ceP2CWY0SR0fAQAgAAQEBAQ= ceP2CWY0SR0fAQAgAAQEBAQ=
C: YDMGCSqGSIb3EgECAgIBAAD/////3LQBHXTpFfZgrejpLlLImP C: YDMGCSqGSIb3EgECAgIBAAD/////3LQBHXTpFfZgrejpLlLImP
wkhbfa2QteAQAgAG1yYwE= wkhbfa2QteAQAgAG1yYwE=
S: A001 OK GSSAPI authentication successful S: A001 OK GSSAPI authentication successful
The following example demonstrates use of initial response
Example:
S: * OK [CAPABILITY IMAP4rev2 STARTTLS AUTH=GSSAPI
LOGINDISABLED] Server ready
C: A01 STARTTLS
S: A01 OK STARTLS completed
<TLS negotiation, further commands are under [TLS] layer>
C: A02 CAPABILITY
S: * CAPABILITY IMAP4rev2 AUTH=GSSAPI AUTH=PLAIN
S: A02 OK CAPABILITY completed
C: A01 AUTHENTICATE PLAIN dGVzdAB0ZXN0AHRlc3Q=
S: A001 OK Success (tls protection)
Note: The line breaks within server challenges and client responses Note: The line breaks within server challenges and client responses
are for editorial clarity and are not in real authenticators. are for editorial clarity and are not in real authenticators.
6.2.3. LOGIN Command 6.2.3. LOGIN Command
Arguments: user name Arguments: user name
password password
Responses: no specific responses for this command Responses: no specific responses for this command
skipping to change at page 46, line 22 skipping to change at page 46, line 22
name name
BAD - command unknown or arguments invalid BAD - command unknown or arguments invalid
The LIST command returns a subset of mailbox names from the complete The LIST command returns a subset of mailbox names from the complete
set of all mailbox names available to the client. Zero or more set of all mailbox names available to the client. Zero or more
untagged LIST responses are returned, containing the name attributes, untagged LIST responses are returned, containing the name attributes,
hierarchy delimiter, name, and possible extension information; see hierarchy delimiter, name, and possible extension information; see
the description of the LIST response (Section 7.3.1) for more detail. the description of the LIST response (Section 7.3.1) for more detail.
The LIST command SHOULD return its data quickly, without undue delay. The LIST command SHOULD return its data quickly, without undue delay.
For example, it SHOULD NOT go to excess trouble to calculate the For example, it should not go to excess trouble to calculate the
\Marked or \Unmarked status or perform other processing; if each name \Marked or \Unmarked status or perform other processing; if each name
requires 1 second of processing, then a list of 1200 names would take requires 1 second of processing, then a list of 1200 names would take
20 minutes! 20 minutes!
The extended LIST command, originally introduced in [RFC5258], The extended LIST command, originally introduced in [RFC5258],
provides capabilities beyond that of the original IMAP LIST command. provides capabilities beyond that of the original IMAP LIST command.
The extended syntax is being used if one or more of the following The extended syntax is being used if one or more of the following
conditions is true: conditions is true:
1. if the first word after the command name begins with a 1. if the first word after the command name begins with a
skipping to change at page 52, line 45 skipping to change at page 52, line 45
B. The mailbox name doesn't satisfy the selection criteria, but B. The mailbox name doesn't satisfy the selection criteria, but
it has at least one descendant mailbox name that satisfies it has at least one descendant mailbox name that satisfies
the selection criteria and that doesn't match the canonical the selection criteria and that doesn't match the canonical
LIST pattern. LIST pattern.
For more information on this case, see the CHILDINFO extended For more information on this case, see the CHILDINFO extended
data item described in Section 6.3.9.6. Note that the data item described in Section 6.3.9.6. Note that the
CHILDINFO extended data item can only be returned when the CHILDINFO extended data item can only be returned when the
RECURSIVEMATCH selection option is specified. RECURSIVEMATCH selection option is specified.
3. Attributes returned in the same LIST response must be treated 3. Attributes returned in the same LIST response are treated
additively. For example, the following response additively. For example, the following response
S: * LIST (\Subscribed \NonExistent) "/" "Fruit/Peach" S: * LIST (\Subscribed \NonExistent) "/" "Fruit/Peach"
means that the "Fruit/Peach" mailbox doesn't exist, but it is means that the "Fruit/Peach" mailbox doesn't exist, but it is
subscribed. subscribed.
6.3.9.4. Additional LIST-related Requirements on Clients 6.3.9.4. Additional LIST-related Requirements on Clients
All clients MUST treat a LIST attribute with a stronger meaning as All clients MUST treat a LIST attribute with a stronger meaning as
skipping to change at page 107, line 4 skipping to change at page 107, line 4
There is no need for a server that included the special flag \* There is no need for a server that included the special flag \*
to return a new PERMANENTFLAGS response code when a new keyword to return a new PERMANENTFLAGS response code when a new keyword
was successfully set on a message upon client request. However was successfully set on a message upon client request. However
if the server has a limit on the number of different keywords if the server has a limit on the number of different keywords
that can be stored in a mailbox and that limit is reached, the that can be stored in a mailbox and that limit is reached, the
server MUST send a new PERMANENTFLAGS response code without the server MUST send a new PERMANENTFLAGS response code without the
special flag \*. special flag \*.
PRIVACYREQUIRED PRIVACYREQUIRED
The operation is not permitted due to a lack of privacy. If The operation is not permitted due to a lack of data
Transport Layer Security (TLS) is not in use, the client could confidentiality. If Transport Layer Security (TLS) is not in
try STARTTLS (see Section 6.2.1) or alternatively reconnect to use, the client could try STARTTLS (see Section 6.2.1) or
Implicit TLS port, and then repeat the operation. alternatively reconnect on Implicit TLS port, and then repeat
the operation.
C: d login "fred" "foo" C: d login "fred" "foo"
S: d NO [PRIVACYREQUIRED] Connection offers no privacy S: d NO [PRIVACYREQUIRED] Connection offers no privacy
C: d select inbox C: d select inbox
S: d NO [PRIVACYREQUIRED] Connection offers no privacy S: d NO [PRIVACYREQUIRED] Connection offers no privacy
READ-ONLY READ-ONLY
The mailbox is selected read-only, or its access while selected The mailbox is selected read-only, or its access while selected
skipping to change at page 126, line 16 skipping to change at page 126, line 16
S: + Ready for additional command text S: + Ready for additional command text
C: FRED FOOBAR {7} C: FRED FOOBAR {7}
S: + Ready for additional command text S: + Ready for additional command text
C: fat man C: fat man
S: A001 OK LOGIN completed S: A001 OK LOGIN completed
C: A044 BLURDYBLOOP {102856} C: A044 BLURDYBLOOP {102856}
S: A044 BAD No such command as "BLURDYBLOOP" S: A044 BAD No such command as "BLURDYBLOOP"
8. Sample IMAP4rev2 connection 8. Sample IMAP4rev2 connection
The following is a transcript of an IMAP4rev2 connection. A long The following is a transcript of an IMAP4rev2 connection on a non TLS
line in this sample is broken for editorial clarity. port. A long line in this sample is broken for editorial clarity.
S: * OK IMAP4rev2 Service Ready S: * OK [CAPABILITY STARTTLS AUTH=SCRAM-SHA-256 LOGINDISABLED
C: a001 login mrc secret IMAP4rev2] IMAP4rev2 Service Ready
S: a001 OK LOGIN completed C: a000 starttls
S: a000 OK Proceed with TLS negotiation
<TLS negotiation>
C: A001 AUTHENTICATE SCRAM-SHA-256
biwsbj11c2VyLHI9ck9wck5HZndFYmVSV2diTkVrcU8=
S: + cj1yT3ByTkdmd0ViZVJXZ2JORWtxTyVodllEcFdVYTJSYVRDQWZ1eEZJbGopaE5s
RiRrMCxzPVcyMlphSjBTTlk3c29Fc1VFamI2Z1E9PSxpPTQwOTYNCg==
C: Yz1iaXdzLHI9ck9wck5HZndFYmVSV2diTkVrcU8laHZZRHBXVWEyUmFUQ0FmdXhG
SWxqKWhObEYkazAscD1kSHpiWmFwV0lrNGpVaE4rVXRlOXl0YWc5empmTUhnc3Ft
bWl6N0FuZFZRPQ==
S: + dj02cnJpVFJCaTIzV3BSUi93dHVwK21NaFVaVW4vZEI1bkxUSlJzamw5NUc0PQ==
C:
S: A001 OK SCRAM-SHA-256 authentication successful
C: babc ENABLE IMAP4rev2
S: * ENABLED IMAP4rev2
S: babc OK Some capabilities enabled
C: a002 select inbox C: a002 select inbox
S: * 18 EXISTS S: * 18 EXISTS
S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft) S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
S: * OK [UIDVALIDITY 3857529045] UIDs valid S: * OK [UIDVALIDITY 3857529045] UIDs valid
S: * LIST () "/" INBOX ("OLDNAME" ("inbox")) S: * LIST () "/" INBOX ("OLDNAME" ("inbox"))
S: a002 OK [READ-WRITE] SELECT completed S: a002 OK [READ-WRITE] SELECT completed
C: a003 fetch 12 full C: a003 fetch 12 full
S: * 12 FETCH (FLAGS (\Seen) INTERNALDATE "17-Jul-1996 02:44:25 -0700" 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)" RFC822.SIZE 4286 ENVELOPE ("Wed, 17 Jul 1996 02:23:25 -0700 (PDT)"
"IMAP4rev2 WG mtg summary and minutes" "IMAP4rev2 WG mtg summary and minutes"
skipping to change at page 146, line 8 skipping to change at page 145, line 34
10. Author's Note 10. Author's Note
This document is a revision or rewrite of earlier documents, and This document is a revision or rewrite of earlier documents, and
supercedes the protocol specification in those documents: RFC 3501, supercedes the protocol specification in those documents: RFC 3501,
RFC 2060, RFC 1730, unpublished IMAP2bis.TXT document, RFC 1176, and RFC 2060, RFC 1730, unpublished IMAP2bis.TXT document, RFC 1176, and
RFC 1064. RFC 1064.
11. Security Considerations 11. Security Considerations
IMAP4rev2 protocol transactions, including electronic mail data, are IMAP4rev2 protocol transactions, including electronic mail data, are
sent in the clear over the network unless protection from snooping is sent in the clear over the network exposing them to possible
negotiated. This can be accomplished either by the use of Implicit eavesdropping and manipulation unless protection is negotiated. This
TLS port, STARTTLS command, negotiated privacy protection in the can be accomplished either by the use of Implicit TLS port, STARTTLS
AUTHENTICATE command, or some other protection mechanism. command, negotiated privacy protection in the AUTHENTICATE command,
or some other protection mechanism.
11.1. TLS related Security Considerations 11.1. TLS related Security Considerations
This section applies to both use of STARTTLS command and Implicit TLS This section applies to both use of STARTTLS command and Implicit TLS
port. port.
IMAP client and server implementations MUST comply with relevant TLS IMAP client and server implementations MUST comply with relevant TLS
recommendations from [RFC8314]. recommendations from [RFC8314].
Clients and servers MUST implement TLS 1.2 [TLS-1.2] or newer. Use Clients and servers MUST implement TLS 1.2 [TLS-1.2] or newer. Use
of TLS 1.3 [TLS-1.3] is RECOMMENDED. TLS 1.2 may be used only in of TLS 1.3 [TLS-1.3] is RECOMMENDED. TLS 1.2 may be used only in
cases where the other party has not yet implemented TLS 1.3. cases where the other party has not yet implemented TLS 1.3.
Additionally, when using TLS 1.2, IMAP implementations MUST implement Additionally, when using TLS 1.2, IMAP implementations MUST implement
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 cipher suite. This is TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 cipher suite. This is
important as it assures that any two compliant implementations can be important as it assures that any two compliant implementations can be
configured to interoperate. Other TLS cipher suites recommended in configured to interoperate. Other TLS cipher suites recommended in
RFC 7525 are RECOMMENDED: TLS_DHE_RSA_WITH_AES_128_GCM_SHA256, RFC 7525 [RFC7525] are RECOMMENDED:
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256,
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 and TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 and
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384. All other cipher suites are TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384. All other cipher suites are
OPTIONAL. Note that this is a change from section 2.1 of [IMAP-TLS]. OPTIONAL. Note that this is a change from section 2.1 of [IMAP-TLS].
The list of mandatory-to-implement TLS 1.3 cipher suites is described The list of mandatory-to-implement TLS 1.3 cipher suites is described
in Section 9.1 of [TLS-1.3]. in Section 9.1 of [TLS-1.3].
During the TLS negotiation [TLS-1.3][TLS-1.2], the client MUST check During the TLS negotiation [TLS-1.3][TLS-1.2], the client MUST check
its understanding of the server hostname against the server's its understanding of the server hostname against the server's
identity as presented in the server Certificate message, in order to identity as presented in the server Certificate message, in order to
prevent man-in-the-middle attacks. This procedure is described in prevent on-path attackers attempting to masquerade as the server.
[RFC7817]. This procedure is described in [RFC7817].
Both the client and server MUST check the result of the STARTTLS Both the client and server MUST check the result of the STARTTLS
command and subsequent TLS ([TLS-1.3][TLS-1.2]) negotiation to see command and subsequent TLS ([TLS-1.3][TLS-1.2]) negotiation to see
whether acceptable authentication and/or privacy was achieved. whether acceptable authentication and/or privacy was achieved.
11.2. STARTTLS command versa use of Implicit TLS port 11.2. STARTTLS command versa use of Implicit TLS port
For maximum backward compatibility clients MUST implement both TLS For maximum backward compatibility clients MUST implement both TLS
negotiation on implicit TLS port and TLS negotiation using STARTTLS negotiation on implicit TLS port and TLS negotiation using STARTTLS
command. command.
Servers MUST implement TLS negotiation on implicit TLS port and Servers MUST implement TLS negotiation on implicit TLS port and
SHOULD implement STARTTLS command on cleartext port. SHOULD implement STARTTLS command on cleartext port.
Some site/firewall maintainers insist on TLS site-wide and prefer not Some site/firewall maintainers insist on TLS site-wide and prefer not
to rely on a configuration option in each higher-level protocol. For to rely on a configuration option in each higher-level protocol. For
this reason, IMAP4rev2 clients SHOULD try both ports 993 and 143 (and this reason, IMAP4rev2 clients SHOULD try both ports 993 and 143 (and
both IPv4 and IPv6) concurrently by default, unless overriden by both IPv4 and IPv6) concurrently by default, unless overridden by
either user configuration or DNS SRV records [RFC6186]. Note that if either user configuration or DNS SRV records [RFC6186]. Note that if
a server answers on both ports, it MUST allow STARTTLS command on a server answers on both ports, it MUST allow STARTTLS command on
port 143. port 143.
11.3. Client handling of unsolicited responses not suitable for the 11.3. Client handling of unsolicited responses not suitable for the
current connection state current connection state
Cleartext mail transmission (whether caused by firewall configuration Cleartext mail transmission (whether caused by firewall configuration
errors that result in TLS stripping or weak security policies in errors that result in TLS stripping or weak security policies in
email clients that choose not to negotiate TLS in the first place) email clients that choose not to negotiate TLS in the first place)
can enable injection of responses that can confuse or even cause can enable injection of responses that can confuse or even cause
crashes in email clients. The following measures are recommended to crashes in email clients. The following measures are recommended to
minimize damage from them. minimize damage from them.
See Section 7.1.4 for special security considerations related to See Section 7.1.4 for special security considerations related to
PREAUTH response. PREAUTH response.
Many server responses and response codes are only meaningful in Many server responses and response codes are only meaningful in
authenticated or even selected state. However, nothing prevents a authenticated or even selected state. However, nothing prevents a
server (or a man-in-the-middle attacker) from sending such invalid server (or an on-path attacker) from sending such invalid
responses in cleartext before STARTTLS/AUTHENTICATE commands are responses in cleartext before STARTTLS/AUTHENTICATE commands are
issued. Before authentication clients SHOULD ignore any responses issued. Before authentication clients SHOULD ignore any responses
other than CAPABILITY and server status responses (Section 7.1), other than CAPABILITY and server status responses (Section 7.1),
as well as any response codes other than CAPABILITY. Client as well as any response codes other than CAPABILITY. Client
SHOULD ignore the ALERT response code until after TLS has been SHOULD ignore the ALERT response code until after TLS has been
successfully negotiated (whether using STARTTLS or TLS negotiation successfully negotiated (whether using STARTTLS or TLS negotiation
on implicit TLS port). Unless explicitly allowed by an IMAP on implicit TLS port). Unless explicitly allowed by an IMAP
extension, when not in selected state clients MUST ignore extension, when not in selected state clients MUST ignore
responses/response codes related to message and mailbox status responses/response codes related to message and mailbox status
such as FLAGS, EXIST, EXPUNGE and FETCH. such as FLAGS, EXIST, EXPUNGE and FETCH.
skipping to change at page 150, line 51 skipping to change at page 150, line 33
Protocol version 4 - LIST Command Extensions", RFC 5258, Protocol version 4 - LIST Command Extensions", RFC 5258,
DOI 10.17487/RFC5258, June 2008, DOI 10.17487/RFC5258, June 2008,
<https://www.rfc-editor.org/info/rfc5258>. <https://www.rfc-editor.org/info/rfc5258>.
[RFC5788] Melnikov, A. and D. Cridland, "IMAP4 Keyword Registry", [RFC5788] Melnikov, A. and D. Cridland, "IMAP4 Keyword Registry",
RFC 5788, DOI 10.17487/RFC5788, March 2010, RFC 5788, DOI 10.17487/RFC5788, March 2010,
<https://www.rfc-editor.org/info/rfc5788>. <https://www.rfc-editor.org/info/rfc5788>.
[ABNF] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax [ABNF] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008, Specifications: ABNF", STD 68, RFC 5234, January 2008,
<http://www.rfc-editor.org/info/rfc5234>. <https://www.rfc-editor.org/info/rfc5234>.
[ANONYMOUS] [ANONYMOUS]
Zeilenga, K., "Anonymous Simple Authentication and Zeilenga, K., "Anonymous Simple Authentication and
Security Layer (SASL) Mechanism", RFC 4505, June 2006, Security Layer (SASL) Mechanism", RFC 4505, June 2006,
<http://www.rfc-editor.org/info/rfc4505>. <https://www.rfc-editor.org/info/rfc4505>.
[CHARSET] Freed, N. and J. Postel, "IANA Charset Registration [CHARSET] Freed, N. and J. Postel, "IANA Charset Registration
Procedures", BCP 19, RFC 2978, October 2000, Procedures", BCP 19, RFC 2978, October 2000,
<http://www.rfc-editor.org/info/rfc2978>. <https://www.rfc-editor.org/info/rfc2978>.
[SCRAM-SHA-256] [SCRAM-SHA-256]
Hansen, T., "SCRAM-SHA-256 and SCRAM-SHA-256-PLUS Simple Hansen, T., "SCRAM-SHA-256 and SCRAM-SHA-256-PLUS Simple
Authentication and Security Layer (SASL) Mechanisms", Authentication and Security Layer (SASL) Mechanisms",
RFC 7677, DOI 10.17487/RFC7677, November 2015, RFC 7677, DOI 10.17487/RFC7677, November 2015,
<https://www.rfc-editor.org/info/rfc7677>. <https://www.rfc-editor.org/info/rfc7677>.
[DISPOSITION] [DISPOSITION]
Troost, R., Dorner, S., and K. Moore, Ed., "Communicating Troost, R., Dorner, S., and K. Moore, Ed., "Communicating
Presentation Information in Internet Messages: The Presentation Information in Internet Messages: The
Content-Disposition Header Field", RFC 2183, August 1997, Content-Disposition Header Field", RFC 2183, August 1997,
<http://www.rfc-editor.org/info/rfc2183>. <https://www.rfc-editor.org/info/rfc2183>.
[PLAIN] Zeilenga, K., Ed., "The PLAIN Simple Authentication and [PLAIN] Zeilenga, K., Ed., "The PLAIN Simple Authentication and
Security Layer (SASL) Mechanism", RFC 4616, August 2006, Security Layer (SASL) Mechanism", RFC 4616, August 2006,
<http://www.rfc-editor.org/info/rfc4616>. <https://www.rfc-editor.org/info/rfc4616>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[LANGUAGE-TAGS] [LANGUAGE-TAGS]
Alvestrand, H., "Content Language Headers", RFC 3282, May Alvestrand, H., "Content Language Headers", RFC 3282, May
2002, <http://www.rfc-editor.org/info/rfc3282>. 2002, <https://www.rfc-editor.org/info/rfc3282>.
[LOCATION] [LOCATION]
Palme, J., Hopmann, A., and N. Shelness, "MIME Palme, J., Hopmann, A., and N. Shelness, "MIME
Encapsulation of Aggregate Documents, such as HTML Encapsulation of Aggregate Documents, such as HTML
(MHTML)", RFC 2557, March 1999, (MHTML)", RFC 2557, March 1999,
<http://www.rfc-editor.org/info/rfc2557>. <https://www.rfc-editor.org/info/rfc2557>.
[MD5] Myers, J. and M. Rose, "The Content-MD5 Header Field", [MD5] Myers, J. and M. Rose, "The Content-MD5 Header Field",
RFC 1864, October 1995, RFC 1864, October 1995,
<http://www.rfc-editor.org/info/rfc1864>. <https://www.rfc-editor.org/info/rfc1864>.
[MIME-HDRS] [MIME-HDRS]
Moore, K., "MIME (Multipurpose Internet Mail Extensions) Moore, K., "MIME (Multipurpose Internet Mail Extensions)
Part Three: Message Header Extensions for Non-ASCII Text", Part Three: Message Header Extensions for Non-ASCII Text",
RFC 2047, November 1996, RFC 2047, November 1996,
<http://www.rfc-editor.org/info/rfc2047>. <https://www.rfc-editor.org/info/rfc2047>.
[MIME-IMB] [MIME-IMB]
Freed, N. and N. Borenstein, "Multipurpose Internet Mail Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message Extensions (MIME) Part One: Format of Internet Message
Bodies", RFC 2045, November 1996, Bodies", RFC 2045, November 1996,
<http://www.rfc-editor.org/info/rfc2045>. <https://www.rfc-editor.org/info/rfc2045>.
[MIME-IMT] [MIME-IMT]
Freed, N. and N. Borenstein, "Multipurpose Internet Mail Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part Two: Media Types", RFC 2046, Extensions (MIME) Part Two: Media Types", RFC 2046,
November 1996, <http://www.rfc-editor.org/info/rfc2046>. November 1996, <https://www.rfc-editor.org/info/rfc2046>.
[RFC2231] Freed, N. and K. Moore, "MIME Parameter Value and Encoded [RFC2231] Freed, N. and K. Moore, "MIME Parameter Value and Encoded
Word Extensions: Character Sets, Languages, and Word Extensions: Character Sets, Languages, and
Continuations", RFC 2231, DOI 10.17487/RFC2231, November Continuations", RFC 2231, DOI 10.17487/RFC2231, November
1997, <https://www.rfc-editor.org/info/rfc2231>. 1997, <https://www.rfc-editor.org/info/rfc2231>.
[RFC-5322] [RFC-5322]
Resnick, P., Ed., "Internet Message Format", RFC 5322, Resnick, P., Ed., "Internet Message Format", RFC 5322,
October 2008, <http://www.rfc-editor.org/info/rfc5322>. October 2008, <https://www.rfc-editor.org/info/rfc5322>.
[SASL] Melnikov, A., Ed. and K. Zeilenga, Ed., "Simple [SASL] Melnikov, A., Ed. and K. Zeilenga, Ed., "Simple
Authentication and Security Layer (SASL)", RFC 4422, June Authentication and Security Layer (SASL)", RFC 4422, June
2006, <http://www.rfc-editor.org/info/rfc4422>. 2006, <https://www.rfc-editor.org/info/rfc4422>.
[TLS-1.2] Dierks, T. and E. Rescorla, "The Transport Layer Security [TLS-1.2] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008, (TLS) Protocol Version 1.2", RFC 5246, August 2008,
<http://www.rfc-editor.org/info/rfc5246>. <https://www.rfc-editor.org/info/rfc5246>.
[TLS-1.3] Rescorla, E., "The Transport Layer Security (TLS) Protocol [TLS-1.3] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>. <https://www.rfc-editor.org/info/rfc8446>.
[UTF-7] Goldsmith, D. and M. Davis, "UTF-7 A Mail-Safe [UTF-7] Goldsmith, D. and M. Davis, "UTF-7 A Mail-Safe
Transformation Format of Unicode", RFC 2152, May 1997, Transformation Format of Unicode", RFC 2152, May 1997,
<http://www.rfc-editor.org/info/rfc2152>. <https://www.rfc-editor.org/info/rfc2152>.
[UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO [UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November
2003, <http://www.rfc-editor.org/info/rfc3629>. 2003, <https://www.rfc-editor.org/info/rfc3629>.
[MULTIAPPEND] [MULTIAPPEND]
Crispin, M., "Internet Message Access Protocol (IMAP) - Crispin, M., "Internet Message Access Protocol (IMAP) -
MULTIAPPEND Extension", RFC 3502, March 2003, MULTIAPPEND Extension", RFC 3502, March 2003,
<http://www.rfc-editor.org/info/rfc3502>. <https://www.rfc-editor.org/info/rfc3502>.
[NET-UNICODE] [NET-UNICODE]
Klensin, J. and M. Padlipsky, "Unicode Format for Network Klensin, J. and M. Padlipsky, "Unicode Format for Network
Interchange", RFC 5198, DOI 10.17487/RFC5198, March 2008, Interchange", RFC 5198, DOI 10.17487/RFC5198, March 2008,
<https://www.rfc-editor.org/info/rfc5198>. <https://www.rfc-editor.org/info/rfc5198>.
[I18N-HDRS] [I18N-HDRS]
Yang, A., Steele, S., and N. Freed, "Internationalized Yang, A., Steele, S., and N. Freed, "Internationalized
Email Headers", RFC 6532, DOI 10.17487/RFC6532, February Email Headers", RFC 6532, DOI 10.17487/RFC6532, February
2012, <https://www.rfc-editor.org/info/rfc6532>. 2012, <https://www.rfc-editor.org/info/rfc6532>.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
<https://www.rfc-editor.org/info/rfc4648>. <https://www.rfc-editor.org/info/rfc4648>.
[RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre,
"Recommendations for Secure Use of Transport Layer
Security (TLS) and Datagram Transport Layer Security
(DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May
2015, <https://www.rfc-editor.org/info/rfc7525>.
[RFC7817] Melnikov, A., "Updated Transport Layer Security (TLS) [RFC7817] Melnikov, A., "Updated Transport Layer Security (TLS)
Server Identity Check Procedure for Email-Related Server Identity Check Procedure for Email-Related
Protocols", RFC 7817, DOI 10.17487/RFC7817, March 2016, Protocols", RFC 7817, DOI 10.17487/RFC7817, March 2016,
<https://www.rfc-editor.org/info/rfc7817>. <https://www.rfc-editor.org/info/rfc7817>.
[RFC8098] Hansen, T., Ed. and A. Melnikov, Ed., "Message Disposition [RFC8098] Hansen, T., Ed. and A. Melnikov, Ed., "Message Disposition
Notification", STD 85, RFC 8098, DOI 10.17487/RFC8098, Notification", STD 85, RFC 8098, DOI 10.17487/RFC8098,
February 2017, <https://www.rfc-editor.org/info/rfc8098>. February 2017, <https://www.rfc-editor.org/info/rfc8098>.
[RFC8314] Moore, K. and C. Newman, "Cleartext Considered Obsolete: [RFC8314] Moore, K. and C. Newman, "Cleartext Considered Obsolete:
Use of Transport Layer Security (TLS) for Email Submission Use of Transport Layer Security (TLS) for Email Submission
and Access", RFC 8314, DOI 10.17487/RFC8314, January 2018, and Access", RFC 8314, DOI 10.17487/RFC8314, January 2018,
<https://www.rfc-editor.org/info/rfc8314>. <https://www.rfc-editor.org/info/rfc8314>.
[IMAP-IMPLEMENTATION] [IMAP-IMPLEMENTATION]
Leiba, B., "IMAP4 Implementation Recommendations", Leiba, B., "IMAP4 Implementation Recommendations",
RFC 2683, September 1999, RFC 2683, September 1999,
<http://www.rfc-editor.org/info/rfc2683>. <https://www.rfc-editor.org/info/rfc2683>.
[IMAP-MULTIACCESS] [IMAP-MULTIACCESS]
Gahrns, M., "IMAP4 Multi-Accessed Mailbox Practice", Gahrns, M., "IMAP4 Multi-Accessed Mailbox Practice",
RFC 2180, July 1997, RFC 2180, July 1997,
<http://www.rfc-editor.org/info/rfc2180>. <https://www.rfc-editor.org/info/rfc2180>.
13.2. Informative References (related protocols) 13.2. Informative References (related protocols)
[CERT-555316] [CERT-555316]
CERT, "Vulnerability Note VU#555316: STARTTLS plaintext CERT, "Vulnerability Note VU#555316: STARTTLS plaintext
command injection vulnerability", September 2011, command injection vulnerability", September 2011,
<https://www.kb.cert.org/vuls/id/555316>. <https://www.kb.cert.org/vuls/id/555316>.
[RFC2193] Gahrns, M., "IMAP4 Mailbox Referrals", RFC 2193, [RFC2193] Gahrns, M., "IMAP4 Mailbox Referrals", RFC 2193,
DOI 10.17487/RFC2193, September 1997, DOI 10.17487/RFC2193, September 1997,
skipping to change at page 154, line 45 skipping to change at page 154, line 36
DOI 10.17487/RFC6186, March 2011, DOI 10.17487/RFC6186, March 2011,
<https://www.rfc-editor.org/info/rfc6186>. <https://www.rfc-editor.org/info/rfc6186>.
[RFC7888] Melnikov, A., Ed., "IMAP4 Non-synchronizing Literals", [RFC7888] Melnikov, A., Ed., "IMAP4 Non-synchronizing Literals",
RFC 7888, DOI 10.17487/RFC7888, May 2016, RFC 7888, DOI 10.17487/RFC7888, May 2016,
<https://www.rfc-editor.org/info/rfc7888>. <https://www.rfc-editor.org/info/rfc7888>.
[IMAP-DISC] [IMAP-DISC]
Melnikov, A., Ed., "Synchronization Operations for Melnikov, A., Ed., "Synchronization Operations for
Disconnected IMAP4 Clients", RFC 4549, June 2006, Disconnected IMAP4 Clients", RFC 4549, June 2006,
<http://www.rfc-editor.org/info/rfc4549>. <https://www.rfc-editor.org/info/rfc4549>.
[IMAP-I18N] [IMAP-I18N]
Newman, C., Gulbrandsen, A., and A. Melnikov, "Internet Newman, C., Gulbrandsen, A., and A. Melnikov, "Internet
Message Access Protocol Internationalization", RFC 5255, Message Access Protocol Internationalization", RFC 5255,
DOI 10.17487/RFC5255, June 2008, DOI 10.17487/RFC5255, June 2008,
<http://www.rfc-editor.org/info/rfc5255>. <https://www.rfc-editor.org/info/rfc5255>.
[IMAP-MODEL] [IMAP-MODEL]
Crispin, M., "Distributed Electronic Mail Models in Crispin, M., "Distributed Electronic Mail Models in
IMAP4", RFC 1733, December 1994, IMAP4", RFC 1733, December 1994,
<http://www.rfc-editor.org/info/rfc1733>. <https://www.rfc-editor.org/info/rfc1733>.
[IMAP-UTF-8] [IMAP-UTF-8]
Resnick, P., Ed., Newman, C., Ed., and S. Shen, Ed., "IMAP Resnick, P., Ed., Newman, C., Ed., and S. Shen, Ed., "IMAP
Support for UTF-8", RFC 6855, DOI 10.17487/RFC6855, March Support for UTF-8", RFC 6855, DOI 10.17487/RFC6855, March
2013, <http://www.rfc-editor.org/info/rfc6855>. 2013, <https://www.rfc-editor.org/info/rfc6855>.
[SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, [SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
October 2008, <http://www.rfc-editor.org/info/rfc5321>. October 2008, <https://www.rfc-editor.org/info/rfc5321>.
[RFC3516] Nerenberg, L., "IMAP4 Binary Content Extension", RFC 3516, [RFC3516] Nerenberg, L., "IMAP4 Binary Content Extension", RFC 3516,
DOI 10.17487/RFC3516, April 2003, DOI 10.17487/RFC3516, April 2003,
<https://www.rfc-editor.org/info/rfc3516>. <https://www.rfc-editor.org/info/rfc3516>.
[RFC4314] Melnikov, A., "IMAP4 Access Control List (ACL) Extension", [RFC4314] Melnikov, A., "IMAP4 Access Control List (ACL) Extension",
RFC 4314, December 2005, RFC 4314, December 2005,
<http://www.rfc-editor.org/info/rfc4314>. <https://www.rfc-editor.org/info/rfc4314>.
[RFC2087] Myers, J., "IMAP4 QUOTA extension", RFC 2087, January [RFC2087] Myers, J., "IMAP4 QUOTA extension", RFC 2087, January
1997, <http://www.rfc-editor.org/info/rfc2087>. 1997, <https://www.rfc-editor.org/info/rfc2087>.
[IMAP-URL] [IMAP-URL]
Melnikov, A., Ed. and C. Newman, "IMAP URL Scheme", Melnikov, A., Ed. and C. Newman, "IMAP URL Scheme",
RFC 5092, DOI 10.17487/RFC5092, November 2007, RFC 5092, DOI 10.17487/RFC5092, November 2007,
<http://www.rfc-editor.org/info/rfc5092>. <https://www.rfc-editor.org/info/rfc5092>.
[IMAP-KEYWORDS-REG] [IMAP-KEYWORDS-REG]
IANA, "IMAP and JMAP Keywords", December 2009, IANA, "IMAP and JMAP Keywords", December 2009,
<https://www.iana.org/assignments/imap-jmap-keywords/imap- <https://www.iana.org/assignments/imap-jmap-keywords/imap-
jmap-keywords.xhtml>. jmap-keywords.xhtml>.
[IMAP-MAILBOX-NAME-ATTRS-REG] [IMAP-MAILBOX-NAME-ATTRS-REG]
IANA, "IMAP Mailbox Name Attributes", June 2018, IANA, "IMAP Mailbox Name Attributes", June 2018,
<https://www.iana.org/assignments/imap-mailbox-name- <https://www.iana.org/assignments/imap-mailbox-name-
attributes/imap-mailbox-name-attributes.xhtml>. attributes/imap-mailbox-name-attributes.xhtml>.
skipping to change at page 156, line 15 skipping to change at page 155, line 49
13.3. Informative References (historical aspects of IMAP and related 13.3. Informative References (historical aspects of IMAP and related
protocols) protocols)
[RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
4rev1", RFC 3501, DOI 10.17487/RFC3501, March 2003, 4rev1", RFC 3501, DOI 10.17487/RFC3501, March 2003,
<https://www.rfc-editor.org/info/rfc3501>. <https://www.rfc-editor.org/info/rfc3501>.
[IMAP-COMPAT] [IMAP-COMPAT]
Crispin, M., "IMAP4 Compatibility with IMAP2bis", Crispin, M., "IMAP4 Compatibility with IMAP2bis",
RFC 2061, December 1996, RFC 2061, December 1996,
<http://www.rfc-editor.org/info/rfc2061>. <https://www.rfc-editor.org/info/rfc2061>.
[IMAP-HISTORICAL] [IMAP-HISTORICAL]
Crispin, M., "IMAP4 Compatibility with IMAP2 and Crispin, M., "IMAP4 Compatibility with IMAP2 and
IMAP2bis", RFC 1732, December 1994, IMAP2bis", RFC 1732, December 1994,
<http://www.rfc-editor.org/info/rfc1732>. <https://www.rfc-editor.org/info/rfc1732>.
[IMAP2BIS]
Crispin, M., "INTERACTIVE MAIL ACCESS PROTOCOL - VERSION
2bis", draft-ietf-imap-imap2bis-02 (work in progress),
October 1993, <https://www.ietf.org/archive/id/draft-ietf-
imap-imap2bis-02.txt>.
[IMAP-OBSOLETE] [IMAP-OBSOLETE]
Crispin, M., "Internet Message Access Protocol - Obsolete Crispin, M., "Internet Message Access Protocol - Obsolete
Syntax", RFC 2062, December 1996, Syntax", RFC 2062, December 1996,
<http://www.rfc-editor.org/info/rfc2062>. <https://www.rfc-editor.org/info/rfc2062>.
[IMAP2] Crispin, M., "Interactive Mail Access Protocol: Version [IMAP2] Crispin, M., "Interactive Mail Access Protocol: Version
2", RFC 1176, August 1990, 2", RFC 1176, August 1990,
<http://www.rfc-editor.org/info/rfc1176>. <https://www.rfc-editor.org/info/rfc1176>.
[RFC-822] Crocker, D., "STANDARD FOR THE FORMAT OF ARPA INTERNET [RFC-822] Crocker, D., "STANDARD FOR THE FORMAT OF ARPA INTERNET
TEXT MESSAGES", STD 11, RFC 822, August 1982, TEXT MESSAGES", STD 11, RFC 822, August 1982,
<http://www.rfc-editor.org/info/rfc822>. <https://www.rfc-editor.org/info/rfc822>.
[IMAP-TLS] [IMAP-TLS]
Newman, C., "Using TLS with IMAP, POP3 and ACAP", Newman, C., "Using TLS with IMAP, POP3 and ACAP",
RFC 2595, June 1999, RFC 2595, June 1999,
<http://www.rfc-editor.org/info/rfc2595>. <https://www.rfc-editor.org/info/rfc2595>.
Appendix A. Backward compatibility with IMAP4rev1 Appendix A. Backward compatibility with IMAP4rev1
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.
skipping to change at page 162, line 23 skipping to change at page 162, line 16
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 Murray Kucherawy, Timo Sirainen, Bron Gondwana, Stephan Thank you to Murray Kucherawy, Timo Sirainen, Bron Gondwana, Stephan
Bosch, Robert Sparks, Arnt Gulbrandsen and Daniel Migault for Bosch, Robert Sparks, Arnt Gulbrandsen, Daniel Migault, Roman Danyliw
extensive feedback. and Eric Vyncke for extensive feedback.
This document incorporates text from RFC 4315 (by Mark Crispin), RFC This document incorporates text from RFC 4315 (by Mark Crispin), RFC
4466 (by Cyrus Daboo), RFC 4731 (by Dave Cridland), RFC 5161 (by Arnt 4466 (by Cyrus Daboo), RFC 4731 (by Dave Cridland), RFC 5161 (by Arnt
Gulbrandsen), RFC 5465 (by Arnt Gulbrandsen and Curtis King), RFC Gulbrandsen), RFC 5465 (by Arnt Gulbrandsen and Curtis King), RFC
5530 (by Arnt Gulbrandsen), RFC 5819 (by Timo Sirainen), RFC 6154 (by 5530 (by Arnt Gulbrandsen), RFC 5819 (by Timo Sirainen), RFC 6154 (by
Jamie Nicolson), RFC 8438 (by Stephan Bosch) so work done by authors/ Jamie Nicolson), RFC 8438 (by Stephan Bosch) so work done by authors/
editors of these documents is appreciated. Note that editors of this editors of these documents is appreciated. Note that editors of this
document were redacted from the above list. document were redacted from the above list.
The CHILDREN return option was originally proposed by Mike Gahrns and The CHILDREN return option was originally proposed by Mike Gahrns and
 End of changes. 65 change blocks. 
93 lines changed or deleted 140 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/