idnits 2.17.1 draft-melnikov-dmap-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 18, 2015) is 3113 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'CHARSET' is defined on line 2428, but no explicit reference was found in the text == Unused Reference: 'DIGEST-MD5' is defined on line 2432, but no explicit reference was found in the text == Unused Reference: 'DISPOSITION' is defined on line 2437, but no explicit reference was found in the text == Unused Reference: 'PLAIN' is defined on line 2443, but no explicit reference was found in the text == Unused Reference: 'LANGUAGE-TAGS' is defined on line 2452, but no explicit reference was found in the text == Unused Reference: 'LOCATION' is defined on line 2456, but no explicit reference was found in the text == Unused Reference: 'MD5' is defined on line 2462, but no explicit reference was found in the text == Unused Reference: 'MIME-HDRS' is defined on line 2466, but no explicit reference was found in the text == Unused Reference: 'MIME-IMB' is defined on line 2472, but no explicit reference was found in the text == Unused Reference: 'MIME-IMT' is defined on line 2478, but no explicit reference was found in the text == Unused Reference: 'TLS' is defined on line 2491, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2831 (ref. 'DIGEST-MD5') (Obsoleted by RFC 6331) ** Obsolete normative reference: RFC 5246 (ref. 'TLS') (Obsoleted by RFC 8446) Summary: 3 errors (**), 0 flaws (~~), 13 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Melnikov, Ed. 3 Internet-Draft Isode Ltd 4 Intended status: Standards Track October 18, 2015 5 Expires: April 20, 2016 7 DMAP MESSAGE ACCESS PROTOCOL 8 draft-melnikov-dmap-00.txt 10 Abstract 12 The DMAP Message Access Protocol, Version 1 allows a client to access 13 and manipulate electronic mail messages on a server, without 14 revealing too much information about messages being accessed to the 15 server. DMAP permits manipulation of mailboxes (remote message 16 folders) in a way that is functionally equivalent to local folders. 17 DMAP also provides the capability for an offline client to 18 resynchronize with the server and for message submission. DMAP 19 supports discovery of keys (signets) belonging to other users the 20 client can communicate to. Syncronization and publication of keys 21 (private key, might include certificates) and signets (public part, 22 certificate). 24 DMAP includes operations for creating, deleting, and renaming 25 mailboxes, checking for new messages, permanently removing messages, 26 setting and clearing flags, RFC 5322 and RFC 2045 parsing, and 27 selective fetching of message attributes, texts, and portions 28 thereof. Messages in DMAP are accessed by the use of numbers. These 29 numbers are either message sequence numbers or unique identifiers. 31 Note: This document is a very early draft and omission of specific 32 syntax is intentional. It is intended to stimulate discussions about 33 specific protocol syntax and general design. 35 Status of This Memo 37 This Internet-Draft is submitted in full conformance with the 38 provisions of BCP 78 and BCP 79. 40 Internet-Drafts are working documents of the Internet Engineering 41 Task Force (IETF). Note that other groups may also distribute 42 working documents as Internet-Drafts. The list of current Internet- 43 Drafts is at http://datatracker.ietf.org/drafts/current/. 45 Internet-Drafts are draft documents valid for a maximum of six months 46 and may be updated, replaced, or obsoleted by other documents at any 47 time. It is inappropriate to use Internet-Drafts as reference 48 material or to cite them other than as "work in progress." 49 This Internet-Draft will expire on April 20, 2016. 51 Copyright Notice 53 Copyright (c) 2015 IETF Trust and the persons identified as the 54 document authors. All rights reserved. 56 This document is subject to BCP 78 and the IETF Trust's Legal 57 Provisions Relating to IETF Documents 58 (http://trustee.ietf.org/license-info) in effect on the date of 59 publication of this document. Please review these documents 60 carefully, as they describe your rights and restrictions with respect 61 to this document. Code Components extracted from this document must 62 include Simplified BSD License text as described in Section 4.e of 63 the Trust Legal Provisions and are provided without warranty as 64 described in the Simplified BSD License. 66 This document may contain material from IETF Documents or IETF 67 Contributions published or made publicly available before November 68 10, 2008. The person(s) controlling the copyright in some of this 69 material may not have granted the IETF Trust the right to allow 70 modifications of such material outside the IETF Standards Process. 71 Without obtaining an adequate license from the person(s) controlling 72 the copyright in such materials, this document may not be modified 73 outside the IETF Standards Process, and derivative works of it may 74 not be created outside the IETF Standards Process, except to format 75 it for publication as an RFC or to translate it into languages other 76 than English. 78 Table of Contents 80 1. How to Read This Document . . . . . . . . . . . . . . . . . . 4 81 1.1. Organization of This Document . . . . . . . . . . . . . . 4 82 1.2. Conventions Used in This Document . . . . . . . . . . . . 4 83 1.3. Special Notes to Implementors/To Do . . . . . . . . . . . 5 84 2. Design Goals . . . . . . . . . . . . . . . . . . . . . . . . 6 85 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 6 86 3.1. Link Level . . . . . . . . . . . . . . . . . . . . . . . 6 87 3.2. Commands and Responses . . . . . . . . . . . . . . . . . 7 88 3.2.1. Client Protocol Sender and Server Protocol Receiver . 7 89 3.2.2. Server Protocol Sender and Client Protocol Receiver . 8 90 3.3. Message Attributes . . . . . . . . . . . . . . . . . . . 8 91 3.3.1. Message Numbers . . . . . . . . . . . . . . . . . . . 9 92 3.3.2. Flags Message Attribute . . . . . . . . . . . . . . . 11 93 3.3.3. Internal Date Message Attribute . . . . . . . . . . . 12 94 3.3.4. Size Message Attribute . . . . . . . . . . . . . . . 12 95 3.3.5. Body Structure Message Attribute . . . . . . . . . . 12 96 3.3.6. Modification Sequence (MODSEQ) Message Attribute . . 12 98 3.4. Message Texts . . . . . . . . . . . . . . . . . . . . . . 13 99 4. State and Flow Diagram . . . . . . . . . . . . . . . . . . . 13 100 4.1. Not Authenticated State . . . . . . . . . . . . . . . . . 13 101 4.2. Authenticated State . . . . . . . . . . . . . . . . . . . 13 102 4.3. Selected State . . . . . . . . . . . . . . . . . . . . . 13 103 4.4. Logout State . . . . . . . . . . . . . . . . . . . . . . 13 104 5. Data Formats . . . . . . . . . . . . . . . . . . . . . . . . 15 105 5.1. Atom . . . . . . . . . . . . . . . . . . . . . . . . . . 16 106 5.2. Number . . . . . . . . . . . . . . . . . . . . . . . . . 16 107 5.3. String . . . . . . . . . . . . . . . . . . . . . . . . . 16 108 5.3.1. 8-bit and Binary Strings . . . . . . . . . . . . . . 16 109 5.4. Parenthesized List . . . . . . . . . . . . . . . . . . . 16 110 5.5. NIL . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 111 6. Operational Considerations . . . . . . . . . . . . . . . . . 17 112 6.1. Mailbox Naming . . . . . . . . . . . . . . . . . . . . . 17 113 6.1.1. Mailbox Hierarchy Naming . . . . . . . . . . . . . . 18 114 6.2. Mailbox Size and Message Status Updates . . . . . . . . . 18 115 6.3. Response when no Command in Progress . . . . . . . . . . 18 116 6.4. Autologout Timer . . . . . . . . . . . . . . . . . . . . 19 117 6.5. Multiple Commands in Progress (Command Pipelining) . . . 19 118 7. Client Commands . . . . . . . . . . . . . . . . . . . . . . . 19 119 7.1. Client Commands - Any State . . . . . . . . . . . . . . . 20 120 7.1.1. CAPABILITY Command . . . . . . . . . . . . . . . . . 20 121 7.1.2. NOOP Command . . . . . . . . . . . . . . . . . . . . 21 122 7.1.3. LOGOUT Command . . . . . . . . . . . . . . . . . . . 21 123 7.2. Client Commands - Not Authenticated State . . . . . . . . 21 124 7.2.1. AUTHENTICATE Command . . . . . . . . . . . . . . . . 22 125 7.3. Client Commands - Authenticated State . . . . . . . . . . 24 126 7.3.1. SELECT Command . . . . . . . . . . . . . . . . . . . 24 127 7.3.2. EXAMINE Command . . . . . . . . . . . . . . . . . . . 25 128 7.3.3. CREATE Command . . . . . . . . . . . . . . . . . . . 25 129 7.3.4. DELETE Command . . . . . . . . . . . . . . . . . . . 26 130 7.3.5. RENAME Command . . . . . . . . . . . . . . . . . . . 27 131 7.3.6. SUBSCRIBE Command . . . . . . . . . . . . . . . . . . 28 132 7.3.7. UNSUBSCRIBE Command . . . . . . . . . . . . . . . . . 28 133 7.3.8. LIST Command . . . . . . . . . . . . . . . . . . . . 29 134 7.3.9. STATUS Command . . . . . . . . . . . . . . . . . . . 30 135 7.3.10. APPEND Command . . . . . . . . . . . . . . . . . . . 31 136 7.4. Client Commands - Authenticated State - Key Ring 137 Management . . . . . . . . . . . . . . . . . . . . . . . 32 138 7.4.1. GETKEY Command . . . . . . . . . . . . . . . . . . . 32 139 7.4.2. ADDKEY Command . . . . . . . . . . . . . . . . . . . 32 140 7.4.3. DELETEKEY Command . . . . . . . . . . . . . . . . . . 33 141 7.4.4. LISTKEYS Command . . . . . . . . . . . . . . . . . . 33 142 7.5. Client Commands - Authenticated State - Signet Ring 143 Management . . . . . . . . . . . . . . . . . . . . . . . 33 144 7.6. Client Commands - Selected State . . . . . . . . . . . . 33 145 7.6.1. CLOSE Command . . . . . . . . . . . . . . . . . . . . 34 146 7.6.2. EXPUNGE Command . . . . . . . . . . . . . . . . . . . 34 147 7.6.3. SEARCH Command . . . . . . . . . . . . . . . . . . . 35 148 7.6.4. FETCH Command . . . . . . . . . . . . . . . . . . . . 36 149 7.6.5. STORE Command . . . . . . . . . . . . . . . . . . . . 38 150 7.6.6. COPY Command . . . . . . . . . . . . . . . . . . . . 39 151 7.6.7. SUBMIT Command . . . . . . . . . . . . . . . . . . . 40 152 7.6.8. UID Command . . . . . . . . . . . . . . . . . . . . . 41 153 7.7. Client Commands - Experimental/Expansion . . . . . . . . 42 154 7.7.1. X Command . . . . . . . . . . . . . . . . . . . 43 155 8. Server Responses . . . . . . . . . . . . . . . . . . . . . . 43 156 8.1. Server Responses - Status Responses . . . . . . . . . . . 44 157 8.1.1. OK Response . . . . . . . . . . . . . . . . . . . . . 45 158 8.1.2. NO Response . . . . . . . . . . . . . . . . . . . . . 46 159 8.1.3. BAD Response . . . . . . . . . . . . . . . . . . . . 46 160 8.1.4. PREAUTH Response . . . . . . . . . . . . . . . . . . 46 161 8.1.5. BYE Response . . . . . . . . . . . . . . . . . . . . 47 162 8.2. Server Responses - Server and Mailbox Status . . . . . . 47 163 8.2.1. CAPABILITY Response . . . . . . . . . . . . . . . . . 48 164 8.2.2. STATUS Response . . . . . . . . . . . . . . . . . . . 48 165 8.2.3. FLAGS Response . . . . . . . . . . . . . . . . . . . 49 166 8.3. Server Responses - Mailbox Size . . . . . . . . . . . . . 49 167 8.3.1. EXISTS Response . . . . . . . . . . . . . . . . . . . 49 168 8.4. Server Responses - Message Status . . . . . . . . . . . . 49 169 8.4.1. FETCH Response . . . . . . . . . . . . . . . . . . . 49 170 8.5. Server Responses - Command Continuation Request . . . . . 51 171 9. Sample DMAP connection . . . . . . . . . . . . . . . . . . . 51 172 10. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 51 173 11. Security Considerations . . . . . . . . . . . . . . . . . . . 52 174 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 52 175 13. Normative References . . . . . . . . . . . . . . . . . . . . 52 176 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 54 177 Appendix B. Acknowledgement . . . . . . . . . . . . . . . . . . 54 178 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 179 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 57 181 1. How to Read This Document 183 1.1. Organization of This Document 185 1.2. Conventions Used in This Document 187 "Conventions" are basic principles or procedures. Document 188 conventions are noted in this section. 190 In examples, "C:" and "S:" indicate lines sent by the client and 191 server respectively. 193 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 194 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 195 document are to be interpreted as described in [KEYWORDS]. 197 The word "can" (not "may") is used to refer to a possible 198 circumstance or situation, as opposed to an optional facility of the 199 protocol. 201 "User" is used to refer to a human user, whereas "client" refers to 202 the software being run by the user. 204 "Connection" refers to the entire sequence of client/server 205 interaction from the initial establishment of the network connection 206 until its termination. 208 "Session" refers to the sequence of client/server interaction from 209 the time that a mailbox is selected (SELECT or EXAMINE command) until 210 the time that selection ends (SELECT or EXAMINE of another mailbox, 211 CLOSE command, or connection termination). 213 Characters are 8-bit UTF-8 unless otherwise specified. 215 1.3. Special Notes to Implementors/To Do 217 [[CREF1: This section needs to be rewritten or removed before 218 publication.]] 220 This specification is experimental. While early implementations are 221 encouraged, there are lots of open issues and possibility for 222 drastical change to the protocol. Implementors are enouraged to 223 contact authors of this specification before starting implementing 224 this specification. 226 The following changes are planned (this is not an exhaustive list): 228 Include LITERAL+ syntax. 230 Incorporate IDLE 232 Merge LIST and STATUS into a single command 234 Fix the mailbox (folder) hierarchy separator character to be "." 236 Reorganize sections to group command by purpose. 238 2. Design Goals 240 This protocols strives to satisfy the following goals (note that some 241 of the goals are in conflict, so certain compromises were made): 243 Any DMAP connection is always protected by TLS. [[CREF2: Add text 244 about server TLS identity verification.]] 246 Most of the message content and associated metadata is encrypted 247 with a key only known to DMAP clients, so DMAP servers get very 248 limited access to user data. 250 Open Issue: should the list of mailbox names be accessible to 251 the server (unencrypted)? What about their attributes (e.g. 252 mailbox roles, such as Sent or Drafts)? It might still be 253 possible for a server (or MITM attacker) to figure out mailbox 254 roles based on usage pattern. 256 Open Issue: should it be possible for the server to search for 257 messages which contain a particular message flag (in that case 258 such flags should be stored unencrypted)? 260 Open Issue: is it useful to support searching for all messages 261 from or to a particular domain? (Compare this with searching 262 for a particular sender/recipient, which is useful) 264 The protocol allows for efficient bandwidth usage for mobile 265 clients. For example, it should be possible to download a message 266 body structure, which is much smaller than the message itself and 267 allows the client to decide which body parts is worth downloading. 268 Also, it should be possible to download binary body parts (without 269 any Content Transfer Encoding). 271 Submission of new messages through DMAP is supported in order to 272 make client configuration easier. 274 The best bits of the IMAP protocol are reused, making 275 implementations slightly easier. 277 3. Protocol Overview 279 3.1. Link Level 281 The DMAP protocol assumes a reliable data stream such as that 282 provided by TCP. When TCP is used, an DMAP server listens on port 283 XXX. 285 3.2. Commands and Responses 287 An DMAP connection consists of the establishment of a client/server 288 network connection, mandatory TLS authentication exchange . Once TLS 289 exchange completes successfully the connection proceeds with an 290 initial greeting from the server, and client/server interactions. 291 These client/server interactions consist of a client command, server 292 data, and a server completion result response. 294 [[CREF3: Might need revising if this changes.]]> All interactions 295 transmitted by client and server are in the form of lines, that is, 296 strings that end with a CRLF. The protocol receiver of an DMAP 297 client or server is either reading a line, or is reading a sequence 298 of octets with a known count followed by a line. 300 3.2.1. Client Protocol Sender and Server Protocol Receiver 302 The client command begins an operation. Each client command is 303 prefixed with an identifier (typically a short alphanumeric string, 304 e.g., A0001, A0002, etc.) called a "tag". A different tag is 305 generated by the client for each command. 307 Clients MUST follow the syntax outlined in this specification 308 strictly. It is a syntax error to send a command with missing or 309 extraneous spaces or arguments. 311 There are two cases in which a line from the client does not 312 represent a complete command. In one case, a command argument is 313 quoted with an octet count (see the description of literal in String 314 under Data Formats); in the other case, the command arguments require 315 server feedback (see the AUTHENTICATE command). In either case, the 316 server sends a command continuation request response if it is ready 317 for the octets (if appropriate) and the remainder of the command. 318 This response is prefixed with the token "+". 320 Note: If instead, the server detected an error in the command, it 321 sends a BAD completion response with a tag matching the command 322 (as described below) to reject the command and prevent the client 323 from sending any more of the command. 325 It is also possible for the server to send a completion response 326 for some other command (if multiple commands are in progress), or 327 untagged data. In either case, the command continuation request 328 is still pending; the client takes the appropriate action for the 329 response, and reads another response from the server. In all 330 cases, the client MUST send a complete command (including 331 receiving all command continuation request responses and command 332 continuations for the command) before initiating a new command. 334 The protocol receiver of an DMAP server reads a command line from the 335 client, parses the command and its arguments, and transmits server 336 data and a server command completion result response. 338 3.2.2. Server Protocol Sender and Client Protocol Receiver 340 Data transmitted by the server to the client and status responses 341 that do not indicate command completion are prefixed with the token 342 "*", and are called untagged responses. 344 Server data MAY be sent as a result of a client command, or MAY be 345 sent unilaterally by the server. There is no syntactic difference 346 between server data that resulted from a specific command and server 347 data that were sent unilaterally. 349 The server completion result response indicates the success or 350 failure of the operation. It is tagged with the same tag as the 351 client command which began the operation. Thus, if more than one 352 command is in progress, the tag in a server completion response 353 identifies the command to which the response applies. There are 354 three possible server completion responses: OK (indicating success), 355 NO (indicating failure), or BAD (indicating a protocol error such as 356 unrecognized command or command syntax error). 358 Servers SHOULD enforce the syntax outlined in this specification 359 strictly. Any client command with a protocol syntax error, including 360 (but not limited to) missing or extraneous spaces or arguments, 361 SHOULD be rejected, and the client given a BAD server completion 362 response. 364 The protocol receiver of an DMAP client reads a response line from 365 the server. It then takes action on the response based upon the 366 first token of the response, which can be a tag, a "*", or a "+". 368 A client MUST be prepared to accept any server response at all times. 369 This includes server data that was not requested. Server data SHOULD 370 be recorded, so that the client can reference its recorded copy 371 rather than sending a command to the server to request the data. In 372 the case of certain server data, the data MUST be recorded. 374 This topic is discussed in greater detail in the Server Responses 375 section. 377 3.3. Message Attributes 379 In addition to message text, each message has several attributes 380 associated with it. These attributes can be retrieved individually 381 or in conjunction with other attributes or message texts. 383 3.3.1. Message Numbers 385 TBD: decide if message sequence numbers are needed 387 Messages in DMAP are accessed by one of two numbers; the unique 388 identifier or the message sequence number. 390 3.3.1.1. Unique Identifier (UID) Message Attribute 392 An unsigned 32-bit value assigned to each message, which when used 393 with the unique identifier validity value (see below) forms a 64-bit 394 value that MUST NOT refer to any other message in the mailbox or any 395 subsequent mailbox with the same name forever. Unique identifiers 396 are assigned in a strictly ascending fashion in the mailbox; as each 397 message is added to the mailbox it is assigned a higher UID than the 398 message(s) which were added previously. Unlike message sequence 399 numbers, unique identifiers are not necessarily contiguous. 401 The unique identifier of a message MUST NOT change during the 402 session, and SHOULD NOT change between sessions. Any change of 403 unique identifiers between sessions MUST be detectable using the 404 UIDVALIDITY mechanism discussed below. Persistent unique identifiers 405 are required for a client to resynchronize its state from a previous 406 session with the server (e.g., disconnected or offline access 407 clients). 409 Associated with every mailbox are two 32-bit unsigned values which 410 aid in unique identifier handling: the next unique identifier value 411 (UIDNEXT) and the unique identifier validity value (UIDVALIDITY). 413 The next unique identifier value is the predicted value that will be 414 assigned to a new message in the mailbox. Unless the unique 415 identifier validity also changes (see below), the next unique 416 identifier value MUST have the following two characteristics. First, 417 the next unique identifier value MUST NOT change unless new messages 418 are added to the mailbox; and second, the next unique identifier 419 value MUST change whenever new messages are added to the mailbox, 420 even if those new messages are subsequently expunged. 422 Note: The next unique identifier value is intended to provide a 423 means for a client to determine whether any messages have been 424 delivered to the mailbox since the previous time it checked this 425 value. It is not intended to provide any guarantee that any 426 message will have this unique identifier. A client can only 427 assume, at the time that it obtains the next unique identifier 428 value, that messages arriving after that time will have a UID 429 greater than or equal to that value. 431 The unique identifier validity value is sent in a UIDVALIDITY 432 response code in an OK untagged response at mailbox selection time. 434 Unique identifiers MUST persist at all times. The following 435 considerations about unique identifiers apply: 437 1. Unique identifiers MUST be strictly ascending in the mailbox 438 at all times. If the physical message store is re-ordered (or 439 messages are modified) by a non-DMAP agent, this requires that 440 the unique identifiers in the mailbox be regenerated, since 441 the former unique identifiers are no longer strictly ascending 442 as a result of the re-ordering. 444 2. If the mailbox is deleted and a new mailbox with the same name 445 is created at a later date (or another mailbox is renamed to 446 have the name of a previously deleted or renamed mailbox), the 447 server must either keep track of unique identifiers from the 448 previous instance of the mailbox, or it must assign a new 449 UIDVALIDITY value to the new instance of the mailbox. A good 450 UIDVALIDITY value to use in this case is a 32-bit 451 representation of the creation date/time of the mailbox. It 452 is alright to use a constant such as 1, but only if it 453 guaranteed that unique identifiers will never be reused, even 454 in the case of a mailbox being deleted (or renamed) and a new 455 mailbox by the same name created at some future time. 457 3. The combination of mailbox name, UIDVALIDITY, and UID must 458 refer to a single immutable message on that server forever. 459 In particular, the internal date, message size, body 460 structure, and message texts (all BODY[...] fetch data items) 461 must never change. This does not include message numbers, nor 462 does it include attributes that can be set by a STORE command 463 (e.g., FLAGS). 465 3.3.1.2. Message Sequence Number Message Attribute 467 A relative position from 1 to the number of messages in the mailbox. 468 This position MUST be ordered by ascending unique identifier. As 469 each new message is added, it is assigned a message sequence number 470 that is 1 higher than the number of messages in the mailbox before 471 that new message was added. 473 Message sequence numbers can be reassigned during the session. For 474 example, when a message is permanently removed (expunged) from the 475 mailbox, the message sequence number for all subsequent messages is 476 decremented. The number of messages in the mailbox is also 477 decremented. Similarly, a new message can be assigned a message 478 sequence number that was once held by some other message prior to an 479 expunge. 481 In addition to accessing messages by relative position in the 482 mailbox, message sequence numbers can be used in mathematical 483 calculations. For example, if an untagged "11 EXISTS" is received, 484 and previously an untagged "8 EXISTS" was received, three new 485 messages have arrived with message sequence numbers of 9, 10, and 11. 486 Another example, if message 287 in a 523 message mailbox has UID 487 12345, there are exactly 286 messages which have lesser UIDs and 236 488 messages which have greater UIDs. 490 3.3.2. Flags Message Attribute 492 A list of zero or more named tokens associated with the message. A 493 flag is set by its addition to this list, and is cleared by its 494 removal. There are two types of flags in DMAP. A flag of either 495 type can be permanent or session-only. 497 A system flag is a flag name that is pre-defined in this 498 specification. All system flags begin with "\". Certain system 499 flags (\Deleted and \Seen) have special semantics described 500 elsewhere. The currently-defined system flags are: [[CREF4: Alexey: 501 some of these should be moved to the encrypted per message metadata 502 block.]] 504 \Seen Message has been read. 506 \Answered Message has been answered. 508 \Forwarded Message has been forwarded. 510 \Flagged Message is "flagged" for urgent/special attention. 512 \Deleted Message is "deleted" for removal by later EXPUNGE. 514 \Draft Message has not completed composition (marked as a draft). 516 \Submitted and \SubmitPending The \SubmitPending flag designates the 517 message as awaiting to be submitted. This keyword allows storing 518 messages waiting to be submitted in the same mailbox where 519 messages that were already submitted and/or are being edited are 520 stored. A mail client sets this flag when it decides that the 521 message needs to be sent out. When a client (it might be a 522 different client from the one that decided that the message is 523 pending submission) starts sending the message, it atomically adds 524 the \Submitted flag. Once submission is successful, the 525 \SubmitPending flag is atomically cleared. The two flags allow 526 messages being actively submitted (messages that have both 527 \Submitted and \SubmitPending flags set) to be distinguished from 528 messages awaiting to be submitted, or from messages already 529 submitted. They also allow all messages that were supposed to be 530 submitted to be found, if the client submitting them crashes or 531 quits before submitting them. [[CREF5: Update SUBMIT to also talk 532 about these flags.]] 534 A keyword is defined by the server implementation. Keywords do not 535 begin with "\". Servers MAY permit the client to define new keywords 536 in the mailbox (see the description of the PERMANENTFLAGS response 537 code for more information). Keywords registered in documents that 538 extend this specification SHOULD start with "$". 540 A flag can be permanent or session-only on a per-flag basis. 541 Permanent flags are those which the client can add or remove from the 542 message flags permanently; that is, concurrent and subsequent 543 sessions will see any change in permanent flags. Changes to session 544 flags are valid only in that session. 546 3.3.3. Internal Date Message Attribute 548 The internal date and time of the message on the server. This is not 549 the date and time in the [RFC-5322] header, but rather a date and 550 time which reflects when the message was received. In the case of 551 messages delivered via DMTP , this SHOULD be the date and time of 552 final delivery of the message. In the case of messages delivered by 553 the DMAP COPY command, this SHOULD be the internal date and time of 554 the source message. In the case of messages delivered by the DMAP 555 APPEND command, this SHOULD be the date and time as specified in the 556 APPEND command description. All other cases are implementation 557 defined. 559 3.3.4. Size Message Attribute 561 The number of octets in the message. 563 3.3.5. Body Structure Message Attribute 565 A parsed representation of the body structure information of the 566 message. 568 3.3.6. Modification Sequence (MODSEQ) Message Attribute 570 A 63 bits positive integer that gets incremented every time there is 571 a change to one of mutable attributes of a message. (Currently such 572 mutable attributes only include message flags). 574 3.4. Message Texts 576 In addition to being able to fetch the full text of a message, DMAP 577 permits the fetching of portions of the full message. Specifically, 578 it is possible to fetch any message chunk. 580 4. State and Flow Diagram 582 Once the connection between client and server is established, an DMAP 583 connection is in one of four states. The initial state is identified 584 in the server greeting. Most commands are only valid in certain 585 states. It is a protocol error for the client to attempt a command 586 while the connection is in an inappropriate state, and the server 587 will respond with a BAD or NO (depending upon server implementation) 588 command completion result. 590 4.1. Not Authenticated State 592 In the not authenticated state, the client MUST supply authentication 593 credentials before most commands will be permitted. This state is 594 entered when a connection starts unless the connection has been pre- 595 authenticated. 597 4.2. Authenticated State 599 In the authenticated state, the client is authenticated and MUST 600 select a mailbox to access before commands that affect messages will 601 be permitted. This state is entered when a pre-authenticated 602 connection starts, when acceptable authentication credentials have 603 been provided, after an error in selecting a mailbox, or after a 604 successful CLOSE command. 606 4.3. Selected State 608 TBD: Decide if Selected state can be eliminated entirely 610 In a selected state, a mailbox has been selected to access. This 611 state is entered when a mailbox has been successfully selected. 613 4.4. Logout State 615 In the logout state, the connection is being terminated. This state 616 can be entered as a result of a client request (via the LOGOUT 617 command) or by unilateral action on the part of either the client or 618 server. 620 If the client requests the logout state, the server MUST send an 621 untagged BYE response and a tagged OK response to the LOGOUT command 622 before the server closes the connection; and the client MUST read the 623 tagged OK response to the LOGOUT command before the client closes the 624 connection. 626 A server MUST NOT unilaterally close the connection without sending 627 an untagged BYE response that contains the reason for having done so. 628 A client SHOULD NOT unilaterally close the connection, and instead 629 SHOULD issue a LOGOUT command. If the server detects that the client 630 has unilaterally closed the connection, the server MAY omit the 631 untagged BYE response and simply close its connection. 633 +----------------------+ 634 |connection established| 635 +----------------------+ 636 || 637 \/ 638 +--------------------------------------+ 639 | server greeting | 640 +--------------------------------------+ 641 || (1) || (2) || (3) 642 \/ || || 643 +-----------------+ || || 644 |Not Authenticated| || || 645 +-----------------+ || || 646 || (7) || (4) || || 647 || \/ \/ || 648 || +----------------+ || 649 || | Authenticated |<=++ || 650 || +----------------+ || || 651 || || (7) || (5) || (6) || 652 || || \/ || || 653 || || +--------+ || || 654 || || |Selected|==++ || 655 || || +--------+ || 656 || || || (7) || 657 \/ \/ \/ \/ 658 +--------------------------------------+ 659 | Logout | 660 +--------------------------------------+ 661 || 662 \/ 663 +-------------------------------+ 664 |both sides close the connection| 665 +-------------------------------+ 667 (1) connection without pre-authentication (OK greeting) 668 (2) pre-authenticated connection (PREAUTH greeting) 669 (3) rejected connection (BYE greeting) 670 (4) successful AUTHENTICATE command 671 (5) successful SELECT or EXAMINE command 672 (6) CLOSE command, or failed SELECT or EXAMINE command 673 (7) LOGOUT command, server shutdown, or connection closed 675 5. Data Formats 677 DMAP uses textual commands and responses. Data in DMAP can be in one 678 of several forms: atom, number, string, parenthesized list, or NIL. 679 Note that a particular data item may take more than one form; for 680 example, a data item defined as using "astring" syntax may be either 681 an atom or a string. 683 5.1. Atom 685 An atom consists of one or more non-special characters. 687 5.2. Number 689 A number consists of one or more digit characters, and represents a 690 numeric value. 692 5.3. String 694 A string is in one of two forms: either literal or quoted string. 695 The literal form is the general form of string. The quoted string 696 form is an alternative that avoids the overhead of processing a 697 literal at the cost of limitations of characters which may be used. 699 A literal is a sequence of zero or more octets (including CR and LF), 700 prefix-quoted with an octet count in the form of an open brace ("{"), 701 the number of octets, close brace ("}"), and CRLF. In the case of 702 literals transmitted from server to client, the CRLF is immediately 703 followed by the octet data. In the case of literals transmitted from 704 client to server, the client MUST wait to receive a command 705 continuation request (described later in this document) before 706 sending the octet data (and the remainder of the command). 708 A quoted string is a sequence of zero or more 7-bit characters, 709 excluding CR and LF, with double quote (<">) characters at each end. 711 The empty string is represented as either "" (a quoted string with 712 zero characters between double quotes) or as {0} followed by CRLF (a 713 literal with an octet count of 0). 715 Note: Even if the octet count is 0, a client transmitting a 716 literal MUST wait to receive a command continuation request. 718 5.3.1. 8-bit and Binary Strings 720 ...Include direct support for BINARY-like literals. 722 5.4. Parenthesized List 724 Data structures are represented as a "parenthesized list"; a sequence 725 of data items, delimited by space, and bounded at each end by 726 parentheses. A parenthesized list can contain other parenthesized 727 lists, using multiple levels of parentheses to indicate nesting. 729 The empty list is represented as () -- a parenthesized list with no 730 members. 732 5.5. NIL 734 The special form "NIL" represents the non-existence of a particular 735 data item that is represented as a string or parenthesized list, as 736 distinct from the empty string "" or the empty parenthesized list (). 738 Note: NIL is never used for any data item which takes the form of 739 an atom. For example, a mailbox name of "NIL" is a mailbox named 740 NIL as opposed to a non-existent mailbox name. This is because 741 mailbox uses "astring" syntax which is an atom or a string. 742 Conversely, an addr-name of NIL is a non-existent personal name, 743 because addr-name uses "nstring" syntax which is NIL or a string, 744 but never an atom. 746 6. Operational Considerations 748 The following rules are listed here to ensure that all DMAP 749 implementations interoperate properly. 751 6.1. Mailbox Naming 753 Mailbox names are encoded in UTF-8. 755 The case-insensitive mailbox name INBOX is a special name reserved to 756 mean "the primary mailbox for this user on this server". The 757 interpretation of all other names is implementation-dependent. 759 In particular, this specification takes no position on case 760 sensitivity in non-INBOX mailbox names. Some server implementations 761 are fully case-sensitive; others preserve case of a newly-created 762 name but otherwise are case-insensitive; and yet others coerce names 763 to a particular case. Client implementations MUST interact with any 764 of these. 766 There are certain client considerations when creating a new mailbox 767 name: 769 1. Any character which is one of the atom-specials (see the Formal 770 Syntax) will require that the mailbox name be represented as a 771 quoted string or literal. 773 2. CTL and other non-graphic characters are difficult to represent 774 in a user interface and are thus disallowed. 776 3. Although the list-wildcard characters ("%" and "*") are valid in 777 a mailbox name, it is difficult to use such mailbox names with 778 the LIST command due to the conflict with wildcard 779 interpretation. 781 4. The "/" character is reserved to delimit levels of hierarchy. 783 6.1.1. Mailbox Hierarchy Naming 785 If it is desired to export hierarchical mailbox names, mailbox names 786 MUST be left-to-right hierarchical using a single "/" character to 787 separate levels of hierarchy. 789 6.2. Mailbox Size and Message Status Updates 791 At any time, a server can send data that the client did not request. 792 Sometimes, such behavior is REQUIRED. For example, agents other than 793 the server MAY add messages to the mailbox (e.g., new message 794 delivery), change the flags of the messages in the mailbox (e.g., 795 simultaneous access to the same mailbox by multiple agents), or even 796 remove messages from the mailbox. A server MUST send mailbox size 797 updates automatically if a mailbox size change is observed during the 798 processing of a command. A server SHOULD send message flag updates 799 automatically, without requiring the client to request such updates 800 explicitly. 802 Special rules exist for server notification of a client about the 803 removal of messages to prevent synchronization errors; see the 804 description of the EXPUNGE response for more detail. In particular, 805 it is NOT permitted to send an EXISTS response that would reduce the 806 number of messages in the mailbox; only the EXPUNGE response can do 807 this. 809 Regardless of what implementation decisions a client makes on 810 remembering data from the server, a client implementation MUST record 811 mailbox size updates. It MUST NOT assume that any command after the 812 initial mailbox selection will return the size of the mailbox. 814 6.3. Response when no Command in Progress 816 Server implementations are permitted to send an untagged response 817 (except for EXPUNGE) while there is no command in progress. Server 818 implementations that send such responses MUST deal with flow control 819 considerations. Specifically, they MUST either (1) verify that the 820 size of the data does not exceed the underlying transport's available 821 window size, or (2) use non-blocking writes. 823 6.4. Autologout Timer 825 If a server has an inactivity autologout timer that applies to 826 sessions after authentication, the duration of that timer MUST be at 827 least 30 minutes. The receipt of ANY command from the client during 828 that interval SHOULD suffice to reset the autologout timer. 830 6.5. Multiple Commands in Progress (Command Pipelining) 832 The client MAY send another command without waiting for the 833 completion result response of a command, subject to ambiguity rules 834 (see below) and flow control constraints on the underlying data 835 stream. Similarly, a server MAY begin processing another command 836 before processing the current command to completion, subject to 837 ambiguity rules. However, any command continuation request responses 838 and command continuations MUST be negotiated before any subsequent 839 command is initiated. 841 The exception is if an ambiguity would result because of a command 842 that would affect the results of other commands. Clients MUST NOT 843 send multiple commands without waiting if an ambiguity would result. 844 If the server detects a possible ambiguity, it MUST execute commands 845 to completion in the order given by the client. 847 7. Client Commands 849 DMAP commands are described in this section. Commands are organized 850 by the state in which the command is permitted. Commands which are 851 permitted in multiple states are listed in the minimum permitted 852 state (for example, commands valid in authenticated and selected 853 state are listed in the authenticated state commands). 855 Command arguments, identified by "Arguments:" in the command 856 descriptions below, are described by function, not by syntax. The 857 precise syntax of command arguments is described in the Formal Syntax 858 (Section 10). 860 Some commands cause specific server responses to be returned; these 861 are identified by "Responses:" in the command descriptions below. 862 See the response descriptions in the Responses section for 863 information on these responses, and the Formal Syntax section for the 864 precise syntax of these responses. It is possible for server data to 865 be transmitted as a result of any command. Thus, commands that do 866 not specifically require server data specify "no specific responses 867 for this command" instead of "none". 869 The "Result:" in the command description refers to the possible 870 tagged status responses to a command, and any special interpretation 871 of these status responses. 873 The state of a connection is only changed by successful commands 874 which are documented as changing state. A rejected command (BAD 875 response) never changes the state of the connection or of the 876 selected mailbox. A failed command (NO response) generally does not 877 change the state of the connection or of the selected mailbox; the 878 exception being the SELECT and EXAMINE commands. 880 7.1. Client Commands - Any State 882 The following commands are valid in any state: CAPABILITY, NOOP, and 883 LOGOUT. 885 7.1.1. CAPABILITY Command 887 Arguments: none 889 Responses: REQUIRED untagged response: CAPABILITY 891 Result: OK - capability completed 892 BAD - command unknown or arguments invalid 894 The CAPABILITY command requests a listing of capabilities that the 895 server supports. The server MUST send a single untagged CAPABILITY 896 response with "DMAP=..." (see below) as one of the listed 897 capabilities before the (tagged) OK response. 899 The DMAP= capability describes in which mode DMAP operates. It MUST 900 be followed by one of "TRUSTFUL", "CAUTIOUS" or "PARANOID". [[CREF6: 901 Add more details about different modes and how they change the 902 behaviour]] 904 A capability name which begins with "AUTH=" indicates that the server 905 supports that particular authentication mechanism. All such names 906 are, by definition, part of this specification. For example, the 907 authorization capability for an experimental "blurdybloop" 908 authenticator would be "AUTH=XBLURDYBLOOP" and not 909 "XAUTH=BLURDYBLOOP" or "XAUTH=XBLURDYBLOOP". 911 Other capability names refer to extensions, revisions, or amendments 912 to this specification. See the documentation of the CAPABILITY 913 response for additional information. No capabilities, beyond the 914 base DMAP set defined in this specification, are enabled without 915 explicit client action to invoke the capability. 917 See the section entitled "Client Commands - Experimental/Expansion" 918 for information about the form of site or implementation-specific 919 capabilities. 921 7.1.2. NOOP Command 923 Arguments: none 925 Responses: no specific responses for this command (but see below) 927 Result: OK - noop completed 928 BAD - arguments invalid 930 The NOOP command always succeeds. It does nothing. 932 Since any command can return a status update as untagged data, the 933 NOOP command can be used as a periodic poll for new messages or 934 message status updates during a period of inactivity (this is the 935 preferred method to do this). The NOOP command can also be used to 936 reset any inactivity autologout timer on the server. 938 7.1.3. LOGOUT Command 940 Arguments: none 942 Responses: REQUIRED untagged response: BYE 944 Result: OK - logout completed 945 BAD - command unknown or arguments invalid 947 The LOGOUT command informs the server that the client is done with 948 the connection. The server MUST send a BYE untagged response before 949 the (tagged) OK response, and then close the network connection. 951 7.2. Client Commands - Not Authenticated State 953 In the not authenticated state, the AUTHENTICATE command establishes 954 authentication and enters the authenticated state. The AUTHENTICATE 955 command provides a general mechanism for a variety of authentication 956 techniques, privacy protection, and integrity checking. 958 [[CREF7: Is this still a useful feature in DMAP context?]] Server 959 implementations MAY allow access to certain mailboxes without 960 establishing authentication. This can be done by means of the 961 ANONYMOUS [SASL] authenticator described in [ANONYMOUS]. The 962 restrictions placed on anonymous users are implementation-dependent. 964 Once authenticated (including as anonymous), it is not possible to 965 re-enter not authenticated state. 967 In addition to the universal commands (CAPABILITY, NOOP, and LOGOUT), 968 the following commands are valid in the not authenticated state: 969 AUTHENTICATE. See the Security Considerations section for important 970 information about these commands. 972 7.2.1. AUTHENTICATE Command 974 Arguments: authentication mechanism name 976 Responses: continuation data can be requested 978 Result: OK - authenticate completed, now in authenticated state 979 NO - authenticate failure: unsupported authentication 980 mechanism, credentials rejected 981 BAD - command unknown or arguments invalid, 982 authentication exchange cancelled 984 The AUTHENTICATE command indicates a [SASL] authentication mechanism 985 to the server. If the server supports the requested authentication 986 mechanism, it performs an authentication protocol exchange to 987 authenticate and identify the client. It MAY also negotiate an 988 OPTIONAL security layer for subsequent protocol interactions. If the 989 requested authentication mechanism is not supported, the server 990 SHOULD reject the AUTHENTICATE command by sending a tagged NO 991 response. 993 The AUTHENTICATE command supports the optional "initial response" 994 feature of [SASL]. 996 The service name specified by this protocol's profile of [SASL] is 997 "DMAP". 999 The authentication protocol exchange consists of a series of server 1000 challenges and client responses that are specific to the 1001 authentication mechanism. A server challenge consists of a command 1002 continuation request response with the "+" token followed by a BASE64 1003 encoded string. The client response consists of a single line 1004 consisting of a BASE64 encoded string. If the client wishes to 1005 cancel an authentication exchange, it issues a line consisting of a 1006 single "*". If the server receives such a response, or if it 1007 receives an invalid BASE64 string (e.g. characters outside the 1008 BASE64 alphabet, or non-terminal "="), it MUST reject the 1009 AUTHENTICATE command by sending a tagged BAD response. 1011 If a security layer is negotiated through the [SASL] authentication 1012 exchange, it takes effect immediately following the CRLF that 1013 concludes the authentication exchange for the client, and the CRLF of 1014 the tagged OK response for the server. 1016 While client and server implementations MUST implement the 1017 AUTHENTICATE command itself, it is not required to implement any 1018 authentication mechanisms other than the STACIE mechanism described 1019 in [[Add ref]]. Also, an authentication mechanism is not required to 1020 support any security layers. 1022 Note: a server implementation MUST implement a configuration in 1023 which it does NOT permit any plaintext password mechanisms such as 1024 PLAIN. Server sites SHOULD NOT use any configuration which 1025 permits a plaintext password mechanism. Client and server 1026 implementations SHOULD implement additional [SASL] mechanisms that 1027 do not use plaintext passwords, such as STACIE, SCRAM [[CREF8: Add 1028 references]], and/or the GSSAPI mechanism described in [SASL]. 1030 Servers and clients can support multiple authentication mechanisms. 1031 The server SHOULD list its supported authentication mechanisms in the 1032 response to the CAPABILITY command so that the client knows which 1033 authentication mechanisms to use. 1035 A server MAY include a CAPABILITY response code in the tagged OK 1036 response of a successful AUTHENTICATE command in order to send 1037 capabilities automatically. It is unnecessary for a client to send a 1038 separate CAPABILITY command if it recognizes these automatic 1039 capabilities. This should only be done if a security layer was not 1040 negotiated by the AUTHENTICATE command, because the tagged OK 1041 response as part of an AUTHENTICATE command is not protected by 1042 encryption/integrity checking. [SASL] requires the client to re- 1043 issue a CAPABILITY command in this case. The server MAY advertise 1044 different capabilities after a successful AUTHENTICATE command. 1046 If an AUTHENTICATE command fails with a NO response, the client MAY 1047 try another authentication mechanism by issuing another AUTHENTICATE 1048 command. In other words, the client MAY request authentication types 1049 in decreasing order of preference. 1051 The authorization identity passed from the client to the server 1052 during the authentication exchange is interpreted by the server as 1053 the user name whose privileges the client is requesting. 1055 7.3. Client Commands - Authenticated State 1057 In the authenticated state, commands that manipulate mailboxes as 1058 atomic entities are permitted. Of these commands, the SELECT and 1059 EXAMINE commands will select a mailbox for access and enter the 1060 selected state. [[CREF9: Should we also add "one shot resync" 1061 commands a la QRESYNC/JMAP?]] 1063 In addition to the universal commands (CAPABILITY, NOOP, and LOGOUT), 1064 the following commands are valid in the authenticated state: SELECT, 1065 EXAMINE, CREATE, DELETE, RENAME, SUBSCRIBE, UNSUBSCRIBE, LIST, 1066 STATUS, and APPEND, as well as key ring and signet ring management 1067 commands described in subsequent sections. 1069 7.3.1. SELECT Command 1071 Arguments: mailbox name 1073 Responses: REQUIRED untagged responses: FLAGS, EXISTS 1074 REQUIRED OK untagged responses: PERMANENTFLAGS, 1075 UIDNEXT, UIDVALIDITY 1077 Result: OK - select completed, now in selected state 1078 NO - select failure, now in authenticated state: no 1079 such mailbox, can't access mailbox 1080 BAD - command unknown or arguments invalid 1082 The SELECT command selects a mailbox so that messages in the mailbox 1083 can be accessed. Before returning an OK to the client, the server 1084 MUST send the following untagged data to the client. 1086 FLAGS Defined flags in the mailbox. See the description of the 1087 FLAGS response for more detail. 1089 EXISTS The number of messages in the mailbox. See the 1090 description of the EXISTS response for more detail. 1092 OK [PERMANENTFLAGS ()] A list of message flags that 1093 the client can change permanently. If this is missing, the client 1094 should assume that all flags can be changed permanently. 1096 OK [UIDNEXT ] The next unique identifier value. Refer to 1097 Section 3.3.1.1 for more information. 1099 OK [UIDVALIDITY ] The unique identifier validity value. Refer to 1100 Section 3.3.1.1 for more information. If this is missing, the 1101 server does not support unique identifiers. 1103 Only one mailbox can be selected at a time in a connection; 1104 simultaneous access to multiple mailboxes requires multiple 1105 connections. The SELECT command automatically deselects any 1106 currently selected mailbox before attempting the new selection. 1107 [[CREF10: Add CLOSED response to delimit old and new mailbox state.]] 1108 Consequently, if a mailbox is selected and a SELECT command that 1109 fails is attempted, no mailbox is selected. 1111 If the client is permitted to modify the mailbox, the server SHOULD 1112 prefix the text of the tagged OK response with the "[READ-WRITE]" 1113 response code. 1115 If the client is not permitted to modify the mailbox but is permitted 1116 read access, the mailbox is selected as read-only, and the server 1117 MUST prefix the text of the tagged OK response to SELECT with the 1118 "[READ-ONLY]" response code. Read-only access through SELECT differs 1119 from the EXAMINE command in that certain read-only mailboxes MAY 1120 permit the change of permanent state on a per-user (as opposed to 1121 global) basis. 1123 7.3.2. EXAMINE Command 1125 Arguments: mailbox name 1127 Responses: REQUIRED untagged responses: FLAGS, EXISTS 1128 REQUIRED OK untagged responses: PERMANENTFLAGS, 1129 UIDNEXT, UIDVALIDITY 1131 Result: OK - examine completed, now in selected state 1132 NO - examine failure, now in authenticated state: no 1133 such mailbox, can't access mailbox BAD - command unknown 1134 or arguments invalid 1136 The EXAMINE command is identical to SELECT and returns the same 1137 output; however, the selected mailbox is identified as read-only. No 1138 changes to the permanent state of the mailbox, including per-user 1139 state, are permitted. 1141 The text of the tagged OK response to the EXAMINE command MUST begin 1142 with the "[READ-ONLY]" response code. 1144 7.3.3. CREATE Command 1146 Arguments: mailbox name 1148 Responses: no specific responses for this command 1150 Result: OK - create completed 1151 NO - create failure: can't create mailbox with that name 1152 BAD - command unknown or arguments invalid 1154 The CREATE command creates a mailbox with the given name. [[CREF11: 1155 Encrypted mailbox name?]] An OK response is returned only if a new 1156 mailbox with that name has been created. It is an error to attempt 1157 to create INBOX or a mailbox with a name that refers to an extant 1158 mailbox. Any error in creation will return a tagged NO response. 1160 If the mailbox name is suffixed with the server's hierarchy separator 1161 character (as returned from the server by a LIST command), this is a 1162 declaration that the client intends to create mailbox names under 1163 this name in the hierarchy. Server implementations that do not 1164 require this declaration MUST ignore the declaration. In any case, 1165 the name created is without the trailing hierarchy delimiter. 1167 If the server's hierarchy separator character appears elsewhere in 1168 the name, the server SHOULD create any superior hierarchical names 1169 that are needed for the CREATE command to be successfully completed. 1170 In other words, an attempt to create "foo/bar/zap" on a server in 1171 which "/" is the hierarchy separator character SHOULD create foo/ and 1172 foo/bar/ if they do not already exist. 1174 If a new mailbox is created with the same name as a mailbox which was 1175 deleted, its unique identifiers MUST be greater than any unique 1176 identifiers used in the previous incarnation of the mailbox UNLESS 1177 the new incarnation has a different unique identifier validity value. 1178 See the description of the UID command for more detail. 1180 7.3.4. DELETE Command 1182 Arguments: mailbox name 1184 Responses: no specific responses for this command 1186 Result: OK - delete completed 1187 NO - delete failure: can't delete mailbox with that name 1188 BAD - command unknown or arguments invalid 1190 The DELETE command permanently removes the mailbox with the given 1191 name. A tagged OK response is returned only if the mailbox has been 1192 deleted. It is an error to attempt to delete INBOX or a mailbox name 1193 that does not exist. 1195 The DELETE command MUST NOT remove inferior hierarchical names. For 1196 example, if a mailbox "foo" has an inferior "foo.bar" (assuming "." 1197 is the hierarchy delimiter character), removing "foo" MUST NOT remove 1198 "foo.bar". It is an error to attempt to delete a name that has 1199 inferior hierarchical names and also has the \Noselect mailbox name 1200 attribute (see the description of the LIST response for more 1201 details). 1203 It is permitted to delete a name that has inferior hierarchical names 1204 and does not have the \Noselect mailbox name attribute. If the 1205 server implementation does not permit deleting the name while 1206 inferior hierarchical names exists the \Noselect mailbox name 1207 attribute is set for that name. In any case, all messages in that 1208 mailbox are removed by the DELETE command. 1210 The value of the highest-used unique identifier of the deleted 1211 mailbox MUST be preserved so that a new mailbox created with the same 1212 name will not reuse the identifiers of the former incarnation, UNLESS 1213 the new incarnation has a different unique identifier validity value. 1214 See the description of the UID command for more detail. 1216 7.3.5. RENAME Command 1218 Arguments: existing mailbox name 1219 new mailbox name 1221 Responses: no specific responses for this command 1223 Result: OK - rename completed 1224 NO - rename failure: can't rename mailbox with that name, 1225 can't rename to mailbox with that name 1226 BAD - command unknown or arguments invalid 1228 The RENAME command changes the name of a mailbox. A tagged OK 1229 response is returned only if the mailbox has been renamed. It is an 1230 error to attempt to rename from a mailbox name that does not exist or 1231 to a mailbox name that already exists. Any error in renaming will 1232 return a tagged NO response. 1234 If the name has inferior hierarchical names, then the inferior 1235 hierarchical names MUST also be renamed. For example, a rename of 1236 "foo" to "zap" will rename "foo/bar" (assuming "/" is the hierarchy 1237 delimiter character) to "zap/bar". 1239 If the server's hierarchy separator character appears in the name, 1240 the server SHOULD create any superior hierarchical names that are 1241 needed for the RENAME command to complete successfully. In other 1242 words, an attempt to rename "foo/bar/zap" to baz/rag/zowie on a 1243 server in which "/" is the hierarchy separator character SHOULD 1244 create baz/ and baz/rag/ if they do not already exist. 1246 The value of the highest-used unique identifier of the old mailbox 1247 name MUST be preserved so that a new mailbox created with the same 1248 name will not reuse the identifiers of the former incarnation, UNLESS 1249 the new incarnation has a different unique identifier validity value. 1250 See the description of the UID command for more detail. 1252 [[CREF12: If we always support returning roles for mailboxes, there 1253 is no need for this special behaviour.]] Renaming INBOX is permitted, 1254 and has special behavior. It moves all messages in INBOX to a new 1255 mailbox with the given name, leaving INBOX empty. If the server 1256 implementation supports inferior hierarchical names of INBOX, these 1257 are unaffected by a rename of INBOX. 1259 7.3.6. SUBSCRIBE Command 1261 Arguments: mailbox 1263 Responses: no specific responses for this command 1265 Result: OK - subscribe completed 1266 NO - subscribe failure: can't subscribe to that name 1267 BAD - command unknown or arguments invalid 1269 The SUBSCRIBE command adds the specified mailbox name to the server's 1270 set of "active" or "subscribed" mailboxes as returned by the LIST 1271 (SUBSCRIBED) command. This command returns a tagged OK response only 1272 if the subscription is successful. 1274 A server MAY validate the mailbox argument to SUBSCRIBE to verify 1275 that it exists. However, it MUST NOT unilaterally remove an existing 1276 mailbox name from the subscription list even if a mailbox by that 1277 name no longer exists. [[CREF13: Do we need this restriction?]] 1279 Note: This requirement is because a server site can choose to 1280 routinely remove a mailbox with a well-known name (e.g., "system- 1281 alerts") after its contents expire, with the intention of 1282 recreating it when new contents are appropriate. 1284 7.3.7. UNSUBSCRIBE Command 1286 Arguments: mailbox name 1288 Responses: no specific responses for this command 1290 Result: OK - unsubscribe completed 1291 NO - unsubscribe failure: can't unsubscribe that name 1292 BAD - command unknown or arguments invalid 1294 The UNSUBSCRIBE command removes the specified mailbox name from the 1295 server's set of "active" or "subscribed" mailboxes as returned by the 1296 LIST (SUBSCRIBED) command. This command returns a tagged OK response 1297 only if the unsubscription is successful. [[CREF14: We can allow 1298 UNSUBSCRIBE to succeed for a mailbox which is not subscribed.]] 1300 7.3.8. LIST Command 1302 Arguments: OPTIONAL selection options 1303 mailbox name with possible wildcards 1304 OPTIONAL return options 1306 Responses: untagged responses: LIST 1308 Result: OK - list completed 1309 NO - list failure: can't list that reference or name 1310 BAD - command unknown or arguments invalid 1312 [[CREF15: Update to include options, like "SUBSCRIBED".]] The LIST 1313 command returns a subset of names from the complete set of all names 1314 available to the client. Zero or more untagged LIST replies are 1315 returned, containing the name attributes, hierarchy delimiter, name, 1316 and optional mailbox status information; see the description of the 1317 LIST reply for more detail. 1319 The LIST command SHOULD return its data quickly, without undue delay. 1320 If each name requires 1 second of processing, then a list of 1200 1321 names would take 20 minutes! 1323 The returned mailbox names MUST match the supplied mailbox name 1324 pattern. 1326 The character "*" is a wildcard, and matches zero or more characters 1327 at this position. The character "%" is similar to "*", but it does 1328 not match a hierarchy delimiter. If the "%" wildcard is the last 1329 character of a mailbox name argument, matching levels of hierarchy 1330 are also returned. If these levels of hierarchy are not also 1331 selectable mailboxes, they are returned with the \Noselect mailbox 1332 name attribute (see the description of the LIST response for more 1333 details). 1335 Server implementations are permitted to "hide" otherwise accessible 1336 mailboxes from the wildcard characters, by preventing certain 1337 characters or names from matching a wildcard in certain situations. 1338 For example, a UNIX-based server might restrict the interpretation of 1339 "*" so that an initial "/" character does not match. 1341 [[CREF16: Is this needed with roles?]] The special name INBOX is 1342 included in the output from LIST, if INBOX is supported by this 1343 server for this user and if the uppercase string "INBOX" matches the 1344 mailbox name arguments with wildcards as described above. The 1345 criteria for omitting INBOX is whether SELECT INBOX will return 1346 failure; it is not relevant whether the user's real INBOX resides on 1347 this or some other server. 1349 7.3.9. STATUS Command 1351 Arguments: mailbox name 1352 status data item names 1354 Responses: REQUIRED untagged responses: STATUS 1356 Result: OK - status completed 1357 NO - status failure: no status for that name 1358 BAD - command unknown or arguments invalid 1360 The STATUS command requests the status of the indicated mailbox. It 1361 does not change the currently selected mailbox, nor does it affect 1362 the state of any messages in the queried mailbox. 1364 The STATUS command provides an alternative to opening a second DMAP 1365 connection and doing an EXAMINE command on a mailbox to query that 1366 mailbox's status without deselecting the current mailbox in the first 1367 DMAP connection. 1369 Unlike the LIST command, the STATUS command is not guaranteed to be 1370 fast in its response. Under certain circumstances, it can be quite 1371 slow. In some implementations, the server is obliged to open the 1372 mailbox read-only internally to obtain certain status information. 1373 Also unlike the LIST command, the STATUS command does not accept 1374 wildcards. [[CREF17: Remove this restriction?]] 1376 Note: The STATUS command is intended to access the status of 1377 mailboxes other than the currently selected mailbox. Because the 1378 STATUS command can cause the mailbox to be opened internally, and 1379 because this information is available by other means on the 1380 selected mailbox, the STATUS command SHOULD NOT be used on the 1381 currently selected mailbox. 1383 The STATUS command MUST NOT be used as a "check for new messages 1384 in the selected mailbox" operation (refer to sections 7, 1385 Section 8.3.1 for more information about the proper method for new 1386 message checking). 1388 The currently defined status data items that can be requested are: 1390 MESSAGES The number of messages in the mailbox. 1392 UIDNEXT The next unique identifier value of the mailbox. Refer to 1393 Section 3.3.1.1 for more information. 1395 UIDVALIDITY The unique identifier validity value of the mailbox. 1396 Refer to Section 3.3.1.1 for more information. 1398 UNSEEN The number of messages which do not have the \Seen flag set. 1400 7.3.10. APPEND Command 1402 Arguments: mailbox name 1403 OPTIONAL flag parenthesized list 1404 OPTIONAL date/time string 1405 message literal 1407 Responses: no specific responses for this command 1409 Result: OK - append completed 1410 NO - append error: can't append to that mailbox, error 1411 in flags or date/time or message text 1412 BAD - command unknown or arguments invalid 1414 The APPEND command appends the literal argument as a new message to 1415 the end of the specified destination mailbox. This argument SHOULD 1416 be in the format of a DMIME message. Binary data is permitted in the 1417 message. 1419 If a flag parenthesized list is specified, the flags SHOULD be set in 1420 the resulting message; otherwise, the flag list of the resulting 1421 message is set to empty by default. 1423 If a date-time is specified, the internal date SHOULD be set in the 1424 resulting message; otherwise, the internal date of the resulting 1425 message is set to the current date and time by default. 1427 If the append is unsuccessful for any reason, the mailbox MUST be 1428 restored to its state before the APPEND attempt; no partial appending 1429 is permitted. 1431 If the destination mailbox does not exist, a server MUST return an 1432 error, and MUST NOT automatically create the mailbox. Unless it is 1433 certain that the destination mailbox can not be created, the server 1434 MUST send the response code "[TRYCREATE]" as the prefix of the text 1435 of the tagged NO response. This gives a hint to the client that it 1436 can attempt a CREATE command and retry the APPEND if the CREATE is 1437 successful. 1439 If the mailbox is currently selected, the normal new message actions 1440 MUST occur. Specifically, the server MUST notify the client 1441 immediately via an untagged EXISTS response. 1443 Note: The APPEND command is not used for message submission. 1445 7.4. Client Commands - Authenticated State - Key Ring Management 1447 This section describes user's key ring management commands: GETKEY, 1448 ADDKEY, DELETEKEY, LISTKEYS. 1450 7.4.1. GETKEY Command 1452 Arguments: key ID 1453 key part indicator (PRIVATE, PUBLIC or BOTH) 1455 Responses: REQUIRED untagged responses: KEY 1457 Result: OK - getkey completed 1458 NO - getkey failure: the key with key id was not found 1459 BAD - arguments invalid 1461 The GETKEY command requests the server to return private key, public 1462 key or both. 1464 7.4.2. ADDKEY Command 1466 Arguments: key ID 1467 Signet Signing Request (might contain public key or both 1468 public and private key) 1470 Responses: none 1472 Result: OK - addkey completed 1473 NO - addkey failure: the key already exists or storage 1474 failure 1475 BAD - arguments invalid 1477 The ADDKEY command requests the server to add the specified public 1478 key or both public key and the corresponding private key to the key 1479 ring. [[CREF18: Whether both or just public key are uploaded depends 1480 on the DMAP mode.]] 1482 It is an error to add a key with the key id which already exists. 1483 [[CREF19: Add more details about the response code to be returned in 1484 such case.]] DELETEKEY should be used first to delete such key. 1486 7.4.3. DELETEKEY Command 1488 Arguments: key ID 1490 Responses: none 1492 Result: OK - deletekey completed 1493 NO - deletekey failure: the key is not found 1494 BAD - arguments invalid 1496 The DELETEKEY command requests the server to delete the corresponding 1497 public (and the associated private, if exists) key using the key 1498 identifier. 1500 DELETEKEY MUST fail with a tagged NO response if there are any 1501 messages on the server associated with the key id or if the expiry of 1502 the key hasn't been reached. 1504 7.4.4. LISTKEYS Command 1506 Arguments: None 1508 Responses: KEY untagged response for each key 1510 Result: OK - listkeys completed 1511 NO - listkeys failure: no status for that name 1512 BAD - arguments invalid 1514 The LISTKEYS command requests the server to return key ids of all 1515 keys in the key ring. Each key id is returned using the KEY untagged 1516 response which doesn't include anything other than the key id. 1518 7.5. Client Commands - Authenticated State - Signet Ring Management 1520 This section describes signet ring management commands: GETSIGNET, 1521 ADDSIGNET, DELETESIGNET, LISTSIGNETS. 1523 [[CREF20: TBD. Email address is used instead of key id to 1524 get/add/delete/list. LISTSIGNETS should allow for wildcards.]] 1526 7.6. Client Commands - Selected State 1528 In the selected state, commands that manipulate messages in a mailbox 1529 are permitted. 1531 In addition to the universal commands (CAPABILITY, NOOP, and LOGOUT), 1532 and the authenticated state commands (SELECT, EXAMINE, CREATE, 1533 DELETE, RENAME, SUBSCRIBE, UNSUBSCRIBE, LIST, STATUS and APPEND), the 1534 following commands are valid in the selected state: CLOSE, EXPUNGE, 1535 SEARCH , FETCH, STORE, COPY, SUBMIT and UID. 1537 7.6.1. CLOSE Command 1539 Arguments: none 1541 Responses: no specific responses for this command 1543 Result: OK - close completed, now in authenticated state 1544 BAD - command unknown or arguments invalid 1546 The CLOSE command permanently removes all messages that have the 1547 \Deleted flag set from the currently selected mailbox, and returns to 1548 the authenticated state from the selected state. No untagged EXPUNGE 1549 responses are sent. 1551 No messages are removed, and no error is given, if the mailbox is 1552 selected by an EXAMINE command or is otherwise selected read-only. 1554 Even if a mailbox is selected, a SELECT, EXAMINE, or LOGOUT command 1555 MAY be issued without previously issuing a CLOSE command. The 1556 SELECT, EXAMINE, and LOGOUT commands implicitly close the currently 1557 selected mailbox without doing an expunge. However, when many 1558 messages are deleted, a CLOSE-LOGOUT or CLOSE-SELECT sequence is 1559 considerably faster than an EXPUNGE-LOGOUT or EXPUNGE-SELECT because 1560 no untagged EXPUNGE responses (which the client would probably 1561 ignore) are sent. 1563 7.6.2. EXPUNGE Command 1565 Arguments: none 1567 Responses: untagged responses: EXPUNGE 1569 Result: OK - expunge completed 1570 NO - expunge failure: can't expunge (e.g., permission 1571 denied) 1572 BAD - command unknown or arguments invalid 1574 [[CREF21: Switch to returning UIDs in EXPUNGE response?]] The EXPUNGE 1575 command permanently removes all messages that have the \Deleted flag 1576 set from the currently selected mailbox. Before returning an OK to 1577 the client, an untagged EXPUNGE response is sent for each message 1578 that is removed. Note that if any messages with the \Recent flag set 1579 are expunged, an untagged RECENT response is sent after the untagged 1580 EXPUNGE(s) to update the client's count of RECENT messages. 1582 7.6.3. SEARCH Command 1584 Arguments: searching criteria (one or more) 1586 Responses: REQUIRED untagged response: SEARCH 1588 Result: OK - search completed 1589 NO - search error: can't search that criteria 1590 BAD - command unknown or arguments invalid 1592 The SEARCH command searches the mailbox for messages that match the 1593 given searching criteria. Searching criteria consist of one or more 1594 search keys. The untagged SEARCH response from the server contains a 1595 listing of message sequence numbers corresponding to those messages 1596 that match the searching criteria. 1598 When multiple keys are specified, the result is the intersection (AND 1599 function) of all the messages that match those keys. For example, 1600 the criteria DELETED SINCE 1-Feb-2015 refers to all deleted messages 1601 that were placed in the mailbox since February 1, 2015. A search key 1602 can also be a parenthesized list of one or more search keys (e.g., 1603 for use with the OR and NOT keys). 1605 In all search keys that use strings, a message matches the key if the 1606 string is a substring of the associated text. The matching is case- 1607 insensitive. Note that the empty string is a substring. 1609 The defined search keys are as follows. Refer to the Formal Syntax 1610 section for the precise syntactic definitions of the arguments. 1612 Messages with message sequence numbers corresponding 1613 to the specified message sequence number set. 1615 ALL All messages in the mailbox; the default initial key for ANDing. 1617 BEFORE Messages whose internal date (disregarding time and 1618 timezone) is earlier than the specified date. 1620 DELETED Messages with the \Deleted flag set. 1622 LARGER Messages with an [RFC-5322] size larger than the 1623 specified number of octets. 1625 NOT Messages that do not match the specified search 1626 key. 1628 ON Messages whose internal date (disregarding time and 1629 timezone) is within the specified date. 1631 OR Messages that match either search 1632 key. 1634 SEEN Messages that have the \Seen flag set. 1636 SINCE Messages whose internal date (disregarding time and 1637 timezone) is within or later than the specified date. 1639 SMALLER Messages with an [RFC-5322] size smaller than the 1640 specified number of octets. 1642 UID Messages with unique identifiers corresponding to 1643 the specified unique identifier set. Sequence set ranges are 1644 permitted. 1646 UNDELETED Messages that do not have the \Deleted flag set. 1648 UNSEEN Messages that do not have the \Seen flag set. 1650 7.6.4. FETCH Command 1652 Arguments: sequence set 1653 message data item names or macro 1655 Responses: untagged responses: FETCH 1657 Result: OK - fetch completed 1658 NO - fetch error: can't fetch that data 1659 BAD - command unknown or arguments invalid 1661 The FETCH command retrieves data associated with a message in the 1662 mailbox. The data items to be fetched can be either a single atom or 1663 a parenthesized list. 1665 [[CREF22: Make sure the following statement is true once ABNF is 1666 done.]] Most data items, identified in the formal syntax under the 1667 msg-att-static rule, are static and MUST NOT change for any 1668 particular message. Other data items, identified in the formal 1669 syntax under the msg-att-dynamic rule, MAY change, either as a result 1670 of a STORE command or due to external events. 1672 For example, if a client receives a BODYSTRUCTURE for a message 1673 when it already knows the envelope, it can safely ignore the newly 1674 transmitted body structure. 1676 There are three macros which specify commonly-used sets of data 1677 items, and can be used instead of data items. A macro must be used 1678 by itself, and not in conjunction with other macros or data items. 1680 FAST Macro equivalent to: (FLAGS INTERNALDATE SIZE) 1682 FULL Macro equivalent to: (FLAGS INTERNALDATE SIZE BODYSTRUCTURE) 1684 The currently defined data items that can be fetched are: 1686 BODY[
]<> 1688 The content of a particular chunk or of the whole message. The 1689 section specification has the following syntax: .. For example "0.1" - the first Tracing 1691 chunk. "67.2" - the second Display-Content chunk. [[CREF23: 1692 This needs more thought. In particular, is nesting of body 1693 parts allowed?]] 1695 The section specification can be the empty string, in which 1696 case the content of the whole message is returned. 1698 It is possible to fetch a substring of the designated text. 1699 This is done by appending an open angle bracket ("<"), the 1700 octet position of the first desired octet, a period, the 1701 maximum number of octets desired, and a close angle bracket 1702 (">") to the part specifier. If the starting octet is beyond 1703 the end of the text, an empty string is returned. 1705 Any partial fetch that attempts to read beyond the end of the 1706 text is truncated as appropriate. A partial fetch that starts 1707 at octet 0 is returned as a partial fetch, even if this 1708 truncation happened. 1710 Note: This means that BODY[]<0.2048> of a 1500-octet message 1711 will return BODY[]<0> with a literal of size 1500, not 1712 BODY[]. 1714 The \Seen flag is implicitly set; if this causes the flags to 1715 change, they SHOULD be included as part of the FETCH responses. 1717 BODY.PEEK[
]<> An alternate form of BODY[
] 1718 that does not implicitly set the \Seen flag. 1720 BODYSTRUCTURE 1722 [[CREF24: Decide if this is going to be binary or human 1723 readable (e.g. a list).]] 1724 The BODYSTRUCTURE FETCH item contains basic information about 1725 all chunks of the message which enables clients to download 1726 only specific chunks of the message without downloading the 1727 whole message. This is computed by the server by extracting 1728 available chunk types and associated data from the message. 1729 This can provide performance improvements when dealing with big 1730 attachments. 1732 FLAGS The flags that are set for this message. 1734 META Encrypted block of data that represents mutable state 1735 associated with the message, such as encrypted flags. [[CREF25: 1736 TBD]] 1738 MODSEQ The message modification sequence. It is a 63 bit unsigned 1739 integer (expressed as a decimal), which changes every time 1740 message's flags or encrypted metadata block changes. [[CREF26: 1741 TBD]] 1743 INTERNALDATE The internal date of the message. 1745 SIZE The size of the message in octets. 1747 UID The unique identifier for the message. 1749 7.6.5. STORE Command 1751 Arguments: sequence set 1752 message data item name 1753 value for message data item 1755 Responses: untagged responses: FETCH 1757 Result: OK - store completed 1758 NO - store error: can't store that data 1759 BAD - command unknown or arguments invalid 1761 The STORE command alters data associated with a message in the 1762 mailbox. Normally, STORE will return the updated value of the data 1763 with an untagged FETCH response. A suffix of ".SILENT" in the data 1764 item name prevents the untagged FETCH, and the server SHOULD assume 1765 that the client has determined the updated value itself or does not 1766 care about the updated value. 1768 Note: Regardless of whether or not the ".SILENT" suffix was used, 1769 the server SHOULD send an untagged FETCH response if a change to a 1770 message's flags from an external source is observed. The intent 1771 is that the status of the flags is determinate without a race 1772 condition. 1774 The currently defined data items that can be stored are: 1776 FLAGS Replace the flags for the message (other than 1777 \Recent) with the argument. The new value of the flags is 1778 returned as if a FETCH of those flags was done. 1780 FLAGS.SILENT Equivalent to FLAGS, but without returning 1781 a new value. 1783 +FLAGS Add the argument to the flags for the message. 1784 The new value of the flags is returned as if a FETCH of those 1785 flags was done. 1787 +FLAGS.SILENT Equivalent to +FLAGS, but without 1788 returning a new value. 1790 -FLAGS Remove the argument from the flags for the 1791 message. The new value of the flags is returned as if a FETCH of 1792 those flags was done. 1794 -FLAGS.SILENT Equivalent to -FLAGS, but without 1795 returning a new value. 1797 Example: C: A003 STORE 2:4 +FLAGS (\Deleted) 1798 S: * 2 FETCH (FLAGS (\Deleted \Seen)) 1799 S: * 3 FETCH (FLAGS (\Deleted)) 1800 S: * 4 FETCH (FLAGS (\Deleted \Flagged \Seen)) 1801 S: A003 OK STORE completed 1803 7.6.6. COPY Command 1805 Arguments: sequence set 1806 mailbox name 1808 Responses: no specific responses for this command 1810 Result: OK - copy completed 1811 NO - copy error: can't copy those messages or to that 1812 name 1813 BAD - command unknown or arguments invalid 1815 The COPY command copies the specified message(s) to the end of the 1816 specified destination mailbox. The flags and internal date of the 1817 message(s) SHOULD be preserved, and the Recent flag SHOULD be set, in 1818 the copy. 1820 If the destination mailbox does not exist, a server SHOULD return an 1821 error. It SHOULD NOT automatically create the mailbox. Unless it is 1822 certain that the destination mailbox can not be created, the server 1823 MUST send the response code "[TRYCREATE]" as the prefix of the text 1824 of the tagged NO response. This gives a hint to the client that it 1825 can attempt a CREATE command and retry the COPY if the CREATE is 1826 successful. 1828 If the COPY command is unsuccessful for any reason, server 1829 implementations MUST restore the destination mailbox to its state 1830 before the COPY attempt. 1832 Example: C: A003 COPY 2:4 MEETING 1833 S: A003 OK COPY completed 1835 7.6.7. SUBMIT Command 1837 Arguments: message number of the message to send 1838 OPTIONAL list of delivery options (e.g. "delay submission 1839 until", etc.) 1841 Responses: FETCH response with updated message flags 1843 Result: OK - Message submitted for delivery 1844 NO - Submission error: can't move to the Sent mailbox, 1845 error 1846 in flags or date/time or message text 1847 BAD - arguments invalid 1849 The SUBMIT command submits the specified message using DMTP protocol. 1850 The server ensures that the current user key is used with the message 1851 being submitted, so the server MUST reject messages which don't 1852 contain a valid signature using the current signing key. The server 1853 MUST also ensure that the origin chunk provides the correct author 1854 information (which may be distinct from the "From" header embedded in 1855 the meta chunk). [[CREF27: Add DMIME reference here.]] The server 1856 also sets/clears some message flags in the process in order to 1857 prevent other DMAP clients from submitting the same message at the 1858 same time. This is described in more details below. 1860 [[CREF28: One of the delivery options can specify whether to move the 1861 submitted message to the Sent mailbox. TBD.]] 1863 Clients MUST NOT submit a message which is either not marked with the 1864 \SubmitPending keyword , or which is marked with the \Submitted 1865 keyword. Servers MUST reject such a command with a tagged NO bearing 1866 the SUBMISSIONRACE response code. 1868 In the course of submission, servers MUST atomically add the 1869 \Submitted flag to the message. A transient state where the message 1870 is temporarily marked with both \Submitted and \SubmitPending flags 1871 MAY be hidden from any IMAP session or it MAY be visible in some or 1872 all of them. 1874 If the command succeeded, the message MUST be marked with the 1875 \Submitted flag, the \SubmitPending flag MUST be cleared and a FETCH 1876 response containing the message UID and its new flags MUST be sent. 1878 If the command fails, the server MUST clear both the \Submitted or 1879 \SubmitPending flags. 1881 Clients MUST be prepared to handle failing submission at any time. 1882 Servers MAY reject message submission for any reason. 1884 [[CREF29: Delivery options: TBD.]] The server MUST process all 1885 specified delivery options and their detailed options. The server 1886 MUST respond with a tagged BAD if the client used unrecognized or 1887 unannounced option, or if a recognized option is used in an invalid 1888 way. If the server cannot honor a recognized and announced option, 1889 it MUST respond with a tagged NO with the POLICYDENIED response code 1890 and the message MUST NOT be submitted, nor its flags changed. 1892 7.6.8. UID Command 1894 Arguments: command name 1895 command arguments 1897 Responses: untagged responses: FETCH, SEARCH 1899 Result: OK - UID command completed 1900 NO - UID command error 1901 BAD - command unknown or arguments invalid 1903 The UID command has two forms. In the first form, it takes as its 1904 arguments a COPY, FETCH, or STORE command with arguments appropriate 1905 for the associated command. However, the numbers in the sequence set 1906 argument are unique identifiers instead of message sequence numbers. 1907 Sequence set ranges are permitted, but there is no guarantee that 1908 unique identifiers will be contiguous. 1910 A non-existent unique identifier is ignored without any error message 1911 generated. Thus, it is possible for a UID FETCH command to return an 1912 OK without any data or a UID COPY or UID STORE to return an OK 1913 without performing any operations. 1915 In the second form, the UID command takes a SEARCH command with 1916 SEARCH command arguments. The interpretation of the arguments is the 1917 same as with SEARCH; however, the numbers returned in a SEARCH 1918 response for a UID SEARCH command are unique identifiers instead of 1919 message sequence numbers. For example, the command UID SEARCH 1:100 1920 UID 443:557 returns the unique identifiers corresponding to the 1921 intersection of two sequence sets, the message sequence number range 1922 1:100 and the UID range 443:557. 1924 Note: in the above example, the UID range 443:557 appears. The 1925 same comment about a non-existent unique identifier being ignored 1926 without any error message also applies here. Hence, even if 1927 neither UID 443 or 557 exist, this range is valid and would 1928 include an existing UID 495. 1930 Also note that a UID range of 559:* always includes the UID of the 1931 last message in the mailbox, even if 559 is higher than any 1932 assigned UID value. This is because the contents of a range are 1933 independent of the order of the range endpoints. Thus, any UID 1934 range with * as one of the endpoints indicates at least one 1935 message (the message with the highest numbered UID), unless the 1936 mailbox is empty. 1938 The number after the "*" in an untagged FETCH response is always a 1939 message sequence number, not a unique identifier, even for a UID 1940 command response. However, server implementations MUST implicitly 1941 include the UID message data item as part of any FETCH response 1942 caused by a UID command, regardless of whether a UID was specified as 1943 a message data item to the FETCH. 1945 Note: The rule about including the UID message data item as part of a 1946 FETCH response primarily applies to the UID FETCH and UID STORE 1947 commands, including a UID FETCH command that does not include UID as 1948 a message data item. Although it is unlikely that the other UID 1949 commands will cause an untagged FETCH, this rule applies to these 1950 commands as well. 1952 Example: C: A999 UID FETCH 4827313:4828442 FLAGS 1953 S: * 23 FETCH (FLAGS (\Seen) UID 4827313) 1954 S: * 24 FETCH (FLAGS (\Seen) UID 4827943) 1955 S: * 25 FETCH (FLAGS (\Seen) UID 4828442) 1956 S: A999 OK UID FETCH completed 1958 7.7. Client Commands - Experimental/Expansion 1959 7.7.1. X Command 1961 Arguments: implementation defined 1963 Responses: implementation defined 1965 Result: OK - command completed 1966 NO - failure 1967 BAD - command unknown or arguments invalid 1969 Any command prefixed with an X is an experimental command. Commands 1970 which are not part of this specification, a standard or standards- 1971 track revision of this specification, or an IESG-approved 1972 experimental protocol, MUST use the X prefix. 1974 Any added untagged responses issued by an experimental command MUST 1975 also be prefixed with an X. Server implementations MUST NOT send any 1976 such untagged responses, unless the client requested it by issuing 1977 the associated experimental command. 1979 Example: C: a441 CAPABILITY 1980 S: * CAPABILITY DMAP XPIG-LATIN 1981 S: a441 OK CAPABILITY completed 1982 C: A442 XPIG-LATIN 1983 S: * XPIG-LATIN ow-nay eaking-spay ig-pay atin-lay 1984 S: A442 OK XPIG-LATIN ompleted-cay 1986 8. Server Responses 1988 Server responses are in three forms: status responses, server data, 1989 and command continuation request. The information contained in a 1990 server response, identified by "Contents:" in the response 1991 descriptions below, is described by function, not by syntax. The 1992 precise syntax of server responses is described in the Formal Syntax 1993 section. 1995 The client MUST be prepared to accept any response at all times. 1997 Status responses can be tagged or untagged. Tagged status responses 1998 indicate the completion result (OK, NO, or BAD status) of a client 1999 command, and have a tag matching the command. 2001 Some status responses, and all server data, are untagged. An 2002 untagged response is indicated by the token "*" instead of a tag. 2003 Untagged status responses indicate server greeting, or server status 2004 that does not indicate the completion of a command (for example, an 2005 impending system shutdown alert). For historical reasons, untagged 2006 server data responses are also called "unsolicited data", although 2007 strictly speaking, only unilateral server data is truly 2008 "unsolicited". 2010 Certain server data MUST be recorded by the client when it is 2011 received; this is noted in the description of that data. Such data 2012 conveys critical information which affects the interpretation of all 2013 subsequent commands and responses (e.g., updates reflecting the 2014 creation or destruction of messages). 2016 Other server data SHOULD be recorded for later reference; if the 2017 client does not need to record the data, or if recording the data has 2018 no obvious purpose (e.g., a SEARCH response when no SEARCH command is 2019 in progress), the data SHOULD be ignored. 2021 An example of unilateral untagged server data occurs when the DMAP 2022 connection is in the selected state. In the selected state, the 2023 server checks the mailbox for new messages as part of command 2024 execution. Normally, this is part of the execution of every command; 2025 hence, a NOOP command suffices to check for new messages. If new 2026 messages are found, the server sends untagged EXISTS and RECENT 2027 responses reflecting the new size of the mailbox. Server 2028 implementations that offer multiple simultaneous access to the same 2029 mailbox SHOULD also send appropriate unilateral untagged FETCH and 2030 EXPUNGE responses if another agent changes the state of any message 2031 flags or expunges any messages. 2033 Command continuation request responses use the token "+" instead of a 2034 tag. These responses are sent by the server to indicate acceptance 2035 of an incomplete client command and readiness for the remainder of 2036 the command. 2038 8.1. Server Responses - Status Responses 2040 Status responses are OK, NO, BAD, PREAUTH and BYE. OK, NO, and BAD 2041 can be tagged or untagged. PREAUTH and BYE are always untagged. 2043 Status responses MAY include an OPTIONAL "response code". A response 2044 code consists of data inside square brackets in the form of an atom, 2045 possibly followed by a space and arguments. The response code 2046 contains additional information or status codes for client software 2047 beyond the OK/NO/BAD condition, and are defined when there is a 2048 specific action that a client can take based upon the additional 2049 information. 2051 The currently defined response codes are: 2053 ALERT The human-readable text contains a special alert that MUST be 2054 presented to the user in a fashion that calls the user's attention 2055 to the message. 2057 CAPABILITY Followed by a list of capabilities. This can appear in 2058 the initial OK or PREAUTH response to transmit an initial 2059 capabilities list. This makes it unnecessary for a client to send 2060 a separate CAPABILITY command if it recognizes this response. 2062 PERMANENTFLAGS Followed by a parenthesized list of flags, indicates 2063 which of the known flags the client can change permanently. Any 2064 flags that are in the FLAGS untagged response, but not the 2065 PERMANENTFLAGS list, can not be set permanently. If the client 2066 attempts to STORE a flag that is not in the PERMANENTFLAGS list, 2067 the server will either ignore the change or store the state change 2068 for the remainder of the current session only. The PERMANENTFLAGS 2069 list can also include the special flag \*, which indicates that it 2070 is possible to create new keywords by attempting to store those 2071 flags in the mailbox. 2073 READ-ONLY The mailbox is selected read-only, or its access while 2074 selected has changed from read-write to read-only. 2076 READ-WRITE The mailbox is selected read-write, or its access while 2077 selected has changed from read-only to read-write. 2079 TRYCREATE An APPEND or COPY attempt is failing because the target 2080 mailbox does not exist (as opposed to some other reason). This is 2081 a hint to the client that the operation can succeed if the mailbox 2082 is first created by the CREATE command. 2084 UIDNEXT Followed by a decimal number, indicates the next unique 2085 identifier value. Refer to Section 3.3.1.1 for more information. 2087 UIDVALIDITY Followed by a decimal number, indicates the unique 2088 identifier validity value. Refer to Section 3.3.1.1 for more 2089 information. 2091 Additional response codes defined by particular client or server 2092 implementations SHOULD be prefixed with an "X" until they are added 2093 to a revision of this protocol. Client implementations SHOULD ignore 2094 response codes that they do not recognize. 2096 8.1.1. OK Response 2098 Contents: OPTIONAL response code 2099 human-readable text 2101 The OK response indicates an information message from the server. 2102 When tagged, it indicates successful completion of the associated 2103 command. The human-readable text MAY be presented to the user as an 2104 information message. The untagged form indicates an information-only 2105 message; the nature of the information MAY be indicated by a response 2106 code. 2108 The untagged form is also used as one of three possible greetings at 2109 connection startup. It indicates that the connection is not yet 2110 authenticated and that an AUTHENTICATE command is needed. 2112 Example: S: * OK DMAP server ready 2113 [...] 2114 C: A001 SELECT mailbox 2115 [...] 2116 S: * OK [ALERT] System shutdown in 10 minutes 2117 S: A001 OK SELECT Completed 2119 8.1.2. NO Response 2121 Contents: OPTIONAL response code 2122 human-readable text 2124 The NO response indicates an operational error message from the 2125 server. When tagged, it indicates unsuccessful completion of the 2126 associated command. The untagged form indicates a warning; the 2127 command can still complete successfully. The human-readable text 2128 describes the condition. 2130 8.1.3. BAD Response 2132 Contents: OPTIONAL response code 2133 human-readable text 2135 The BAD response indicates an error message from the server. When 2136 tagged, it reports a protocol-level error in the client's command; 2137 the tag indicates the command that caused the error. The untagged 2138 form indicates a protocol-level error for which the associated 2139 command can not be determined; it can also indicate an internal 2140 server failure. The human-readable text describes the condition. 2142 8.1.4. PREAUTH Response 2144 Contents: OPTIONAL response code 2145 human-readable text 2147 The PREAUTH response is always untagged, and is one of three possible 2148 greetings at connection startup. It indicates that the connection 2149 has already been authenticated by external means; thus no 2150 AUTHENTICATE command is needed. 2152 Example: S: * PREAUTH DMAP server logged in as Smith 2154 8.1.5. BYE Response 2156 Contents: OPTIONAL response code 2157 human-readable text 2159 The BYE response is always untagged, and indicates that the server is 2160 about to close the connection. The human-readable text MAY be 2161 displayed to the user in a status report by the client. The BYE 2162 response is sent under one of four conditions: 2164 1. as part of a normal logout sequence. The server will close the 2165 connection after sending the tagged OK response to the LOGOUT 2166 command. 2168 2. as a panic shutdown announcement. The server closes the 2169 connection immediately. 2171 3. as an announcement of an inactivity autologout. The server 2172 closes the connection immediately. 2174 4. as one of three possible greetings at connection startup, 2175 indicating that the server is not willing to accept a connection 2176 from this client. The server closes the connection immediately. 2178 The difference between a BYE that occurs as part of a normal LOGOUT 2179 sequence (the first case) and a BYE that occurs because of a failure 2180 (the other three cases) is that the connection closes immediately in 2181 the failure case. In all cases the client SHOULD continue to read 2182 response data from the server until the connection is closed; this 2183 will ensure that any pending untagged or completion responses are 2184 read and processed. 2186 Example: S: * BYE Autologout; idle for too long 2188 8.2. Server Responses - Server and Mailbox Status 2190 These responses are always untagged. This is how server and mailbox 2191 status data are transmitted from the server to the client. Many of 2192 these responses typically result from a command with the same name. 2194 8.2.1. CAPABILITY Response 2196 Contents: capability listing 2198 The CAPABILITY response occurs as a result of a CAPABILITY command. 2199 The capability listing contains a space-separated listing of 2200 capability names that the server supports. 2202 The capability listing MUST include the atom "DMAP=...", which 2203 describes in which mode DMAP operates. It MUST be followed by one of 2204 "TRUSTFUL", "CAUTIOUS" or "PARANOID". 2206 A capability name which begins with "AUTH=" indicates that the server 2207 supports that particular authentication mechanism. 2209 Other capability names indicate that the server supports an 2210 extension, revision, or amendment to the DMAP protocol. Server 2211 responses MUST conform to this document until the client issues a 2212 command that uses the associated capability. 2214 Capability names MUST either begin with "X" or be standard or 2215 standards-track DMAP extensions, revisions, or amendments registered 2216 with IANA. A server MUST NOT offer unregistered or non-standard 2217 capability names, unless such names are prefixed with an "X". 2219 Client implementations SHOULD NOT require any capability name other 2220 than "DMAP", and MUST ignore any unknown capability names. 2222 A server MAY send capabilities automatically, by using the CAPABILITY 2223 response code in the initial PREAUTH or OK responses, and by sending 2224 an updated CAPABILITY response code in the tagged OK response as part 2225 of a successful authentication. It is unnecessary for a client to 2226 send a separate CAPABILITY command if it recognizes these automatic 2227 capabilities. 2229 Example: S: * CAPABILITY DMAP AUTH=GSSAPI XPIG-LATIN 2231 8.2.2. STATUS Response 2233 Contents: encrypted mailbox name 2234 status parenthesized list 2236 The STATUS response occurs as a result of an STATUS command. It 2237 returns the mailbox name that matches the STATUS specification and 2238 the requested mailbox status information. 2240 Example: S: * STATUS blurdybloop (MESSAGES 231 UIDNEXT 44292) 2242 8.2.3. FLAGS Response 2244 Contents: flag parenthesized list 2246 The FLAGS response occurs as a result of a SELECT or EXAMINE command. 2247 The flag parenthesized list identifies the flags (at a minimum, the 2248 system-defined flags) that are applicable for this mailbox. Flags 2249 other than the system flags can also exist, depending on server 2250 implementation. 2252 The update from the FLAGS response MUST be recorded by the client. 2254 Example: S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft) 2256 8.3. Server Responses - Mailbox Size 2258 These responses are always untagged. This is how changes in the size 2259 of the mailbox are transmitted from the server to the client. 2260 Immediately following the "*" token is a number that represents a 2261 message count. 2263 8.3.1. EXISTS Response 2265 Contents: none 2267 The EXISTS response reports the number of messages in the mailbox. 2268 This response occurs as a result of a SELECT or EXAMINE command, and 2269 if the size of the mailbox changes (e.g., new messages). 2271 The update from the EXISTS response MUST be recorded by the client. 2273 Example: S: * 23 EXISTS 2275 8.4. Server Responses - Message Status 2277 [[CREF30: Get rid of message numbers altogether?]] These responses 2278 are always untagged. This is how message data are transmitted from 2279 the server to the client, often as a result of a command with the 2280 same name. Immediately following the "*" token is a number that 2281 represents a message sequence number. 2283 8.4.1. FETCH Response 2285 Contents: message data 2287 The FETCH response returns data about a message to the client. The 2288 data are pairs of data item names and their values in parentheses. 2290 This response occurs as the result of a FETCH or STORE command, as 2291 well as by unilateral server decision (e.g., flag updates). 2293 The current data items are: 2295 BODY[
]<> 2297 A string expressing the contents of the specified chunk or of 2298 the whole message. The section string has the following 2299 syntax: .. For example "0.1" - the first 2300 Tracing chunk. "67.2" - the second Display-Content chunk. 2301 [[CREF31: This needs more thought.]] 2303 The section specification can be the empty string, in which 2304 case the content of the whole message is returned. 2306 If the origin octet is specified, this string is a substring of 2307 the entire body contents, starting at that origin octet. This 2308 means that BODY[]<0> MAY be truncated, but BODY[] is NEVER 2309 truncated. 2311 Note: The origin octet facility MUST NOT be used by a server 2312 in a FETCH response unless the client specifically requested 2313 it by means of a FETCH of a BODY[
]<> data 2314 item. 2316 Binary data is allowed in responses. 2318 BODYSTRUCTURE 2320 [[CREF32: Decide if this is going to be binary or human 2321 readable (e.g. a list).]] 2323 The BODYSTRUCTURE FETCH item contains basic information about 2324 all chunks of the message which enables clients to download 2325 only specific chunks of the message without downloading the 2326 whole message. This can provide performance improvements when 2327 dealing with big attachments. 2329 For each chunk of the message, the BODYSTRUCTURE includes (in 2330 the following order): 2332 chunk type One octet (for binary representation). 2334 body size A number giving the size of the chunk in octets (3 2335 octets in network byte order for binary representation). 2337 FLAGS A parenthesized list of flags that are set for this message. 2339 META Encrypted block of data that represents mutable state 2340 associated with the message, such as encrypted flags. [[CREF33: 2341 TBD]] 2343 MODSEQ A 63 bit unsigned integer (expressed as a decimal), which 2344 represents the message modification sequence. [[CREF34: TBD]] 2346 INTERNALDATE A string representing the internal date of the message 2347 (delivery date or date specified in the APPEND that created the 2348 message). 2350 SIZE A number expressing the size of the message in octets. 2352 UID A number expressing the unique identifier of the message. 2354 Example: S: * 23 FETCH (FLAGS (\Seen) SIZE 44827) 2356 8.5. Server Responses - Command Continuation Request 2358 The command continuation request response is indicated by a "+" token 2359 instead of a tag. This form of response indicates that the server is 2360 ready to accept the continuation of a command from the client. The 2361 remainder of this response is a line of text. 2363 This response is used in the AUTHENTICATE command to transmit server 2364 data to the client, and request additional client data. This 2365 response is also used if an argument to any command is a literal. 2367 [[CREF35: Add non sync literals?]] The client is not permitted to 2368 send the octets of the literal unless the server indicates that it is 2369 expected. This permits the server to process commands and reject 2370 errors on a line-by-line basis. The remainder of the command, 2371 including the CRLF that terminates a command, follows the octets of 2372 the literal. If there are any additional command arguments, the 2373 literal octets are followed by a space and those arguments. 2375 9. Sample DMAP connection 2377 The following is a transcript of an DMAP connection. A long line in 2378 this sample is broken for editorial clarity. 2380 TBD 2382 10. Formal Syntax 2384 The following syntax specification uses the Augmented Backus-Naur 2385 Form (ABNF) notation as specified in [ABNF]. 2387 In the case of alternative or optional rules in which a later rule 2388 overlaps an earlier rule, the rule which is listed earlier MUST take 2389 priority. For example, "\Seen" when parsed as a flag is the \Seen 2390 flag name and not a flag-extension, even though "\Seen" can be parsed 2391 as a flag-extension. Some, but not all, instances of this rule are 2392 noted below. 2394 Note: [ABNF] rules MUST be followed strictly; in particular: 2396 (1) Except as noted otherwise, all alphabetic characters are case- 2397 insensitive. The use of upper or lower case characters to define 2398 token strings is for editorial clarity only. Implementations MUST 2399 accept these strings in a case-insensitive fashion. 2401 (2) In all cases, SP refers to exactly one space. It is NOT 2402 permitted to substitute TAB, insert additional spaces, or 2403 otherwise treat SP as being equivalent to LWSP. 2405 (3) The ASCII NUL character, %x00, MUST NOT be used at any time. 2407 TBD 2409 11. Security Considerations 2411 12. IANA Considerations 2413 IMAP4 capabilities are registered by publishing a standards track or 2414 IESG approved experimental RFC. The registry is currently located 2415 at: http://www.iana.org/assignments/dmap-capabilities 2417 13. Normative References 2419 [ABNF] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 2420 Specifications: ABNF", STD 68, RFC 5234, January 2008, 2421 . 2423 [ANONYMOUS] 2424 Zeilenga, K., "Anonymous Simple Authentication and 2425 Security Layer (SASL) Mechanism", RFC 4505, June 2006, 2426 . 2428 [CHARSET] Freed, N. and J. Postel, "IANA Charset Registration 2429 Procedures", BCP 19, RFC 2978, October 2000, 2430 . 2432 [DIGEST-MD5] 2433 Leach, P. and C. Newman, "Using Digest Authentication as a 2434 SASL Mechanism", RFC 2831, May 2000, 2435 . 2437 [DISPOSITION] 2438 Troost, R., Dorner, S., and K. Moore, Ed., "Communicating 2439 Presentation Information in Internet Messages: The 2440 Content-Disposition Header Field", RFC 2183, August 1997, 2441 . 2443 [PLAIN] Zeilenga, K., Ed., "The PLAIN Simple Authentication and 2444 Security Layer (SASL) Mechanism", RFC 4616, August 2006, 2445 . 2447 [KEYWORDS] 2448 Bradner, S., "Key words for use in RFCs to Indicate 2449 Requirement Levels", BCP 14, RFC 2119, March 1997, 2450 . 2452 [LANGUAGE-TAGS] 2453 Alvestrand, H., "Content Language Headers", RFC 3282, May 2454 2002, . 2456 [LOCATION] 2457 Palme, J., Hopmann, A., and N. Shelness, "MIME 2458 Encapsulation of Aggregate Documents, such as HTML 2459 (MHTML)", RFC 2557, March 1999, 2460 . 2462 [MD5] Myers, J. and M. Rose, "The Content-MD5 Header Field", 2463 RFC 1864, October 1995, 2464 . 2466 [MIME-HDRS] 2467 Moore, K., "MIME (Multipurpose Internet Mail Extensions) 2468 Part Three: Message Header Extensions for Non-ASCII Text", 2469 RFC 2047, November 1996, 2470 . 2472 [MIME-IMB] 2473 Freed, N. and N. Borenstein, "Multipurpose Internet Mail 2474 Extensions (MIME) Part One: Format of Internet Message 2475 Bodies", RFC 2045, November 1996, 2476 . 2478 [MIME-IMT] 2479 Freed, N. and N. Borenstein, "Multipurpose Internet Mail 2480 Extensions (MIME) Part Two: Media Types", RFC 2046, 2481 November 1996, . 2483 [RFC-5322] 2484 Resnick, P., Ed., "Internet Message Format", RFC 5322, 2485 October 2008, . 2487 [SASL] Melnikov, A., Ed. and K. Zeilenga, Ed., "Simple 2488 Authentication and Security Layer (SASL)", RFC 4422, June 2489 2006, . 2491 [TLS] Dierks, T. and E. Rescorla, "The Transport Layer Security 2492 (TLS) Protocol Version 1.2", RFC 5246, August 2008, 2493 . 2495 Appendix A. Change Log 2497 1. TBD 2499 Appendix B. Acknowledgement 2501 This protocol was born after discussions with Ladar Levison. However 2502 he might not necessarily agree with its content and all errors belong 2503 to the editor of this document. 2505 This document is heavily influenced by IMAP (RFC 3501) by Mark 2506 Crispin. 2508 This document borrows some text from draft-kundrat-imap-submit-02.txt 2510 Index 2512 + 2513 +FLAGS 39 2514 +FLAGS.SILENT 39 2516 - 2517 -FLAGS 39 2518 -FLAGS.SILENT 39 2520 A 2521 ADDKEY (command) 32 2522 ALERT (response code) 45 2523 ALL (search key) 35 2524 APPEND (command) 31 2525 AUTHENTICATE (command) 22 2527 B 2528 BAD (response) 46 2529 BODY.PEEK[
]<> (fetch item) 37 2530 BODYSTRUCTURE (fetch item) 37 2531 BODYSTRUCTURE (fetch result) 50 2532 BODY[
]<> (fetch result) 50 2533 BODY[
]<> (fetch item) 37 2534 BYE (response) 47 2535 Body Structure (message attribute) 12 2537 C 2538 CAPABILITY (command) 20 2539 CAPABILITY (response code) 45 2540 CAPABILITY (response) 48 2541 CLOSE (command) 34 2542 COPY (command) 39 2543 CREATE (command) 25 2545 D 2546 DELETE (command) 26 2547 DELETED (search key) 35 2548 DELETEKEY (command) 33 2550 E 2551 EXAMINE (command) 25 2552 EXPUNGE (command) 34 2554 F 2555 FAST (fetch item) 37 2556 FETCH (command) 36 2557 FETCH (response) 49 2558 FLAGS (fetch item) 38 2559 FLAGS (fetch result) 50 2560 FLAGS (response) 49 2561 FLAGS (store command data item) 39 2562 FLAGS.SILENT (store command data item) 39 2563 FULL (fetch item) 37 2564 Flags (message attribute) 11 2566 G 2567 GETKEY (command) 32 2569 I 2570 INTERNALDATE (fetch item) 38 2571 INTERNALDATE (fetch result) 51 2572 Internal Date (message attribute) 12 2574 K 2575 Keyword (type of flag) 12 2577 L 2578 LARGER (search key) 35 2579 LIST (command) 29 2580 LISTKEYS (command) 33 2581 LOGOUT (command) 21 2583 M 2584 MAY (specification requirement term) 5 2585 MESSAGES (status item) 31 2586 META (fetch result) 38, 51 2587 MODSEQ (fetch result) 38, 51 2588 MUST (specification requirement term) 5 2589 MUST NOT (specification requirement term) 5 2590 Message Sequence Number (message attribute) 10 2591 Modification Sequence (message attribute) 12 2593 N 2594 NO (response) 46 2595 NOOP (command) 21 2596 NOT (search key) 35 2598 O 2599 OK (response) 45 2600 ON (search key) 35 2601 OPTIONAL (specification requirement term) 5 2602 OR (search key) 36 2604 P 2605 PERMANENTFLAGS (response code) 45 2606 PREAUTH (response) 46 2607 Permanent Flag (class of flag) 12 2609 R 2610 READ-ONLY (response code) 45 2611 READ-WRITE (response code) 45 2612 RECOMMENDED (specification requirement term) 5 2613 RENAME (command) 27 2614 REQUIRED (specification requirement term) 5 2616 S 2617 SEARCH (command) 35 2618 SEEN (search key) 36 2619 SELECT (command) 24 2620 SHOULD (specification requirement term) 5 2621 SHOULD NOT (specification requirement term) 5 2622 SINCE (search key) 36 2623 SIZE (fetch item) 38 2624 SIZE (fetch result) 51 2625 SMALLER (search key) 36 2626 STATUS (command) 30 2627 STATUS (response) 48 2628 STORE (command) 38 2629 SUBMIT (command) 40 2630 SUBSCRIBE (command) 28 2631 Session Flag (class of flag) 12 2632 Size (message attribute) 12 2633 System Flag (type of flag) 11 2635 T 2636 TRYCREATE (response code) 45 2638 U 2639 UID (command) 41 2640 UID (fetch item) 38 2641 UID (fetch result) 51 2642 UID (search key) 36 2643 UIDNEXT (response code) 45 2644 UIDNEXT (status item) 31 2645 UIDVALIDITY (response code) 45 2646 UIDVALIDITY (status item) 31 2647 UNDELETED (search key) 36 2648 UNSEEN (search key) 36 2649 UNSEEN (status item) 31 2650 UNSUBSCRIBE (command) 28 2651 Unique Identifier (UID) (message attribute) 9 2653 X 2654 X (command) 43 2656 \ 2657 \Answered (system flag) 11 2658 \Deleted (system flag) 11 2659 \Draft (system flag) 11 2660 \Flagged (system flag) 11 2661 \Forwarded (system flag) 11 2662 \Seen (system flag) 11 2663 \Submitted and \SubmitPending (system flags) 11 2665 Author's Address 2666 Alexey Melnikov (editor) 2667 Isode Ltd 2668 14 Castle Mews 2669 Hampton, Middlesex TW12 2NP 2670 UK 2672 Email: Alexey.Melnikov@isode.com