< draft-ietf-extra-imap4rev2-28.txt		draft-ietf-extra-imap4rev2-29.txt >
	Network Working Group A. Melnikov, Ed.		Network Working Group A. Melnikov, Ed.
	Internet-Draft Isode Ltd		Internet-Draft Isode Ltd
	Obsoletes: 3501 (if approved) B. Leiba, Ed.		Obsoletes: 3501 (if approved) B. Leiba, Ed.
	Intended status: Standards Track Futurewei Technologies		Intended status: Standards Track Futurewei Technologies
	Expires: August 14, 2021 February 10, 2021		Expires: August 17, 2021 February 13, 2021
	Internet Message Access Protocol (IMAP) - Version 4rev2		Internet Message Access Protocol (IMAP) - Version 4rev2
	draft-ietf-extra-imap4rev2-28		draft-ietf-extra-imap4rev2-29
	Abstract		Abstract
	The Internet Message Access Protocol, Version 4rev2 (IMAP4rev2)		The Internet Message Access Protocol, Version 4rev2 (IMAP4rev2)
	allows a client to access and manipulate electronic mail messages on		allows a client to access and manipulate electronic mail messages on
	a server. IMAP4rev2 permits manipulation of mailboxes (remote		a server. IMAP4rev2 permits manipulation of mailboxes (remote
	message folders) in a way that is functionally equivalent to local		message folders) in a way that is functionally equivalent to local
	folders. IMAP4rev2 also provides the capability for an offline		folders. IMAP4rev2 also provides the capability for an offline
	client to resynchronize with the server.		client to resynchronize with the server.
	skipping to change at page 1, line 48 ¶		skipping to change at page 1, line 48 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at https://datatracker.ietf.org/drafts/current/.		Drafts is at https://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on August 14, 2021.		This Internet-Draft will expire on August 17, 2021.
	Copyright Notice		Copyright Notice
	Copyright (c) 2021 IETF Trust and the persons identified as the		Copyright (c) 2021 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(https://trustee.ietf.org/license-info) in effect on the date of		(https://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	skipping to change at page 2, line 41 ¶		skipping to change at page 2, line 41 ¶
	Table of Contents		Table of Contents
	1. How to Read This Document . . . . . . . . . . . . . . . . . . 5		1. How to Read This Document . . . . . . . . . . . . . . . . . . 5
	1.1. Organization of This Document . . . . . . . . . . . . . . 5		1.1. Organization of This Document . . . . . . . . . . . . . . 5
	1.2. Conventions Used in This Document . . . . . . . . . . . . 5		1.2. Conventions Used in This Document . . . . . . . . . . . . 5
	1.3. Special Notes to Implementors . . . . . . . . . . . . . . 6		1.3. Special Notes to Implementors . . . . . . . . . . . . . . 6
	2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 7		2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 7
	2.1. Link Level . . . . . . . . . . . . . . . . . . . . . . . 7		2.1. Link Level . . . . . . . . . . . . . . . . . . . . . . . 7
	2.2. Commands and Responses . . . . . . . . . . . . . . . . . 7		2.2. Commands and Responses . . . . . . . . . . . . . . . . . 7
	2.2.1. Client Protocol Sender and Server Protocol Receiver . 7		2.2.1. Client Protocol Sender and Server Protocol Receiver . 8
	2.2.2. Server Protocol Sender and Client Protocol Receiver . 8		2.2.2. Server Protocol Sender and Client Protocol Receiver . 8
	2.3. Message Attributes . . . . . . . . . . . . . . . . . . . 9		2.3. Message Attributes . . . . . . . . . . . . . . . . . . . 9
	2.3.1. Message Numbers . . . . . . . . . . . . . . . . . . . 9		2.3.1. Message Numbers . . . . . . . . . . . . . . . . . . . 9
	2.3.2. Flags Message Attribute . . . . . . . . . . . . . . . 12		2.3.2. Flags Message Attribute . . . . . . . . . . . . . . . 12
	2.3.3. Internal Date Message Attribute . . . . . . . . . . . 14		2.3.3. Internal Date Message Attribute . . . . . . . . . . . 14
	2.3.4. [RFC-5322] Size Message Attribute . . . . . . . . . . 14		2.3.4. [RFC-5322] Size Message Attribute . . . . . . . . . . 14
	2.3.5. Envelope Structure Message Attribute . . . . . . . . 14		2.3.5. Envelope Structure Message Attribute . . . . . . . . 14
	2.3.6. Body Structure Message Attribute . . . . . . . . . . 14		2.3.6. Body Structure Message Attribute . . . . . . . . . . 14
	2.4. Message Texts . . . . . . . . . . . . . . . . . . . . . . 14		2.4. Message Texts . . . . . . . . . . . . . . . . . . . . . . 15
	3. State and Flow Diagram . . . . . . . . . . . . . . . . . . . 14		3. State and Flow Diagram . . . . . . . . . . . . . . . . . . . 15
	3.1. Not Authenticated State . . . . . . . . . . . . . . . . . 15		3.1. Not Authenticated State . . . . . . . . . . . . . . . . . 15
	3.2. Authenticated State . . . . . . . . . . . . . . . . . . . 15		3.2. Authenticated State . . . . . . . . . . . . . . . . . . . 15
	3.3. Selected State . . . . . . . . . . . . . . . . . . . . . 15		3.3. Selected State . . . . . . . . . . . . . . . . . . . . . 15
	3.4. Logout State . . . . . . . . . . . . . . . . . . . . . . 15		3.4. Logout State . . . . . . . . . . . . . . . . . . . . . . 15
	4. Data Formats . . . . . . . . . . . . . . . . . . . . . . . . 17		4. Data Formats . . . . . . . . . . . . . . . . . . . . . . . . 18
	4.1. Atom . . . . . . . . . . . . . . . . . . . . . . . . . . 17		4.1. Atom . . . . . . . . . . . . . . . . . . . . . . . . . . 18
	4.1.1. Sequence set and UID set . . . . . . . . . . . . . . 17		4.1.1. Sequence set and UID set . . . . . . . . . . . . . . 18
	4.2. Number . . . . . . . . . . . . . . . . . . . . . . . . . 17		4.2. Number . . . . . . . . . . . . . . . . . . . . . . . . . 18
	4.3. String . . . . . . . . . . . . . . . . . . . . . . . . . 17		4.3. String . . . . . . . . . . . . . . . . . . . . . . . . . 18
	4.3.1. 8-bit and Binary Strings . . . . . . . . . . . . . . 18		4.3.1. 8-bit and Binary Strings . . . . . . . . . . . . . . 19
	4.4. Parenthesized List . . . . . . . . . . . . . . . . . . . 19		4.4. Parenthesized List . . . . . . . . . . . . . . . . . . . 20
	4.5. NIL . . . . . . . . . . . . . . . . . . . . . . . . . . . 19		4.5. NIL . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
	5. Operational Considerations . . . . . . . . . . . . . . . . . 20		5. Operational Considerations . . . . . . . . . . . . . . . . . 21
	5.1. Mailbox Naming . . . . . . . . . . . . . . . . . . . . . 20		5.1. Mailbox Naming . . . . . . . . . . . . . . . . . . . . . 21
	5.1.1. Mailbox Hierarchy Naming . . . . . . . . . . . . . . 21		5.1.1. Mailbox Hierarchy Naming . . . . . . . . . . . . . . 22
	5.1.2. Namespaces . . . . . . . . . . . . . . . . . . . . . 21		5.1.2. Namespaces . . . . . . . . . . . . . . . . . . . . . 22
	5.2. Mailbox Size and Message Status Updates . . . . . . . . . 23		5.2. Mailbox Size and Message Status Updates . . . . . . . . . 24
	5.3. Response when no Command in Progress . . . . . . . . . . 23		5.3. Response when no Command in Progress . . . . . . . . . . 24
	5.4. Autologout Timer . . . . . . . . . . . . . . . . . . . . 23		5.4. Autologout Timer . . . . . . . . . . . . . . . . . . . . 24
	5.5. Multiple Commands in Progress (Command Pipelining) . . . 24		5.5. Multiple Commands in Progress (Command Pipelining) . . . 25
	6. Client Commands . . . . . . . . . . . . . . . . . . . . . . . 25		6. Client Commands . . . . . . . . . . . . . . . . . . . . . . . 26
	6.1. Client Commands - Any State . . . . . . . . . . . . . . . 26		6.1. Client Commands - Any State . . . . . . . . . . . . . . . 27
	6.1.1. CAPABILITY Command . . . . . . . . . . . . . . . . . 26		6.1.1. CAPABILITY Command . . . . . . . . . . . . . . . . . 27
	6.1.2. NOOP Command . . . . . . . . . . . . . . . . . . . . 27		6.1.2. NOOP Command . . . . . . . . . . . . . . . . . . . . 28
	6.1.3. LOGOUT Command . . . . . . . . . . . . . . . . . . . 27		6.1.3. LOGOUT Command . . . . . . . . . . . . . . . . . . . 28
	6.2. Client Commands - Not Authenticated State . . . . . . . . 28		6.2. Client Commands - Not Authenticated State . . . . . . . . 29
	6.2.1. STARTTLS Command . . . . . . . . . . . . . . . . . . 28		6.2.1. STARTTLS Command . . . . . . . . . . . . . . . . . . 29
	6.2.2. AUTHENTICATE Command . . . . . . . . . . . . . . . . 30		6.2.2. AUTHENTICATE Command . . . . . . . . . . . . . . . . 31
	6.2.3. LOGIN Command . . . . . . . . . . . . . . . . . . . . 33		6.2.3. LOGIN Command . . . . . . . . . . . . . . . . . . . . 35
	6.3. Client Commands - Authenticated State . . . . . . . . . . 34		6.3. Client Commands - Authenticated State . . . . . . . . . . 35
	6.3.1. ENABLE Command . . . . . . . . . . . . . . . . . . . 34		6.3.1. ENABLE Command . . . . . . . . . . . . . . . . . . . 36
	6.3.2. SELECT Command . . . . . . . . . . . . . . . . . . . 36		6.3.2. SELECT Command . . . . . . . . . . . . . . . . . . . 38
	6.3.3. EXAMINE Command . . . . . . . . . . . . . . . . . . . 38		6.3.3. EXAMINE Command . . . . . . . . . . . . . . . . . . . 40
	6.3.4. CREATE Command . . . . . . . . . . . . . . . . . . . 39		6.3.4. CREATE Command . . . . . . . . . . . . . . . . . . . 41
	6.3.5. DELETE Command . . . . . . . . . . . . . . . . . . . 40		6.3.5. DELETE Command . . . . . . . . . . . . . . . . . . . 42
	6.3.6. RENAME Command . . . . . . . . . . . . . . . . . . . 42		6.3.6. RENAME Command . . . . . . . . . . . . . . . . . . . 44
	6.3.7. SUBSCRIBE Command . . . . . . . . . . . . . . . . . . 45		6.3.7. SUBSCRIBE Command . . . . . . . . . . . . . . . . . . 47
	6.3.8. UNSUBSCRIBE Command . . . . . . . . . . . . . . . . . 45		6.3.8. UNSUBSCRIBE Command . . . . . . . . . . . . . . . . . 47
	6.3.9. LIST Command . . . . . . . . . . . . . . . . . . . . 46		6.3.9. LIST Command . . . . . . . . . . . . . . . . . . . . 48
	6.3.10. NAMESPACE Command . . . . . . . . . . . . . . . . . . 64		6.3.10. NAMESPACE Command . . . . . . . . . . . . . . . . . . 66
	6.3.11. STATUS Command . . . . . . . . . . . . . . . . . . . 68		6.3.11. STATUS Command . . . . . . . . . . . . . . . . . . . 71
	6.3.12. APPEND Command . . . . . . . . . . . . . . . . . . . 69		6.3.12. APPEND Command . . . . . . . . . . . . . . . . . . . 73
	6.3.13. IDLE Command . . . . . . . . . . . . . . . . . . . . 72		6.3.13. IDLE Command . . . . . . . . . . . . . . . . . . . . 76
	6.4. Client Commands - Selected State . . . . . . . . . . . . 74		6.4. Client Commands - Selected State . . . . . . . . . . . . 77
	6.4.1. CLOSE Command . . . . . . . . . . . . . . . . . . . . 75		6.4.1. CLOSE Command . . . . . . . . . . . . . . . . . . . . 78
	6.4.2. UNSELECT Command . . . . . . . . . . . . . . . . . . 75		6.4.2. UNSELECT Command . . . . . . . . . . . . . . . . . . 78
	6.4.3. EXPUNGE Command . . . . . . . . . . . . . . . . . . . 76		6.4.3. EXPUNGE Command . . . . . . . . . . . . . . . . . . . 79
	6.4.4. SEARCH Command . . . . . . . . . . . . . . . . . . . 76		6.4.4. SEARCH Command . . . . . . . . . . . . . . . . . . . 79
	6.4.5. FETCH Command . . . . . . . . . . . . . . . . . . . . 88		6.4.5. FETCH Command . . . . . . . . . . . . . . . . . . . . 92
	6.4.6. STORE Command . . . . . . . . . . . . . . . . . . . . 93		6.4.6. STORE Command . . . . . . . . . . . . . . . . . . . . 97
	6.4.7. COPY Command . . . . . . . . . . . . . . . . . . . . 94		6.4.7. COPY Command . . . . . . . . . . . . . . . . . . . . 98
	6.4.8. MOVE Command . . . . . . . . . . . . . . . . . . . . 95		6.4.8. MOVE Command . . . . . . . . . . . . . . . . . . . . 99
	6.4.9. UID Command . . . . . . . . . . . . . . . . . . . . . 97		6.4.9. UID Command . . . . . . . . . . . . . . . . . . . . . 101
	6.5. Client Commands - Experimental/Expansion . . . . . . . . 99		6.5. Client Commands - Experimental/Expansion . . . . . . . . 103
	7. Server Responses . . . . . . . . . . . . . . . . . . . . . . 99		7. Server Responses . . . . . . . . . . . . . . . . . . . . . . 103
	7.1. Server Responses - Generic Status Responses . . . . . . . 100		7.1. Server Responses - Generic Status Responses . . . . . . . 104
	7.1.1. OK Response . . . . . . . . . . . . . . . . . . . . . 109		7.1.1. OK Response . . . . . . . . . . . . . . . . . . . . . 113
	7.1.2. NO Response . . . . . . . . . . . . . . . . . . . . . 109		7.1.2. NO Response . . . . . . . . . . . . . . . . . . . . . 113
	7.1.3. BAD Response . . . . . . . . . . . . . . . . . . . . 109		7.1.3. BAD Response . . . . . . . . . . . . . . . . . . . . 113
	7.1.4. PREAUTH Response . . . . . . . . . . . . . . . . . . 110		7.1.4. PREAUTH Response . . . . . . . . . . . . . . . . . . 114
	7.1.5. BYE Response . . . . . . . . . . . . . . . . . . . . 110		7.1.5. BYE Response . . . . . . . . . . . . . . . . . . . . 114
	7.2. Server Responses - Server Status . . . . . . . . . . . . 111		7.2. Server Responses - Server Status . . . . . . . . . . . . 115
	7.2.1. ENABLED Response . . . . . . . . . . . . . . . . . . 111		7.2.1. ENABLED Response . . . . . . . . . . . . . . . . . . 115
	7.2.2. CAPABILITY Response . . . . . . . . . . . . . . . . . 111		7.2.2. CAPABILITY Response . . . . . . . . . . . . . . . . . 115
	7.3. Server Responses - Mailbox Status . . . . . . . . . . . . 113		7.3. Server Responses - Mailbox Status . . . . . . . . . . . . 117
	7.3.1. LIST Response . . . . . . . . . . . . . . . . . . . . 113		7.3.1. LIST Response . . . . . . . . . . . . . . . . . . . . 117
	7.3.2. NAMESPACE Response . . . . . . . . . . . . . . . . . 117		7.3.2. NAMESPACE Response . . . . . . . . . . . . . . . . . 121
	7.3.3. STATUS Response . . . . . . . . . . . . . . . . . . . 117		7.3.3. STATUS Response . . . . . . . . . . . . . . . . . . . 121
	7.3.4. ESEARCH Response . . . . . . . . . . . . . . . . . . 117		7.3.4. ESEARCH Response . . . . . . . . . . . . . . . . . . 121
	7.3.5. FLAGS Response . . . . . . . . . . . . . . . . . . . 119		7.3.5. FLAGS Response . . . . . . . . . . . . . . . . . . . 123
	7.4. Server Responses - Mailbox Size . . . . . . . . . . . . . 119		7.4. Server Responses - Mailbox Size . . . . . . . . . . . . . 123
	7.4.1. EXISTS Response . . . . . . . . . . . . . . . . . . . 119		7.4.1. EXISTS Response . . . . . . . . . . . . . . . . . . . 123
	7.5. Server Responses - Message Status . . . . . . . . . . . . 119		7.5. Server Responses - Message Status . . . . . . . . . . . . 123
	7.5.1. EXPUNGE Response . . . . . . . . . . . . . . . . . . 119		7.5.1. EXPUNGE Response . . . . . . . . . . . . . . . . . . 123
	7.5.2. FETCH Response . . . . . . . . . . . . . . . . . . . 120		7.5.2. FETCH Response . . . . . . . . . . . . . . . . . . . 124
	7.6. Server Responses - Command Continuation Request . . . . . 126		7.6. Server Responses - Command Continuation Request . . . . . 130
	8. Sample IMAP4rev2 connection . . . . . . . . . . . . . . . . . 127		8. Sample IMAP4rev2 connection . . . . . . . . . . . . . . . . . 131
	9. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 128		9. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 132
	10. Author's Note . . . . . . . . . . . . . . . . . . . . . . . . 146		10. Author's Note . . . . . . . . . . . . . . . . . . . . . . . . 150
	11. Security Considerations . . . . . . . . . . . . . . . . . . . 146		11. Security Considerations . . . . . . . . . . . . . . . . . . . 150
	11.1. TLS related Security Considerations . . . . . . . . . . 147		11.1. TLS related Security Considerations . . . . . . . . . . 151
	11.2. STARTTLS command versa use of Implicit TLS port . . . . 147		11.2. STARTTLS command versa use of Implicit TLS port . . . . 151
	11.3. Client handling of unsolicited responses not suitable		11.3. Client handling of unsolicited responses not suitable
	for the current connection state . . . . . . . . . . . . 148		for the current connection state . . . . . . . . . . . . 152
	11.4. COPYUID and APPENDUID response codes . . . . . . . . . . 148		11.4. COPYUID and APPENDUID response codes . . . . . . . . . . 152
	11.5. LIST command and Other Users' namespace . . . . . . . . 149		11.5. LIST command and Other Users' namespace . . . . . . . . 153
	11.6. Other Security Considerations . . . . . . . . . . . . . 149		11.6. Use of MD5 . . . . . . . . . . . . . . . . . . . . . . . 153
	12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 150		11.7. Other Security Considerations . . . . . . . . . . . . . 153
	12.1. Updates to IMAP4 Capabilities registry . . . . . . . . . 150		12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 154
	12.2. GSSAPI/SASL service name . . . . . . . . . . . . . . . . 151		12.1. Updates to IMAP4 Capabilities registry . . . . . . . . . 154
			12.2. GSSAPI/SASL service name . . . . . . . . . . . . . . . . 155
	12.3. LIST Selection Options, LIST Return Options, LIST		12.3. LIST Selection Options, LIST Return Options, LIST
	extended data items . . . . . . . . . . . . . . . . . . 151		extended data items . . . . . . . . . . . . . . . . . . 155
	12.4. IMAP Mailbox Name Attributes and IMAP Response Codes . . 151		12.4. IMAP Mailbox Name Attributes and IMAP Response Codes . . 155
	13. References . . . . . . . . . . . . . . . . . . . . . . . . . 151		13. References . . . . . . . . . . . . . . . . . . . . . . . . . 155
	13.1. Normative References . . . . . . . . . . . . . . . . . . 151		13.1. Normative References . . . . . . . . . . . . . . . . . . 156
	13.2. Informative References (related protocols) . . . . . . . 155		13.2. Informative References (related protocols) . . . . . . . 159
	13.3. Informative References (historical aspects of IMAP and		13.3. Informative References (historical aspects of IMAP and
	related protocols) . . . . . . . . . . . . . . . . . . . 157		related protocols) . . . . . . . . . . . . . . . . . . . 162
	Appendix A. Backward compatibility with IMAP4rev1 . . . . . . . 158		Appendix A. Backward compatibility with IMAP4rev1 . . . . . . . 163
	A.1. Mailbox International Naming Convention for compatibility		A.1. Mailbox International Naming Convention for compatibility
	with IMAP4rev1 . . . . . . . . . . . . . . . . . . . . . 158		with IMAP4rev1 . . . . . . . . . . . . . . . . . . . . . 163
	Appendix B. Backward compatibility with BINARY extension . . . . 160		Appendix B. Backward compatibility with BINARY extension . . . . 165
	Appendix C. Backward compatibility with LIST-EXTENDED extension 160		Appendix C. Backward compatibility with LIST-EXTENDED extension 165
	Appendix D. 63 bit body part and message sizes . . . . . . . . . 160		Appendix D. 63 bit body part and message sizes . . . . . . . . . 165
	Appendix E. Changes from RFC 3501 / IMAP4rev1 . . . . . . . . . 161		Appendix E. Changes from RFC 3501 / IMAP4rev1 . . . . . . . . . 166
	Appendix F. Other Recommended IMAP Extensions . . . . . . . . . 163		Appendix F. Other Recommended IMAP Extensions . . . . . . . . . 168
	Appendix G. Acknowledgement . . . . . . . . . . . . . . . . . . 163		Appendix G. Acknowledgement . . . . . . . . . . . . . . . . . . 168
	Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164		Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 169		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 174
	1. How to Read This Document		1. How to Read This Document
	1.1. Organization of This Document		1.1. Organization of This Document
	This document is written from the point of view of the implementor of		This document is written from the point of view of the implementor of
	an IMAP4rev2 client or server. Beyond the protocol overview in		an IMAP4rev2 client or server. Beyond the protocol overview in
	section 2, it is not optimized for someone trying to understand the		section 2, it is not optimized for someone trying to understand the
	operation of the protocol. The material in sections 3 through 5		operation of the protocol. The material in sections 3 through 5
	provides the general context and definitions with which IMAP4rev2		provides the general context and definitions with which IMAP4rev2
	skipping to change at page 26, line 41 ¶		skipping to change at page 27, line 41 ¶
	to this specification. See the documentation of the CAPABILITY		to this specification. See the documentation of the CAPABILITY
	response in Section 7.2.2 for additional information. If IMAP4rev1		response in Section 7.2.2 for additional information. If IMAP4rev1
	capability is not advertised, no capabilities, beyond the base		capability is not advertised, no capabilities, beyond the base
	IMAP4rev2 set defined in this specification, are enabled without		IMAP4rev2 set defined in this specification, are enabled without
	explicit client action to invoke the capability. If both IMAP4rev1		explicit client action to invoke the capability. If both IMAP4rev1
	and IMAP4rev2 capabilities are advertised, no capabilities, beyond		and IMAP4rev2 capabilities are advertised, no capabilities, beyond
	the base IMAP4rev1 set specified in RFC 3501, are enabled without		the base IMAP4rev1 set specified in RFC 3501, are enabled without
	explicit client action to invoke the capability.		explicit client action to invoke the capability.
	Client and server implementations MUST implement the STARTTLS		Client and server implementations MUST implement the STARTTLS
	Section 6.2.1, LOGINDISABLED, and AUTH=PLAIN (described in [PLAIN])		Section 6.2.1 and LOGINDISABLED capabilities on cleartext ports.
	capabilities. See the Security Considerations (Section 11) for		Client and server implementations MUST also implement AUTH=PLAIN
	important information.		(described in [PLAIN]) capability on both cleartext and Implicit TLS
			ports. See the Security Considerations (Section 11) for important
			information.
	Unless specified otherwise, all registered extensions to IMAP4rev1		Unless specified otherwise, all registered extensions to IMAP4rev1
	are also valid extensions to IMAP4rev2.		are also valid extensions to IMAP4rev2.
	Example: C: abcd CAPABILITY		Example: C: abcd CAPABILITY
	S: * CAPABILITY IMAP4rev2 STARTTLS AUTH=GSSAPI		S: * CAPABILITY IMAP4rev2 STARTTLS AUTH=GSSAPI
	LOGINDISABLED		LOGINDISABLED
	S: abcd OK CAPABILITY completed		S: abcd OK CAPABILITY completed
	C: efgh STARTTLS		C: efgh STARTTLS
	S: efgh OK STARTLS completed		S: efgh OK STARTLS completed
	skipping to change at page 29, line 7 ¶		skipping to change at page 30, line 7 ¶
	Arguments: none		Arguments: none
	Responses: no specific response for this command		Responses: no specific response for this command
	Result: OK - starttls completed, begin TLS negotiation		Result: OK - starttls completed, begin TLS negotiation
	NO - TLS negotiation can't be initiated, due to server		NO - TLS negotiation can't be initiated, due to server
	configuration error		configuration error
	BAD - STARTTLS received after a successful TLS		BAD - STARTTLS received after a successful TLS
	negotiation or arguments invalid		negotiation or arguments invalid
			Note that STARTTLS command is available only on cleartext ports. The
			server MUST always respond with tagged BAD response when STARTTLS
			command is received on Implicit TLS port.
	A TLS [TLS-1.3] negotiation begins immediately after the CRLF at the		A TLS [TLS-1.3] negotiation begins immediately after the CRLF at the
	end of the tagged OK response from the server. Once a client issues		end of the tagged OK response from the server. Once a client issues
	a STARTTLS command, it MUST NOT issue further commands until a server		a STARTTLS command, it MUST NOT issue further commands until a server
	response is seen and the TLS negotiation is complete. Some past		response is seen and the TLS negotiation is complete. Some past
	server implementation incorrectly implemented STARTTLS processing and		server implementation incorrectly implemented STARTTLS processing and
	are known to contain STARTTLS plaintext command injection		are known to contain STARTTLS plaintext command injection
	vulnerability [CERT-555316]. In order to avoid this vulnerability,		vulnerability [CERT-555316]. In order to avoid this vulnerability,
	server implementations MUST do one of the following If any data is		server implementations MUST do one of the following If any data is
	received in the same TCP buffer after the CRLF that starts the		received in the same TCP buffer after the CRLF that starts the
	STARTTLS command:		STARTTLS command:
	skipping to change at page 36, line 37 ¶		skipping to change at page 38, line 22 ¶
	Designers of IMAP extensions are discouraged from creating extensions		Designers of IMAP extensions are discouraged from creating extensions
	that require ENABLE unless there is no good alternative design.		that require ENABLE unless there is no good alternative design.
	Specifically, extensions that cause potentially incompatible behavior		Specifically, extensions that cause potentially incompatible behavior
	changes to deployed server responses (and thus benefit from ENABLE)		changes to deployed server responses (and thus benefit from ENABLE)
	have a higher complexity cost than extensions that do not.		have a higher complexity cost than extensions that do not.
	6.3.2. SELECT Command		6.3.2. SELECT Command
	Arguments: mailbox name		Arguments: mailbox name
	Responses: REQUIRED untagged responses: FLAGS, EXISTS		Responses: REQUIRED untagged responses: FLAGS, EXISTS, LIST
	REQUIRED OK untagged responses: PERMANENTFLAGS,		REQUIRED OK untagged responses: PERMANENTFLAGS,
	UIDNEXT, UIDVALIDITY		UIDNEXT, UIDVALIDITY
	REQUIRED untagged response: LIST
	Result: OK - select completed, now in selected state		Result: OK - select completed, now in selected state
	NO - select failure, now in authenticated state: no		NO - select failure, now in authenticated state: no
	such mailbox, can't access mailbox		such mailbox, can't access mailbox
	BAD - command unknown or arguments invalid		BAD - command unknown or arguments invalid
	The SELECT command selects a mailbox so that messages in the mailbox		The SELECT command selects a mailbox so that messages in the mailbox
	can be accessed. Before returning an OK to the client, the server		can be accessed. Before returning an OK to the client, the server
	MUST send the following untagged data to the client. (The order of		MUST send the following untagged data to the client. (The order of
	individual responses is not important.) Note that earlier versions		individual responses is not important.) Note that earlier versions
	of this protocol (e.g. IMAP2bis) only required the FLAGS and EXISTS		of this protocol (e.g. IMAP4rev1 version specified in RFC 2060) only
	untagged data; consequently, client implementations SHOULD implement		required the FLAGS and EXISTS untagged responses and UIDVALIDITY
			response code; consequently, client implementations SHOULD implement
	default behavior for missing data as discussed with the individual		default behavior for missing data as discussed with the individual
	item.		item.
	FLAGS Defined flags in the mailbox. See the description of the		FLAGS Defined flags in the mailbox. See the description of the
	FLAGS response in Section 7.3.5 for more detail.		FLAGS response in Section 7.3.5 for more detail.
	<n> EXISTS The number of messages in the mailbox. See the		<n> EXISTS The number of messages in the mailbox. See the
	description of the EXISTS response in Section 7.4.1 for more		description of the EXISTS response in Section 7.4.1 for more
	detail.		detail.
	LIST The server MUST return a LIST response with the mailbox name.		LIST The server MUST return a LIST response with the mailbox name.
	If the server allows de-normalized UTF-8 mailbox names (see		The list of mailbox attributes MUST be accurate. If the server
	Section 5.1) and the supplied mailbox name differs from the		allows de-normalized UTF-8 mailbox names (see Section 5.1) and the
	normalized version, the server MUST return LIST with the OLDNAME		supplied mailbox name differs from the normalized version, the
	extended data item. See Section 6.3.9.7 for more details.		server MUST return LIST with the OLDNAME extended data item. See
			Section 6.3.9.7 for more details.
	OK [PERMANENTFLAGS (<list of flags>)] A list of message flags that		OK [PERMANENTFLAGS (<list of flags>)] A list of message flags that
	the client can change permanently. If this is missing, the client		the client can change permanently. If this is missing, the client
	should assume that all flags can be changed permanently.		should assume that all flags can be changed permanently.
	OK [UIDNEXT <n>] The next unique identifier value. Refer to		OK [UIDNEXT <n>] The next unique identifier value. Refer to
	Section 2.3.1.1 for more information.		Section 2.3.1.1 for more information.
	OK [UIDVALIDITY <n>] The unique identifier validity value. Refer to		OK [UIDVALIDITY <n>] The unique identifier validity value. Refer to
	Section 2.3.1.1 for more information.		Section 2.3.1.1 for more information.
	skipping to change at page 38, line 44 ¶		skipping to change at page 40, line 33 ¶
	Note that IMAP4rev1 compliant servers can also send the untagged		Note that IMAP4rev1 compliant servers can also send the untagged
	RECENT response which was deprecated in IMAP4rev2. E.g. "* 0		RECENT response which was deprecated in IMAP4rev2. E.g. "* 0
	RECENT". Pure IMAP4rev2 clients are advised to ignore the untagged		RECENT". Pure IMAP4rev2 clients are advised to ignore the untagged
	RECENT response.		RECENT response.
	6.3.3. EXAMINE Command		6.3.3. EXAMINE Command
	Arguments: mailbox name		Arguments: mailbox name
	Responses: REQUIRED untagged responses: FLAGS, EXISTS		Responses: REQUIRED untagged responses: FLAGS, EXISTS, LIST
	REQUIRED OK untagged responses: PERMANENTFLAGS,		REQUIRED OK untagged responses: PERMANENTFLAGS,
	UIDNEXT, UIDVALIDITY		UIDNEXT, UIDVALIDITY
	REQUIRED untagged response: LIST
	Result: OK - examine completed, now in selected state		Result: OK - examine completed, now in selected state
	NO - examine failure, now in authenticated state: no		NO - examine failure, now in authenticated state: no
	such mailbox, can't access mailbox BAD - command unknown		such mailbox, can't access mailbox BAD - command unknown
	or arguments invalid		or arguments invalid
	The EXAMINE command is identical to SELECT and returns the same		The EXAMINE command is identical to SELECT and returns the same
	output; however, the selected mailbox is identified as read-only. No		output; however, the selected mailbox is identified as read-only. No
	changes to the permanent state of the mailbox, including per-user		changes to the permanent state of the mailbox, including per-user
	state, are permitted.		state, are permitted.
	skipping to change at page 66, line 6 ¶		skipping to change at page 68, line 6 ¶
	namespace.		namespace.
	Example 6:		Example 6:
	In this example, a server supports two Personal Namespaces. In		In this example, a server supports two 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 with the \Sent attribute. Furthermore, after a
	deleted from a mailbox, the client is configured to move that message		message is deleted from a mailbox, the client is configured to move
	to a mailbox called 'Deleted Items'.		that message to a mailbox with the \Trash attribute. The server
			signals specific mailbox names that should be used for these purposed
			by returning LIST responses with \NonExistent attribute. I.e. the
			server is hinting to the client which mailbox names to use for sent
			and deleted messages.
	Note that this example demonstrates how some extension parameters can		Note that this example demonstrates how some extension parameters can
	be passed to further describe the #mh namespace. See the fictitious		be passed to further describe the #mh namespace. See the fictitious
	"X-PARAM" extension parameter.		"X-PARAM" extension parameter.
	C: A001 NAMESPACE		C: A001 NAMESPACE
	S: * NAMESPACE (("" "/")("#mh/" "/" "X-PARAM"		S: * NAMESPACE (("" "/")("#mh/" "/" "X-PARAM"
	("FLAG1" "FLAG2"))) NIL NIL		("FLAG1" "FLAG2"))) NIL NIL
	S: A001 OK NAMESPACE command completed		S: A001 OK NAMESPACE command completed
	< It is desired to keep only one copy of sent mail.		C: A002 LIST (SPECIAL-USE) "" "*"
	It is unclear which Personal Namespace the client		S: * LIST (\NonExistent \Archive) "/" Archives
	should use to create the 'Sent Mail' mailbox.		S: * LIST (\NonExistent \Drafts) "/" Drafts
	The user is prompted to select a namespace and only		S: * LIST (\NonExistent \Junk) "/" Junk
	one 'Sent Mail' mailbox is created. >		S: * LIST (\NonExistent \Sent) "/" "Sent Mail"
			S: * LIST (\NonExistent \Trash) "/" "Deleted Items"
			S: A002 OK LIST Completed
	C: A002 CREATE "Sent Mail"		C: A003 LIST (SPECIAL-USE) "#mh/" "*"
	S: A002 OK CREATE command completed		S: * LIST (\NonExistent \Archive) "/" "#mh/Archives"
			S: * LIST (\NonExistent \Drafts) "/" "#mh/Drafts"
			S: * LIST (\NonExistent \Junk) "/" "#mh/Junk"
			S: * LIST (\NonExistent \Sent) "/" "#mh/Sent Mail"
			S: * LIST (\NonExistent \Trash) "/" "#mh/Deleted Items"
			S: A003 OK LIST Completed
	< The client is designed so that it keeps two		< It is desired to keep only one copy of sent mail.
	'Deleted Items' mailboxes, one for each namespace. >		It is unclear which Personal Namespace the client
			should use to create the 'Sent Mail' mailbox.
			The user is prompted to select a namespace and only
			one 'Sent Mail' mailbox is created. >
	C: A003 CREATE "Delete Items"		C: A004 CREATE "Sent Mail"
	S: A003 OK CREATE command completed		S: A004 OK CREATE command completed
	C: A004 CREATE "#mh/Deleted Items"		< The client is designed so that it keeps two
	S: A004 OK CREATE command completed		'Deleted Items' mailboxes, one for each namespace. >
			C: A005 CREATE "Delete Items"
			S: A005 OK CREATE command completed
			C: A006 CREATE "#mh/Deleted Items"
			S: A006 OK CREATE command completed
	The next level of hierarchy following the Other Users' Namespace		The next level of hierarchy following the Other Users' Namespace
	prefix SHOULD consist of <username>, where <username> is a user name		prefix SHOULD consist of <username>, where <username> is a user name
	as per the LOGIN or AUTHENTICATE command.		as per the LOGIN or AUTHENTICATE command.
	A client can construct a LIST command by appending a "%" to the Other		A client can construct a LIST command by appending a "%" to the Other
	Users' Namespace prefix to discover the Personal Namespaces of other		Users' Namespace prefix to discover the Personal Namespaces of other
	users that are available to the currently authenticated user.		users that are available to the currently authenticated user.
	In response to such a LIST command, a server SHOULD NOT return user		In response to such a LIST command, a server SHOULD NOT return user
	skipping to change at page 74, line 10 ¶		skipping to change at page 77, line 18 ¶
	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
	S: * FLAGS (\Deleted \Seen \Flagged)		S: * FLAGS (\Deleted \Seen \Flagged)
	S: * OK [PERMANENTFLAGS (\Deleted \Seen \Flagged)] Limited		S: * OK [PERMANENTFLAGS (\Deleted \Seen \Flagged)] Limited
	S: * 3 EXISTS		S: * 3 EXISTS
	S: * OK [UIDVALIDITY 1]		S: * OK [UIDVALIDITY 1]
			S: * OK [UIDNEXT 1]
	S: * LIST () "/" INBOX		S: * LIST () "/" INBOX
	S: A001 OK [READ-WRITE] SELECT completed		S: A001 OK [READ-WRITE] SELECT completed
	C: A002 IDLE		C: A002 IDLE
	S: + idling		S: + idling
	...time passes; new mail arrives...		...time passes; new mail arrives...
	S: * 4 EXISTS		S: * 4 EXISTS
	C: DONE		C: DONE
	S: A002 OK IDLE terminated		S: A002 OK IDLE terminated
	...another client expunges message 2 now...		...another client expunges message 2 now...
	C: A003 FETCH 4 ALL		C: A003 FETCH 4 ALL
	skipping to change at page 77, line 13 ¶		skipping to change at page 80, line 19 ¶
	is assumed (see below). The order of individual options is		is assumed (see below). The order of individual options is
	arbitrary. Individual options may contain parameters enclosed in		arbitrary. Individual options may contain parameters enclosed in
	parentheses. (However, if an option has a mandatory parameter, which		parentheses. (However, if an option has a mandatory parameter, which
	can always be represented as a number or a sequence-set, the option		can always be represented as a number or a sequence-set, the option
	parameter does not need the enclosing parentheses. See the Formal		parameter does not need the enclosing parentheses. See the Formal
	Syntax (Section 9) for more details). If an option has parameters,		Syntax (Section 9) for more details). If an option has parameters,
	they consist of atoms and/or strings and/or lists in a specific		they consist of atoms and/or strings and/or lists in a specific
	order. Any options not defined by extensions that the server		order. Any options not defined by extensions that the server
	supports MUST be rejected with a BAD response.		supports MUST be rejected with a BAD response.
			Note that IMAP4rev1 used SEARCH responses [RFC3501] instead of
			ESEARCH responses. IMAP4rev2-only clients MUST ignore SEARCH
			responses.
	This document specifies the following result options:		This document specifies the following result options:
	MIN		MIN
	Return the lowest message number/UID that satisfies the SEARCH		Return the lowest message number/UID that satisfies the SEARCH
	criteria.		criteria.
	If the SEARCH results in no matches, the server MUST NOT		If the SEARCH results in no matches, the server MUST NOT
	include the MIN result option in the ESEARCH response; however,		include the MIN result option in the ESEARCH response; however,
	it still MUST send the ESEARCH response.		it still MUST send the ESEARCH response.
	skipping to change at page 96, line 16 ¶		skipping to change at page 100, line 16 ¶
	error. It MUST NOT automatically create the mailbox. Unless it is		error. It MUST NOT automatically create the mailbox. Unless it is
	certain that the destination mailbox can not be created, the server		certain that the destination mailbox can not be created, the server
	MUST send the response code "[TRYCREATE]" as the prefix of the text		MUST send the response code "[TRYCREATE]" as the prefix of the text
	of the tagged NO response. This gives a hint to the client that it		of the tagged NO response. This gives a hint to the client that it
	can attempt a CREATE command and retry the MOVE if the CREATE is		can attempt a CREATE command and retry the MOVE if the CREATE is
	successful.		successful.
	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 listed in		COPY affect MOVE in the same way. Response codes listed in
	Section 7.1, as well as those defined by extensions, are sent as		Section 7.1, as well as those defined by extensions, are sent as
	appropriate.		indicated for COPY.
	Servers send COPYUID in response to a MOVE or a UID MOVE (see		Servers send COPYUID in response to a MOVE or a UID MOVE (see
	Section 6.4.9) command. For additional information about COPYUID see		Section 6.4.9) command. For additional information about COPYUID see
	Section 7.1. Note that there are several exceptions listed in		Section 7.1. Note that there are several exceptions listed in
	Section 6.4.7 that allow servers not to return COPYUID.		Section 6.4.7 that allow servers not to return COPYUID.
	Servers are also REQUIRED to send the COPYUID response code in an		Servers are also REQUIRED to send the COPYUID response code in an
	untagged OK before sending EXPUNGE or similar responses. (Sending		untagged OK before sending EXPUNGE or similar 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
	skipping to change at page 112, line 6 ¶		skipping to change at page 116, line 6 ¶
	Contents: capability listing		Contents: capability listing
	The CAPABILITY response occurs as a result of a CAPABILITY command.		The CAPABILITY response occurs as a result of a CAPABILITY command.
	The capability listing contains a space-separated listing of		The capability listing contains a space-separated listing of
	capability names that the server supports. The capability listing		capability names that the server supports. The capability listing
	MUST include the atom "IMAP4rev2", but note that it doesn't have to		MUST include the atom "IMAP4rev2", but note that it doesn't have to
	be the first capability listed. The order of capability names has no		be the first capability listed. The order of capability names has no
	significance.		significance.
	In addition, client and server implementations MUST implement the		In addition, client and server implementations MUST implement the
	"STARTTLS", "LOGINDISABLED", and "AUTH=PLAIN" (described in [PLAIN])		"STARTTLS" and "LOGINDISABLED" (only on the cleartext port), and
	capabilities. See the Security Considerations (Section 11) for		"AUTH=PLAIN" (described in [PLAIN]) capabilities. See the Security
	important information related to these capabilities.		Considerations (Section 11) for important information related to
			these capabilities.
	A capability name which begins with "AUTH=" indicates that the server		A capability name which begins with "AUTH=" indicates that the server
	supports that particular authentication mechanism [SASL].		supports that particular authentication mechanism [SASL].
	The LOGINDISABLED capability indicates that the LOGIN command is		The LOGINDISABLED capability indicates that the LOGIN command is
	disabled, and that the server will respond with a tagged NO response		disabled, and that the server will respond with a tagged NO response
	to any attempt to use the LOGIN command even if the user name and		to any attempt to use the LOGIN command even if the user name and
	password are valid. An IMAP client MUST NOT issue the LOGIN command		password are valid. An IMAP client MUST NOT issue the LOGIN command
	if the server advertises the LOGINDISABLED capability.		if the server advertises the LOGINDISABLED capability.
	skipping to change at page 112, line 34 ¶		skipping to change at page 116, line 35 ¶
	are advertised, server responses MUST conform to RFC 3501 until the		are advertised, server responses MUST conform to RFC 3501 until the
	client issues a command that uses the associated capability. (For		client issues a command that uses the associated capability. (For
	example, the client can issue ENABLE IMAP4rev2 to enable IMAP4rev2		example, the client can issue ENABLE IMAP4rev2 to enable IMAP4rev2
	specific behaviour).		specific behaviour).
	Capability names SHOULD be registered with IANA using RFC Required		Capability names SHOULD be registered with IANA using RFC Required
	policy. A server SHOULD NOT offer unregistered capability names.		policy. A server SHOULD NOT offer unregistered capability names.
	Client implementations SHOULD NOT require any capability name other		Client implementations SHOULD NOT require any capability name other
	than "IMAP4rev2", and possibly "STARTTLS" and "LOGINDISABLED" (on a		than "IMAP4rev2", and possibly "STARTTLS" and "LOGINDISABLED" (on a
	non implicit TLS port). Client implementations MUST ignore any		cleartext port). Client implementations MUST ignore any unknown
	unknown capability names.		capability names.
	A server MAY send capabilities automatically, by using the CAPABILITY		A server MAY send capabilities automatically, by using the CAPABILITY
	response code in the initial PREAUTH or OK responses, and by sending		response code in the initial PREAUTH or OK responses, and by sending
	an updated CAPABILITY response code in the tagged OK response as part		an updated CAPABILITY response code in the tagged OK response as part
	of a successful authentication. It is unnecessary for a client to		of a successful authentication. It is unnecessary for a client to
	send a separate CAPABILITY command if it recognizes these automatic		send a separate CAPABILITY command if it recognizes these automatic
	capabilities and there was no change to the TLS and/or authentication		capabilities and there was no change to the TLS and/or authentication
	state since they were received.		state since they were received.
	The list of capabilities returned by a server MAY change during the		The list of capabilities returned by a server MAY change during the
	skipping to change at page 127, line 35 ¶		skipping to change at page 131, line 35 ¶
	port. A long line in this sample is broken for editorial clarity.		port. A long line in this sample is broken for editorial clarity.
	S: * OK [CAPABILITY STARTTLS AUTH=SCRAM-SHA-256 LOGINDISABLED		S: * OK [CAPABILITY STARTTLS AUTH=SCRAM-SHA-256 LOGINDISABLED
	IMAP4rev2] IMAP4rev2 Service Ready		IMAP4rev2] IMAP4rev2 Service Ready
	C: a000 starttls		C: a000 starttls
	S: a000 OK Proceed with TLS negotiation		S: a000 OK Proceed with TLS negotiation
	<TLS negotiation>		<TLS negotiation>
	C: A001 AUTHENTICATE SCRAM-SHA-256		C: A001 AUTHENTICATE SCRAM-SHA-256
	biwsbj11c2VyLHI9ck9wck5HZndFYmVSV2diTkVrcU8=		biwsbj11c2VyLHI9ck9wck5HZndFYmVSV2diTkVrcU8=
	S: + cj1yT3ByTkdmd0ViZVJXZ2JORWtxTyVodllEcFdVYTJSYVRDQWZ1eEZJbGopaE5s		S: + cj1yT3ByTkdmd0ViZVJXZ2JORWtxTyVodllEcFdVYTJSYVRDQWZ1eEZJbGopaE5s
	RiRrMCxzPVcyMlphSjBTTlk3c29Fc1VFamI2Z1E9PSxpPTQwOTYNCg==		RiRrMCxzPVcyMlphSjBTTlk3c29Fc1VFamI2Z1E9PSxpPTQwOTY=
	C: Yz1iaXdzLHI9ck9wck5HZndFYmVSV2diTkVrcU8laHZZRHBXVWEyUmFUQ0FmdXhG		C: Yz1iaXdzLHI9ck9wck5HZndFYmVSV2diTkVrcU8laHZZRHBXVWEyUmFUQ0FmdXhG
	SWxqKWhObEYkazAscD1kSHpiWmFwV0lrNGpVaE4rVXRlOXl0YWc5empmTUhnc3Ft		SWxqKWhObEYkazAscD1kSHpiWmFwV0lrNGpVaE4rVXRlOXl0YWc5empmTUhnc3Ft
	bWl6N0FuZFZRPQ==		bWl6N0FuZFZRPQ==
	S: + dj02cnJpVFJCaTIzV3BSUi93dHVwK21NaFVaVW4vZEI1bkxUSlJzamw5NUc0PQ==		S: + dj02cnJpVFJCaTIzV3BSUi93dHVwK21NaFVaVW4vZEI1bkxUSlJzamw5NUc0PQ==
	C:		C:
	S: A001 OK SCRAM-SHA-256 authentication successful		S: A001 OK SCRAM-SHA-256 authentication successful
	C: babc ENABLE IMAP4rev2		C: babc ENABLE IMAP4rev2
	S: * ENABLED IMAP4rev2		S: * ENABLED IMAP4rev2
	S: babc OK Some capabilities enabled		S: babc OK Some capabilities enabled
	C: a002 select inbox		C: a002 select inbox
	skipping to change at page 131, line 48 ¶		skipping to change at page 135, line 48 ¶
	capability = ("AUTH=" auth-type) / atom		capability = ("AUTH=" auth-type) / atom
	; New capabilities SHOULD be		; New capabilities SHOULD be
	; registered with IANA using		; registered with IANA using
	; RFC Required policy, i.e. in		; RFC Required policy, i.e. in
	; a standards-track, an experimental		; a standards-track, an experimental
	; or an informational RFC.		; or an informational RFC.
	capability-data = "CAPABILITY" *(SP capability) SP "IMAP4rev2"		capability-data = "CAPABILITY" *(SP capability) SP "IMAP4rev2"
	*(SP capability)		*(SP capability)
	; Servers MUST implement the STARTTLS, AUTH=PLAIN,		; Servers MUST implement the STARTTLS and LOGINDISABLED
	; and LOGINDISABLED capabilities.		; (on cleartext port), AUTH=PLAIN capabilities.
	; Servers which offer RFC 1730 compatibility MUST		; Servers which offer RFC 1730 compatibility MUST
	; list "IMAP4" as the first capability.		; list "IMAP4" as the first capability.
	; Servers which offer RFC 3501 compatibility MUST		; Servers which offer RFC 3501 compatibility MUST
	; list "IMAP4rev1" as one of capabilities.		; list "IMAP4rev1" as one of capabilities.
	CHAR = <defined in [ABNF]>		CHAR = <defined in [ABNF]>
	CHAR8 = %x01-ff		CHAR8 = %x01-ff
	; any OCTET except NUL, %x00		; any OCTET except NUL, %x00
	skipping to change at page 147, line 4 ¶		skipping to change at page 151, line 4 ¶
	supercedes the protocol specification in those documents: RFC 3501,		supercedes the protocol specification in those documents: RFC 3501,
	RFC 2060, RFC 1730, unpublished IMAP2bis.TXT document, RFC 1176, and		RFC 2060, RFC 1730, unpublished IMAP2bis.TXT document, RFC 1176, and
	RFC 1064.		RFC 1064.
	11. Security Considerations		11. Security Considerations
	IMAP4rev2 protocol transactions, including electronic mail data, are		IMAP4rev2 protocol transactions, including electronic mail data, are
	sent in the clear over the network exposing them to possible		sent in the clear over the network exposing them to possible
	eavesdropping and manipulation unless protection is negotiated. This		eavesdropping and manipulation unless protection is negotiated. This
	can be accomplished either by the use of Implicit TLS port, STARTTLS		can be accomplished either by the use of Implicit TLS port, STARTTLS
	command, negotiated privacy protection in the AUTHENTICATE command,		command, negotiated confidentiality protection in the AUTHENTICATE
	or some other protection mechanism.		command, or some other protection mechanism.
	11.1. TLS related Security Considerations		11.1. TLS related Security Considerations
	This section applies to both use of STARTTLS command and Implicit TLS		This section applies to both use of STARTTLS command and Implicit TLS
	port.		port.
	IMAP client and server implementations MUST comply with relevant TLS		IMAP client and server implementations MUST comply with relevant TLS
	recommendations from [RFC8314].		recommendations from [RFC8314].
	Clients and servers MUST implement TLS 1.2 [TLS-1.2] or newer. Use		Clients and servers MUST implement TLS 1.2 [TLS-1.2] or newer. Use
	skipping to change at page 147, line 43 ¶		skipping to change at page 151, line 43 ¶
	identity as presented in the server Certificate message, in order to		identity as presented in the server Certificate message, in order to
	prevent on-path attackers attempting to masquerade as the server.		prevent on-path attackers attempting to masquerade as the server.
	This procedure is described in [RFC7817].		This procedure is described in [RFC7817].
	Both the client and server MUST check the result of the STARTTLS		Both the client and server MUST check the result of the STARTTLS
	command and subsequent TLS ([TLS-1.3][TLS-1.2]) negotiation to see		command and subsequent TLS ([TLS-1.3][TLS-1.2]) negotiation to see
	whether acceptable authentication and/or privacy was achieved.		whether acceptable authentication and/or privacy was achieved.
	11.2. STARTTLS command versa use of Implicit TLS port		11.2. STARTTLS command versa use of Implicit TLS port
	For maximum backward compatibility clients MUST implement both TLS		For maximum backward compatibility the client MUST implement both TLS
	negotiation on implicit TLS port and TLS negotiation using STARTTLS		negotiation on implicit TLS port and TLS negotiation using STARTTLS
	command.		command on cleartext port.
	Servers MUST implement TLS negotiation on implicit TLS port and		The server MUST implement TLS negotiation on implicit TLS port. The
	SHOULD implement STARTTLS command on cleartext port.		server SHOULD also implement IMAP on cleartext port. If the server
			listens on a cleartext port, it MUST allow STARTTLS command on it.
	Some site/firewall maintainers insist on TLS site-wide and prefer not		Some site/firewall maintainers insist on TLS site-wide and prefer not
	to rely on a configuration option in each higher-level protocol. For		to rely on a configuration option in each higher-level protocol. For
	this reason, IMAP4rev2 clients SHOULD try both ports 993 and 143 (and		this reason, IMAP4rev2 clients SHOULD try both ports 993 and 143 (and
	both IPv4 and IPv6) concurrently by default, unless overridden by		both IPv4 and IPv6) concurrently by default, unless overridden by
	either user configuration or DNS SRV records [RFC6186]. Note that if		either user configuration or DNS SRV records [RFC6186]. A good
	a server answers on both ports, it MUST allow STARTTLS command on		algorithm for implementing such concurrent connect is described in
	port 143.		[RFC8305].
	11.3. Client handling of unsolicited responses not suitable for the		11.3. Client handling of unsolicited responses not suitable for the
	current connection state		current connection state
	Cleartext mail transmission (whether caused by firewall configuration		Cleartext mail transmission (whether caused by firewall configuration
	errors that result in TLS stripping or weak security policies in		errors that result in TLS stripping or weak security policies in
	email clients that choose not to negotiate TLS in the first place)		email clients that choose not to negotiate TLS in the first place)
	can enable injection of responses that can confuse or even cause		can enable injection of responses that can confuse or even cause
	crashes in email clients. The following measures are recommended to		crashes in email clients. The following measures are recommended to
	minimize damage from them.		minimize damage from them.
	skipping to change at page 149, line 15 ¶		skipping to change at page 153, line 15 ¶
	11.5. LIST command and Other Users' namespace		11.5. LIST command and Other Users' namespace
	In response to a LIST command containing an argument of the Other		In response to a LIST command containing an argument of the Other
	Users' Namespace prefix, a server SHOULD NOT list users that have not		Users' Namespace prefix, a server SHOULD NOT list users that have not
	granted list access to their personal mailboxes to the currently		granted list access to their personal mailboxes to the currently
	authenticated user. Providing such a list, could compromise security		authenticated user. Providing such a list, could compromise security
	by potentially disclosing confidential information of who is located		by potentially disclosing confidential information of who is located
	on the server, or providing a starting point of a list of user		on the server, or providing a starting point of a list of user
	accounts to attack.		accounts to attack.
	11.6. Other Security Considerations		11.6. Use of MD5
			The BODYSTRUCTURE FETCH Data item can contain a the MD5 digest of the
			message body in the "body MD5" field (body-fld-md5 ABNF production).
			While MD5 is no longer considered a secure cryptographic hash
			[RFC6151], this field is used solely to expose the value of the
			Content-MD5 header field (if present in the original message), which
			is just a message integrity check and is not used for cryptographic
			purposes. Also note that other mechanisms that provide message
			integrity checks were defined since RFC 1864 was published and are
			now more commonly used than Content-MD5. Two such mechanisms are
			DKIM-Signature [RFC6376] header field and S/MIME signing
			[RFC8550][RFC8550].
			11.7. 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 150, line 17 ¶		skipping to change at page 154, line 29 ¶
	attack as well as a password spraying attack. Accounts with		attack as well as a password spraying attack. Accounts with
	passwords that match well known passwords from spraying attacks MUST		passwords that match well known passwords from spraying attacks MUST
	be blocked and users associated with such accounts must be requested		be blocked and users associated with such accounts must be requested
	to change their passwords. Only password with significant strength		to change their passwords. Only password with significant strength
	SHOULD be accepted.		SHOULD be accepted.
	Additional security considerations are discussed in the section		Additional security considerations are discussed in the section
	discussing the AUTHENTICATE (see Section 6.2.2) and LOGIN (see		discussing the AUTHENTICATE (see Section 6.2.2) and LOGIN (see
	Section 6.2.3) commands.		Section 6.2.3) commands.
	Note that the BODYSTRUCTURE FETCH data item can contain an MD5 hash
	taken from the Content-MD5 header field. This is used purely for
	message integrity check, so it is only used for detecting unintended
	modifications of the message.
	12. IANA Considerations		12. IANA Considerations
	IANA is requested to update "Service Names and Transport Protocol		IANA is requested to update "Service Names and Transport Protocol
	Port Numbers" registry as follows:		Port Numbers" registry as follows:
	1. Registration for TCP port 143 and the corresponding "imap"		1. Registration for TCP port 143 and the corresponding "imap"
	service name should be updated to point to this document and RFC		service name should be updated to point to this document and RFC
	3501.		3501.
	2. Registration for TCP port 993 and the corresponding "imaps"		2. Registration for TCP port 993 and the corresponding "imaps"
	skipping to change at page 155, line 22 ¶		skipping to change at page 159, line 31 ¶
	RFC 2180, July 1997,		RFC 2180, July 1997,
	<https://www.rfc-editor.org/info/rfc2180>.		<https://www.rfc-editor.org/info/rfc2180>.
	13.2. Informative References (related protocols)		13.2. Informative References (related protocols)
	[CERT-555316]		[CERT-555316]
	CERT, "Vulnerability Note VU#555316: STARTTLS plaintext		CERT, "Vulnerability Note VU#555316: STARTTLS plaintext
	command injection vulnerability", September 2011,		command injection vulnerability", September 2011,
	<https://www.kb.cert.org/vuls/id/555316>.		<https://www.kb.cert.org/vuls/id/555316>.
			[RFC6151] Turner, S. and L. Chen, "Updated Security Considerations
			for the MD5 Message-Digest and the HMAC-MD5 Algorithms",
			RFC 6151, DOI 10.17487/RFC6151, March 2011,
			<https://www.rfc-editor.org/info/rfc6151>.
	[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>.
	[RFC5256] Crispin, M. and K. Murchison, "Internet Message Access		[RFC5256] Crispin, M. and K. Murchison, "Internet Message Access
	skipping to change at page 157, line 10 ¶		skipping to change at page 161, line 21 ¶
	<https://www.rfc-editor.org/info/rfc4314>.		<https://www.rfc-editor.org/info/rfc4314>.
	[RFC2087] Myers, J., "IMAP4 QUOTA extension", RFC 2087, January		[RFC2087] Myers, J., "IMAP4 QUOTA extension", RFC 2087, January
	1997, <https://www.rfc-editor.org/info/rfc2087>.		1997, <https://www.rfc-editor.org/info/rfc2087>.
	[IMAP-URL]		[IMAP-URL]
	Melnikov, A., Ed. and C. Newman, "IMAP URL Scheme",		Melnikov, A., Ed. and C. Newman, "IMAP URL Scheme",
	RFC 5092, DOI 10.17487/RFC5092, November 2007,		RFC 5092, DOI 10.17487/RFC5092, November 2007,
	<https://www.rfc-editor.org/info/rfc5092>.		<https://www.rfc-editor.org/info/rfc5092>.
			[RFC8305] Schinazi, D. and T. Pauly, "Happy Eyeballs Version 2:
			Better Connectivity Using Concurrency", RFC 8305,
			DOI 10.17487/RFC8305, December 2017,
			<https://www.rfc-editor.org/info/rfc8305>.
			[RFC6376] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed.,
			"DomainKeys Identified Mail (DKIM) Signatures", STD 76,
			RFC 6376, DOI 10.17487/RFC6376, September 2011,
			<https://www.rfc-editor.org/info/rfc6376>.
			[RFC8550] Schaad, J., Ramsdell, B., and S. Turner, "Secure/
			Multipurpose Internet Mail Extensions (S/MIME) Version 4.0
			Certificate Handling", RFC 8550, DOI 10.17487/RFC8550,
			April 2019, <https://www.rfc-editor.org/info/rfc8550>.
			[RFC8551] Schaad, J., Ramsdell, B., and S. Turner, "Secure/
			Multipurpose Internet Mail Extensions (S/MIME) Version 4.0
			Message Specification", RFC 8551, DOI 10.17487/RFC8551,
			April 2019, <https://www.rfc-editor.org/info/rfc8551>.
	[IMAP-KEYWORDS-REG]		[IMAP-KEYWORDS-REG]
	IANA, "IMAP and JMAP Keywords", December 2009,		IANA, "IMAP and JMAP Keywords", December 2009,
	<https://www.iana.org/assignments/imap-jmap-keywords/imap-		<https://www.iana.org/assignments/imap-jmap-keywords/imap-
	jmap-keywords.xhtml>.		jmap-keywords.xhtml>.
	[IMAP-MAILBOX-NAME-ATTRS-REG]		[IMAP-MAILBOX-NAME-ATTRS-REG]
	IANA, "IMAP Mailbox Name Attributes", June 2018,		IANA, "IMAP Mailbox Name Attributes", June 2018,
	<https://www.iana.org/assignments/imap-mailbox-name-		<https://www.iana.org/assignments/imap-mailbox-name-
	attributes/imap-mailbox-name-attributes.xhtml>.		attributes/imap-mailbox-name-attributes.xhtml>.
	skipping to change at page 158, line 22 ¶		skipping to change at page 163, line 9 ¶
	[IMAP-TLS]		[IMAP-TLS]
	Newman, C., "Using TLS with IMAP, POP3 and ACAP",		Newman, C., "Using TLS with IMAP, POP3 and ACAP",
	RFC 2595, June 1999,		RFC 2595, June 1999,
	<https://www.rfc-editor.org/info/rfc2595>.		<https://www.rfc-editor.org/info/rfc2595>.
	Appendix A. Backward compatibility with IMAP4rev1		Appendix A. Backward compatibility with IMAP4rev1
	An implementation that wants to remain compatible with IMAP4rev1 can		An implementation that wants to remain compatible with IMAP4rev1 can
	advertise both IMAP4rev1 and IMAP4rev2 in its CAPABILITY response/		advertise both IMAP4rev1 and IMAP4rev2 in its CAPABILITY response/
	response code. While some IMAP4rev1 responses were removed in		response code. (Such server implementation is likely to also want to
			advertise other IMAP4rev1 extensions that were folded into IMAP4rev2.
			See Appendix E.) While some IMAP4rev1 responses were removed in
	IMAP4rev2, their presence will not break IMAP4rev2-only clients.		IMAP4rev2, their presence will not break IMAP4rev2-only clients.
	If both IMAP4rev1 and IMAP4rev2 are advertised, an IMAP client that		If both IMAP4rev1 and IMAP4rev2 are advertised, an IMAP client that
	wants to use IMAP4rev2 MUST issue an "ENABLE IMAP4rev2" command.		wants to use IMAP4rev2 MUST issue an "ENABLE IMAP4rev2" command.
	Servers advertising both IMAP4rev1 and IMAP4rev2 MUST NOT generate		Servers advertising both IMAP4rev1 and IMAP4rev2 MUST NOT generate
	UTF-8 quoted strings unless the client has issued "ENABLE IMAP4rev2".		UTF-8 quoted strings unless the client has issued "ENABLE IMAP4rev2".
	Consider implementation of mechanisms described or referenced in		Consider implementation of mechanisms described or referenced in
	[IMAP-UTF-8] to achieve this goal.		[IMAP-UTF-8] to achieve this goal.
	Servers advertising both IMAP4rev1 and IMAP4rev2, and clients		Servers advertising both IMAP4rev1 and IMAP4rev2, and clients
	intending to be compatible with IMAP4rev1 servers MUST be compatible		intending to be compatible with IMAP4rev1 servers MUST be compatible
	with the international mailbox naming convention described in the		with the international mailbox naming convention described in
	following subsection.		Appendix A.1.
	Also see Appendix D for special considerations for servers that		Also see Appendix D for special considerations for servers that
	support 63 bit body part/message sizes and want to advertise support		support 63 bit body part/message sizes and want to advertise support
	for both IMAP4rev1 and IMAP4rev2.		for both IMAP4rev1 and IMAP4rev2.
	A.1. Mailbox International Naming Convention for compatibility with		A.1. Mailbox International Naming Convention for compatibility with
	IMAP4rev1		IMAP4rev1
	Support for the Mailbox International Naming Convention described in		Support for the Mailbox International Naming Convention described in
	this section is not required for IMAP4rev2-only clients and servers.		this section is not required for IMAP4rev2-only clients and servers.
	skipping to change at page 164, line 24 ¶		skipping to change at page 169, line 16 ¶
	Thank you to Damian Poddebniak, Fabian Ising, Hanno Boeck and		Thank you to Damian Poddebniak, Fabian Ising, Hanno Boeck and
	Sebastian Schinzel for pointing out that the ENABLE command should be		Sebastian Schinzel for pointing out that the ENABLE command should be
	a member of "command-auth" and not "command-any" ABNF production, as		a member of "command-auth" and not "command-any" ABNF production, as
	well as pointing out security issues associated with ALERT, PREAUTH		well as pointing out security issues associated with ALERT, PREAUTH
	and other responses received before authentication.		and other responses received before authentication.
	Index		Index
	$		$
	$Forwarded (predefined flag) 12		$Forwarded (predefined flag) 13
	$Junk (predefined flag) 13		$Junk (predefined flag) 13
	$MDNSent (predefined flag) 13		$MDNSent (predefined flag) 13
	$NotJunk (predefined flag) 13		$NotJunk (predefined flag) 13
	$Phishing (predefined flag) 13		$Phishing (predefined flag) 13
	+		+
	+FLAGS <flag list> 93		+FLAGS <flag list> 97
	+FLAGS.SILENT <flag list> 93		+FLAGS.SILENT <flag list> 97
	-		-
	-FLAGS <flag list> 93		-FLAGS <flag list> 97
	-FLAGS.SILENT <flag list> 93		-FLAGS.SILENT <flag list> 97
	A		A
	ALERT (response code) 101		ALERT (response code) 105
	ALL (fetch item) 89		ALL (fetch item) 93
	ALL (search key) 79		ALL (search key) 82
	ALL (search result option) 77		ALL (search result option) 80
	ALL (search return item name) 118		ALL (search return item name) 122
	ALREADYEXISTS (response code) 101		ALREADYEXISTS (response code) 105
	ANSWERED (search key) 79		ANSWERED (search key) 82
	APPEND (command) 69		APPEND (command) 73
	APPENDUID (response code) 101		APPENDUID (response code) 105
	AUTHENTICATE (command) 30		AUTHENTICATE (command) 31
	AUTHENTICATIONFAILED (response code) 102		AUTHENTICATIONFAILED (response code) 106
	AUTHORIZATIONFAILED (response code) 102		AUTHORIZATIONFAILED (response code) 106
	B		B
	BAD (response) 109		BAD (response) 113
	BADCHARSET (response code) 102		BADCHARSET (response code) 106
	BCC <string> (search key) 79		BCC <string> (search key) 82
	BEFORE <date> (search key) 79		BEFORE <date> (search key) 82
	BINARY.PEEK[<section-binary>]<<partial>> (fetch item) 89		BINARY.PEEK[<section-binary>]<<partial>> (fetch item) 93
	BINARY.SIZE[<section-binary>] (fetch item) 90		BINARY.SIZE[<section-binary>] (fetch item) 94
	BINARY.SIZE[<section-binary>] (fetch result) 121		BINARY.SIZE[<section-binary>] (fetch result) 125
	BINARY[<section-binary>]<<number>> (fetch result) 120		BINARY[<section-binary>]<<number>> (fetch result) 124
	BINARY[<section-binary>]<<partial>> (fetch item) 89		BINARY[<section-binary>]<<partial>> (fetch item) 93
	BODY (fetch item) 90		BODY (fetch item) 94
	BODY (fetch result) 121		BODY (fetch result) 125
	BODY <string> (search key) 79		BODY <string> (search key) 82
	BODY.PEEK[<section>]<<partial>> (fetch item) 90		BODY.PEEK[<section>]<<partial>> (fetch item) 94
	BODYSTRUCTURE (fetch item) 91		BODYSTRUCTURE (fetch item) 95
	BODYSTRUCTURE (fetch result) 122		BODYSTRUCTURE (fetch result) 126
	BODY[<section>]<<origin octet>> (fetch result) 121		BODY[<section>]<<origin octet>> (fetch result) 125
	BODY[<section>]<<partial>> (fetch item) 90		BODY[<section>]<<partial>> (fetch item) 94
	BYE (response) 110		BYE (response) 114
	Body Structure (message attribute) 14		Body Structure (message attribute) 14
	C		C
	CANNOT (response code) 102		CANNOT (response code) 106
	CAPABILITY (command) 26		CAPABILITY (command) 27
	CAPABILITY (response code) 103		CAPABILITY (response code) 107
	CAPABILITY (response) 111		CAPABILITY (response) 115
	CC <string> (search key) 79		CC <string> (search key) 82
	CLIENTBUG (response code) 103		CLIENTBUG (response code) 107
	CLOSE (command) 75		CLOSE (command) 78
	CLOSED (response code) 103		CLOSED (response code) 107
	CONTACTADMIN (response code) 103		CONTACTADMIN (response code) 107
	COPY (command) 94		COPY (command) 98
	COPYUID (response code) 104		COPYUID (response code) 108
	CORRUPTION (response code) 104		CORRUPTION (response code) 108
	COUNT (search result option) 77		COUNT (search result option) 81
	COUNT (search return item name) 118		COUNT (search return item name) 122
	CREATE (command) 39		CREATE (command) 41
	D		D
	DELETE (command) 40		DELETE (command) 42
	DELETED (search key) 79		DELETED (search key) 83
	DELETED (status item) 69		DELETED (status item) 73
	DRAFT (search key) 79		DRAFT (search key) 83
	E		E
	ENABLE (command) 34		ENABLE (command) 36
	ENVELOPE (fetch item) 91		ENVELOPE (fetch item) 95
	ENVELOPE (fetch result) 125		ENVELOPE (fetch result) 129
	ESEARCH (response) 117		ESEARCH (response) 121
	EXAMINE (command) 38		EXAMINE (command) 40
	EXPIRED (response code) 104		EXPIRED (response code) 108
	EXPUNGE (command) 76		EXPUNGE (command) 79
	EXPUNGE (response) 119		EXPUNGE (response) 123
	EXPUNGEISSUED (response code) 104		EXPUNGEISSUED (response code) 108
	Envelope Structure (message attribute) 14		Envelope Structure (message attribute) 14
	F		F
	FAST (fetch item) 89		FAST (fetch item) 93
	FETCH (command) 88		FETCH (command) 92
	FETCH (response) 120		FETCH (response) 124
	FLAGGED (search key) 79		FLAGGED (search key) 83
	FLAGS (fetch item) 91		FLAGS (fetch item) 95
	FLAGS (fetch result) 126		FLAGS (fetch result) 130
	FLAGS (response) 119		FLAGS (response) 123
	FLAGS <flag list> (store command data item) 93		FLAGS <flag list> (store command data item) 97
	FLAGS.SILENT <flag list> (store command data item) 93		FLAGS.SILENT <flag list> (store command data item) 97
	FROM <string> (search key) 79		FROM <string> (search key) 83
	FULL (fetch item) 89		FULL (fetch item) 93
	Flags (message attribute) 12		Flags (message attribute) 12
	H		H
	HASCHILDREN (response code) 105		HASCHILDREN (response code) 109
	HEADER (part specifier) 91		HEADER (part specifier) 95
	HEADER <field-name> <string> (search key) 80		HEADER <field-name> <string> (search key) 83
	HEADER.FIELDS (part specifier) 91		HEADER.FIELDS (part specifier) 95
	HEADER.FIELDS.NOT (part specifier) 91		HEADER.FIELDS.NOT (part specifier) 95
	I		I
	IDLE (command) 72		IDLE (command) 76
	INTERNALDATE (fetch item) 91		INTERNALDATE (fetch item) 95
	INTERNALDATE (fetch result) 126		INTERNALDATE (fetch result) 130
	INUSE (response code) 105		INUSE (response code) 109
	Internal Date (message attribute) 14		Internal Date (message attribute) 14
	K		K
	KEYWORD <flag> (search key) 80		KEYWORD <flag> (search key) 83
	Keyword (type of flag) 12		Keyword (type of flag) 12
	L		L
	LARGER <n> (search key) 80		LARGER <n> (search key) 83
	LIMIT (response code) 105		LIMIT (response code) 109
	LIST (command) 46		LIST (command) 48
	LIST (response) 113		LIST (response) 117
	LOGOUT (command) 27		LOGOUT (command) 28
	M		M
	MAX (search result option) 77		MAX (search result option) 80
	MAX (search return item name) 118		MAX (search return item name) 122
	MAY (specification requirement term) 5		MAY (specification requirement term) 5
	MESSAGES (status item) 69		MESSAGES (status item) 72
	MIME (part specifier) 92		MIME (part specifier) 96
	MIN (search result option) 77		MIN (search result option) 80
	MIN (search return item name) 118		MIN (search return item name) 122
	MOVE (command) 95		MOVE (command) 99
	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) 64		NAMESPACE (command) 66
	NAMESPACE (response) 117		NAMESPACE (response) 121
	NO (response) 109		NO (response) 113
	NONEXISTENT (response code) 105		NONEXISTENT (response code) 109
	NOOP (command) 27		NOOP (command) 28
	NOPERM (response code) 106		NOPERM (response code) 110
	NOT <search-key> (search key) 80		NOT <search-key> (search key) 83
	NOT RECOMMENDED (specification requirement term) 5		NOT RECOMMENDED (specification requirement term) 5
	O		O
	OK (response) 109		OK (response) 113
	ON <date> (search key) 80		ON <date> (search key) 83
	OPTIONAL (specification requirement term) 5		OPTIONAL (specification requirement term) 5
	OR <search-key1> <search-key2> (search key) 80		OR <search-key1> <search-key2> (search key) 83
	OVERQUOTA (response code) 106		OVERQUOTA (response code) 110
	P		P
	PARSE (response code) 106		PARSE (response code) 110
	PERMANENTFLAGS (response code) 106		PERMANENTFLAGS (response code) 110
	PREAUTH (response) 110		PREAUTH (response) 114
	PRIVACYREQUIRED (response code) 107		PRIVACYREQUIRED (response code) 111
	Permanent Flag (class of flag) 13		Permanent Flag (class of flag) 14
	Predefined keywords 12		Predefined keywords 13
	R		R
	READ-ONLY (response code) 107		READ-ONLY (response code) 111
	READ-WRITE (response code) 107		READ-WRITE (response code) 111
	RECOMMENDED (specification requirement term) 5		RECOMMENDED (specification requirement term) 5
	RENAME (command) 42		RENAME (command) 44
	REQUIRED (specification requirement term) 5		REQUIRED (specification requirement term) 5
	RFC822.SIZE (fetch item) 91		RFC822.SIZE (fetch item) 95
	RFC822.SIZE (fetch result) 126		RFC822.SIZE (fetch result) 130
	S		S
	SAVE (search result option) 77		SAVE (search result option) 81
	SEARCH (command) 76		SEARCH (command) 79
	SEEN (search key) 80		SEEN (search key) 83
	SELECT (command) 36		SELECT (command) 38
	SENTBEFORE <date> (search key) 80		SENTBEFORE <date> (search key) 83
	SENTON <date> (search key) 80		SENTON <date> (search key) 83
	SENTSINCE <date> (search key) 80		SENTSINCE <date> (search key) 83
	SERVERBUG (response code) 107		SERVERBUG (response code) 111
	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) 80		SINCE <date> (search key) 84
	SIZE (status item) 69		SIZE (status item) 73
	SMALLER <n> (search key) 80		SMALLER <n> (search key) 84
	STARTTLS (command) 28		STARTTLS (command) 29
	STATUS (command) 68		STATUS (command) 71
	STATUS (response) 117		STATUS (response) 121
	STORE (command) 93		STORE (command) 97
	SUBJECT <string> (search key) 80		SUBJECT <string> (search key) 84
	SUBSCRIBE (command) 45		SUBSCRIBE (command) 47
	Session Flag (class of flag) 13		Session Flag (class of flag) 14
	System Flag (type of flag) 12		System Flag (type of flag) 12
	T		T
	TEXT (part specifier) 91		TEXT (part specifier) 95
	TEXT <string> (search key) 81		TEXT <string> (search key) 84
	TO <string> (search key) 81		TO <string> (search key) 84
	TRYCREATE (response code) 107		TRYCREATE (response code) 111
	U		U
	UID (command) 97		UID (command) 101
	UID (fetch item) 91		UID (fetch item) 95
	UID (fetch result) 126		UID (fetch result) 130
	UID <sequence set> (search key) 81		UID <sequence set> (search key) 84
	UIDNEXT (response code) 107		UIDNEXT (response code) 111
	UIDNEXT (status item) 69		UIDNEXT (status item) 72
	UIDNOTSTICKY (response code) 108		UIDNOTSTICKY (response code) 112
	UIDVALIDITY (response code) 108		UIDVALIDITY (response code) 112
	UIDVALIDITY (status item) 69		UIDVALIDITY (status item) 72
	UNANSWERED (search key) 81		UNANSWERED (search key) 84
	UNAVAILABLE (response code) 108		UNAVAILABLE (response code) 112
	UNDELETED (search key) 81		UNDELETED (search key) 84
	UNDRAFT (search key) 81		UNDRAFT (search key) 84
	UNFLAGGED (search key) 81		UNFLAGGED (search key) 84
	UNKEYWORD <flag> (search key) 81		UNKEYWORD <flag> (search key) 84
	UNKNOWN-CTE (response code) 108		UNKNOWN-CTE (response code) 112
	UNSEEN (search key) 81		UNSEEN (search key) 84
	UNSEEN (status item) 69		UNSEEN (status item) 73
	UNSELECT (command) 75		UNSELECT (command) 78
	UNSUBSCRIBE (command) 45		UNSUBSCRIBE (command) 47
	Unique Identifier (UID) (message attribute) 9		Unique Identifier (UID) (message attribute) 10
	[		[
	[RFC-5322] Size (message attribute) 14		[RFC-5322] Size (message attribute) 14
	\		\
	\All (mailbox name attribute) 115		\All (mailbox name attribute) 119
	\Answered (system flag) 12		\Answered (system flag) 12
	\Archive (mailbox name attribute) 115		\Archive (mailbox name attribute) 119
	\Deleted (system flag) 12		\Deleted (system flag) 12
	\Draft (system flag) 12		\Draft (system flag) 12
	\Drafts (mailbox name attribute) 115		\Drafts (mailbox name attribute) 119
	\Flagged (mailbox name attribute) 115		\Flagged (mailbox name attribute) 119
	\Flagged (system flag) 12		\Flagged (system flag) 12
	\HasChildren (mailbox name attribute) 114		\HasChildren (mailbox name attribute) 118
	\HasNoChildren (mailbox name attribute) 114		\HasNoChildren (mailbox name attribute) 118
	\Junk (mailbox name attribute) 115		\Junk (mailbox name attribute) 119
	\Marked (mailbox name attribute) 114		\Marked (mailbox name attribute) 118
	\Noinferiors (mailbox name attribute) 113		\Noinferiors (mailbox name attribute) 117
	\NonExistent (mailbox name attribute) 113		\NonExistent (mailbox name attribute) 117
	\Noselect (mailbox name attribute) 113		\Noselect (mailbox name attribute) 118
	\Recent (system flag) 12		\Recent (system flag) 12
	\Remote (mailbox name attribute) 114		\Remote (mailbox name attribute) 118
	\Seen (system flag) 12		\Seen (system flag) 12
	\Sent (mailbox name attribute) 115		\Sent (mailbox name attribute) 119
	\Subscribed (mailbox name attribute) 114		\Subscribed (mailbox name attribute) 118
	\Trash (mailbox name attribute) 115		\Trash (mailbox name attribute) 119
	\Unmarked (mailbox name attribute) 114		\Unmarked (mailbox name attribute) 118
	Authors' Addresses		Authors' Addresses
	Alexey Melnikov (editor)		Alexey Melnikov (editor)
	Isode Ltd		Isode Ltd
	14 Castle Mews		14 Castle Mews
	Hampton, Middlesex TW12 2NP		Hampton, Middlesex TW12 2NP
	UK		UK
	Email: Alexey.Melnikov@isode.com		Email: Alexey.Melnikov@isode.com
End of changes. 75 change blocks.
	344 lines changed or deleted		414 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/