< draft-ietf-extra-imap4rev2-05.txt   draft-ietf-extra-imap4rev2-06.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 Huawei Technologies Intended status: Standards Track Huawei Technologies
Expires: January 10, 2020 July 9, 2019 Expires: April 29, 2020 October 27, 2019
INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev2 INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev2
draft-ietf-extra-imap4rev2-05 draft-ietf-extra-imap4rev2-06
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 47 skipping to change at page 1, line 47
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 January 10, 2020. This Internet-Draft will expire on April 29, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 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 15 skipping to change at page 3, line 15
3.3. Selected State . . . . . . . . . . . . . . . . . . . . . 14 3.3. Selected State . . . . . . . . . . . . . . . . . . . . . 14
3.4. Logout State . . . . . . . . . . . . . . . . . . . . . . 14 3.4. Logout State . . . . . . . . . . . . . . . . . . . . . . 14
4. Data Formats . . . . . . . . . . . . . . . . . . . . . . . . 16 4. Data Formats . . . . . . . . . . . . . . . . . . . . . . . . 16
4.1. Atom . . . . . . . . . . . . . . . . . . . . . . . . . . 16 4.1. Atom . . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.1.1. Sequence set and UID set . . . . . . . . . . . . . . 16 4.1.1. Sequence set and UID set . . . . . . . . . . . . . . 16
4.2. Number . . . . . . . . . . . . . . . . . . . . . . . . . 16 4.2. Number . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.3. String . . . . . . . . . . . . . . . . . . . . . . . . . 16 4.3. String . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.3.1. 8-bit and Binary Strings . . . . . . . . . . . . . . 17 4.3.1. 8-bit and Binary Strings . . . . . . . . . . . . . . 17
4.4. Parenthesized List . . . . . . . . . . . . . . . . . . . 18 4.4. Parenthesized List . . . . . . . . . . . . . . . . . . . 18
4.5. NIL . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 4.5. NIL . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
5. Operational Considerations . . . . . . . . . . . . . . . . . 18 5. Operational Considerations . . . . . . . . . . . . . . . . . 19
5.1. Mailbox Naming . . . . . . . . . . . . . . . . . . . . . 18 5.1. Mailbox Naming . . . . . . . . . . . . . . . . . . . . . 19
5.1.1. Mailbox Hierarchy Naming . . . . . . . . . . . . . . 19 5.1.1. Mailbox Hierarchy Naming . . . . . . . . . . . . . . 20
5.1.2. Namespaces . . . . . . . . . . . . . . . . . . . . . 20 5.1.2. Namespaces . . . . . . . . . . . . . . . . . . . . . 20
5.2. Mailbox Size and Message Status Updates . . . . . . . . . 21 5.2. Mailbox Size and Message Status Updates . . . . . . . . . 21
5.3. Response when no Command in Progress . . . . . . . . . . 21 5.3. Response when no Command in Progress . . . . . . . . . . 22
5.4. Autologout Timer . . . . . . . . . . . . . . . . . . . . 22 5.4. Autologout Timer . . . . . . . . . . . . . . . . . . . . 22
5.5. Multiple Commands in Progress (Command Pipelining) . . . 22 5.5. Multiple Commands in Progress (Command Pipelining) . . . 22
6. Client Commands . . . . . . . . . . . . . . . . . . . . . . . 23 6. Client Commands . . . . . . . . . . . . . . . . . . . . . . . 23
6.1. Client Commands - Any State . . . . . . . . . . . . . . . 24 6.1. Client Commands - Any State . . . . . . . . . . . . . . . 24
6.1.1. CAPABILITY Command . . . . . . . . . . . . . . . . . 24 6.1.1. CAPABILITY Command . . . . . . . . . . . . . . . . . 24
6.1.2. NOOP Command . . . . . . . . . . . . . . . . . . . . 25 6.1.2. NOOP Command . . . . . . . . . . . . . . . . . . . . 25
6.1.3. LOGOUT Command . . . . . . . . . . . . . . . . . . . 25 6.1.3. LOGOUT Command . . . . . . . . . . . . . . . . . . . 26
6.2. Client Commands - Not Authenticated State . . . . . . . . 26 6.2. Client Commands - Not Authenticated State . . . . . . . . 26
6.2.1. STARTTLS Command . . . . . . . . . . . . . . . . . . 26 6.2.1. STARTTLS Command . . . . . . . . . . . . . . . . . . 27
6.2.2. AUTHENTICATE Command . . . . . . . . . . . . . . . . 27 6.2.2. AUTHENTICATE Command . . . . . . . . . . . . . . . . 28
6.2.3. LOGIN Command . . . . . . . . . . . . . . . . . . . . 30 6.2.3. LOGIN Command . . . . . . . . . . . . . . . . . . . . 31
6.3. Client Commands - Authenticated State . . . . . . . . . . 31 6.3. Client Commands - Authenticated State . . . . . . . . . . 31
6.3.1. ENABLE Command . . . . . . . . . . . . . . . . . . . 31 6.3.1. ENABLE Command . . . . . . . . . . . . . . . . . . . 32
6.3.2. SELECT Command . . . . . . . . . . . . . . . . . . . 33 6.3.2. SELECT Command . . . . . . . . . . . . . . . . . . . 34
6.3.3. EXAMINE Command . . . . . . . . . . . . . . . . . . . 35 6.3.3. EXAMINE Command . . . . . . . . . . . . . . . . . . . 35
6.3.4. CREATE Command . . . . . . . . . . . . . . . . . . . 35 6.3.4. CREATE Command . . . . . . . . . . . . . . . . . . . 36
6.3.5. DELETE Command . . . . . . . . . . . . . . . . . . . 36 6.3.5. DELETE Command . . . . . . . . . . . . . . . . . . . 37
6.3.6. RENAME Command . . . . . . . . . . . . . . . . . . . 38 6.3.6. RENAME Command . . . . . . . . . . . . . . . . . . . 38
6.3.7. SUBSCRIBE Command . . . . . . . . . . . . . . . . . . 40 6.3.7. SUBSCRIBE Command . . . . . . . . . . . . . . . . . . 40
6.3.8. UNSUBSCRIBE Command . . . . . . . . . . . . . . . . . 41 6.3.8. UNSUBSCRIBE Command . . . . . . . . . . . . . . . . . 41
6.3.9. LIST Command . . . . . . . . . . . . . . . . . . . . 41 6.3.9. LIST Command . . . . . . . . . . . . . . . . . . . . 41
6.3.10. LSUB Command . . . . . . . . . . . . . . . . . . . . 58 6.3.10. LSUB Command . . . . . . . . . . . . . . . . . . . . 58
6.3.11. NAMESPACE Command . . . . . . . . . . . . . . . . . . 59 6.3.11. NAMESPACE Command . . . . . . . . . . . . . . . . . . 59
6.3.12. STATUS Command . . . . . . . . . . . . . . . . . . . 63 6.3.12. STATUS Command . . . . . . . . . . . . . . . . . . . 63
6.3.13. APPEND Command . . . . . . . . . . . . . . . . . . . 65 6.3.13. APPEND Command . . . . . . . . . . . . . . . . . . . 65
6.3.14. IDLE Command . . . . . . . . . . . . . . . . . . . . 67 6.3.14. IDLE Command . . . . . . . . . . . . . . . . . . . . 67
6.4. Client Commands - Selected State . . . . . . . . . . . . 69 6.4. Client Commands - Selected State . . . . . . . . . . . . 69
6.4.1. CHECK Command . . . . . . . . . . . . . . . . . . . . 70 6.4.1. CLOSE Command . . . . . . . . . . . . . . . . . . . . 69
6.4.2. CLOSE Command . . . . . . . . . . . . . . . . . . . . 70 6.4.2. UNSELECT Command . . . . . . . . . . . . . . . . . . 70
6.4.3. UNSELECT Command . . . . . . . . . . . . . . . . . . 71 6.4.3. EXPUNGE Command . . . . . . . . . . . . . . . . . . . 70
6.4.4. EXPUNGE Command . . . . . . . . . . . . . . . . . . . 71 6.4.4. SEARCH Command . . . . . . . . . . . . . . . . . . . 71
6.4.5. SEARCH Command . . . . . . . . . . . . . . . . . . . 72 6.4.5. FETCH Command . . . . . . . . . . . . . . . . . . . . 77
6.4.6. FETCH Command . . . . . . . . . . . . . . . . . . . . 77 6.4.6. STORE Command . . . . . . . . . . . . . . . . . . . . 81
6.4.7. STORE Command . . . . . . . . . . . . . . . . . . . . 81 6.4.7. COPY Command . . . . . . . . . . . . . . . . . . . . 82
6.4.8. COPY Command . . . . . . . . . . . . . . . . . . . . 82 6.4.8. MOVE Command . . . . . . . . . . . . . . . . . . . . 83
6.4.9. MOVE Command . . . . . . . . . . . . . . . . . . . . 83 6.4.9. UID Command . . . . . . . . . . . . . . . . . . . . . 85
6.4.10. UID Command . . . . . . . . . . . . . . . . . . . . . 85
6.5. Client Commands - Experimental/Expansion . . . . . . . . 87 6.5. Client Commands - Experimental/Expansion . . . . . . . . 87
6.5.1. X<atom> Command . . . . . . . . . . . . . . . . . . . 87 6.5.1. X<atom> Command . . . . . . . . . . . . . . . . . . . 87
7. Server Responses . . . . . . . . . . . . . . . . . . . . . . 88 7. Server Responses . . . . . . . . . . . . . . . . . . . . . . 87
7.1. Server Responses - Status Responses . . . . . . . . . . . 89 7.1. Server Responses - Status Responses . . . . . . . . . . . 88
7.1.1. OK Response . . . . . . . . . . . . . . . . . . . . . 96 7.1.1. OK Response . . . . . . . . . . . . . . . . . . . . . 96
7.1.2. NO Response . . . . . . . . . . . . . . . . . . . . . 96 7.1.2. NO Response . . . . . . . . . . . . . . . . . . . . . 96
7.1.3. BAD Response . . . . . . . . . . . . . . . . . . . . 97 7.1.3. BAD Response . . . . . . . . . . . . . . . . . . . . 97
7.1.4. PREAUTH Response . . . . . . . . . . . . . . . . . . 97 7.1.4. PREAUTH Response . . . . . . . . . . . . . . . . . . 97
7.1.5. BYE Response . . . . . . . . . . . . . . . . . . . . 97 7.1.5. BYE Response . . . . . . . . . . . . . . . . . . . . 97
7.2. Server Responses - Server and Mailbox Status . . . . . . 98 7.2. Server Responses - Server and Mailbox Status . . . . . . 98
7.2.1. The ENABLED Response . . . . . . . . . . . . . . . . 98 7.2.1. The ENABLED Response . . . . . . . . . . . . . . . . 98
7.2.2. CAPABILITY Response . . . . . . . . . . . . . . . . . 98 7.2.2. CAPABILITY Response . . . . . . . . . . . . . . . . . 98
7.2.3. LIST Response . . . . . . . . . . . . . . . . . . . . 99 7.2.3. LIST Response . . . . . . . . . . . . . . . . . . . . 99
7.2.4. LSUB Response . . . . . . . . . . . . . . . . . . . . 102 7.2.4. LSUB Response . . . . . . . . . . . . . . . . . . . . 102
7.2.5. NAMESPACE Response . . . . . . . . . . . . . . . . . 103 7.2.5. NAMESPACE Response . . . . . . . . . . . . . . . . . 102
7.2.6. STATUS Response . . . . . . . . . . . . . . . . . . . 103 7.2.6. STATUS Response . . . . . . . . . . . . . . . . . . . 103
7.2.7. ESEARCH Response . . . . . . . . . . . . . . . . . . 103 7.2.7. ESEARCH Response . . . . . . . . . . . . . . . . . . 103
7.2.8. FLAGS Response . . . . . . . . . . . . . . . . . . . 104 7.2.8. FLAGS Response . . . . . . . . . . . . . . . . . . . 104
7.3. Server Responses - Mailbox Size . . . . . . . . . . . . . 104 7.3. Server Responses - Mailbox Size . . . . . . . . . . . . . 104
7.3.1. EXISTS Response . . . . . . . . . . . . . . . . . . . 104 7.3.1. EXISTS Response . . . . . . . . . . . . . . . . . . . 104
7.4. Server Responses - Message Status . . . . . . . . . . . . 104 7.4. Server Responses - Message Status . . . . . . . . . . . . 104
7.4.1. EXPUNGE Response . . . . . . . . . . . . . . . . . . 105 7.4.1. EXPUNGE Response . . . . . . . . . . . . . . . . . . 104
7.4.2. FETCH Response . . . . . . . . . . . . . . . . . . . 105 7.4.2. FETCH Response . . . . . . . . . . . . . . . . . . . 105
7.5. Server Responses - Command Continuation Request . . . . . 111 7.5. Server Responses - Command Continuation Request . . . . . 111
8. Sample IMAP4rev2 connection . . . . . . . . . . . . . . . . . 112 8. Sample IMAP4rev2 connection . . . . . . . . . . . . . . . . . 112
9. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 113 9. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 113
10. Author's Note . . . . . . . . . . . . . . . . . . . . . . . . 128 10. Author's Note . . . . . . . . . . . . . . . . . . . . . . . . 128
11. Security Considerations . . . . . . . . . . . . . . . . . . . 128 11. Security Considerations . . . . . . . . . . . . . . . . . . . 128
11.1. STARTTLS Security Considerations . . . . . . . . . . . . 128 11.1. STARTTLS Security Considerations . . . . . . . . . . . . 128
11.2. COPYUID and APPENDUID response codes . . . . . . . . . . 129 11.2. COPYUID and APPENDUID response codes . . . . . . . . . . 129
11.3. Other Security Considerations . . . . . . . . . . . . . 129 11.3. LIST command and Other Users' namespace . . . . . . . . 129
11.4. Other Security Considerations . . . . . . . . . . . . . 129
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 130 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 130
12.1. Updates to IMAP4 Capabilities registry . . . . . . . . . 130 12.1. Updates to IMAP4 Capabilities registry . . . . . . . . . 130
12.2. GSSAPI/SASL service name . . . . . . . . . . . . . . . . 130 12.2. GSSAPI/SASL service name . . . . . . . . . . . . . . . . 131
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 130 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 131
13.1. Normative References . . . . . . . . . . . . . . . . . . 130 13.1. Normative References . . . . . . . . . . . . . . . . . . 131
13.2. Informative References (related protocols) . . . . . . . 133 13.2. Informative References (related protocols) . . . . . . . 134
13.3. Informative References (historical aspects of IMAP and 13.3. Informative References (historical aspects of IMAP and
related protocols) . . . . . . . . . . . . . . . . . . . 135 related protocols) . . . . . . . . . . . . . . . . . . . 135
Appendix A. Backward compatibility with IMAP4rev1 . . . . . . . 135 Appendix A. Backward compatibility with IMAP4rev1 . . . . . . . 136
A.1. Mailbox International Naming Convention . . . . . . . . . 136 A.1. Mailbox International Naming Convention . . . . . . . . . 136
Appendix B. Backward compatibility with BINARY extension . . . . 137 Appendix B. Backward compatibility with BINARY extension . . . . 138
Appendix C. Changes from RFC 3501 / IMAP4rev1 . . . . . . . . . 138 Appendix C. Changes from RFC 3501 / IMAP4rev1 . . . . . . . . . 138
Appendix D. Acknowledgement . . . . . . . . . . . . . . . . . . 139 Appendix D. Acknowledgement . . . . . . . . . . . . . . . . . . 140
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 145 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 145
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
skipping to change at page 6, line 8 skipping to change at page 6, line 8
"User" is used to refer to a human user, whereas "client" refers to "User" is used to refer to a human user, whereas "client" refers to
the software being run by the user. the software being run by the user.
"Connection" refers to the entire sequence of client/server "Connection" refers to the entire sequence of client/server
interaction from the initial establishment of the network connection interaction from the initial establishment of the network connection
until its termination. until its termination.
"Session" refers to the sequence of client/server interaction from "Session" refers to the sequence of client/server interaction from
the time that a mailbox is selected (SELECT or EXAMINE command) until the time that a mailbox is selected (SELECT or EXAMINE command) until
the time that selection ends (SELECT or EXAMINE of another mailbox, the time that selection ends (SELECT or EXAMINE of another mailbox,
CLOSE command, or connection termination). CLOSE command, UNSELECT command, or connection termination).
Characters are 7-bit US-ASCII unless otherwise specified. Other Characters are 7-bit US-ASCII unless otherwise specified. Other
character sets are indicated using a "CHARSET", as described in character sets are indicated using a "CHARSET", as described in
[MIME-IMT] and defined in [CHARSET]. CHARSETs have important [MIME-IMT] and defined in [CHARSET]. CHARSETs have important
additional semantics in addition to defining character set; refer to additional semantics in addition to defining character set; refer to
these documents for more detail. these documents for more detail.
There are several protocol conventions in IMAP. These refer to There are several protocol conventions in IMAP. These refer to
aspects of the specification which are not strictly part of the IMAP aspects of the specification which are not strictly part of the IMAP
protocol, but reflect generally-accepted practice. Implementations protocol, but reflect generally-accepted practice. Implementations
skipping to change at page 12, line 26 skipping to change at page 12, line 26
implementations. These keywords SHOULD be supported (i.e. allowed in implementations. These keywords SHOULD be supported (i.e. allowed in
APPEND, COPY, MOVE and SEARCH commands) by server implementations: APPEND, COPY, MOVE and SEARCH commands) by server implementations:
$Forwarded Message has been forwarded to another email address, $Forwarded Message has been forwarded to another email address,
embedded within or attached to a new message. An email client embedded within or attached to a new message. An email client
sets this keyword when it successfully forwards the message to sets this keyword when it successfully forwards the message to
another email address. Typical usage of this keyword is to show a another email address. Typical usage of this keyword is to show a
different (or additional) icon for a message that has been different (or additional) icon for a message that has been
forwarded. Once set, the flag SHOULD NOT be cleared. forwarded. Once set, the flag SHOULD NOT be cleared.
$MDNSent Message Disposition Notification was generated and sent for $MDNSent Message Disposition Notification [RFC8098] was generated
this message. and sent for this message.
A flag can be permanent or session-only on a per-flag basis. A flag can be permanent or session-only on a per-flag basis.
Permanent flags are those which the client can add or remove from the Permanent flags are those which the client can add or remove from the
message flags permanently; that is, concurrent and subsequent message flags permanently; that is, concurrent and subsequent
sessions will see any change in permanent flags. Changes to session sessions will see any change in permanent flags. Changes to session
flags are valid only in that session. flags are valid only in that session.
2.3.3. Internal Date Message Attribute 2.3.3. Internal Date Message Attribute
The internal date and time of the message on the server. This is not The internal date and time of the message on the server. This is not
skipping to change at page 14, line 25 skipping to change at page 14, line 25
can be entered as a result of a client request (via the LOGOUT can be entered as a result of a client request (via the LOGOUT
command) or by unilateral action on the part of either the client or command) or by unilateral action on the part of either the client or
server. server.
If the client requests the logout state, the server MUST send an If the client requests the logout state, the server MUST send an
untagged BYE response and a tagged OK response to the LOGOUT command untagged BYE response and a tagged OK response to the LOGOUT command
before the server closes the connection; and the client MUST read the before the server closes the connection; and the client MUST read the
tagged OK response to the LOGOUT command before the client closes the tagged OK response to the LOGOUT command before the client closes the
connection. connection.
A server MUST NOT unilaterally close the connection without sending A server SHOULD NOT unilaterally close the connection without sending
an untagged BYE response that contains the reason for having done so. an untagged BYE response that contains the reason for having done so.
A client SHOULD NOT unilaterally close the connection, and instead A client SHOULD NOT unilaterally close the connection, and instead
SHOULD issue a LOGOUT command. If the server detects that the client SHOULD issue a LOGOUT command. If the server detects that the client
has unilaterally closed the connection, the server MAY omit the has unilaterally closed the connection, the server MAY omit the
untagged BYE response and simply close its connection. untagged BYE response and simply close its connection.
+----------------------+ +----------------------+
|connection established| |connection established|
+----------------------+ +----------------------+
|| ||
skipping to change at page 18, line 39 skipping to change at page 19, line 5
distinct from the empty string "" or the empty parenthesized list (). distinct from the empty string "" or the empty parenthesized list ().
Note: NIL is never used for any data item which takes the form of Note: NIL is never used for any data item which takes the form of
an atom. For example, a mailbox name of "NIL" is a mailbox named an atom. For example, a mailbox name of "NIL" is a mailbox named
NIL as opposed to a non-existent mailbox name. This is because NIL as opposed to a non-existent mailbox name. This is because
mailbox uses "astring" syntax which is an atom or a string. mailbox uses "astring" syntax which is an atom or a string.
Conversely, an addr-name of NIL is a non-existent personal name, Conversely, an addr-name of NIL is a non-existent personal name,
because addr-name uses "nstring" syntax which is NIL or a string, because addr-name uses "nstring" syntax which is NIL or a string,
but never an atom. but never an atom.
Examples:
The following LIST response:
* LIST () "/" NIL
is equivalent to:
* LIST () "/" "NIL"
as LIST response ABNF is using astring for mailbox name.
However, the following response
* FETCH 1 (BODY[1] NIL)
is not equivalent to:
* FETCH 1 (BODY[1] "NIL")
The former means absence of the body part, while the latter
means that it contains literal sequence of characters "NIL".
5. Operational Considerations 5. Operational Considerations
The following rules are listed here to ensure that all IMAP4rev2 The following rules are listed here to ensure that all IMAP4rev2
implementations interoperate properly. implementations interoperate properly.
5.1. Mailbox Naming 5.1. Mailbox Naming
In IMAP4rev2, Mailbox names are encoded in Net-Unicode [NET-UNICODE] In IMAP4rev2, Mailbox names are encoded in Net-Unicode [NET-UNICODE]
(this differs from IMAP4rev1). Client implementations MAY attempt to (this differs from IMAP4rev1). Client implementations MAY attempt to
create Net-Unicode mailbox names, and MUST interpret any 8-bit create Net-Unicode mailbox names, and MUST interpret any 8-bit
skipping to change at page 23, line 11 skipping to change at page 23, line 35
any untagged EXPUNGE returned by the UID SEARCH. any untagged EXPUNGE returned by the UID SEARCH.
For example, the following non-waiting command sequences are invalid: For example, the following non-waiting command sequences are invalid:
FETCH + NOOP + STORE FETCH + NOOP + STORE
STORE + COPY + FETCH STORE + COPY + FETCH
COPY + COPY COPY + COPY
CHECK + FETCH
The following are examples of valid non-waiting command sequences: The following are examples of valid non-waiting command sequences:
FETCH + STORE + SEARCH + CHECK FETCH + STORE + SEARCH + NOOP
STORE + COPY + EXPUNGE STORE + COPY + EXPUNGE
UID SEARCH + UID SEARCH may be valid or invalid as a non-waiting UID SEARCH + UID SEARCH may be valid or invalid as a non-waiting
command sequence, depending upon whether or not the second UID command sequence, depending upon whether or not the second UID
SEARCH contains message sequence numbers. SEARCH contains message sequence numbers.
6. Client Commands 6. Client Commands
IMAP4rev2 commands are described in this section. Commands are IMAP4rev2 commands are described in this section. Commands are
skipping to change at page 25, line 29 skipping to change at page 25, line 45
Responses: no specific responses for this command (but see below) Responses: no specific responses for this command (but see below)
Result: OK - noop completed Result: OK - noop completed
BAD - command unknown or arguments invalid BAD - command unknown or arguments invalid
The NOOP command always succeeds. It does nothing. The NOOP command always succeeds. It does nothing.
Since any command can return a status update as untagged data, the Since any command can return a status update as untagged data, the
NOOP command can be used as a periodic poll for new messages or NOOP command can be used as a periodic poll for new messages or
message status updates during a period of inactivity (this is the message status updates during a period of inactivity (the IDLE
preferred method to do this). The NOOP command can also be used to command Section 6.3.14 should be used instead of NOOP if real-time
reset any inactivity autologout timer on the server. updates to mailbox state are desirable). The NOOP command can also
be used to reset any inactivity autologout timer on the server.
Example: C: a002 NOOP Example: C: a002 NOOP
S: a002 OK NOOP completed S: a002 OK NOOP completed
. . . . . .
C: a047 NOOP C: a047 NOOP
S: * 22 EXPUNGE S: * 22 EXPUNGE
S: * 23 EXISTS S: * 23 EXISTS
S: * 14 FETCH (UID 1305 FLAGS (\Seen \Deleted)) S: * 14 FETCH (UID 1305 FLAGS (\Seen \Deleted))
S: a047 OK NOOP completed S: a047 OK NOOP completed
skipping to change at page 29, line 20 skipping to change at page 29, line 37
Note: a server implementation MUST implement a configuration in Note: a server implementation MUST implement a configuration in
which it does NOT permit any plaintext password mechanisms, unless which it does NOT permit any plaintext password mechanisms, unless
either the STARTTLS command has been negotiated or some other either the STARTTLS command has been negotiated or some other
mechanism that protects the session from password snooping has mechanism that protects the session from password snooping has
been provided. Server sites SHOULD NOT use any configuration been provided. Server sites SHOULD NOT use any configuration
which permits a plaintext password mechanism without such a which permits a plaintext password mechanism without such a
protection mechanism against password snooping. Client and server protection mechanism against password snooping. Client and server
implementations SHOULD implement additional [SASL] mechanisms that implementations SHOULD implement additional [SASL] mechanisms that
do not use plaintext passwords, such the GSSAPI mechanism do not use plaintext passwords, such the GSSAPI mechanism
described in [SASL] and/or the [DIGEST-MD5] mechanism. described in [SASL] and/or the SCRAM-SHA-256/SCRAM-SHA-256-PLUS
[SCRAM-SHA-256] mechanisms.
Servers and clients can support multiple authentication mechanisms. Servers and clients can support multiple authentication mechanisms.
The server SHOULD list its supported authentication mechanisms in the The server SHOULD list its supported authentication mechanisms in the
response to the CAPABILITY command so that the client knows which response to the CAPABILITY command so that the client knows which
authentication mechanisms to use. authentication mechanisms to use.
A server MAY include a CAPABILITY response code in the tagged OK A server MAY include a CAPABILITY response code in the tagged OK
response of a successful AUTHENTICATE command in order to send response of a successful AUTHENTICATE command in order to send
capabilities automatically. It is unnecessary for a client to send a capabilities automatically. It is unnecessary for a client to send a
separate CAPABILITY command if it recognizes these automatic separate CAPABILITY command if it recognizes these automatic
skipping to change at page 31, line 49 skipping to change at page 32, line 19
Arguments: capability names Arguments: capability names
Responses: no specific responses for this command Responses: no specific responses for this command
Result: OK - Relevant capabilities enabled Result: OK - Relevant capabilities enabled
BAD - No arguments, or syntax error in an argument BAD - No arguments, or syntax error in an argument
Several IMAP extensions allow the server to return unsolicited Several IMAP extensions allow the server to return unsolicited
responses specific to these extensions in certain circumstances. responses specific to these extensions in certain circumstances.
However, servers cannot send those unsolicited responses (with the However, servers cannot send those unsolicited responses (with the
exception of response codes included in tagged or untagged OK/NO/BAD exception of response codes (see Section 7.1) included in tagged or
responses, which can always be sent) until they know that the clients untagged OK/NO/BAD responses, which can always be sent) until they
support such extensions and thus won't choke on the extension know that the clients support such extensions and thus won't choke on
response data. the extension response data.
The ENABLE command provides an explicit indication from the client The ENABLE command provides an explicit indication from the client
that it supports particular extensions. that it supports particular extensions.
The ENABLE command takes a list of capability names, and requests the The ENABLE command takes a list of capability names, and requests the
server to enable the named extensions. Once enabled using ENABLE, server to enable the named extensions. Once enabled using ENABLE,
each extension remains active until the IMAP connection is closed. each extension remains active until the IMAP connection is closed.
For each argument, the server does the following: For each argument, the server does the following:
o If the argument is not an extension known to the server, the o If the argument is not an extension known to the server, the
skipping to change at page 42, line 5 skipping to change at page 42, line 5
NO - list failure: can't list that reference or name NO - list failure: can't list that reference or name
BAD - command unknown or arguments invalid BAD - command unknown or arguments invalid
THIS VERSION HAS ONLY AN INITIAL PASS AT ADDING THE EXTENDED LIST THIS VERSION HAS ONLY AN INITIAL PASS AT ADDING THE EXTENDED LIST
SYNTAX AND OPTIONS. THERE'S STILL A GOOD DEAL OR WORK TO DO ON IT, SYNTAX AND OPTIONS. THERE'S STILL A GOOD DEAL OR WORK TO DO ON IT,
AND THE ABNF IS NOT THERE YET. AND THE ABNF IS NOT THERE YET.
The LIST command returns a subset of names from the complete set of The LIST command returns a subset of names from the complete set of
all names available to the client. Zero or more untagged LIST all names available to the client. Zero or more untagged LIST
replies are returned, containing the name attributes, hierarchy replies are returned, containing the name attributes, hierarchy
delimiter, and name; see the description of the LIST reply for more delimiter, name, and possible extension information; see the
detail. description of the LIST reply 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, introduced in [RFC5258] provides The extended LIST command, originally introduced in [RFC5258],
capabilities beyond that of the original IMAP LIST command. The provides capabilities beyond that of the original IMAP LIST command.
extended syntax is being used if one of the following conditions is The extended syntax is being used if one of the following conditions
true: 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
parenthesis ("LIST selection options") parenthesis ("LIST selection options")
2. if the second word after the command name begins with a 2. if the second word after the command name begins with a
parenthesis ("multiple mailbox patterns") parenthesis ("multiple mailbox patterns")
3. if the LIST command has more than 2 parameters ("LIST return 3. if the LIST command has more than 2 parameters ("LIST return
options") options")
An empty ("" string) reference name argument indicates that the An empty ("" string) reference name argument indicates that the
mailbox name is interpreted as by SELECT. The returned mailbox names mailbox name is interpreted as by SELECT. The returned mailbox names
MUST match the supplied mailbox name pattern(s). A non-empty MUST match the supplied mailbox name pattern(s). A non-empty
reference name argument is the name of a mailbox or a level of reference name argument is the name of a mailbox or a level of
mailbox hierarchy, and indicates the context in which the mailbox mailbox hierarchy, and indicates the context in which the mailbox
name is interpreted. name is interpreted. Clients SHOULD use the empty reference
argument.
In the basic syntax only, an empty ("" string) mailbox name argument In the basic syntax only, an empty ("" string) mailbox name argument
is a special request to return the hierarchy delimiter and the root is a special request to return the hierarchy delimiter and the root
name of the name given in the reference. The value returned as the name of the name given in the reference. The value returned as the
root MAY be the empty string if the reference is non-rooted or is an root MAY be the empty string if the reference is non-rooted or is an
empty string. In all cases, a hierarchy delimiter (or NIL if there empty string. In all cases, a hierarchy delimiter (or NIL if there
is no hierarchy) is returned. This permits a client to get the is no hierarchy) is returned. This permits a client to get the
hierarchy delimiter (or find out that the mailbox names are flat) hierarchy delimiter (or find out that the mailbox names are flat)
even when no mailboxes by that name currently exist. even when no mailboxes by that name currently exist.
skipping to change at page 59, line 32 skipping to change at page 59, line 32
Result: OK - command completed Result: OK - command completed
NO - Can't complete the command NO - Can't complete the command
BAD - arguments invalid BAD - arguments invalid
The NAMESPACE command causes a single ungagged NAMESPACE response to The NAMESPACE command causes a single ungagged NAMESPACE response to
be returned. The untagged NAMESPACE response contains the prefix and be returned. The untagged NAMESPACE response contains the prefix and
hierarchy delimiter to the server's Personal Namespace(s), Other hierarchy delimiter to the server's Personal Namespace(s), Other
Users' Namespace(s), and Shared Namespace(s) that the server wishes Users' Namespace(s), and Shared Namespace(s) that the server wishes
to expose. The response will contain a NIL for any namespace class to expose. The response will contain a NIL for any namespace class
that is not available. Namespace_Response_Extensions MAY be included that is not available. Namespace-Response-Extensions ABNF non
in the response. Namespace_Response_Extensions which are not on the terminal is defined for extensibility and MAY be included in the
IETF standards track, MUST be prefixed with an "X-". response. Namespace-Response-Extensions which are not on the IETF
standards track, MUST be prefixed with an "X-".
Example 1: Example 1:
In this example a server supports a single personal namespace. No In this example a server supports a single personal namespace. No
leading prefix is used on personal mailboxes and "/" is the hierarchy leading prefix is used on personal mailboxes and "/" is the hierarchy
delimiter. delimiter.
C: A001 NAMESPACE C: A001 NAMESPACE
S: * NAMESPACE (("" "/")) NIL NIL S: * NAMESPACE (("" "/")) NIL NIL
S: A001 OK NAMESPACE command completed S: A001 OK NAMESPACE command completed
skipping to change at page 61, line 6 skipping to change at page 61, line 6
C: A002 CREATE "INBOX.Sent Mail" C: A002 CREATE "INBOX.Sent Mail"
S: A002 OK CREATE command completed S: A002 OK CREATE command completed
Although typically a server will support only a single Personal Although typically a server will support only a single Personal
Namespace, and a single Other User's Namespace, circumstances exist Namespace, and a single Other User's Namespace, circumstances exist
where there MAY be multiples of these, and a client MUST be prepared where there MAY be multiples of these, and a client MUST be prepared
for them. If a client is configured such that it is required to for them. If a client is configured such that it is required to
create a certain mailbox, there can be circumstances where it is create a certain mailbox, there can be circumstances where it is
unclear which Personal Namespaces it should create the mailbox in. unclear which Personal Namespaces it should create the mailbox in.
In these situations a client SHOULD let the user select which In these situations a client SHOULD let the user select which
namespaces to create the mailbox in. namespaces to create the mailbox in or just use the first personal
namespace.
Example 6: Example 6:
In this example, a server supports 2 Personal Namespaces. In In this example, a server supports 2 Personal Namespaces. In
addition to the regular Personal Namespace, the user has an addition to the regular Personal Namespace, the user has an
additional personal namespace to allow access to mailboxes in an MH additional personal namespace to allow access to mailboxes in an MH
format mailstore. format mailstore.
The client is configured to save a copy of all mail sent by the user The client is configured to save a copy of all mail sent by the user
into a mailbox called 'Sent Mail'. Furthermore, after a message is into a mailbox called 'Sent Mail'. Furthermore, after a message is
skipping to change at page 65, line 8 skipping to change at page 65, line 8
Section 2.3.1.1 for more information. Section 2.3.1.1 for more information.
UIDVALIDITY The unique identifier validity value of the mailbox. UIDVALIDITY The unique identifier validity value of the mailbox.
Refer to Section 2.3.1.1 for more information. Refer to Section 2.3.1.1 for more information.
UNSEEN The number of messages which do not have the \Seen flag set. UNSEEN The number of messages which do not have the \Seen flag set.
SIZE The total size of the mailbox in octets. This is not strictly SIZE The total size of the mailbox in octets. This is not strictly
required to be an exact value, but it MUST be equal to or greater required to be an exact value, but it MUST be equal to or greater
than the sum of the values of the RFC822.SIZE FETCH message data than the sum of the values of the RFC822.SIZE FETCH message data
items (see Section 6.4.6) of all messages in the mailbox. items (see Section 6.4.5) of all messages in the mailbox.
Example: C: A042 STATUS blurdybloop (UIDNEXT MESSAGES) Example: C: A042 STATUS blurdybloop (UIDNEXT MESSAGES)
S: * STATUS blurdybloop (MESSAGES 231 UIDNEXT 44292) S: * STATUS blurdybloop (MESSAGES 231 UIDNEXT 44292)
S: A042 OK STATUS completed S: A042 OK STATUS completed
6.3.13. APPEND Command 6.3.13. APPEND Command
Arguments: mailbox name Arguments: mailbox name
OPTIONAL flag parenthesized list OPTIONAL flag parenthesized list
OPTIONAL date/time string OPTIONAL date/time string
skipping to change at page 66, line 35 skipping to change at page 66, line 35
If the server does not return the APPENDUID response codes, the If the server does not return the APPENDUID response codes, the
client can discover this information by selecting the destination client can discover this information by selecting the destination
mailbox. The location of messages placed in the destination mailbox mailbox. The location of messages placed in the destination mailbox
by APPEND can be determined by using FETCH and/or SEARCH commands by APPEND can be determined by using FETCH and/or SEARCH commands
(e.g., for Message-ID or some unique marker placed in the message in (e.g., for Message-ID or some unique marker placed in the message in
an APPEND). an APPEND).
If the mailbox is currently selected, the normal new message actions If the mailbox is currently selected, the normal new message actions
SHOULD occur. Specifically, the server SHOULD notify the client SHOULD occur. Specifically, the server SHOULD notify the client
immediately via an untagged EXISTS response. If the server does not immediately via an untagged EXISTS response. If the server does not
do so, the client MAY issue a NOOP command (or failing that, a CHECK do so, the client MAY issue a NOOP command after one or more APPEND
command) after one or more APPEND commands. commands.
Example: C: A003 APPEND saved-messages (\Seen) {310} Example: C: A003 APPEND saved-messages (\Seen) {310}
S: + Ready for literal data S: + Ready for literal data
C: Date: Mon, 7 Feb 1994 21:52:25 -0800 (PST) C: Date: Mon, 7 Feb 1994 21:52:25 -0800 (PST)
C: From: Fred Foobar <foobar@Blurdybloop.COM> C: From: Fred Foobar <foobar@Blurdybloop.COM>
C: Subject: afternoon meeting C: Subject: afternoon meeting
C: To: mooch@owatagu.siam.edu C: To: mooch@owatagu.siam.edu
C: Message-Id: <B27397-0100000@Blurdybloop.COM> C: Message-Id: <B27397-0100000@Blurdybloop.COM>
C: MIME-Version: 1.0 C: MIME-Version: 1.0
C: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII C: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
skipping to change at page 68, line 31 skipping to change at page 68, line 31
responds to the continuation, and as long as an IDLE command is responds to the continuation, and as long as an IDLE command is
active, the server is now free to send untagged EXISTS, EXPUNGE, active, the server is now free to send untagged EXISTS, EXPUNGE,
FETCH, and other responses at any time. If the server choose to send FETCH, and other responses at any time. If the server choose to send
unsolicited FETCH responses, they MUST include UID FETCH item. unsolicited FETCH responses, they MUST include UID FETCH item.
The IDLE command is terminated by the receipt of a "DONE" The IDLE command is terminated by the receipt of a "DONE"
continuation from the client; such response satisfies the server's continuation from the client; such response satisfies the server's
continuation request. At that point, the server MAY send any continuation request. At that point, the server MAY send any
remaining queued untagged responses and then MUST immediately send remaining queued untagged responses and then MUST immediately send
the tagged response to the IDLE command and prepare to process other the tagged response to the IDLE command and prepare to process other
commands. As in the base specification, the processing of any new commands. As for other commands, the processing of any new command
command may cause the sending of unsolicited untagged responses, may cause the sending of unsolicited untagged responses, subject to
subject to the ambiguity limitations. The client MUST NOT send a the ambiguity limitations. The client MUST NOT send a command while
command while the server is waiting for the DONE, since the server the server is waiting for the DONE, since the server will not be able
will not be able to distinguish a command from a continuation. to distinguish a command from a continuation.
The server MAY consider a client inactive if it has an IDLE command The server MAY consider a client inactive if it has an IDLE command
running, and if such a server has an inactivity timeout it MAY log running, and if such a server has an inactivity timeout it MAY log
the client off implicitly at the end of its timeout period. Because the client off implicitly at the end of its timeout period. Because
of that, clients using IDLE are advised to terminate the IDLE and re- of that, clients using IDLE are advised to terminate the IDLE and re-
issue it at least every 29 minutes to avoid being logged off. This issue it at least every 29 minutes to avoid being logged off. This
still allows a client to receive immediate mailbox updates even still allows a client to receive immediate mailbox updates even
though it need only "poll" at half hour intervals. though it need only "poll" at half hour intervals.
Example: C: A001 SELECT INBOX Example: C: A001 SELECT INBOX
skipping to change at page 69, line 46 skipping to change at page 69, line 46
6.4. Client Commands - Selected State 6.4. Client Commands - Selected State
In the selected state, commands that manipulate messages in a mailbox In the selected state, commands that manipulate messages in a mailbox
are permitted. are permitted.
In addition to the universal commands (CAPABILITY, NOOP, and LOGOUT), In addition to the universal commands (CAPABILITY, NOOP, and LOGOUT),
and the authenticated state commands (SELECT, EXAMINE, NAMESPACE, and the authenticated state commands (SELECT, EXAMINE, NAMESPACE,
CREATE, DELETE, RENAME, SUBSCRIBE, UNSUBSCRIBE, LIST, LSUB , STATUS, CREATE, DELETE, RENAME, SUBSCRIBE, UNSUBSCRIBE, LIST, LSUB , STATUS,
and APPEND), the following commands are valid in the selected state: and APPEND), the following commands are valid in the selected state:
CHECK, CLOSE, UNSELECT, EXPUNGE, SEARCH, FETCH, STORE, COPY, MOVE, CLOSE, UNSELECT, EXPUNGE, SEARCH, FETCH, STORE, COPY, MOVE, and UID.
and UID.
6.4.1. CHECK Command
Arguments: none
Responses: no specific responses for this command
Result: OK - check completed
BAD - command unknown or arguments invalid
The CHECK command requests a checkpoint of the currently selected
mailbox. A checkpoint refers to any implementation-dependent
housekeeping associated with the mailbox (e.g., resolving the
server's in-memory state of the mailbox with the state on its disk)
that is not normally executed as part of each command. A checkpoint
MAY take a non-instantaneous amount of real time to complete. If a
server implementation has no such housekeeping considerations, CHECK
is equivalent to NOOP.
There is no guarantee that an EXISTS untagged response will happen as
a result of CHECK. NOOP, not CHECK, SHOULD be used for new message
polling.
Example: C: FXXZ CHECK
S: FXXZ OK CHECK Completed
6.4.2. CLOSE Command 6.4.1. CLOSE Command
Arguments: none Arguments: none
Responses: no specific responses for this command Responses: no specific responses for this command
Result: OK - close completed, now in authenticated state Result: OK - close completed, now in authenticated state
BAD - command unknown or arguments invalid BAD - command unknown or arguments invalid
The CLOSE command permanently removes all messages that have the The CLOSE command permanently removes all messages that have the
\Deleted flag set from the currently selected mailbox, and returns to \Deleted flag set from the currently selected mailbox, and returns to
the authenticated state from the selected state. No untagged EXPUNGE the authenticated state from the selected state. No untagged EXPUNGE
responses are sent. responses are sent.
No messages are removed, and no error is given, if the mailbox is No messages are removed, and no error is given, if the mailbox is
selected by an EXAMINE command or is otherwise selected read-only. selected by an EXAMINE command or is otherwise selected read-only.
skipping to change at page 71, line 10 skipping to change at page 70, line 27
SELECT, EXAMINE, and LOGOUT commands implicitly close the currently SELECT, EXAMINE, and LOGOUT commands implicitly close the currently
selected mailbox without doing an expunge. However, when many selected mailbox without doing an expunge. However, when many
messages are deleted, a CLOSE-LOGOUT or CLOSE-SELECT sequence is messages are deleted, a CLOSE-LOGOUT or CLOSE-SELECT sequence is
considerably faster than an EXPUNGE-LOGOUT or EXPUNGE-SELECT because considerably faster than an EXPUNGE-LOGOUT or EXPUNGE-SELECT because
no untagged EXPUNGE responses (which the client would probably no untagged EXPUNGE responses (which the client would probably
ignore) are sent. ignore) are sent.
Example: C: A341 CLOSE Example: C: A341 CLOSE
S: A341 OK CLOSE completed S: A341 OK CLOSE completed
6.4.3. UNSELECT Command 6.4.2. UNSELECT Command
Arguments: none Arguments: none
Responses: no specific responses for this command Responses: no specific responses for this command
Result: OK - unselect completed, now in authenticated state Result: OK - unselect completed, now in authenticated state
BAD - no mailbox selected, or argument supplied but none BAD - no mailbox selected, or argument supplied but none
permitted permitted
The UNSELECT command frees server's resources associated with the The UNSELECT command frees server's resources associated with the
selected mailbox and returns the server to the authenticated state. selected mailbox and returns the server to the authenticated state.
This command performs the same actions as CLOSE, except that no This command performs the same actions as CLOSE, except that no
messages are permanently removed from the currently selected mailbox. messages are permanently removed from the currently selected mailbox.
Example: C: A342 UNSELECT Example: C: A342 UNSELECT
S: A342 OK Unselect completed S: A342 OK Unselect completed
6.4.4. EXPUNGE Command 6.4.3. EXPUNGE Command
Arguments: none Arguments: none
Responses: untagged responses: EXPUNGE Responses: untagged responses: EXPUNGE
Result: OK - expunge completed Result: OK - expunge completed
NO - expunge failure: can't expunge (e.g., permission NO - expunge failure: can't expunge (e.g., permission
denied) denied)
BAD - command unknown or arguments invalid BAD - command unknown or arguments invalid
skipping to change at page 72, line 9 skipping to change at page 71, line 24
S: * 3 EXPUNGE S: * 3 EXPUNGE
S: * 3 EXPUNGE S: * 3 EXPUNGE
S: * 5 EXPUNGE S: * 5 EXPUNGE
S: * 8 EXPUNGE S: * 8 EXPUNGE
S: A202 OK EXPUNGE completed S: A202 OK EXPUNGE completed
Note: In this example, messages 3, 4, 7, and 11 had the \Deleted flag Note: In this example, messages 3, 4, 7, and 11 had the \Deleted flag
set. See the description of the EXPUNGE response for further set. See the description of the EXPUNGE response for further
explanation. explanation.
6.4.5. SEARCH Command 6.4.4. SEARCH Command
Arguments: OPTIONAL result specifier Arguments: OPTIONAL result specifier
OPTIONAL [CHARSET] specification OPTIONAL [CHARSET] specification
searching criteria (one or more) searching criteria (one or more)
Responses: REQUIRED untagged response: ESEARCH Responses: REQUIRED untagged response: ESEARCH
Result: OK - search completed Result: OK - search completed
NO - search error: can't search that [CHARSET] or NO - search error: can't search that [CHARSET] or
criteria criteria
skipping to change at page 74, line 35 skipping to change at page 74, line 6
ANSWERED Messages with the \Answered flag set. ANSWERED Messages with the \Answered flag set.
BCC <string> Messages that contain the specified string in the BCC <string> Messages that contain the specified string in the
envelope structure's BCC field. envelope structure's BCC field.
BEFORE <date> Messages whose internal date (disregarding time and BEFORE <date> Messages whose internal date (disregarding time and
timezone) is earlier than the specified date. timezone) is earlier than the specified date.
BODY <string> Messages that contain the specified string in the body BODY <string> Messages that contain the specified string in the body
of the message. of the message. Unlike TEXT (see below), this doesn't match any
header fields.
CC <string> Messages that contain the specified string in the CC <string> Messages that contain the specified string in the
envelope structure's CC field. envelope structure's CC field.
DELETED Messages with the \Deleted flag set. DELETED Messages with the \Deleted flag set.
DRAFT Messages with the \Draft flag set. DRAFT Messages with the \Draft flag set.
FLAGGED Messages with the \Flagged flag set. FLAGGED Messages with the \Flagged flag set.
skipping to change at page 75, line 47 skipping to change at page 75, line 19
SINCE <date> Messages whose internal date (disregarding time and SINCE <date> Messages whose internal date (disregarding time and
timezone) is within or later than the specified date. timezone) is within or later than the specified date.
SMALLER <n> Messages with an [RFC-5322] size smaller than the SMALLER <n> Messages with an [RFC-5322] size smaller than the
specified number of octets. specified number of octets.
SUBJECT <string> Messages that contain the specified string in the SUBJECT <string> Messages that contain the specified string in the
envelope structure's SUBJECT field. envelope structure's SUBJECT field.
TEXT <string> Messages that contain the specified string in the TEXT <string> Messages that contain the specified string in the
header or body of the message. header (including MIME header fields) or body of the message.
TO <string> Messages that contain the specified string in the TO <string> Messages that contain the specified string in the
envelope structure's TO field. envelope structure's TO field.
UID <sequence set> Messages with unique identifiers corresponding to UID <sequence set> Messages with unique identifiers corresponding to
the specified unique identifier set. Sequence set ranges are the specified unique identifier set. Sequence set ranges are
permitted. permitted.
UNANSWERED Messages that do not have the \Answered flag set. UNANSWERED Messages that do not have the \Answered flag set.
skipping to change at page 77, line 20 skipping to change at page 77, line 5
S: * ESEARCH (TAG "A285") UID MIN 7 MAX 3800 S: * ESEARCH (TAG "A285") UID MIN 7 MAX 3800
S: A285 OK SEARCH completed S: A285 OK SEARCH completed
The following example demonstrates returning the number of deleted The following example demonstrates returning the number of deleted
messages: messages:
Example: C: A286 SEARCH RETURN (COUNT) DELETED Example: C: A286 SEARCH RETURN (COUNT) DELETED
S: * ESEARCH (TAG "A286") COUNT 15 S: * ESEARCH (TAG "A286") COUNT 15
S: A286 OK SEARCH completed S: A286 OK SEARCH completed
6.4.6. FETCH Command 6.4.5. FETCH Command
Arguments: sequence set Arguments: sequence set
message data item names or macro message data item names or macro
Responses: untagged responses: FETCH Responses: untagged responses: FETCH
Result: OK - fetch completed Result: OK - fetch completed
NO - fetch error: can't fetch that data NO - fetch error: can't fetch that data
BAD - command unknown or arguments invalid BAD - command unknown or arguments invalid
skipping to change at page 81, line 38 skipping to change at page 81, line 11
returned). returned).
UID The unique identifier for the message. UID The unique identifier for the message.
Example: C: A654 FETCH 2:4 (FLAGS BODY[HEADER.FIELDS (DATE FROM)]) Example: C: A654 FETCH 2:4 (FLAGS BODY[HEADER.FIELDS (DATE FROM)])
S: * 2 FETCH .... S: * 2 FETCH ....
S: * 3 FETCH .... S: * 3 FETCH ....
S: * 4 FETCH .... S: * 4 FETCH ....
S: A654 OK FETCH completed S: A654 OK FETCH completed
6.4.7. STORE Command 6.4.6. STORE Command
Arguments: sequence set Arguments: sequence set
message data item name message data item name
value for message data item value for message data item
Responses: untagged responses: FETCH Responses: untagged responses: FETCH
Result: OK - store completed Result: OK - store completed
NO - store error: can't store that data NO - store error: can't store that data
BAD - command unknown or arguments invalid BAD - command unknown or arguments invalid
skipping to change at page 82, line 43 skipping to change at page 82, line 18
-FLAGS.SILENT <flag list> Equivalent to -FLAGS, but without -FLAGS.SILENT <flag list> Equivalent to -FLAGS, but without
returning a new value. returning a new value.
Example: C: A003 STORE 2:4 +FLAGS (\Deleted) Example: C: A003 STORE 2:4 +FLAGS (\Deleted)
S: * 2 FETCH (FLAGS (\Deleted \Seen)) S: * 2 FETCH (FLAGS (\Deleted \Seen))
S: * 3 FETCH (FLAGS (\Deleted)) S: * 3 FETCH (FLAGS (\Deleted))
S: * 4 FETCH (FLAGS (\Deleted \Flagged \Seen)) S: * 4 FETCH (FLAGS (\Deleted \Flagged \Seen))
S: A003 OK STORE completed S: A003 OK STORE completed
6.4.8. COPY Command 6.4.7. COPY Command
Arguments: sequence set Arguments: sequence set
mailbox name mailbox name
Responses: no specific responses for this command Responses: no specific responses for this command
Result: OK - copy completed Result: OK - copy completed
NO - copy error: can't copy those messages or to that NO - copy error: can't copy those messages or to that
name name
BAD - command unknown or arguments invalid BAD - command unknown or arguments invalid
skipping to change at page 83, line 44 skipping to change at page 83, line 18
If the server does not return the COPYUID response code, the client If the server does not return the COPYUID response code, the client
can discover this information by selecting the destination mailbox. can discover this information by selecting the destination mailbox.
The location of messages placed in the destination mailbox by COPY The location of messages placed in the destination mailbox by COPY
can be determined by using FETCH and/or SEARCH commands (e.g., for can be determined by using FETCH and/or SEARCH commands (e.g., for
Message-ID). Message-ID).
Example: C: A003 COPY 2:4 MEETING Example: C: A003 COPY 2:4 MEETING
S: A003 OK COPY completed S: A003 OK COPY completed
6.4.9. MOVE Command 6.4.8. MOVE Command
Arguments: sequence set Arguments: sequence set
mailbox name mailbox name
Responses: no specific responses for this command Responses: no specific responses for this command
Result: OK - move completed Result: OK - move completed
NO - move error: can't move those messages or to that NO - move error: can't move those messages or to that
name name
BAD - command unknown or arguments invalid BAD - command unknown or arguments invalid
skipping to change at page 84, line 46 skipping to change at page 84, line 21
both mailboxes (it would be bad for a partial failure to result in a both mailboxes (it would be bad for a partial failure to result in a
bunch of duplicate messages). This is true even if the server bunch of duplicate messages). This is true even if the server
returns a tagged NO response to the command. returns a tagged NO response to the command.
Because of the similarity of MOVE to COPY, extensions that affect Because of the similarity of MOVE to COPY, extensions that affect
COPY affect MOVE in the same way. Response codes such as TRYCREATE COPY affect MOVE in the same way. Response codes such as TRYCREATE
(see Section 7.1), as well as those defined by extensions, are sent (see Section 7.1), as well as those defined by extensions, are sent
as appropriate. as appropriate.
Servers SHOULD send COPYUID in response to a UID MOVE (see Servers SHOULD send COPYUID in response to a UID MOVE (see
Section 6.4.10) command. For additional information see Section 7.1. Section 6.4.9) command. For additional information see Section 7.1.
Servers are also advised to send the COPYUID response code in an Servers are also advised to send the COPYUID response code in an
untagged OK before sending EXPUNGE or moved responses. (Sending untagged OK before sending EXPUNGE or moved responses. (Sending
COPYUID in the tagged OK, as described in the UIDPLUS specification, COPYUID in the tagged OK, as described in the UIDPLUS specification,
means that clients first receive an EXPUNGE for a message and means that clients first receive an EXPUNGE for a message and
afterwards COPYUID for the same message. It can be unnecessarily afterwards COPYUID for the same message. It can be unnecessarily
difficult to process that sequence usefully.) difficult to process that sequence usefully.)
An example: An example:
C: a UID MOVE 42:69 foo C: a UID MOVE 42:69 foo
skipping to change at page 85, line 37 skipping to change at page 85, line 11
MOVE and UID MOVE can be pipelined with other commands, but care has MOVE and UID MOVE can be pipelined with other commands, but care has
to be taken. Both commands modify sequence numbers and also allow to be taken. Both commands modify sequence numbers and also allow
unrelated EXPUNGE responses. The renumbering of other messages in unrelated EXPUNGE responses. The renumbering of other messages in
the source mailbox following any EXPUNGE response can be surprising the source mailbox following any EXPUNGE response can be surprising
and makes it unsafe to pipeline any command that relies on message and makes it unsafe to pipeline any command that relies on message
sequence numbers after a MOVE or UID MOVE. Similarly, MOVE cannot be sequence numbers after a MOVE or UID MOVE. Similarly, MOVE cannot be
pipelined with a command that might cause message renumbering. See pipelined with a command that might cause message renumbering. See
Section 5.5, for more information about ambiguities as well as Section 5.5, for more information about ambiguities as well as
handling requirements for both clients and servers. handling requirements for both clients and servers.
6.4.10. UID Command 6.4.9. UID Command
Arguments: command name Arguments: command name
command arguments command arguments
Responses: untagged responses: FETCH, ESEARCH Responses: untagged responses: FETCH, ESEARCH, EXPUNGE
Result: OK - UID command completed Result: OK - UID command completed
NO - UID command error NO - UID command error
BAD - command unknown or arguments invalid BAD - command unknown or arguments invalid
The UID command has three forms. In the first form, it takes as its The UID command has three forms. In the first form, it takes as its
arguments a COPY, MOVE, FETCH, or STORE command with arguments arguments a COPY, MOVE, FETCH, or STORE command with arguments
appropriate for the associated command. However, the numbers in the appropriate for the associated command. However, the numbers in the
sequence set argument are unique identifiers instead of message sequence set argument are unique identifiers instead of message
sequence numbers. Sequence set ranges are permitted, but there is no sequence numbers. Sequence set ranges are permitted, but there is no
skipping to change at page 91, line 17 skipping to change at page 90, line 48
CANNOT CANNOT
The operation violates some invariant of the server and can The operation violates some invariant of the server and can
never succeed. never succeed.
C: l create "///////" C: l create "///////"
S: l NO [CANNOT] Adjacent slashes are not supported S: l NO [CANNOT] Adjacent slashes are not supported
CAPABILITY Followed by a list of capabilities. This can appear in CAPABILITY Followed by a list of capabilities. This can appear in
the initial OK or PREAUTH response to transmit an initial the initial OK or PREAUTH response to transmit an initial
capabilities list. This makes it unnecessary for a client to send capabilities list. It can also appear in tagged responses to
a separate CAPABILITY command if it recognizes this response. LOGIN or AUTHENTICATE commands. This makes it unnecessary for a
client to send a separate CAPABILITY command if it recognizes this
response.
CLIENTBUG CLIENTBUG
The server has detected a client bug. This can accompany all The server has detected a client bug. This can accompany all
of OK, NO, and BAD, depending on what the client bug is. of OK, NO, and BAD, depending on what the client bug is.
C: k1 select "/archive/projects/experiment-iv" C: k1 select "/archive/projects/experiment-iv"
[...] [...]
S: k1 OK [READ-ONLY] Done S: k1 OK [READ-ONLY] Done
C: k2 status "/archive/projects/experiment-iv" (messages) C: k2 status "/archive/projects/experiment-iv" (messages)
skipping to change at page 94, line 19 skipping to change at page 94, line 4
The user would be over quota after the operation. (The user The user would be over quota after the operation. (The user
may or may not be over quota already.) may or may not be over quota already.)
Note that if the server sends OVERQUOTA but doesn't support the Note that if the server sends OVERQUOTA but doesn't support the
IMAP QUOTA extension defined by [RFC2087], then there is a IMAP QUOTA extension defined by [RFC2087], then there is a
quota, but the client cannot find out what the quota is. quota, but the client cannot find out what the quota is.
C: n1 uid copy 1:* oldmail C: n1 uid copy 1:* oldmail
S: n1 NO [OVERQUOTA] Sorry S: n1 NO [OVERQUOTA] Sorry
C: n2 uid copy 1:* oldmail C: n2 uid copy 1:* oldmail
S: n2 OK [OVERQUOTA] You are now over your soft quota S: n2 OK [OVERQUOTA] You are now over your soft quota
PARSE The human-readable text represents an error in parsing the PARSE The human-readable text represents an error in parsing the
[RFC-5322] header or [MIME-IMB] headers of a message in the [RFC-5322] header or [MIME-IMB] headers of a message in the
mailbox. mailbox.
PERMANENTFLAGS Followed by a parenthesized list of flags, indicates PERMANENTFLAGS Followed by a parenthesized list of flags, indicates
which of the known flags the client can change permanently. Any which of the known flags the client can change permanently. Any
flags that are in the FLAGS untagged response, but not the flags that are in the FLAGS untagged response, but not the
PERMANENTFLAGS list, can not be set permanently. If the client PERMANENTFLAGS list, can not be set permanently. The
attempts to STORE a flag that is not in the PERMANENTFLAGS list, PERMANENTFLAGS list can also include the special flag \*, which
the server will either ignore the change or store the state change indicates that it is possible to create new keywords by attempting
for the remainder of the current session only. The PERMANENTFLAGS to store those keywords in the mailbox. If the client attempts to
list can also include the special flag \*, which indicates that it STORE a flag that is not in the PERMANENTFLAGS list, the server
is possible to create new keywords by attempting to store those will either ignore the change or store the state change for the
flags in the mailbox. remainder of the current session only.
There is no need for a server that included the special flag \* to
return a new PERMANENTFLAGS response code when a new keyword was
successfully set on a message upon client request. However 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 server MUST
send a new PERMANENTFLAGS response code without the 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 privacy. If
Transport Layer Security (TLS) is not in use, the client could Transport Layer Security (TLS) is not in use, the client could
try STARTTLS (see Section 6.2.1) and then repeat the operation. try STARTTLS (see Section 6.2.1) 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
skipping to change at page 103, line 15 skipping to change at page 103, line 4
7.2.5. NAMESPACE Response 7.2.5. NAMESPACE Response
Contents: the prefix and hierarchy delimiter to the server's Contents: the prefix and hierarchy delimiter to the server's
Personal Namespace(s), Other Users' Namespace(s), and Personal Namespace(s), Other Users' Namespace(s), and
Shared Namespace(s) Shared Namespace(s)
The NAMESPACE response occurs as a result of a NAMESPACE command. It The NAMESPACE response occurs as a result of a NAMESPACE command. It
contains the prefix and hierarchy delimiter to the server's Personal contains the prefix and hierarchy delimiter to the server's Personal
Namespace(s), Other Users' Namespace(s), and Shared Namespace(s) that Namespace(s), Other Users' Namespace(s), and Shared Namespace(s) that
the server wishes to expose. The response will contain a NIL for any the server wishes to expose. The response will contain a NIL for any
namespace class that is not available. Namespace_Response_Extensions namespace class that is not available. Namespace-Response-Extensions
MAY be included in the response. Namespace_Response_Extensions which ABNF non terminal is defined for extensibility and MAY be included in
are not on the IETF standards track, MUST be prefixed with an "X-". the response. Namespace-Response-Extensions which are not on the
IETF standards track, MUST be prefixed with an "X-".
Example: S: * NAMESPACE (("" "/")) (("~" "/")) NIL Example: S: * NAMESPACE (("" "/")) (("~" "/")) NIL
7.2.6. STATUS Response 7.2.6. STATUS Response
Contents: name Contents: name
status parenthesized list status parenthesized list
The STATUS response occurs as a result of an STATUS command. It The STATUS response occurs as a result of an STATUS command. It
returns the mailbox name that matches the STATUS specification and returns the mailbox name that matches the STATUS specification and
skipping to change at page 117, line 23 skipping to change at page 117, line 23
command-auth = append / create / delete / examine / list / lsub / command-auth = append / create / delete / examine / list / lsub /
Namespace-Command / Namespace-Command /
rename / select / status / subscribe / unsubscribe / rename / select / status / subscribe / unsubscribe /
idle idle
; Valid only in Authenticated or Selected state ; Valid only in Authenticated or Selected state
command-nonauth = login / authenticate / "STARTTLS" command-nonauth = login / authenticate / "STARTTLS"
; Valid only when in Not Authenticated state ; Valid only when in Not Authenticated state
command-select = "CHECK" / "CLOSE" / "UNSELECT" / "EXPUNGE" / copy / command-select = "CLOSE" / "UNSELECT" / "EXPUNGE" / copy /
move / fetch / store / search / uid move / fetch / store / search / uid
; Valid only when in Selected state ; Valid only when in Selected state
continue-req = "+" SP (resp-text / base64) CRLF continue-req = "+" SP (resp-text / base64) CRLF
copy = "COPY" SP sequence-set SP mailbox copy = "COPY" SP sequence-set SP mailbox
create = "CREATE" SP mailbox create = "CREATE" SP mailbox
; Use of INBOX gives a NO error ; Use of INBOX gives a NO error
skipping to change at page 121, line 38 skipping to change at page 121, line 38
"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
Namespace = nil / "(" 1*Namespace-Descr ")" Namespace = nil / "(" 1*Namespace-Descr ")"
Namespace-Command = "NAMESPACE" Namespace-Command = "NAMESPACE"
Namespace-Descr = "(" string SP Namespace-Descr = "(" string SP
(DQUOTE QUOTED-CHAR DQUOTE / nil) (DQUOTE QUOTED-CHAR DQUOTE / nil)
*(Namespace-Response-Extension) ")" [Namespace-Response-Extensions] ")"
Namespace-Response-Extensions = *(Namespace-Response-Extension)
Namespace-Response-Extension = SP string SP Namespace-Response-Extension = SP string SP
"(" string *(SP string) ")" "(" string *(SP string) ")"
Namespace-Response = "NAMESPACE" SP Namespace Namespace-Response = "NAMESPACE" SP Namespace
SP Namespace SP Namespace SP Namespace SP Namespace
; The first Namespace is the Personal Namespace(s) ; The first Namespace is the Personal Namespace(s)
; The second Namespace is the Other Users' Namespace(s) ; The second Namespace is the Other Users' Namespace(s)
; The third Namespace is the Shared Namespace(s) ; The third Namespace is the Shared Namespace(s)
skipping to change at page 129, line 15 skipping to change at page 129, line 19
11.2. COPYUID and APPENDUID response codes 11.2. COPYUID and APPENDUID response codes
The COPYUID and APPENDUID response codes return information about the The COPYUID and APPENDUID response codes return information about the
mailbox, which may be considered sensitive if the mailbox has mailbox, which may be considered sensitive if the mailbox has
permissions set that permit the client to COPY or APPEND to the permissions set that permit the client to COPY or APPEND to the
mailbox, but not SELECT or EXAMINE it. mailbox, but not SELECT or EXAMINE it.
Consequently, these response codes SHOULD NOT be issued if the client Consequently, these response codes SHOULD NOT be issued if the client
does not have access to SELECT or EXAMINE the mailbox. does not have access to SELECT or EXAMINE the mailbox.
11.3. Other Security Considerations 11.3. LIST command and Other Users' namespace
In response to a LIST command containing an argument of the Other
Users' Namespace prefix, a server SHOULD NOT list users that have not
granted list access to their personal mailboxes to the currently
authenticated user. Providing such a list, could compromise security
by potentially disclosing confidential information of who is located
on the server, or providing a starting point of a list of user
accounts to attack.
11.4. Other Security Considerations
A server error message for an AUTHENTICATE command which fails due to A server error message for an AUTHENTICATE command which fails due to
invalid credentials SHOULD NOT detail why the credentials are invalid credentials SHOULD NOT detail why the credentials are
invalid. invalid.
Use of the LOGIN command sends passwords in the clear. This can be Use of the LOGIN command sends passwords in the clear. This can be
avoided by using the AUTHENTICATE command with a [SASL] mechanism avoided by using the AUTHENTICATE command with a [SASL] mechanism
that does not use plaintext passwords, by first negotiating that does not use plaintext passwords, by first negotiating
encryption via STARTTLS or some other protection mechanism. encryption via STARTTLS or some other protection mechanism.
skipping to change at page 131, line 14 skipping to change at page 131, line 32
[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>. <http://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>. <http://www.rfc-editor.org/info/rfc2978>.
[DIGEST-MD5] [SCRAM-SHA-256]
Leach, P. and C. Newman, "Using Digest Authentication as a Hansen, T., "SCRAM-SHA-256 and SCRAM-SHA-256-PLUS Simple
SASL Mechanism", RFC 2831, May 2000, Authentication and Security Layer (SASL) Mechanisms",
<http://www.rfc-editor.org/info/rfc2831>. RFC 7677, DOI 10.17487/RFC7677, November 2015,
<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>. <http://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>. <http://www.rfc-editor.org/info/rfc4616>.
skipping to change at page 133, line 5 skipping to change at page 133, line 22
[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, <http://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>. <http://www.rfc-editor.org/info/rfc3502>.
[IMAP-IMPLEMENTATION]
Leiba, B., "IMAP4 Implementation Recommendations",
RFC 2683, September 1999,
<http://www.rfc-editor.org/info/rfc2683>.
[IMAP-MULTIACCESS]
Gahrns, M., "IMAP4 Multi-Accessed Mailbox Practice",
RFC 2180, July 1997,
<http://www.rfc-editor.org/info/rfc2180>.
[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>.
[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>.
[RFC7888] Melnikov, A., Ed., "IMAP4 Non-synchronizing Literals", [RFC8098] Hansen, T., Ed. and A. Melnikov, Ed., "Message Disposition
RFC 7888, DOI 10.17487/RFC7888, May 2016, Notification", STD 85, RFC 8098, DOI 10.17487/RFC8098,
<https://www.rfc-editor.org/info/rfc7888>. 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]
Leiba, B., "IMAP4 Implementation Recommendations",
RFC 2683, September 1999,
<http://www.rfc-editor.org/info/rfc2683>.
[IMAP-MULTIACCESS]
Gahrns, M., "IMAP4 Multi-Accessed Mailbox Practice",
RFC 2180, July 1997,
<http://www.rfc-editor.org/info/rfc2180>.
13.2. Informative References (related protocols) 13.2. Informative References (related protocols)
[RFC5258] Leiba, B. and A. Melnikov, "Internet Message Access [RFC5258] Leiba, B. and A. Melnikov, "Internet Message Access
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>.
[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,
<https://www.rfc-editor.org/info/rfc2193>. <https://www.rfc-editor.org/info/rfc2193>.
[RFC3348] Gahrns, M. and R. Cheng, "The Internet Message Action [RFC3348] Gahrns, M. and R. Cheng, "The Internet Message Action
Protocol (IMAP4) Child Mailbox Extension", RFC 3348, Protocol (IMAP4) Child Mailbox Extension", RFC 3348,
DOI 10.17487/RFC3348, July 2002, DOI 10.17487/RFC3348, July 2002,
<https://www.rfc-editor.org/info/rfc3348>. <https://www.rfc-editor.org/info/rfc3348>.
[RFC7888] Melnikov, A., Ed., "IMAP4 Non-synchronizing Literals",
RFC 7888, DOI 10.17487/RFC7888, May 2016,
<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>. <http://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>. <http://www.rfc-editor.org/info/rfc5255>.
skipping to change at page 134, line 31 skipping to change at page 135, line 10
[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>. <http://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, <http://www.rfc-editor.org/info/rfc6855>.
[ACAP] Newman, C. and J. G. Myers, "ACAP -- Application
Configuration Access Protocol", RFC 2244, November 1997,
<http://www.rfc-editor.org/info/rfc2244>.
[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, <http://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>. <http://www.rfc-editor.org/info/rfc4314>.
skipping to change at page 139, line 36 skipping to change at page 140, line 10
9. Mailbox names and message headers now allow for UTF-8. Support 9. 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.
10. UNSEEN response code on SELECT/EXAMINE is now deprecated. 10. UNSEEN response code on SELECT/EXAMINE is now deprecated.
11. RECENT response on SELECT/EXAMINE, \Recent flag, RECENT STATUS 11. RECENT response on SELECT/EXAMINE, \Recent flag, RECENT STATUS
item are now deprecated. item are now deprecated.
12. Clarified that the server doesn't need to send a new
PERMANENTFLAGS response code when a new keyword was successfully
added and the server advertised \* earlier for the same mailbox.
13. Removed the CHECK command. Clients should use NOOP instead.
14. Replaced DIGEST-MD5 SASL mechanism with SCRAM-SHA-256. DIGEST-
MD5 was deprecated.
Appendix D. Acknowledgement Appendix D. 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 for extensive feedback.
This document incorporate text from RFC 4315, RFC 4466, RFC 4731, RFC This document incorporate text from RFC 4315, RFC 4466, RFC 4731, RFC
5161, RFC 6154 so work done by authors/editors of these documents is 5161, RFC 6154 so work done by authors/editors of these documents is
appreciated. appreciated.
Index Index
$ $
$Forwarded (predefined flag) 12 $Forwarded (predefined flag) 12
$MDNSent (predefined flag) 12 $MDNSent (predefined flag) 12
+ +
+FLAGS <flag list> 82 +FLAGS <flag list> 81
+FLAGS.SILENT <flag list> 82 +FLAGS.SILENT <flag list> 81
- -
-FLAGS <flag list> 82 -FLAGS <flag list> 82
-FLAGS.SILENT <flag list> 82 -FLAGS.SILENT <flag list> 82
A A
ALERT (response code) 89 ALERT (response code) 89
ALL (fetch item) 77 ALL (fetch item) 77
ALL (search key) 74 ALL (search key) 73
ALL (search result option) 73 ALL (search result option) 72
ALREADYEXISTS (response code) 89 ALREADYEXISTS (response code) 89
ANSWERED (search key) 74 ANSWERED (search key) 73
APPEND (command) 65 APPEND (command) 65
APPENDUID (response code) 89 APPENDUID (response code) 89
AUTHENTICATE (command) 27 AUTHENTICATE (command) 28
AUTHENTICATIONFAILED (response code) 90 AUTHENTICATIONFAILED (response code) 90
AUTHORIZATIONFAILED (response code) 90 AUTHORIZATIONFAILED (response code) 90
B B
BAD (response) 97 BAD (response) 97
BADCHARSET (response code) 90 BADCHARSET (response code) 90
BCC <string> (search key) 74 BCC <string> (search key) 73
BEFORE <date> (search key) 74 BEFORE <date> (search key) 73
BINARY.PEEK[<section-binary>]<<partial>> (fetch item) 78 BINARY.PEEK[<section-binary>]<<partial>> (fetch item) 78
BINARY.SIZE[<section-binary>] (fetch item) 78 BINARY.SIZE[<section-binary>] (fetch item) 78
BINARY.SIZE[<section-binary>] (fetch result) 106 BINARY.SIZE[<section-binary>] (fetch result) 106
BINARY[<section-binary>]<<number>> (fetch result) 106 BINARY[<section-binary>]<<number>> (fetch result) 105
BINARY[<section-binary>]<<partial>> (fetch item) 78 BINARY[<section-binary>]<<partial>> (fetch item) 77
BODY (fetch item) 78 BODY (fetch item) 78
BODY (fetch result) 106 BODY (fetch result) 106
BODY <string> (search key) 74 BODY <string> (search key) 74
BODY.PEEK[<section>]<<partial>> (fetch item) 80 BODY.PEEK[<section>]<<partial>> (fetch item) 80
BODYSTRUCTURE (fetch item) 81 BODYSTRUCTURE (fetch item) 80
BODYSTRUCTURE (fetch result) 107 BODYSTRUCTURE (fetch result) 107
BODY[<section>]<<origin octet>> (fetch result) 106 BODY[<section>]<<origin octet>> (fetch result) 106
BODY[<section>]<<partial>> (fetch item) 78 BODY[<section>]<<partial>> (fetch item) 78
BYE (response) 97 BYE (response) 97
Body Structure (message attribute) 13 Body Structure (message attribute) 13
C C
CANNOT (response code) 91 CANNOT (response code) 90
CAPABILITY (command) 24 CAPABILITY (command) 24
CAPABILITY (response code) 91 CAPABILITY (response code) 90
CAPABILITY (response) 98 CAPABILITY (response) 98
CC <string> (search key) 74 CC <string> (search key) 74
CHECK (command) 70
CLIENTBUG (response code) 91 CLIENTBUG (response code) 91
CLOSE (command) 70 CLOSE (command) 69
CLOSED (response code) 91 CLOSED (response code) 91
CONTACTADMIN (response code) 92 CONTACTADMIN (response code) 91
COPY (command) 82 COPY (command) 82
COPYUID (response code) 92 COPYUID (response code) 91
CORRUPTION (response code) 92 CORRUPTION (response code) 92
COUNT (search result option) 73 COUNT (search result option) 72
CREATE (command) 35 CREATE (command) 36
D D
DELETE (command) 36 DELETE (command) 37
DELETED (search key) 74 DELETED (search key) 74
DRAFT (search key) 74 DRAFT (search key) 74
E E
ENABLE (command) 31 ENABLE (command) 32
ENVELOPE (fetch item) 81 ENVELOPE (fetch item) 80
ENVELOPE (fetch result) 110 ENVELOPE (fetch result) 109
ESEARCH (response) 103 ESEARCH (response) 103
EXAMINE (command) 35 EXAMINE (command) 35
EXPIRED (response code) 92 EXPIRED (response code) 92
EXPUNGE (command) 71 EXPUNGE (command) 70
EXPUNGE (response) 105 EXPUNGE (response) 104
EXPUNGEISSUED (response code) 93 EXPUNGEISSUED (response code) 92
Envelope Structure (message attribute) 13 Envelope Structure (message attribute) 13
F F
FAST (fetch item) 77 FAST (fetch item) 77
FETCH (command) 77 FETCH (command) 77
FETCH (response) 105 FETCH (response) 105
FLAGGED (search key) 74 FLAGGED (search key) 74
FLAGS (fetch item) 81 FLAGS (fetch item) 80
FLAGS (fetch result) 111 FLAGS (fetch result) 111
FLAGS (response) 104 FLAGS (response) 104
FLAGS <flag list> (store command data item) 82 FLAGS <flag list> (store command data item) 81
FLAGS.SILENT <flag list> (store command data item) 82 FLAGS.SILENT <flag list> (store command data item) 81
FROM <string> (search key) 74 FROM <string> (search key) 74
FULL (fetch item) 78 FULL (fetch item) 77
Flags (message attribute) 11 Flags (message attribute) 11
H H
HEADER (part specifier) 79 HEADER (part specifier) 78
HEADER <field-name> <string> (search key) 74 HEADER <field-name> <string> (search key) 74
HEADER.FIELDS (part specifier) 79 HEADER.FIELDS (part specifier) 78
HEADER.FIELDS.NOT (part specifier) 79 HEADER.FIELDS.NOT (part specifier) 78
I I
IDLE (command) 67 IDLE (command) 67
INTERNALDATE (fetch item) 81 INTERNALDATE (fetch item) 80
INTERNALDATE (fetch result) 111 INTERNALDATE (fetch result) 111
INUSE (response code) 93 INUSE (response code) 92
Internal Date (message attribute) 12 Internal Date (message attribute) 12
K K
KEYWORD <flag> (search key) 75 KEYWORD <flag> (search key) 74
Keyword (type of flag) 12 Keyword (type of flag) 12
L L
LARGER <n> (search key) 75 LARGER <n> (search key) 74
LIMIT (response code) 93 LIMIT (response code) 93
LIST (command) 41 LIST (command) 41
LIST (response) 99 LIST (response) 99
LOGOUT (command) 25 LOGOUT (command) 26
LSUB (command) 58 LSUB (command) 58
LSUB (response) 102 LSUB (response) 102
M M
MAX (search result option) 72 MAX (search result option) 72
MAY (specification requirement term) 5 MAY (specification requirement term) 5
MESSAGES (status item) 64 MESSAGES (status item) 64
MIME (part specifier) 79 MIME (part specifier) 79
MIN (search result option) 72 MIN (search result option) 72
MOVE (command) 83 MOVE (command) 83
MUST (specification requirement term) 5 MUST (specification requirement term) 5
MUST NOT (specification requirement term) 5 MUST NOT (specification requirement term) 5
Message Sequence Number (message attribute) 11 Message Sequence Number (message attribute) 11
N N
NAMESPACE (command) 59 NAMESPACE (command) 59
NAMESPACE (response) 103 NAMESPACE (response) 102
NEW (search key) 75 NEW (search key) 74
NO (response) 96 NO (response) 96
NONEXISTENT (response code) 93 NONEXISTENT (response code) 93
NOOP (command) 25 NOOP (command) 25
NOPERM (response code) 93 NOPERM (response code) 93
NOT <search-key> (search key) 75 NOT <search-key> (search key) 74
NOT RECOMMENDED (specification requirement term) 5 NOT RECOMMENDED (specification requirement term) 5
O O
OK (response) 96 OK (response) 96
ON <date> (search key) 75 ON <date> (search key) 74
OPTIONAL (specification requirement term) 5 OPTIONAL (specification requirement term) 5
OR <search-key1> <search-key2> (search key) 75 OR <search-key1> <search-key2> (search key) 74
OVERQUOTA (response code) 94 OVERQUOTA (response code) 93
P P
PARSE (response code) 94 PARSE (response code) 94
PERMANENTFLAGS (response code) 94 PERMANENTFLAGS (response code) 94
PREAUTH (response) 97 PREAUTH (response) 97
PRIVACYREQUIRED (response code) 94 PRIVACYREQUIRED (response code) 94
Permanent Flag (class of flag) 12 Permanent Flag (class of flag) 12
Predefined keywords 12 Predefined keywords 12
R R
READ-ONLY (response code) 95 READ-ONLY (response code) 94
READ-WRITE (response code) 95 READ-WRITE (response code) 94
RECOMMENDED (specification requirement term) 5 RECOMMENDED (specification requirement term) 5
RENAME (command) 38 RENAME (command) 38
REQUIRED (specification requirement term) 5 REQUIRED (specification requirement term) 5
RFC822 (fetch item) 81 RFC822 (fetch item) 80
RFC822 (fetch result) 111 RFC822 (fetch result) 111
RFC822.HEADER (fetch item) 81 RFC822.HEADER (fetch item) 80
RFC822.HEADER (fetch result) 111 RFC822.HEADER (fetch result) 111
RFC822.SIZE (fetch item) 81 RFC822.SIZE (fetch item) 80
RFC822.SIZE (fetch result) 111 RFC822.SIZE (fetch result) 111
RFC822.TEXT (fetch item) 81 RFC822.TEXT (fetch item) 80
RFC822.TEXT (fetch result) 111 RFC822.TEXT (fetch result) 111
S S
SEARCH (command) 72 SEARCH (command) 71
SEEN (search key) 75 SEEN (search key) 74
SELECT (command) 33 SELECT (command) 34
SENTBEFORE <date> (search key) 75 SENTBEFORE <date> (search key) 74
SENTON <date> (search key) 75 SENTON <date> (search key) 74
SENTSINCE <date> (search key) 75 SENTSINCE <date> (search key) 75
SERVERBUG (response code) 95 SERVERBUG (response code) 94
SHOULD (specification requirement term) 5 SHOULD (specification requirement term) 5
SHOULD NOT (specification requirement term) 5 SHOULD NOT (specification requirement term) 5
SINCE <date> (search key) 75 SINCE <date> (search key) 75
SIZE (status item) 65 SIZE (status item) 65
SMALLER <n> (search key) 75 SMALLER <n> (search key) 75
STARTTLS (command) 26 STARTTLS (command) 27
STATUS (command) 63 STATUS (command) 63
STATUS (response) 103 STATUS (response) 103
STORE (command) 81 STORE (command) 81
SUBJECT <string> (search key) 75 SUBJECT <string> (search key) 75
SUBSCRIBE (command) 40 SUBSCRIBE (command) 40
Session Flag (class of flag) 12 Session Flag (class of flag) 12
System Flag (type of flag) 11 System Flag (type of flag) 11
T T
TEXT (part specifier) 79 TEXT (part specifier) 78
TEXT <string> (search key) 75 TEXT <string> (search key) 75
TO <string> (search key) 75 TO <string> (search key) 75
TRYCREATE (response code) 95 TRYCREATE (response code) 95
U U
UID (command) 85 UID (command) 85
UID (fetch item) 81 UID (fetch item) 80
UID (fetch result) 111 UID (fetch result) 111
UID <sequence set> (search key) 76 UID <sequence set> (search key) 75
UIDNEXT (response code) 95 UIDNEXT (response code) 95
UIDNEXT (status item) 64 UIDNEXT (status item) 64
UIDNOTSTICKY (response code) 95 UIDNOTSTICKY (response code) 95
UIDVALIDITY (response code) 95 UIDVALIDITY (response code) 95
UIDVALIDITY (status item) 64 UIDVALIDITY (status item) 64
UNANSWERED (search key) 76 UNANSWERED (search key) 75
UNAVAILABLE (response code) 95 UNAVAILABLE (response code) 95
UNDELETED (search key) 76 UNDELETED (search key) 75
UNDRAFT (search key) 76 UNDRAFT (search key) 75
UNFLAGGED (search key) 76 UNFLAGGED (search key) 75
UNKEYWORD <flag> (search key) 76 UNKEYWORD <flag> (search key) 75
UNKNOWN-CTE (response code) 96 UNKNOWN-CTE (response code) 95
UNSEEN (search key) 76 UNSEEN (search key) 75
UNSEEN (status item) 64 UNSEEN (status item) 64
UNSELECT (command) 71 UNSELECT (command) 70
UNSUBSCRIBE (command) 41 UNSUBSCRIBE (command) 41
Unique Identifier (UID) (message attribute) 9 Unique Identifier (UID) (message attribute) 9
X X
X<atom> (command) 87 X<atom> (command) 87
[ [
[RFC-5322] Size (message attribute) 13 [RFC-5322] Size (message attribute) 13
\ \
 End of changes. 110 change blocks. 
217 lines changed or deleted 245 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/