imapext-2007

annotate docs/rfc/rfc3501.txt @ 0:ada5e610ab86

find changesets by author, revision, files, or words in the commit message
imap-2007e
author yuuji@gentei.org
date Mon, 14 Sep 2009 15:17:45 +0900
parents
children
rev   line source
yuuji@0 1
yuuji@0 2
yuuji@0 3
yuuji@0 4
yuuji@0 5
yuuji@0 6
yuuji@0 7 Network Working Group M. Crispin
yuuji@0 8 Request for Comments: 3501 University of Washington
yuuji@0 9 Obsoletes: 2060 March 2003
yuuji@0 10 Category: Standards Track
yuuji@0 11
yuuji@0 12
yuuji@0 13 INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1
yuuji@0 14
yuuji@0 15 Status of this Memo
yuuji@0 16
yuuji@0 17 This document specifies an Internet standards track protocol for the
yuuji@0 18 Internet community, and requests discussion and suggestions for
yuuji@0 19 improvements. Please refer to the current edition of the "Internet
yuuji@0 20 Official Protocol Standards" (STD 1) for the standardization state
yuuji@0 21 and status of this protocol. Distribution of this memo is unlimited.
yuuji@0 22
yuuji@0 23 Copyright Notice
yuuji@0 24
yuuji@0 25 Copyright (C) The Internet Society (2003). All Rights Reserved.
yuuji@0 26
yuuji@0 27 Abstract
yuuji@0 28
yuuji@0 29 The Internet Message Access Protocol, Version 4rev1 (IMAP4rev1)
yuuji@0 30 allows a client to access and manipulate electronic mail messages on
yuuji@0 31 a server. IMAP4rev1 permits manipulation of mailboxes (remote
yuuji@0 32 message folders) in a way that is functionally equivalent to local
yuuji@0 33 folders. IMAP4rev1 also provides the capability for an offline
yuuji@0 34 client to resynchronize with the server.
yuuji@0 35
yuuji@0 36 IMAP4rev1 includes operations for creating, deleting, and renaming
yuuji@0 37 mailboxes, checking for new messages, permanently removing messages,
yuuji@0 38 setting and clearing flags, RFC 2822 and RFC 2045 parsing, searching,
yuuji@0 39 and selective fetching of message attributes, texts, and portions
yuuji@0 40 thereof. Messages in IMAP4rev1 are accessed by the use of numbers.
yuuji@0 41 These numbers are either message sequence numbers or unique
yuuji@0 42 identifiers.
yuuji@0 43
yuuji@0 44 IMAP4rev1 supports a single server. A mechanism for accessing
yuuji@0 45 configuration information to support multiple IMAP4rev1 servers is
yuuji@0 46 discussed in RFC 2244.
yuuji@0 47
yuuji@0 48 IMAP4rev1 does not specify a means of posting mail; this function is
yuuji@0 49 handled by a mail transfer protocol such as RFC 2821.
yuuji@0 50
yuuji@0 51
yuuji@0 52
yuuji@0 53
yuuji@0 54
yuuji@0 55
yuuji@0 56
yuuji@0 57
yuuji@0 58 Crispin Standards Track [Page 1]
yuuji@0 59
yuuji@0 60 RFC 3501 IMAPv4 March 2003
yuuji@0 61
yuuji@0 62
yuuji@0 63 Table of Contents
yuuji@0 64
yuuji@0 65 IMAP4rev1 Protocol Specification ................................ 4
yuuji@0 66 1. How to Read This Document ............................... 4
yuuji@0 67 1.1. Organization of This Document ........................... 4
yuuji@0 68 1.2. Conventions Used in This Document ....................... 4
yuuji@0 69 1.3. Special Notes to Implementors ........................... 5
yuuji@0 70 2. Protocol Overview ....................................... 6
yuuji@0 71 2.1. Link Level .............................................. 6
yuuji@0 72 2.2. Commands and Responses .................................. 6
yuuji@0 73 2.2.1. Client Protocol Sender and Server Protocol Receiver ..... 6
yuuji@0 74 2.2.2. Server Protocol Sender and Client Protocol Receiver ..... 7
yuuji@0 75 2.3. Message Attributes ...................................... 8
yuuji@0 76 2.3.1. Message Numbers ......................................... 8
yuuji@0 77 2.3.1.1. Unique Identifier (UID) Message Attribute ....... 8
yuuji@0 78 2.3.1.2. Message Sequence Number Message Attribute ....... 10
yuuji@0 79 2.3.2. Flags Message Attribute ................................. 11
yuuji@0 80 2.3.3. Internal Date Message Attribute ......................... 12
yuuji@0 81 2.3.4. [RFC-2822] Size Message Attribute ....................... 12
yuuji@0 82 2.3.5. Envelope Structure Message Attribute .................... 12
yuuji@0 83 2.3.6. Body Structure Message Attribute ........................ 12
yuuji@0 84 2.4. Message Texts ........................................... 13
yuuji@0 85 3. State and Flow Diagram .................................. 13
yuuji@0 86 3.1. Not Authenticated State ................................. 13
yuuji@0 87 3.2. Authenticated State ..................................... 13
yuuji@0 88 3.3. Selected State .......................................... 13
yuuji@0 89 3.4. Logout State ............................................ 14
yuuji@0 90 4. Data Formats ............................................ 16
yuuji@0 91 4.1. Atom .................................................... 16
yuuji@0 92 4.2. Number .................................................. 16
yuuji@0 93 4.3. String .................................................. 16
yuuji@0 94 4.3.1. 8-bit and Binary Strings ................................ 17
yuuji@0 95 4.4. Parenthesized List ...................................... 17
yuuji@0 96 4.5. NIL ..................................................... 17
yuuji@0 97 5. Operational Considerations .............................. 18
yuuji@0 98 5.1. Mailbox Naming .......................................... 18
yuuji@0 99 5.1.1. Mailbox Hierarchy Naming ................................ 19
yuuji@0 100 5.1.2. Mailbox Namespace Naming Convention ..................... 19
yuuji@0 101 5.1.3. Mailbox International Naming Convention ................. 19
yuuji@0 102 5.2. Mailbox Size and Message Status Updates ................. 21
yuuji@0 103 5.3. Response when no Command in Progress .................... 21
yuuji@0 104 5.4. Autologout Timer ........................................ 22
yuuji@0 105 5.5. Multiple Commands in Progress ........................... 22
yuuji@0 106 6. Client Commands ........................................ 23
yuuji@0 107 6.1. Client Commands - Any State ............................ 24
yuuji@0 108 6.1.1. CAPABILITY Command ..................................... 24
yuuji@0 109 6.1.2. NOOP Command ........................................... 25
yuuji@0 110 6.1.3. LOGOUT Command ......................................... 26
yuuji@0 111
yuuji@0 112
yuuji@0 113
yuuji@0 114 Crispin Standards Track [Page 2]
yuuji@0 115
yuuji@0 116 RFC 3501 IMAPv4 March 2003
yuuji@0 117
yuuji@0 118
yuuji@0 119 6.2. Client Commands - Not Authenticated State .............. 26
yuuji@0 120 6.2.1. STARTTLS Command ....................................... 27
yuuji@0 121 6.2.2. AUTHENTICATE Command ................................... 28
yuuji@0 122 6.2.3. LOGIN Command .......................................... 30
yuuji@0 123 6.3. Client Commands - Authenticated State .................. 31
yuuji@0 124 6.3.1. SELECT Command ......................................... 32
yuuji@0 125 6.3.2. EXAMINE Command ........................................ 34
yuuji@0 126 6.3.3. CREATE Command ......................................... 34
yuuji@0 127 6.3.4. DELETE Command ......................................... 35
yuuji@0 128 6.3.5. RENAME Command ......................................... 37
yuuji@0 129 6.3.6. SUBSCRIBE Command ...................................... 39
yuuji@0 130 6.3.7. UNSUBSCRIBE Command .................................... 39
yuuji@0 131 6.3.8. LIST Command ........................................... 40
yuuji@0 132 6.3.9. LSUB Command ........................................... 43
yuuji@0 133 6.3.10. STATUS Command ......................................... 44
yuuji@0 134 6.3.11. APPEND Command ......................................... 46
yuuji@0 135 6.4. Client Commands - Selected State ....................... 47
yuuji@0 136 6.4.1. CHECK Command .......................................... 47
yuuji@0 137 6.4.2. CLOSE Command .......................................... 48
yuuji@0 138 6.4.3. EXPUNGE Command ........................................ 49
yuuji@0 139 6.4.4. SEARCH Command ......................................... 49
yuuji@0 140 6.4.5. FETCH Command .......................................... 54
yuuji@0 141 6.4.6. STORE Command .......................................... 58
yuuji@0 142 6.4.7. COPY Command ........................................... 59
yuuji@0 143 6.4.8. UID Command ............................................ 60
yuuji@0 144 6.5. Client Commands - Experimental/Expansion ............... 62
yuuji@0 145 6.5.1. X<atom> Command ........................................ 62
yuuji@0 146 7. Server Responses ....................................... 62
yuuji@0 147 7.1. Server Responses - Status Responses .................... 63
yuuji@0 148 7.1.1. OK Response ............................................ 65
yuuji@0 149 7.1.2. NO Response ............................................ 66
yuuji@0 150 7.1.3. BAD Response ........................................... 66
yuuji@0 151 7.1.4. PREAUTH Response ....................................... 67
yuuji@0 152 7.1.5. BYE Response ........................................... 67
yuuji@0 153 7.2. Server Responses - Server and Mailbox Status ........... 68
yuuji@0 154 7.2.1. CAPABILITY Response .................................... 68
yuuji@0 155 7.2.2. LIST Response .......................................... 69
yuuji@0 156 7.2.3. LSUB Response .......................................... 70
yuuji@0 157 7.2.4 STATUS Response ........................................ 70
yuuji@0 158 7.2.5. SEARCH Response ........................................ 71
yuuji@0 159 7.2.6. FLAGS Response ......................................... 71
yuuji@0 160 7.3. Server Responses - Mailbox Size ........................ 71
yuuji@0 161 7.3.1. EXISTS Response ........................................ 71
yuuji@0 162 7.3.2. RECENT Response ........................................ 72
yuuji@0 163 7.4. Server Responses - Message Status ...................... 72
yuuji@0 164 7.4.1. EXPUNGE Response ....................................... 72
yuuji@0 165 7.4.2. FETCH Response ......................................... 73
yuuji@0 166 7.5. Server Responses - Command Continuation Request ........ 79
yuuji@0 167
yuuji@0 168
yuuji@0 169
yuuji@0 170 Crispin Standards Track [Page 3]
yuuji@0 171
yuuji@0 172 RFC 3501 IMAPv4 March 2003
yuuji@0 173
yuuji@0 174
yuuji@0 175 8. Sample IMAP4rev1 connection ............................ 80
yuuji@0 176 9. Formal Syntax .......................................... 81
yuuji@0 177 10. Author's Note .......................................... 92
yuuji@0 178 11. Security Considerations ................................ 92
yuuji@0 179 11.1. STARTTLS Security Considerations ....................... 92
yuuji@0 180 11.2. Other Security Considerations .......................... 93
yuuji@0 181 12. IANA Considerations .................................... 94
yuuji@0 182 Appendices ..................................................... 95
yuuji@0 183 A. References ............................................. 95
yuuji@0 184 B. Changes from RFC 2060 .................................. 97
yuuji@0 185 C. Key Word Index ......................................... 103
yuuji@0 186 Author's Address ............................................... 107
yuuji@0 187 Full Copyright Statement ....................................... 108
yuuji@0 188
yuuji@0 189 IMAP4rev1 Protocol Specification
yuuji@0 190
yuuji@0 191 1. How to Read This Document
yuuji@0 192
yuuji@0 193 1.1. Organization of This Document
yuuji@0 194
yuuji@0 195 This document is written from the point of view of the implementor of
yuuji@0 196 an IMAP4rev1 client or server. Beyond the protocol overview in
yuuji@0 197 section 2, it is not optimized for someone trying to understand the
yuuji@0 198 operation of the protocol. The material in sections 3 through 5
yuuji@0 199 provides the general context and definitions with which IMAP4rev1
yuuji@0 200 operates.
yuuji@0 201
yuuji@0 202 Sections 6, 7, and 9 describe the IMAP commands, responses, and
yuuji@0 203 syntax, respectively. The relationships among these are such that it
yuuji@0 204 is almost impossible to understand any of them separately. In
yuuji@0 205 particular, do not attempt to deduce command syntax from the command
yuuji@0 206 section alone; instead refer to the Formal Syntax section.
yuuji@0 207
yuuji@0 208 1.2. Conventions Used in This Document
yuuji@0 209
yuuji@0 210 "Conventions" are basic principles or procedures. Document
yuuji@0 211 conventions are noted in this section.
yuuji@0 212
yuuji@0 213 In examples, "C:" and "S:" indicate lines sent by the client and
yuuji@0 214 server respectively.
yuuji@0 215
yuuji@0 216 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
yuuji@0 217 "SHOULD", "SHOULD NOT", "MAY", and "OPTIONAL" in this document are to
yuuji@0 218 be interpreted as described in [KEYWORDS].
yuuji@0 219
yuuji@0 220 The word "can" (not "may") is used to refer to a possible
yuuji@0 221 circumstance or situation, as opposed to an optional facility of the
yuuji@0 222 protocol.
yuuji@0 223
yuuji@0 224
yuuji@0 225
yuuji@0 226 Crispin Standards Track [Page 4]
yuuji@0 227
yuuji@0 228 RFC 3501 IMAPv4 March 2003
yuuji@0 229
yuuji@0 230
yuuji@0 231 "User" is used to refer to a human user, whereas "client" refers to
yuuji@0 232 the software being run by the user.
yuuji@0 233
yuuji@0 234 "Connection" refers to the entire sequence of client/server
yuuji@0 235 interaction from the initial establishment of the network connection
yuuji@0 236 until its termination.
yuuji@0 237
yuuji@0 238 "Session" refers to the sequence of client/server interaction from
yuuji@0 239 the time that a mailbox is selected (SELECT or EXAMINE command) until
yuuji@0 240 the time that selection ends (SELECT or EXAMINE of another mailbox,
yuuji@0 241 CLOSE command, or connection termination).
yuuji@0 242
yuuji@0 243 Characters are 7-bit US-ASCII unless otherwise specified. Other
yuuji@0 244 character sets are indicated using a "CHARSET", as described in
yuuji@0 245 [MIME-IMT] and defined in [CHARSET]. CHARSETs have important
yuuji@0 246 additional semantics in addition to defining character set; refer to
yuuji@0 247 these documents for more detail.
yuuji@0 248
yuuji@0 249 There are several protocol conventions in IMAP. These refer to
yuuji@0 250 aspects of the specification which are not strictly part of the IMAP
yuuji@0 251 protocol, but reflect generally-accepted practice. Implementations
yuuji@0 252 need to be aware of these conventions, and avoid conflicts whether or
yuuji@0 253 not they implement the convention. For example, "&" may not be used
yuuji@0 254 as a hierarchy delimiter since it conflicts with the Mailbox
yuuji@0 255 International Naming Convention, and other uses of "&" in mailbox
yuuji@0 256 names are impacted as well.
yuuji@0 257
yuuji@0 258 1.3. Special Notes to Implementors
yuuji@0 259
yuuji@0 260 Implementors of the IMAP protocol are strongly encouraged to read the
yuuji@0 261 IMAP implementation recommendations document [IMAP-IMPLEMENTATION] in
yuuji@0 262 conjunction with this document, to help understand the intricacies of
yuuji@0 263 this protocol and how best to build an interoperable product.
yuuji@0 264
yuuji@0 265 IMAP4rev1 is designed to be upwards compatible from the [IMAP2] and
yuuji@0 266 unpublished IMAP2bis protocols. IMAP4rev1 is largely compatible with
yuuji@0 267 the IMAP4 protocol described in RFC 1730; the exception being in
yuuji@0 268 certain facilities added in RFC 1730 that proved problematic and were
yuuji@0 269 subsequently removed. In the course of the evolution of IMAP4rev1,
yuuji@0 270 some aspects in the earlier protocols have become obsolete. Obsolete
yuuji@0 271 commands, responses, and data formats which an IMAP4rev1
yuuji@0 272 implementation can encounter when used with an earlier implementation
yuuji@0 273 are described in [IMAP-OBSOLETE].
yuuji@0 274
yuuji@0 275 Other compatibility issues with IMAP2bis, the most common variant of
yuuji@0 276 the earlier protocol, are discussed in [IMAP-COMPAT]. A full
yuuji@0 277 discussion of compatibility issues with rare (and presumed extinct)
yuuji@0 278
yuuji@0 279
yuuji@0 280
yuuji@0 281
yuuji@0 282 Crispin Standards Track [Page 5]
yuuji@0 283
yuuji@0 284 RFC 3501 IMAPv4 March 2003
yuuji@0 285
yuuji@0 286
yuuji@0 287 variants of [IMAP2] is in [IMAP-HISTORICAL]; this document is
yuuji@0 288 primarily of historical interest.
yuuji@0 289
yuuji@0 290 IMAP was originally developed for the older [RFC-822] standard, and
yuuji@0 291 as a consequence several fetch items in IMAP incorporate "RFC822" in
yuuji@0 292 their name. With the exception of RFC822.SIZE, there are more modern
yuuji@0 293 replacements; for example, the modern version of RFC822.HEADER is
yuuji@0 294 BODY.PEEK[HEADER]. In all cases, "RFC822" should be interpreted as a
yuuji@0 295 reference to the updated [RFC-2822] standard.
yuuji@0 296
yuuji@0 297 2. Protocol Overview
yuuji@0 298
yuuji@0 299 2.1. Link Level
yuuji@0 300
yuuji@0 301 The IMAP4rev1 protocol assumes a reliable data stream such as that
yuuji@0 302 provided by TCP. When TCP is used, an IMAP4rev1 server listens on
yuuji@0 303 port 143.
yuuji@0 304
yuuji@0 305 2.2. Commands and Responses
yuuji@0 306
yuuji@0 307 An IMAP4rev1 connection consists of the establishment of a
yuuji@0 308 client/server network connection, an initial greeting from the
yuuji@0 309 server, and client/server interactions. These client/server
yuuji@0 310 interactions consist of a client command, server data, and a server
yuuji@0 311 completion result response.
yuuji@0 312
yuuji@0 313 All interactions transmitted by client and server are in the form of
yuuji@0 314 lines, that is, strings that end with a CRLF. The protocol receiver
yuuji@0 315 of an IMAP4rev1 client or server is either reading a line, or is
yuuji@0 316 reading a sequence of octets with a known count followed by a line.
yuuji@0 317
yuuji@0 318 2.2.1. Client Protocol Sender and Server Protocol Receiver
yuuji@0 319
yuuji@0 320 The client command begins an operation. Each client command is
yuuji@0 321 prefixed with an identifier (typically a short alphanumeric string,
yuuji@0 322 e.g., A0001, A0002, etc.) called a "tag". A different tag is
yuuji@0 323 generated by the client for each command.
yuuji@0 324
yuuji@0 325 Clients MUST follow the syntax outlined in this specification
yuuji@0 326 strictly. It is a syntax error to send a command with missing or
yuuji@0 327 extraneous spaces or arguments.
yuuji@0 328
yuuji@0 329 There are two cases in which a line from the client does not
yuuji@0 330 represent a complete command. In one case, a command argument is
yuuji@0 331 quoted with an octet count (see the description of literal in String
yuuji@0 332 under Data Formats); in the other case, the command arguments require
yuuji@0 333 server feedback (see the AUTHENTICATE command). In either case, the
yuuji@0 334
yuuji@0 335
yuuji@0 336
yuuji@0 337
yuuji@0 338 Crispin Standards Track [Page 6]
yuuji@0 339
yuuji@0 340 RFC 3501 IMAPv4 March 2003
yuuji@0 341
yuuji@0 342
yuuji@0 343 server sends a command continuation request response if it is ready
yuuji@0 344 for the octets (if appropriate) and the remainder of the command.
yuuji@0 345 This response is prefixed with the token "+".
yuuji@0 346
yuuji@0 347 Note: If instead, the server detected an error in the
yuuji@0 348 command, it sends a BAD completion response with a tag
yuuji@0 349 matching the command (as described below) to reject the
yuuji@0 350 command and prevent the client from sending any more of the
yuuji@0 351 command.
yuuji@0 352
yuuji@0 353 It is also possible for the server to send a completion
yuuji@0 354 response for some other command (if multiple commands are
yuuji@0 355 in progress), or untagged data. In either case, the
yuuji@0 356 command continuation request is still pending; the client
yuuji@0 357 takes the appropriate action for the response, and reads
yuuji@0 358 another response from the server. In all cases, the client
yuuji@0 359 MUST send a complete command (including receiving all
yuuji@0 360 command continuation request responses and command
yuuji@0 361 continuations for the command) before initiating a new
yuuji@0 362 command.
yuuji@0 363
yuuji@0 364 The protocol receiver of an IMAP4rev1 server reads a command line
yuuji@0 365 from the client, parses the command and its arguments, and transmits
yuuji@0 366 server data and a server command completion result response.
yuuji@0 367
yuuji@0 368 2.2.2. Server Protocol Sender and Client Protocol Receiver
yuuji@0 369
yuuji@0 370 Data transmitted by the server to the client and status responses
yuuji@0 371 that do not indicate command completion are prefixed with the token
yuuji@0 372 "*", and are called untagged responses.
yuuji@0 373
yuuji@0 374 Server data MAY be sent as a result of a client command, or MAY be
yuuji@0 375 sent unilaterally by the server. There is no syntactic difference
yuuji@0 376 between server data that resulted from a specific command and server
yuuji@0 377 data that were sent unilaterally.
yuuji@0 378
yuuji@0 379 The server completion result response indicates the success or
yuuji@0 380 failure of the operation. It is tagged with the same tag as the
yuuji@0 381 client command which began the operation. Thus, if more than one
yuuji@0 382 command is in progress, the tag in a server completion response
yuuji@0 383 identifies the command to which the response applies. There are
yuuji@0 384 three possible server completion responses: OK (indicating success),
yuuji@0 385 NO (indicating failure), or BAD (indicating a protocol error such as
yuuji@0 386 unrecognized command or command syntax error).
yuuji@0 387
yuuji@0 388 Servers SHOULD enforce the syntax outlined in this specification
yuuji@0 389 strictly. Any client command with a protocol syntax error, including
yuuji@0 390 (but not limited to) missing or extraneous spaces or arguments,
yuuji@0 391
yuuji@0 392
yuuji@0 393
yuuji@0 394 Crispin Standards Track [Page 7]
yuuji@0 395
yuuji@0 396 RFC 3501 IMAPv4 March 2003
yuuji@0 397
yuuji@0 398
yuuji@0 399 SHOULD be rejected, and the client given a BAD server completion
yuuji@0 400 response.
yuuji@0 401
yuuji@0 402 The protocol receiver of an IMAP4rev1 client reads a response line
yuuji@0 403 from the server. It then takes action on the response based upon the
yuuji@0 404 first token of the response, which can be a tag, a "*", or a "+".
yuuji@0 405
yuuji@0 406 A client MUST be prepared to accept any server response at all times.
yuuji@0 407 This includes server data that was not requested. Server data SHOULD
yuuji@0 408 be recorded, so that the client can reference its recorded copy
yuuji@0 409 rather than sending a command to the server to request the data. In
yuuji@0 410 the case of certain server data, the data MUST be recorded.
yuuji@0 411
yuuji@0 412 This topic is discussed in greater detail in the Server Responses
yuuji@0 413 section.
yuuji@0 414
yuuji@0 415 2.3. Message Attributes
yuuji@0 416
yuuji@0 417 In addition to message text, each message has several attributes
yuuji@0 418 associated with it. These attributes can be retrieved individually
yuuji@0 419 or in conjunction with other attributes or message texts.
yuuji@0 420
yuuji@0 421 2.3.1. Message Numbers
yuuji@0 422
yuuji@0 423 Messages in IMAP4rev1 are accessed by one of two numbers; the unique
yuuji@0 424 identifier or the message sequence number.
yuuji@0 425
yuuji@0 426
yuuji@0 427 2.3.1.1. Unique Identifier (UID) Message Attribute
yuuji@0 428
yuuji@0 429 A 32-bit value assigned to each message, which when used with the
yuuji@0 430 unique identifier validity value (see below) forms a 64-bit value
yuuji@0 431 that MUST NOT refer to any other message in the mailbox or any
yuuji@0 432 subsequent mailbox with the same name forever. Unique identifiers
yuuji@0 433 are assigned in a strictly ascending fashion in the mailbox; as each
yuuji@0 434 message is added to the mailbox it is assigned a higher UID than the
yuuji@0 435 message(s) which were added previously. Unlike message sequence
yuuji@0 436 numbers, unique identifiers are not necessarily contiguous.
yuuji@0 437
yuuji@0 438 The unique identifier of a message MUST NOT change during the
yuuji@0 439 session, and SHOULD NOT change between sessions. Any change of
yuuji@0 440 unique identifiers between sessions MUST be detectable using the
yuuji@0 441 UIDVALIDITY mechanism discussed below. Persistent unique identifiers
yuuji@0 442 are required for a client to resynchronize its state from a previous
yuuji@0 443 session with the server (e.g., disconnected or offline access
yuuji@0 444 clients); this is discussed further in [IMAP-DISC].
yuuji@0 445
yuuji@0 446
yuuji@0 447
yuuji@0 448
yuuji@0 449
yuuji@0 450 Crispin Standards Track [Page 8]
yuuji@0 451
yuuji@0 452 RFC 3501 IMAPv4 March 2003
yuuji@0 453
yuuji@0 454
yuuji@0 455 Associated with every mailbox are two values which aid in unique
yuuji@0 456 identifier handling: the next unique identifier value and the unique
yuuji@0 457 identifier validity value.
yuuji@0 458
yuuji@0 459 The next unique identifier value is the predicted value that will be
yuuji@0 460 assigned to a new message in the mailbox. Unless the unique
yuuji@0 461 identifier validity also changes (see below), the next unique
yuuji@0 462 identifier value MUST have the following two characteristics. First,
yuuji@0 463 the next unique identifier value MUST NOT change unless new messages
yuuji@0 464 are added to the mailbox; and second, the next unique identifier
yuuji@0 465 value MUST change whenever new messages are added to the mailbox,
yuuji@0 466 even if those new messages are subsequently expunged.
yuuji@0 467
yuuji@0 468 Note: The next unique identifier value is intended to
yuuji@0 469 provide a means for a client to determine whether any
yuuji@0 470 messages have been delivered to the mailbox since the
yuuji@0 471 previous time it checked this value. It is not intended to
yuuji@0 472 provide any guarantee that any message will have this
yuuji@0 473 unique identifier. A client can only assume, at the time
yuuji@0 474 that it obtains the next unique identifier value, that
yuuji@0 475 messages arriving after that time will have a UID greater
yuuji@0 476 than or equal to that value.
yuuji@0 477
yuuji@0 478 The unique identifier validity value is sent in a UIDVALIDITY
yuuji@0 479 response code in an OK untagged response at mailbox selection time.
yuuji@0 480 If unique identifiers from an earlier session fail to persist in this
yuuji@0 481 session, the unique identifier validity value MUST be greater than
yuuji@0 482 the one used in the earlier session.
yuuji@0 483
yuuji@0 484 Note: Ideally, unique identifiers SHOULD persist at all
yuuji@0 485 times. Although this specification recognizes that failure
yuuji@0 486 to persist can be unavoidable in certain server
yuuji@0 487 environments, it STRONGLY ENCOURAGES message store
yuuji@0 488 implementation techniques that avoid this problem. For
yuuji@0 489 example:
yuuji@0 490
yuuji@0 491 1) Unique identifiers MUST be strictly ascending in the
yuuji@0 492 mailbox at all times. If the physical message store is
yuuji@0 493 re-ordered by a non-IMAP agent, this requires that the
yuuji@0 494 unique identifiers in the mailbox be regenerated, since
yuuji@0 495 the former unique identifiers are no longer strictly
yuuji@0 496 ascending as a result of the re-ordering.
yuuji@0 497
yuuji@0 498 2) If the message store has no mechanism to store unique
yuuji@0 499 identifiers, it must regenerate unique identifiers at
yuuji@0 500 each session, and each session must have a unique
yuuji@0 501 UIDVALIDITY value.
yuuji@0 502
yuuji@0 503
yuuji@0 504
yuuji@0 505
yuuji@0 506 Crispin Standards Track [Page 9]
yuuji@0 507
yuuji@0 508 RFC 3501 IMAPv4 March 2003
yuuji@0 509
yuuji@0 510
yuuji@0 511 3) If the mailbox is deleted and a new mailbox with the
yuuji@0 512 same name is created at a later date, the server must
yuuji@0 513 either keep track of unique identifiers from the
yuuji@0 514 previous instance of the mailbox, or it must assign a
yuuji@0 515 new UIDVALIDITY value to the new instance of the
yuuji@0 516 mailbox. A good UIDVALIDITY value to use in this case
yuuji@0 517 is a 32-bit representation of the creation date/time of
yuuji@0 518 the mailbox. It is alright to use a constant such as
yuuji@0 519 1, but only if it guaranteed that unique identifiers
yuuji@0 520 will never be reused, even in the case of a mailbox
yuuji@0 521 being deleted (or renamed) and a new mailbox by the
yuuji@0 522 same name created at some future time.
yuuji@0 523
yuuji@0 524 4) The combination of mailbox name, UIDVALIDITY, and UID
yuuji@0 525 must refer to a single immutable message on that server
yuuji@0 526 forever. In particular, the internal date, [RFC-2822]
yuuji@0 527 size, envelope, body structure, and message texts
yuuji@0 528 (RFC822, RFC822.HEADER, RFC822.TEXT, and all BODY[...]
yuuji@0 529 fetch data items) must never change. This does not
yuuji@0 530 include message numbers, nor does it include attributes
yuuji@0 531 that can be set by a STORE command (e.g., FLAGS).
yuuji@0 532
yuuji@0 533
yuuji@0 534 2.3.1.2. Message Sequence Number Message Attribute
yuuji@0 535
yuuji@0 536 A relative position from 1 to the number of messages in the mailbox.
yuuji@0 537 This position MUST be ordered by ascending unique identifier. As
yuuji@0 538 each new message is added, it is assigned a message sequence number
yuuji@0 539 that is 1 higher than the number of messages in the mailbox before
yuuji@0 540 that new message was added.
yuuji@0 541
yuuji@0 542 Message sequence numbers can be reassigned during the session. For
yuuji@0 543 example, when a message is permanently removed (expunged) from the
yuuji@0 544 mailbox, the message sequence number for all subsequent messages is
yuuji@0 545 decremented. The number of messages in the mailbox is also
yuuji@0 546 decremented. Similarly, a new message can be assigned a message
yuuji@0 547 sequence number that was once held by some other message prior to an
yuuji@0 548 expunge.
yuuji@0 549
yuuji@0 550 In addition to accessing messages by relative position in the
yuuji@0 551 mailbox, message sequence numbers can be used in mathematical
yuuji@0 552 calculations. For example, if an untagged "11 EXISTS" is received,
yuuji@0 553 and previously an untagged "8 EXISTS" was received, three new
yuuji@0 554 messages have arrived with message sequence numbers of 9, 10, and 11.
yuuji@0 555 Another example, if message 287 in a 523 message mailbox has UID
yuuji@0 556 12345, there are exactly 286 messages which have lesser UIDs and 236
yuuji@0 557 messages which have greater UIDs.
yuuji@0 558
yuuji@0 559
yuuji@0 560
yuuji@0 561
yuuji@0 562 Crispin Standards Track [Page 10]
yuuji@0 563
yuuji@0 564 RFC 3501 IMAPv4 March 2003
yuuji@0 565
yuuji@0 566
yuuji@0 567 2.3.2. Flags Message Attribute
yuuji@0 568
yuuji@0 569 A list of zero or more named tokens associated with the message. A
yuuji@0 570 flag is set by its addition to this list, and is cleared by its
yuuji@0 571 removal. There are two types of flags in IMAP4rev1. A flag of
yuuji@0 572 either type can be permanent or session-only.
yuuji@0 573
yuuji@0 574 A system flag is a flag name that is pre-defined in this
yuuji@0 575 specification. All system flags begin with "\". Certain system
yuuji@0 576 flags (\Deleted and \Seen) have special semantics described
yuuji@0 577 elsewhere. The currently-defined system flags are:
yuuji@0 578
yuuji@0 579 \Seen
yuuji@0 580 Message has been read
yuuji@0 581
yuuji@0 582 \Answered
yuuji@0 583 Message has been answered
yuuji@0 584
yuuji@0 585 \Flagged
yuuji@0 586 Message is "flagged" for urgent/special attention
yuuji@0 587
yuuji@0 588 \Deleted
yuuji@0 589 Message is "deleted" for removal by later EXPUNGE
yuuji@0 590
yuuji@0 591 \Draft
yuuji@0 592 Message has not completed composition (marked as a draft).
yuuji@0 593
yuuji@0 594 \Recent
yuuji@0 595 Message is "recently" arrived in this mailbox. This session
yuuji@0 596 is the first session to have been notified about this
yuuji@0 597 message; if the session is read-write, subsequent sessions
yuuji@0 598 will not see \Recent set for this message. This flag can not
yuuji@0 599 be altered by the client.
yuuji@0 600
yuuji@0 601 If it is not possible to determine whether or not this
yuuji@0 602 session is the first session to be notified about a message,
yuuji@0 603 then that message SHOULD be considered recent.
yuuji@0 604
yuuji@0 605 If multiple connections have the same mailbox selected
yuuji@0 606 simultaneously, it is undefined which of these connections
yuuji@0 607 will see newly-arrived messages with \Recent set and which
yuuji@0 608 will see it without \Recent set.
yuuji@0 609
yuuji@0 610 A keyword is defined by the server implementation. Keywords do not
yuuji@0 611 begin with "\". Servers MAY permit the client to define new keywords
yuuji@0 612 in the mailbox (see the description of the PERMANENTFLAGS response
yuuji@0 613 code for more information).
yuuji@0 614
yuuji@0 615
yuuji@0 616
yuuji@0 617
yuuji@0 618 Crispin Standards Track [Page 11]
yuuji@0 619
yuuji@0 620 RFC 3501 IMAPv4 March 2003
yuuji@0 621
yuuji@0 622
yuuji@0 623 A flag can be permanent or session-only on a per-flag basis.
yuuji@0 624 Permanent flags are those which the client can add or remove from the
yuuji@0 625 message flags permanently; that is, concurrent and subsequent
yuuji@0 626 sessions will see any change in permanent flags. Changes to session
yuuji@0 627 flags are valid only in that session.
yuuji@0 628
yuuji@0 629 Note: The \Recent system flag is a special case of a
yuuji@0 630 session flag. \Recent can not be used as an argument in a
yuuji@0 631 STORE or APPEND command, and thus can not be changed at
yuuji@0 632 all.
yuuji@0 633
yuuji@0 634 2.3.3. Internal Date Message Attribute
yuuji@0 635
yuuji@0 636 The internal date and time of the message on the server. This
yuuji@0 637 is not the date and time in the [RFC-2822] header, but rather a
yuuji@0 638 date and time which reflects when the message was received. In
yuuji@0 639 the case of messages delivered via [SMTP], this SHOULD be the
yuuji@0 640 date and time of final delivery of the message as defined by
yuuji@0 641 [SMTP]. In the case of messages delivered by the IMAP4rev1 COPY
yuuji@0 642 command, this SHOULD be the internal date and time of the source
yuuji@0 643 message. In the case of messages delivered by the IMAP4rev1
yuuji@0 644 APPEND command, this SHOULD be the date and time as specified in
yuuji@0 645 the APPEND command description. All other cases are
yuuji@0 646 implementation defined.
yuuji@0 647
yuuji@0 648 2.3.4. [RFC-2822] Size Message Attribute
yuuji@0 649
yuuji@0 650 The number of octets in the message, as expressed in [RFC-2822]
yuuji@0 651 format.
yuuji@0 652
yuuji@0 653 2.3.5. Envelope Structure Message Attribute
yuuji@0 654
yuuji@0 655 A parsed representation of the [RFC-2822] header of the message.
yuuji@0 656 Note that the IMAP Envelope structure is not the same as an
yuuji@0 657 [SMTP] envelope.
yuuji@0 658
yuuji@0 659 2.3.6. Body Structure Message Attribute
yuuji@0 660
yuuji@0 661 A parsed representation of the [MIME-IMB] body structure
yuuji@0 662 information of the message.
yuuji@0 663
yuuji@0 664
yuuji@0 665
yuuji@0 666
yuuji@0 667
yuuji@0 668
yuuji@0 669
yuuji@0 670
yuuji@0 671
yuuji@0 672
yuuji@0 673
yuuji@0 674 Crispin Standards Track [Page 12]
yuuji@0 675
yuuji@0 676 RFC 3501 IMAPv4 March 2003
yuuji@0 677
yuuji@0 678
yuuji@0 679 2.4. Message Texts
yuuji@0 680
yuuji@0 681 In addition to being able to fetch the full [RFC-2822] text of a
yuuji@0 682 message, IMAP4rev1 permits the fetching of portions of the full
yuuji@0 683 message text. Specifically, it is possible to fetch the
yuuji@0 684 [RFC-2822] message header, [RFC-2822] message body, a [MIME-IMB]
yuuji@0 685 body part, or a [MIME-IMB] header.
yuuji@0 686
yuuji@0 687 3. State and Flow Diagram
yuuji@0 688
yuuji@0 689 Once the connection between client and server is established, an
yuuji@0 690 IMAP4rev1 connection is in one of four states. The initial
yuuji@0 691 state is identified in the server greeting. Most commands are
yuuji@0 692 only valid in certain states. It is a protocol error for the
yuuji@0 693 client to attempt a command while the connection is in an
yuuji@0 694 inappropriate state, and the server will respond with a BAD or
yuuji@0 695 NO (depending upon server implementation) command completion
yuuji@0 696 result.
yuuji@0 697
yuuji@0 698 3.1. Not Authenticated State
yuuji@0 699
yuuji@0 700 In the not authenticated state, the client MUST supply
yuuji@0 701 authentication credentials before most commands will be
yuuji@0 702 permitted. This state is entered when a connection starts
yuuji@0 703 unless the connection has been pre-authenticated.
yuuji@0 704
yuuji@0 705 3.2. Authenticated State
yuuji@0 706
yuuji@0 707 In the authenticated state, the client is authenticated and MUST
yuuji@0 708 select a mailbox to access before commands that affect messages
yuuji@0 709 will be permitted. This state is entered when a
yuuji@0 710 pre-authenticated connection starts, when acceptable
yuuji@0 711 authentication credentials have been provided, after an error in
yuuji@0 712 selecting a mailbox, or after a successful CLOSE command.
yuuji@0 713
yuuji@0 714 3.3. Selected State
yuuji@0 715
yuuji@0 716 In a selected state, a mailbox has been selected to access.
yuuji@0 717 This state is entered when a mailbox has been successfully
yuuji@0 718 selected.
yuuji@0 719
yuuji@0 720
yuuji@0 721
yuuji@0 722
yuuji@0 723
yuuji@0 724
yuuji@0 725
yuuji@0 726
yuuji@0 727
yuuji@0 728
yuuji@0 729
yuuji@0 730 Crispin Standards Track [Page 13]
yuuji@0 731
yuuji@0 732 RFC 3501 IMAPv4 March 2003
yuuji@0 733
yuuji@0 734
yuuji@0 735 3.4. Logout State
yuuji@0 736
yuuji@0 737 In the logout state, the connection is being terminated. This
yuuji@0 738 state can be entered as a result of a client request (via the
yuuji@0 739 LOGOUT command) or by unilateral action on the part of either
yuuji@0 740 the client or server.
yuuji@0 741
yuuji@0 742 If the client requests the logout state, the server MUST send an
yuuji@0 743 untagged BYE response and a tagged OK response to the LOGOUT
yuuji@0 744 command before the server closes the connection; and the client
yuuji@0 745 MUST read the tagged OK response to the LOGOUT command before
yuuji@0 746 the client closes the connection.
yuuji@0 747
yuuji@0 748 A server MUST NOT unilaterally close the connection without
yuuji@0 749 sending an untagged BYE response that contains the reason for
yuuji@0 750 having done so. A client SHOULD NOT unilaterally close the
yuuji@0 751 connection, and instead SHOULD issue a LOGOUT command. If the
yuuji@0 752 server detects that the client has unilaterally closed the
yuuji@0 753 connection, the server MAY omit the untagged BYE response and
yuuji@0 754 simply close its connection.
yuuji@0 755
yuuji@0 756
yuuji@0 757
yuuji@0 758
yuuji@0 759
yuuji@0 760
yuuji@0 761
yuuji@0 762
yuuji@0 763
yuuji@0 764
yuuji@0 765
yuuji@0 766
yuuji@0 767
yuuji@0 768
yuuji@0 769
yuuji@0 770
yuuji@0 771
yuuji@0 772
yuuji@0 773
yuuji@0 774
yuuji@0 775
yuuji@0 776
yuuji@0 777
yuuji@0 778
yuuji@0 779
yuuji@0 780
yuuji@0 781
yuuji@0 782
yuuji@0 783
yuuji@0 784
yuuji@0 785
yuuji@0 786 Crispin Standards Track [Page 14]
yuuji@0 787
yuuji@0 788 RFC 3501 IMAPv4 March 2003
yuuji@0 789
yuuji@0 790
yuuji@0 791 +----------------------+
yuuji@0 792 |connection established|
yuuji@0 793 +----------------------+
yuuji@0 794 ||
yuuji@0 795 \/
yuuji@0 796 +--------------------------------------+
yuuji@0 797 | server greeting |
yuuji@0 798 +--------------------------------------+
yuuji@0 799 || (1) || (2) || (3)
yuuji@0 800 \/ || ||
yuuji@0 801 +-----------------+ || ||
yuuji@0 802 |Not Authenticated| || ||
yuuji@0 803 +-----------------+ || ||
yuuji@0 804 || (7) || (4) || ||
yuuji@0 805 || \/ \/ ||
yuuji@0 806 || +----------------+ ||
yuuji@0 807 || | Authenticated |<=++ ||
yuuji@0 808 || +----------------+ || ||
yuuji@0 809 || || (7) || (5) || (6) ||
yuuji@0 810 || || \/ || ||
yuuji@0 811 || || +--------+ || ||
yuuji@0 812 || || |Selected|==++ ||
yuuji@0 813 || || +--------+ ||
yuuji@0 814 || || || (7) ||
yuuji@0 815 \/ \/ \/ \/
yuuji@0 816 +--------------------------------------+
yuuji@0 817 | Logout |
yuuji@0 818 +--------------------------------------+
yuuji@0 819 ||
yuuji@0 820 \/
yuuji@0 821 +-------------------------------+
yuuji@0 822 |both sides close the connection|
yuuji@0 823 +-------------------------------+
yuuji@0 824
yuuji@0 825 (1) connection without pre-authentication (OK greeting)
yuuji@0 826 (2) pre-authenticated connection (PREAUTH greeting)
yuuji@0 827 (3) rejected connection (BYE greeting)
yuuji@0 828 (4) successful LOGIN or AUTHENTICATE command
yuuji@0 829 (5) successful SELECT or EXAMINE command
yuuji@0 830 (6) CLOSE command, or failed SELECT or EXAMINE command
yuuji@0 831 (7) LOGOUT command, server shutdown, or connection closed
yuuji@0 832
yuuji@0 833
yuuji@0 834
yuuji@0 835
yuuji@0 836
yuuji@0 837
yuuji@0 838
yuuji@0 839
yuuji@0 840
yuuji@0 841
yuuji@0 842 Crispin Standards Track [Page 15]
yuuji@0 843
yuuji@0 844 RFC 3501 IMAPv4 March 2003
yuuji@0 845
yuuji@0 846
yuuji@0 847 4. Data Formats
yuuji@0 848
yuuji@0 849 IMAP4rev1 uses textual commands and responses. Data in
yuuji@0 850 IMAP4rev1 can be in one of several forms: atom, number, string,
yuuji@0 851 parenthesized list, or NIL. Note that a particular data item
yuuji@0 852 may take more than one form; for example, a data item defined as
yuuji@0 853 using "astring" syntax may be either an atom or a string.
yuuji@0 854
yuuji@0 855 4.1. Atom
yuuji@0 856
yuuji@0 857 An atom consists of one or more non-special characters.
yuuji@0 858
yuuji@0 859 4.2. Number
yuuji@0 860
yuuji@0 861 A number consists of one or more digit characters, and
yuuji@0 862 represents a numeric value.
yuuji@0 863
yuuji@0 864 4.3. String
yuuji@0 865
yuuji@0 866 A string is in one of two forms: either literal or quoted
yuuji@0 867 string. The literal form is the general form of string. The
yuuji@0 868 quoted string form is an alternative that avoids the overhead of
yuuji@0 869 processing a literal at the cost of limitations of characters
yuuji@0 870 which may be used.
yuuji@0 871
yuuji@0 872 A literal is a sequence of zero or more octets (including CR and
yuuji@0 873 LF), prefix-quoted with an octet count in the form of an open
yuuji@0 874 brace ("{"), the number of octets, close brace ("}"), and CRLF.
yuuji@0 875 In the case of literals transmitted from server to client, the
yuuji@0 876 CRLF is immediately followed by the octet data. In the case of
yuuji@0 877 literals transmitted from client to server, the client MUST wait
yuuji@0 878 to receive a command continuation request (described later in
yuuji@0 879 this document) before sending the octet data (and the remainder
yuuji@0 880 of the command).
yuuji@0 881
yuuji@0 882 A quoted string is a sequence of zero or more 7-bit characters,
yuuji@0 883 excluding CR and LF, with double quote (<">) characters at each
yuuji@0 884 end.
yuuji@0 885
yuuji@0 886 The empty string is represented as either "" (a quoted string
yuuji@0 887 with zero characters between double quotes) or as {0} followed
yuuji@0 888 by CRLF (a literal with an octet count of 0).
yuuji@0 889
yuuji@0 890 Note: Even if the octet count is 0, a client transmitting a
yuuji@0 891 literal MUST wait to receive a command continuation request.
yuuji@0 892
yuuji@0 893
yuuji@0 894
yuuji@0 895
yuuji@0 896
yuuji@0 897
yuuji@0 898 Crispin Standards Track [Page 16]
yuuji@0 899
yuuji@0 900 RFC 3501 IMAPv4 March 2003
yuuji@0 901
yuuji@0 902
yuuji@0 903 4.3.1. 8-bit and Binary Strings
yuuji@0 904
yuuji@0 905 8-bit textual and binary mail is supported through the use of a
yuuji@0 906 [MIME-IMB] content transfer encoding. IMAP4rev1 implementations MAY
yuuji@0 907 transmit 8-bit or multi-octet characters in literals, but SHOULD do
yuuji@0 908 so only when the [CHARSET] is identified.
yuuji@0 909
yuuji@0 910 Although a BINARY body encoding is defined, unencoded binary strings
yuuji@0 911 are not permitted. A "binary string" is any string with NUL
yuuji@0 912 characters. Implementations MUST encode binary data into a textual
yuuji@0 913 form, such as BASE64, before transmitting the data. A string with an
yuuji@0 914 excessive amount of CTL characters MAY also be considered to be
yuuji@0 915 binary.
yuuji@0 916
yuuji@0 917 4.4. Parenthesized List
yuuji@0 918
yuuji@0 919 Data structures are represented as a "parenthesized list"; a sequence
yuuji@0 920 of data items, delimited by space, and bounded at each end by
yuuji@0 921 parentheses. A parenthesized list can contain other parenthesized
yuuji@0 922 lists, using multiple levels of parentheses to indicate nesting.
yuuji@0 923
yuuji@0 924 The empty list is represented as () -- a parenthesized list with no
yuuji@0 925 members.
yuuji@0 926
yuuji@0 927 4.5. NIL
yuuji@0 928
yuuji@0 929 The special form "NIL" represents the non-existence of a particular
yuuji@0 930 data item that is represented as a string or parenthesized list, as
yuuji@0 931 distinct from the empty string "" or the empty parenthesized list ().
yuuji@0 932
yuuji@0 933 Note: NIL is never used for any data item which takes the
yuuji@0 934 form of an atom. For example, a mailbox name of "NIL" is a
yuuji@0 935 mailbox named NIL as opposed to a non-existent mailbox
yuuji@0 936 name. This is because mailbox uses "astring" syntax which
yuuji@0 937 is an atom or a string. Conversely, an addr-name of NIL is
yuuji@0 938 a non-existent personal name, because addr-name uses
yuuji@0 939 "nstring" syntax which is NIL or a string, but never an
yuuji@0 940 atom.
yuuji@0 941
yuuji@0 942
yuuji@0 943
yuuji@0 944
yuuji@0 945
yuuji@0 946
yuuji@0 947
yuuji@0 948
yuuji@0 949
yuuji@0 950
yuuji@0 951
yuuji@0 952
yuuji@0 953
yuuji@0 954 Crispin Standards Track [Page 17]
yuuji@0 955
yuuji@0 956 RFC 3501 IMAPv4 March 2003
yuuji@0 957
yuuji@0 958
yuuji@0 959 5. Operational Considerations
yuuji@0 960
yuuji@0 961 The following rules are listed here to ensure that all IMAP4rev1
yuuji@0 962 implementations interoperate properly.
yuuji@0 963
yuuji@0 964 5.1. Mailbox Naming
yuuji@0 965
yuuji@0 966 Mailbox names are 7-bit. Client implementations MUST NOT attempt to
yuuji@0 967 create 8-bit mailbox names, and SHOULD interpret any 8-bit mailbox
yuuji@0 968 names returned by LIST or LSUB as UTF-8. Server implementations
yuuji@0 969 SHOULD prohibit the creation of 8-bit mailbox names, and SHOULD NOT
yuuji@0 970 return 8-bit mailbox names in LIST or LSUB. See section 5.1.3 for
yuuji@0 971 more information on how to represent non-ASCII mailbox names.
yuuji@0 972
yuuji@0 973 Note: 8-bit mailbox names were undefined in earlier
yuuji@0 974 versions of this protocol. Some sites used a local 8-bit
yuuji@0 975 character set to represent non-ASCII mailbox names. Such
yuuji@0 976 usage is not interoperable, and is now formally deprecated.
yuuji@0 977
yuuji@0 978 The case-insensitive mailbox name INBOX is a special name reserved to
yuuji@0 979 mean "the primary mailbox for this user on this server". The
yuuji@0 980 interpretation of all other names is implementation-dependent.
yuuji@0 981
yuuji@0 982 In particular, this specification takes no position on case
yuuji@0 983 sensitivity in non-INBOX mailbox names. Some server implementations
yuuji@0 984 are fully case-sensitive; others preserve case of a newly-created
yuuji@0 985 name but otherwise are case-insensitive; and yet others coerce names
yuuji@0 986 to a particular case. Client implementations MUST interact with any
yuuji@0 987 of these. If a server implementation interprets non-INBOX mailbox
yuuji@0 988 names as case-insensitive, it MUST treat names using the
yuuji@0 989 international naming convention specially as described in section
yuuji@0 990 5.1.3.
yuuji@0 991
yuuji@0 992 There are certain client considerations when creating a new mailbox
yuuji@0 993 name:
yuuji@0 994
yuuji@0 995 1) Any character which is one of the atom-specials (see the Formal
yuuji@0 996 Syntax) will require that the mailbox name be represented as a
yuuji@0 997 quoted string or literal.
yuuji@0 998
yuuji@0 999 2) CTL and other non-graphic characters are difficult to represent
yuuji@0 1000 in a user interface and are best avoided.
yuuji@0 1001
yuuji@0 1002 3) Although the list-wildcard characters ("%" and "*") are valid
yuuji@0 1003 in a mailbox name, it is difficult to use such mailbox names
yuuji@0 1004 with the LIST and LSUB commands due to the conflict with
yuuji@0 1005 wildcard interpretation.
yuuji@0 1006
yuuji@0 1007
yuuji@0 1008
yuuji@0 1009
yuuji@0 1010 Crispin Standards Track [Page 18]
yuuji@0 1011
yuuji@0 1012 RFC 3501 IMAPv4 March 2003
yuuji@0 1013
yuuji@0 1014
yuuji@0 1015 4) Usually, a character (determined by the server implementation)
yuuji@0 1016 is reserved to delimit levels of hierarchy.
yuuji@0 1017
yuuji@0 1018 5) Two characters, "#" and "&", have meanings by convention, and
yuuji@0 1019 should be avoided except when used in that convention.
yuuji@0 1020
yuuji@0 1021 5.1.1. Mailbox Hierarchy Naming
yuuji@0 1022
yuuji@0 1023 If it is desired to export hierarchical mailbox names, mailbox names
yuuji@0 1024 MUST be left-to-right hierarchical using a single character to
yuuji@0 1025 separate levels of hierarchy. The same hierarchy separator character
yuuji@0 1026 is used for all levels of hierarchy within a single name.
yuuji@0 1027
yuuji@0 1028 5.1.2. Mailbox Namespace Naming Convention
yuuji@0 1029
yuuji@0 1030 By convention, the first hierarchical element of any mailbox name
yuuji@0 1031 which begins with "#" identifies the "namespace" of the remainder of
yuuji@0 1032 the name. This makes it possible to disambiguate between different
yuuji@0 1033 types of mailbox stores, each of which have their own namespaces.
yuuji@0 1034
yuuji@0 1035 For example, implementations which offer access to USENET
yuuji@0 1036 newsgroups MAY use the "#news" namespace to partition the
yuuji@0 1037 USENET newsgroup namespace from that of other mailboxes.
yuuji@0 1038 Thus, the comp.mail.misc newsgroup would have a mailbox
yuuji@0 1039 name of "#news.comp.mail.misc", and the name
yuuji@0 1040 "comp.mail.misc" can refer to a different object (e.g., a
yuuji@0 1041 user's private mailbox).
yuuji@0 1042
yuuji@0 1043 5.1.3. Mailbox International Naming Convention
yuuji@0 1044
yuuji@0 1045 By convention, international mailbox names in IMAP4rev1 are specified
yuuji@0 1046 using a modified version of the UTF-7 encoding described in [UTF-7].
yuuji@0 1047 Modified UTF-7 may also be usable in servers that implement an
yuuji@0 1048 earlier version of this protocol.
yuuji@0 1049
yuuji@0 1050 In modified UTF-7, printable US-ASCII characters, except for "&",
yuuji@0 1051 represent themselves; that is, characters with octet values 0x20-0x25
yuuji@0 1052 and 0x27-0x7e. The character "&" (0x26) is represented by the
yuuji@0 1053 two-octet sequence "&-".
yuuji@0 1054
yuuji@0 1055 All other characters (octet values 0x00-0x1f and 0x7f-0xff) are
yuuji@0 1056 represented in modified BASE64, with a further modification from
yuuji@0 1057 [UTF-7] that "," is used instead of "/". Modified BASE64 MUST NOT be
yuuji@0 1058 used to represent any printing US-ASCII character which can represent
yuuji@0 1059 itself.
yuuji@0 1060
yuuji@0 1061
yuuji@0 1062
yuuji@0 1063
yuuji@0 1064
yuuji@0 1065
yuuji@0 1066 Crispin Standards Track [Page 19]
yuuji@0 1067
yuuji@0 1068 RFC 3501 IMAPv4 March 2003
yuuji@0 1069
yuuji@0 1070
yuuji@0 1071 "&" is used to shift to modified BASE64 and "-" to shift back to
yuuji@0 1072 US-ASCII. There is no implicit shift from BASE64 to US-ASCII, and
yuuji@0 1073 null shifts ("-&" while in BASE64; note that "&-" while in US-ASCII
yuuji@0 1074 means "&") are not permitted. However, all names start in US-ASCII,
yuuji@0 1075 and MUST end in US-ASCII; that is, a name that ends with a non-ASCII
yuuji@0 1076 ISO-10646 character MUST end with a "-").
yuuji@0 1077
yuuji@0 1078 The purpose of these modifications is to correct the following
yuuji@0 1079 problems with UTF-7:
yuuji@0 1080
yuuji@0 1081 1) UTF-7 uses the "+" character for shifting; this conflicts with
yuuji@0 1082 the common use of "+" in mailbox names, in particular USENET
yuuji@0 1083 newsgroup names.
yuuji@0 1084
yuuji@0 1085 2) UTF-7's encoding is BASE64 which uses the "/" character; this
yuuji@0 1086 conflicts with the use of "/" as a popular hierarchy delimiter.
yuuji@0 1087
yuuji@0 1088 3) UTF-7 prohibits the unencoded usage of "\"; this conflicts with
yuuji@0 1089 the use of "\" as a popular hierarchy delimiter.
yuuji@0 1090
yuuji@0 1091 4) UTF-7 prohibits the unencoded usage of "~"; this conflicts with
yuuji@0 1092 the use of "~" in some servers as a home directory indicator.
yuuji@0 1093
yuuji@0 1094 5) UTF-7 permits multiple alternate forms to represent the same
yuuji@0 1095 string; in particular, printable US-ASCII characters can be
yuuji@0 1096 represented in encoded form.
yuuji@0 1097
yuuji@0 1098 Although modified UTF-7 is a convention, it establishes certain
yuuji@0 1099 requirements on server handling of any mailbox name with an
yuuji@0 1100 embedded "&" character. In particular, server implementations
yuuji@0 1101 MUST preserve the exact form of the modified BASE64 portion of a
yuuji@0 1102 modified UTF-7 name and treat that text as case-sensitive, even if
yuuji@0 1103 names are otherwise case-insensitive or case-folded.
yuuji@0 1104
yuuji@0 1105 Server implementations SHOULD verify that any mailbox name with an
yuuji@0 1106 embedded "&" character, used as an argument to CREATE, is: in the
yuuji@0 1107 correctly modified UTF-7 syntax, has no superfluous shifts, and
yuuji@0 1108 has no encoding in modified BASE64 of any printing US-ASCII
yuuji@0 1109 character which can represent itself. However, client
yuuji@0 1110 implementations MUST NOT depend upon the server doing this, and
yuuji@0 1111 SHOULD NOT attempt to create a mailbox name with an embedded "&"
yuuji@0 1112 character unless it complies with the modified UTF-7 syntax.
yuuji@0 1113
yuuji@0 1114 Server implementations which export a mail store that does not
yuuji@0 1115 follow the modified UTF-7 convention MUST convert to modified
yuuji@0 1116 UTF-7 any mailbox name that contains either non-ASCII characters
yuuji@0 1117 or the "&" character.
yuuji@0 1118
yuuji@0 1119
yuuji@0 1120
yuuji@0 1121
yuuji@0 1122 Crispin Standards Track [Page 20]
yuuji@0 1123
yuuji@0 1124 RFC 3501 IMAPv4 March 2003
yuuji@0 1125
yuuji@0 1126
yuuji@0 1127 For example, here is a mailbox name which mixes English,
yuuji@0 1128 Chinese, and Japanese text:
yuuji@0 1129 ~peter/mail/&U,BTFw-/&ZeVnLIqe-
yuuji@0 1130
yuuji@0 1131 For example, the string "&Jjo!" is not a valid mailbox
yuuji@0 1132 name because it does not contain a shift to US-ASCII
yuuji@0 1133 before the "!". The correct form is "&Jjo-!". The
yuuji@0 1134 string "&U,BTFw-&ZeVnLIqe-" is not permitted because it
yuuji@0 1135 contains a superfluous shift. The correct form is
yuuji@0 1136 "&U,BTF2XlZyyKng-".
yuuji@0 1137
yuuji@0 1138 5.2. Mailbox Size and Message Status Updates
yuuji@0 1139
yuuji@0 1140 At any time, a server can send data that the client did not request.
yuuji@0 1141 Sometimes, such behavior is REQUIRED. For example, agents other than
yuuji@0 1142 the server MAY add messages to the mailbox (e.g., new message
yuuji@0 1143 delivery), change the flags of the messages in the mailbox (e.g.,
yuuji@0 1144 simultaneous access to the same mailbox by multiple agents), or even
yuuji@0 1145 remove messages from the mailbox. A server MUST send mailbox size
yuuji@0 1146 updates automatically if a mailbox size change is observed during the
yuuji@0 1147 processing of a command. A server SHOULD send message flag updates
yuuji@0 1148 automatically, without requiring the client to request such updates
yuuji@0 1149 explicitly.
yuuji@0 1150
yuuji@0 1151 Special rules exist for server notification of a client about the
yuuji@0 1152 removal of messages to prevent synchronization errors; see the
yuuji@0 1153 description of the EXPUNGE response for more detail. In particular,
yuuji@0 1154 it is NOT permitted to send an EXISTS response that would reduce the
yuuji@0 1155 number of messages in the mailbox; only the EXPUNGE response can do
yuuji@0 1156 this.
yuuji@0 1157
yuuji@0 1158 Regardless of what implementation decisions a client makes on
yuuji@0 1159 remembering data from the server, a client implementation MUST record
yuuji@0 1160 mailbox size updates. It MUST NOT assume that any command after the
yuuji@0 1161 initial mailbox selection will return the size of the mailbox.
yuuji@0 1162
yuuji@0 1163 5.3. Response when no Command in Progress
yuuji@0 1164
yuuji@0 1165 Server implementations are permitted to send an untagged response
yuuji@0 1166 (except for EXPUNGE) while there is no command in progress. Server
yuuji@0 1167 implementations that send such responses MUST deal with flow control
yuuji@0 1168 considerations. Specifically, they MUST either (1) verify that the
yuuji@0 1169 size of the data does not exceed the underlying transport's available
yuuji@0 1170 window size, or (2) use non-blocking writes.
yuuji@0 1171
yuuji@0 1172
yuuji@0 1173
yuuji@0 1174
yuuji@0 1175
yuuji@0 1176
yuuji@0 1177
yuuji@0 1178 Crispin Standards Track [Page 21]
yuuji@0 1179
yuuji@0 1180 RFC 3501 IMAPv4 March 2003
yuuji@0 1181
yuuji@0 1182
yuuji@0 1183 5.4. Autologout Timer
yuuji@0 1184
yuuji@0 1185 If a server has an inactivity autologout timer, the duration of that
yuuji@0 1186 timer MUST be at least 30 minutes. The receipt of ANY command from
yuuji@0 1187 the client during that interval SHOULD suffice to reset the
yuuji@0 1188 autologout timer.
yuuji@0 1189
yuuji@0 1190 5.5. Multiple Commands in Progress
yuuji@0 1191
yuuji@0 1192 The client MAY send another command without waiting for the
yuuji@0 1193 completion result response of a command, subject to ambiguity rules
yuuji@0 1194 (see below) and flow control constraints on the underlying data
yuuji@0 1195 stream. Similarly, a server MAY begin processing another command
yuuji@0 1196 before processing the current command to completion, subject to
yuuji@0 1197 ambiguity rules. However, any command continuation request responses
yuuji@0 1198 and command continuations MUST be negotiated before any subsequent
yuuji@0 1199 command is initiated.
yuuji@0 1200
yuuji@0 1201 The exception is if an ambiguity would result because of a command
yuuji@0 1202 that would affect the results of other commands. Clients MUST NOT
yuuji@0 1203 send multiple commands without waiting if an ambiguity would result.
yuuji@0 1204 If the server detects a possible ambiguity, it MUST execute commands
yuuji@0 1205 to completion in the order given by the client.
yuuji@0 1206
yuuji@0 1207 The most obvious example of ambiguity is when a command would affect
yuuji@0 1208 the results of another command, e.g., a FETCH of a message's flags
yuuji@0 1209 and a STORE of that same message's flags.
yuuji@0 1210
yuuji@0 1211 A non-obvious ambiguity occurs with commands that permit an untagged
yuuji@0 1212 EXPUNGE response (commands other than FETCH, STORE, and SEARCH),
yuuji@0 1213 since an untagged EXPUNGE response can invalidate sequence numbers in
yuuji@0 1214 a subsequent command. This is not a problem for FETCH, STORE, or
yuuji@0 1215 SEARCH commands because servers are prohibited from sending EXPUNGE
yuuji@0 1216 responses while any of those commands are in progress. Therefore, if
yuuji@0 1217 the client sends any command other than FETCH, STORE, or SEARCH, it
yuuji@0 1218 MUST wait for the completion result response before sending a command
yuuji@0 1219 with message sequence numbers.
yuuji@0 1220
yuuji@0 1221 Note: UID FETCH, UID STORE, and UID SEARCH are different
yuuji@0 1222 commands from FETCH, STORE, and SEARCH. If the client
yuuji@0 1223 sends a UID command, it must wait for a completion result
yuuji@0 1224 response before sending a command with message sequence
yuuji@0 1225 numbers.
yuuji@0 1226
yuuji@0 1227
yuuji@0 1228
yuuji@0 1229
yuuji@0 1230
yuuji@0 1231
yuuji@0 1232
yuuji@0 1233
yuuji@0 1234 Crispin Standards Track [Page 22]
yuuji@0 1235
yuuji@0 1236 RFC 3501 IMAPv4 March 2003
yuuji@0 1237
yuuji@0 1238
yuuji@0 1239 For example, the following non-waiting command sequences are invalid:
yuuji@0 1240
yuuji@0 1241 FETCH + NOOP + STORE
yuuji@0 1242 STORE + COPY + FETCH
yuuji@0 1243 COPY + COPY
yuuji@0 1244 CHECK + FETCH
yuuji@0 1245
yuuji@0 1246 The following are examples of valid non-waiting command sequences:
yuuji@0 1247
yuuji@0 1248 FETCH + STORE + SEARCH + CHECK
yuuji@0 1249 STORE + COPY + EXPUNGE
yuuji@0 1250
yuuji@0 1251 UID SEARCH + UID SEARCH may be valid or invalid as a non-waiting
yuuji@0 1252 command sequence, depending upon whether or not the second UID
yuuji@0 1253 SEARCH contains message sequence numbers.
yuuji@0 1254
yuuji@0 1255 6. Client Commands
yuuji@0 1256
yuuji@0 1257 IMAP4rev1 commands are described in this section. Commands are
yuuji@0 1258 organized by the state in which the command is permitted. Commands
yuuji@0 1259 which are permitted in multiple states are listed in the minimum
yuuji@0 1260 permitted state (for example, commands valid in authenticated and
yuuji@0 1261 selected state are listed in the authenticated state commands).
yuuji@0 1262
yuuji@0 1263 Command arguments, identified by "Arguments:" in the command
yuuji@0 1264 descriptions below, are described by function, not by syntax. The
yuuji@0 1265 precise syntax of command arguments is described in the Formal Syntax
yuuji@0 1266 section.
yuuji@0 1267
yuuji@0 1268 Some commands cause specific server responses to be returned; these
yuuji@0 1269 are identified by "Responses:" in the command descriptions below.
yuuji@0 1270 See the response descriptions in the Responses section for
yuuji@0 1271 information on these responses, and the Formal Syntax section for the
yuuji@0 1272 precise syntax of these responses. It is possible for server data to
yuuji@0 1273 be transmitted as a result of any command. Thus, commands that do
yuuji@0 1274 not specifically require server data specify "no specific responses
yuuji@0 1275 for this command" instead of "none".
yuuji@0 1276
yuuji@0 1277 The "Result:" in the command description refers to the possible
yuuji@0 1278 tagged status responses to a command, and any special interpretation
yuuji@0 1279 of these status responses.
yuuji@0 1280
yuuji@0 1281 The state of a connection is only changed by successful commands
yuuji@0 1282 which are documented as changing state. A rejected command (BAD
yuuji@0 1283 response) never changes the state of the connection or of the
yuuji@0 1284 selected mailbox. A failed command (NO response) generally does not
yuuji@0 1285 change the state of the connection or of the selected mailbox; the
yuuji@0 1286 exception being the SELECT and EXAMINE commands.
yuuji@0 1287
yuuji@0 1288
yuuji@0 1289
yuuji@0 1290 Crispin Standards Track [Page 23]
yuuji@0 1291
yuuji@0 1292 RFC 3501 IMAPv4 March 2003
yuuji@0 1293
yuuji@0 1294
yuuji@0 1295 6.1. Client Commands - Any State
yuuji@0 1296
yuuji@0 1297 The following commands are valid in any state: CAPABILITY, NOOP, and
yuuji@0 1298 LOGOUT.
yuuji@0 1299
yuuji@0 1300 6.1.1. CAPABILITY Command
yuuji@0 1301
yuuji@0 1302 Arguments: none
yuuji@0 1303
yuuji@0 1304 Responses: REQUIRED untagged response: CAPABILITY
yuuji@0 1305
yuuji@0 1306 Result: OK - capability completed
yuuji@0 1307 BAD - command unknown or arguments invalid
yuuji@0 1308
yuuji@0 1309 The CAPABILITY command requests a listing of capabilities that the
yuuji@0 1310 server supports. The server MUST send a single untagged
yuuji@0 1311 CAPABILITY response with "IMAP4rev1" as one of the listed
yuuji@0 1312 capabilities before the (tagged) OK response.
yuuji@0 1313
yuuji@0 1314 A capability name which begins with "AUTH=" indicates that the
yuuji@0 1315 server supports that particular authentication mechanism. All
yuuji@0 1316 such names are, by definition, part of this specification. For
yuuji@0 1317 example, the authorization capability for an experimental
yuuji@0 1318 "blurdybloop" authenticator would be "AUTH=XBLURDYBLOOP" and not
yuuji@0 1319 "XAUTH=BLURDYBLOOP" or "XAUTH=XBLURDYBLOOP".
yuuji@0 1320
yuuji@0 1321 Other capability names refer to extensions, revisions, or
yuuji@0 1322 amendments to this specification. See the documentation of the
yuuji@0 1323 CAPABILITY response for additional information. No capabilities,
yuuji@0 1324 beyond the base IMAP4rev1 set defined in this specification, are
yuuji@0 1325 enabled without explicit client action to invoke the capability.
yuuji@0 1326
yuuji@0 1327 Client and server implementations MUST implement the STARTTLS,
yuuji@0 1328 LOGINDISABLED, and AUTH=PLAIN (described in [IMAP-TLS])
yuuji@0 1329 capabilities. See the Security Considerations section for
yuuji@0 1330 important information.
yuuji@0 1331
yuuji@0 1332 See the section entitled "Client Commands -
yuuji@0 1333 Experimental/Expansion" for information about the form of site or
yuuji@0 1334 implementation-specific capabilities.
yuuji@0 1335
yuuji@0 1336
yuuji@0 1337
yuuji@0 1338
yuuji@0 1339
yuuji@0 1340
yuuji@0 1341
yuuji@0 1342
yuuji@0 1343
yuuji@0 1344
yuuji@0 1345
yuuji@0 1346 Crispin Standards Track [Page 24]
yuuji@0 1347
yuuji@0 1348 RFC 3501 IMAPv4 March 2003
yuuji@0 1349
yuuji@0 1350
yuuji@0 1351 Example: C: abcd CAPABILITY
yuuji@0 1352 S: * CAPABILITY IMAP4rev1 STARTTLS AUTH=GSSAPI
yuuji@0 1353 LOGINDISABLED
yuuji@0 1354 S: abcd OK CAPABILITY completed
yuuji@0 1355 C: efgh STARTTLS
yuuji@0 1356 S: efgh OK STARTLS completed
yuuji@0 1357 <TLS negotiation, further commands are under [TLS] layer>
yuuji@0 1358 C: ijkl CAPABILITY
yuuji@0 1359 S: * CAPABILITY IMAP4rev1 AUTH=GSSAPI AUTH=PLAIN
yuuji@0 1360 S: ijkl OK CAPABILITY completed
yuuji@0 1361
yuuji@0 1362
yuuji@0 1363 6.1.2. NOOP Command
yuuji@0 1364
yuuji@0 1365 Arguments: none
yuuji@0 1366
yuuji@0 1367 Responses: no specific responses for this command (but see below)
yuuji@0 1368
yuuji@0 1369 Result: OK - noop completed
yuuji@0 1370 BAD - command unknown or arguments invalid
yuuji@0 1371
yuuji@0 1372 The NOOP command always succeeds. It does nothing.
yuuji@0 1373
yuuji@0 1374 Since any command can return a status update as untagged data, the
yuuji@0 1375 NOOP command can be used as a periodic poll for new messages or
yuuji@0 1376 message status updates during a period of inactivity (this is the
yuuji@0 1377 preferred method to do this). The NOOP command can also be used
yuuji@0 1378 to reset any inactivity autologout timer on the server.
yuuji@0 1379
yuuji@0 1380 Example: C: a002 NOOP
yuuji@0 1381 S: a002 OK NOOP completed
yuuji@0 1382 . . .
yuuji@0 1383 C: a047 NOOP
yuuji@0 1384 S: * 22 EXPUNGE
yuuji@0 1385 S: * 23 EXISTS
yuuji@0 1386 S: * 3 RECENT
yuuji@0 1387 S: * 14 FETCH (FLAGS (\Seen \Deleted))
yuuji@0 1388 S: a047 OK NOOP completed
yuuji@0 1389
yuuji@0 1390
yuuji@0 1391
yuuji@0 1392
yuuji@0 1393
yuuji@0 1394
yuuji@0 1395
yuuji@0 1396
yuuji@0 1397
yuuji@0 1398
yuuji@0 1399
yuuji@0 1400
yuuji@0 1401
yuuji@0 1402 Crispin Standards Track [Page 25]
yuuji@0 1403
yuuji@0 1404 RFC 3501 IMAPv4 March 2003
yuuji@0 1405
yuuji@0 1406
yuuji@0 1407 6.1.3. LOGOUT Command
yuuji@0 1408
yuuji@0 1409 Arguments: none
yuuji@0 1410
yuuji@0 1411 Responses: REQUIRED untagged response: BYE
yuuji@0 1412
yuuji@0 1413 Result: OK - logout completed
yuuji@0 1414 BAD - command unknown or arguments invalid
yuuji@0 1415
yuuji@0 1416 The LOGOUT command informs the server that the client is done with
yuuji@0 1417 the connection. The server MUST send a BYE untagged response
yuuji@0 1418 before the (tagged) OK response, and then close the network
yuuji@0 1419 connection.
yuuji@0 1420
yuuji@0 1421 Example: C: A023 LOGOUT
yuuji@0 1422 S: * BYE IMAP4rev1 Server logging out
yuuji@0 1423 S: A023 OK LOGOUT completed
yuuji@0 1424 (Server and client then close the connection)
yuuji@0 1425
yuuji@0 1426 6.2. Client Commands - Not Authenticated State
yuuji@0 1427
yuuji@0 1428 In the not authenticated state, the AUTHENTICATE or LOGIN command
yuuji@0 1429 establishes authentication and enters the authenticated state. The
yuuji@0 1430 AUTHENTICATE command provides a general mechanism for a variety of
yuuji@0 1431 authentication techniques, privacy protection, and integrity
yuuji@0 1432 checking; whereas the LOGIN command uses a traditional user name and
yuuji@0 1433 plaintext password pair and has no means of establishing privacy
yuuji@0 1434 protection or integrity checking.
yuuji@0 1435
yuuji@0 1436 The STARTTLS command is an alternate form of establishing session
yuuji@0 1437 privacy protection and integrity checking, but does not establish
yuuji@0 1438 authentication or enter the authenticated state.
yuuji@0 1439
yuuji@0 1440 Server implementations MAY allow access to certain mailboxes without
yuuji@0 1441 establishing authentication. This can be done by means of the
yuuji@0 1442 ANONYMOUS [SASL] authenticator described in [ANONYMOUS]. An older
yuuji@0 1443 convention is a LOGIN command using the userid "anonymous"; in this
yuuji@0 1444 case, a password is required although the server may choose to accept
yuuji@0 1445 any password. The restrictions placed on anonymous users are
yuuji@0 1446 implementation-dependent.
yuuji@0 1447
yuuji@0 1448 Once authenticated (including as anonymous), it is not possible to
yuuji@0 1449 re-enter not authenticated state.
yuuji@0 1450
yuuji@0 1451
yuuji@0 1452
yuuji@0 1453
yuuji@0 1454
yuuji@0 1455
yuuji@0 1456
yuuji@0 1457
yuuji@0 1458 Crispin Standards Track [Page 26]
yuuji@0 1459
yuuji@0 1460 RFC 3501 IMAPv4 March 2003
yuuji@0 1461
yuuji@0 1462
yuuji@0 1463 In addition to the universal commands (CAPABILITY, NOOP, and LOGOUT),
yuuji@0 1464 the following commands are valid in the not authenticated state:
yuuji@0 1465 STARTTLS, AUTHENTICATE and LOGIN. See the Security Considerations
yuuji@0 1466 section for important information about these commands.
yuuji@0 1467
yuuji@0 1468 6.2.1. STARTTLS Command
yuuji@0 1469
yuuji@0 1470 Arguments: none
yuuji@0 1471
yuuji@0 1472 Responses: no specific response for this command
yuuji@0 1473
yuuji@0 1474 Result: OK - starttls completed, begin TLS negotiation
yuuji@0 1475 BAD - command unknown or arguments invalid
yuuji@0 1476
yuuji@0 1477 A [TLS] negotiation begins immediately after the CRLF at the end
yuuji@0 1478 of the tagged OK response from the server. Once a client issues a
yuuji@0 1479 STARTTLS command, it MUST NOT issue further commands until a
yuuji@0 1480 server response is seen and the [TLS] negotiation is complete.
yuuji@0 1481
yuuji@0 1482 The server remains in the non-authenticated state, even if client
yuuji@0 1483 credentials are supplied during the [TLS] negotiation. This does
yuuji@0 1484 not preclude an authentication mechanism such as EXTERNAL (defined
yuuji@0 1485 in [SASL]) from using client identity determined by the [TLS]
yuuji@0 1486 negotiation.
yuuji@0 1487
yuuji@0 1488 Once [TLS] has been started, the client MUST discard cached
yuuji@0 1489 information about server capabilities and SHOULD re-issue the
yuuji@0 1490 CAPABILITY command. This is necessary to protect against man-in-
yuuji@0 1491 the-middle attacks which alter the capabilities list prior to
yuuji@0 1492 STARTTLS. The server MAY advertise different capabilities after
yuuji@0 1493 STARTTLS.
yuuji@0 1494
yuuji@0 1495 Example: C: a001 CAPABILITY
yuuji@0 1496 S: * CAPABILITY IMAP4rev1 STARTTLS LOGINDISABLED
yuuji@0 1497 S: a001 OK CAPABILITY completed
yuuji@0 1498 C: a002 STARTTLS
yuuji@0 1499 S: a002 OK Begin TLS negotiation now
yuuji@0 1500 <TLS negotiation, further commands are under [TLS] layer>
yuuji@0 1501 C: a003 CAPABILITY
yuuji@0 1502 S: * CAPABILITY IMAP4rev1 AUTH=PLAIN
yuuji@0 1503 S: a003 OK CAPABILITY completed
yuuji@0 1504 C: a004 LOGIN joe password
yuuji@0 1505 S: a004 OK LOGIN completed
yuuji@0 1506
yuuji@0 1507
yuuji@0 1508
yuuji@0 1509
yuuji@0 1510
yuuji@0 1511
yuuji@0 1512
yuuji@0 1513
yuuji@0 1514 Crispin Standards Track [Page 27]
yuuji@0 1515
yuuji@0 1516 RFC 3501 IMAPv4 March 2003
yuuji@0 1517
yuuji@0 1518
yuuji@0 1519 6.2.2. AUTHENTICATE Command
yuuji@0 1520
yuuji@0 1521 Arguments: authentication mechanism name
yuuji@0 1522
yuuji@0 1523 Responses: continuation data can be requested
yuuji@0 1524
yuuji@0 1525 Result: OK - authenticate completed, now in authenticated state
yuuji@0 1526 NO - authenticate failure: unsupported authentication
yuuji@0 1527 mechanism, credentials rejected
yuuji@0 1528 BAD - command unknown or arguments invalid,
yuuji@0 1529 authentication exchange cancelled
yuuji@0 1530
yuuji@0 1531 The AUTHENTICATE command indicates a [SASL] authentication
yuuji@0 1532 mechanism to the server. If the server supports the requested
yuuji@0 1533 authentication mechanism, it performs an authentication protocol
yuuji@0 1534 exchange to authenticate and identify the client. It MAY also
yuuji@0 1535 negotiate an OPTIONAL security layer for subsequent protocol
yuuji@0 1536 interactions. If the requested authentication mechanism is not
yuuji@0 1537 supported, the server SHOULD reject the AUTHENTICATE command by
yuuji@0 1538 sending a tagged NO response.
yuuji@0 1539
yuuji@0 1540 The AUTHENTICATE command does not support the optional "initial
yuuji@0 1541 response" feature of [SASL]. Section 5.1 of [SASL] specifies how
yuuji@0 1542 to handle an authentication mechanism which uses an initial
yuuji@0 1543 response.
yuuji@0 1544
yuuji@0 1545 The service name specified by this protocol's profile of [SASL] is
yuuji@0 1546 "imap".
yuuji@0 1547
yuuji@0 1548 The authentication protocol exchange consists of a series of
yuuji@0 1549 server challenges and client responses that are specific to the
yuuji@0 1550 authentication mechanism. A server challenge consists of a
yuuji@0 1551 command continuation request response with the "+" token followed
yuuji@0 1552 by a BASE64 encoded string. The client response consists of a
yuuji@0 1553 single line consisting of a BASE64 encoded string. If the client
yuuji@0 1554 wishes to cancel an authentication exchange, it issues a line
yuuji@0 1555 consisting of a single "*". If the server receives such a
yuuji@0 1556 response, it MUST reject the AUTHENTICATE command by sending a
yuuji@0 1557 tagged BAD response.
yuuji@0 1558
yuuji@0 1559 If a security layer is negotiated through the [SASL]
yuuji@0 1560 authentication exchange, it takes effect immediately following the
yuuji@0 1561 CRLF that concludes the authentication exchange for the client,
yuuji@0 1562 and the CRLF of the tagged OK response for the server.
yuuji@0 1563
yuuji@0 1564 While client and server implementations MUST implement the
yuuji@0 1565 AUTHENTICATE command itself, it is not required to implement any
yuuji@0 1566 authentication mechanisms other than the PLAIN mechanism described
yuuji@0 1567
yuuji@0 1568
yuuji@0 1569
yuuji@0 1570 Crispin Standards Track [Page 28]
yuuji@0 1571
yuuji@0 1572 RFC 3501 IMAPv4 March 2003
yuuji@0 1573
yuuji@0 1574
yuuji@0 1575 in [IMAP-TLS]. Also, an authentication mechanism is not required
yuuji@0 1576 to support any security layers.
yuuji@0 1577
yuuji@0 1578 Note: a server implementation MUST implement a
yuuji@0 1579 configuration in which it does NOT permit any plaintext
yuuji@0 1580 password mechanisms, unless either the STARTTLS command
yuuji@0 1581 has been negotiated or some other mechanism that
yuuji@0 1582 protects the session from password snooping has been
yuuji@0 1583 provided. Server sites SHOULD NOT use any configuration
yuuji@0 1584 which permits a plaintext password mechanism without
yuuji@0 1585 such a protection mechanism against password snooping.
yuuji@0 1586 Client and server implementations SHOULD implement
yuuji@0 1587 additional [SASL] mechanisms that do not use plaintext
yuuji@0 1588 passwords, such the GSSAPI mechanism described in [SASL]
yuuji@0 1589 and/or the [DIGEST-MD5] mechanism.
yuuji@0 1590
yuuji@0 1591 Servers and clients can support multiple authentication
yuuji@0 1592 mechanisms. The server SHOULD list its supported authentication
yuuji@0 1593 mechanisms in the response to the CAPABILITY command so that the
yuuji@0 1594 client knows which authentication mechanisms to use.
yuuji@0 1595
yuuji@0 1596 A server MAY include a CAPABILITY response code in the tagged OK
yuuji@0 1597 response of a successful AUTHENTICATE command in order to send
yuuji@0 1598 capabilities automatically. It is unnecessary for a client to
yuuji@0 1599 send a separate CAPABILITY command if it recognizes these
yuuji@0 1600 automatic capabilities. This should only be done if a security
yuuji@0 1601 layer was not negotiated by the AUTHENTICATE command, because the
yuuji@0 1602 tagged OK response as part of an AUTHENTICATE command is not
yuuji@0 1603 protected by encryption/integrity checking. [SASL] requires the
yuuji@0 1604 client to re-issue a CAPABILITY command in this case.
yuuji@0 1605
yuuji@0 1606 If an AUTHENTICATE command fails with a NO response, the client
yuuji@0 1607 MAY try another authentication mechanism by issuing another
yuuji@0 1608 AUTHENTICATE command. It MAY also attempt to authenticate by
yuuji@0 1609 using the LOGIN command (see section 6.2.3 for more detail). In
yuuji@0 1610 other words, the client MAY request authentication types in
yuuji@0 1611 decreasing order of preference, with the LOGIN command as a last
yuuji@0 1612 resort.
yuuji@0 1613
yuuji@0 1614 The authorization identity passed from the client to the server
yuuji@0 1615 during the authentication exchange is interpreted by the server as
yuuji@0 1616 the user name whose privileges the client is requesting.
yuuji@0 1617
yuuji@0 1618
yuuji@0 1619
yuuji@0 1620
yuuji@0 1621
yuuji@0 1622
yuuji@0 1623
yuuji@0 1624
yuuji@0 1625
yuuji@0 1626 Crispin Standards Track [Page 29]
yuuji@0 1627
yuuji@0 1628 RFC 3501 IMAPv4 March 2003
yuuji@0 1629
yuuji@0 1630
yuuji@0 1631 Example: S: * OK IMAP4rev1 Server
yuuji@0 1632 C: A001 AUTHENTICATE GSSAPI
yuuji@0 1633 S: +
yuuji@0 1634 C: YIIB+wYJKoZIhvcSAQICAQBuggHqMIIB5qADAgEFoQMCAQ6iBw
yuuji@0 1635 MFACAAAACjggEmYYIBIjCCAR6gAwIBBaESGxB1Lndhc2hpbmd0
yuuji@0 1636 b24uZWR1oi0wK6ADAgEDoSQwIhsEaW1hcBsac2hpdmFtcy5jYW
yuuji@0 1637 Mud2FzaGluZ3Rvbi5lZHWjgdMwgdCgAwIBAaEDAgEDooHDBIHA
yuuji@0 1638 cS1GSa5b+fXnPZNmXB9SjL8Ollj2SKyb+3S0iXMljen/jNkpJX
yuuji@0 1639 AleKTz6BQPzj8duz8EtoOuNfKgweViyn/9B9bccy1uuAE2HI0y
yuuji@0 1640 C/PHXNNU9ZrBziJ8Lm0tTNc98kUpjXnHZhsMcz5Mx2GR6dGknb
yuuji@0 1641 I0iaGcRerMUsWOuBmKKKRmVMMdR9T3EZdpqsBd7jZCNMWotjhi
yuuji@0 1642 vd5zovQlFqQ2Wjc2+y46vKP/iXxWIuQJuDiisyXF0Y8+5GTpAL
yuuji@0 1643 pHDc1/pIGmMIGjoAMCAQGigZsEgZg2on5mSuxoDHEA1w9bcW9n
yuuji@0 1644 FdFxDKpdrQhVGVRDIzcCMCTzvUboqb5KjY1NJKJsfjRQiBYBdE
yuuji@0 1645 NKfzK+g5DlV8nrw81uOcP8NOQCLR5XkoMHC0Dr/80ziQzbNqhx
yuuji@0 1646 O6652Npft0LQwJvenwDI13YxpwOdMXzkWZN/XrEqOWp6GCgXTB
yuuji@0 1647 vCyLWLlWnbaUkZdEYbKHBPjd8t/1x5Yg==
yuuji@0 1648 S: + YGgGCSqGSIb3EgECAgIAb1kwV6ADAgEFoQMCAQ+iSzBJoAMC
yuuji@0 1649 AQGiQgRAtHTEuOP2BXb9sBYFR4SJlDZxmg39IxmRBOhXRKdDA0
yuuji@0 1650 uHTCOT9Bq3OsUTXUlk0CsFLoa8j+gvGDlgHuqzWHPSQg==
yuuji@0 1651 C:
yuuji@0 1652 S: + YDMGCSqGSIb3EgECAgIBAAD/////6jcyG4GE3KkTzBeBiVHe
yuuji@0 1653 ceP2CWY0SR0fAQAgAAQEBAQ=
yuuji@0 1654 C: YDMGCSqGSIb3EgECAgIBAAD/////3LQBHXTpFfZgrejpLlLImP
yuuji@0 1655 wkhbfa2QteAQAgAG1yYwE=
yuuji@0 1656 S: A001 OK GSSAPI authentication successful
yuuji@0 1657
yuuji@0 1658 Note: The line breaks within server challenges and client
yuuji@0 1659 responses are for editorial clarity and are not in real
yuuji@0 1660 authenticators.
yuuji@0 1661
yuuji@0 1662
yuuji@0 1663 6.2.3. LOGIN Command
yuuji@0 1664
yuuji@0 1665 Arguments: user name
yuuji@0 1666 password
yuuji@0 1667
yuuji@0 1668 Responses: no specific responses for this command
yuuji@0 1669
yuuji@0 1670 Result: OK - login completed, now in authenticated state
yuuji@0 1671 NO - login failure: user name or password rejected
yuuji@0 1672 BAD - command unknown or arguments invalid
yuuji@0 1673
yuuji@0 1674 The LOGIN command identifies the client to the server and carries
yuuji@0 1675 the plaintext password authenticating this user.
yuuji@0 1676
yuuji@0 1677
yuuji@0 1678
yuuji@0 1679
yuuji@0 1680
yuuji@0 1681
yuuji@0 1682 Crispin Standards Track [Page 30]
yuuji@0 1683
yuuji@0 1684 RFC 3501 IMAPv4 March 2003
yuuji@0 1685
yuuji@0 1686
yuuji@0 1687 A server MAY include a CAPABILITY response code in the tagged OK
yuuji@0 1688 response to a successful LOGIN command in order to send
yuuji@0 1689 capabilities automatically. It is unnecessary for a client to
yuuji@0 1690 send a separate CAPABILITY command if it recognizes these
yuuji@0 1691 automatic capabilities.
yuuji@0 1692
yuuji@0 1693 Example: C: a001 LOGIN SMITH SESAME
yuuji@0 1694 S: a001 OK LOGIN completed
yuuji@0 1695
yuuji@0 1696 Note: Use of the LOGIN command over an insecure network
yuuji@0 1697 (such as the Internet) is a security risk, because anyone
yuuji@0 1698 monitoring network traffic can obtain plaintext passwords.
yuuji@0 1699 The LOGIN command SHOULD NOT be used except as a last
yuuji@0 1700 resort, and it is recommended that client implementations
yuuji@0 1701 have a means to disable any automatic use of the LOGIN
yuuji@0 1702 command.
yuuji@0 1703
yuuji@0 1704 Unless either the STARTTLS command has been negotiated or
yuuji@0 1705 some other mechanism that protects the session from
yuuji@0 1706 password snooping has been provided, a server
yuuji@0 1707 implementation MUST implement a configuration in which it
yuuji@0 1708 advertises the LOGINDISABLED capability and does NOT permit
yuuji@0 1709 the LOGIN command. Server sites SHOULD NOT use any
yuuji@0 1710 configuration which permits the LOGIN command without such
yuuji@0 1711 a protection mechanism against password snooping. A client
yuuji@0 1712 implementation MUST NOT send a LOGIN command if the
yuuji@0 1713 LOGINDISABLED capability is advertised.
yuuji@0 1714
yuuji@0 1715 6.3. Client Commands - Authenticated State
yuuji@0 1716
yuuji@0 1717 In the authenticated state, commands that manipulate mailboxes as
yuuji@0 1718 atomic entities are permitted. Of these commands, the SELECT and
yuuji@0 1719 EXAMINE commands will select a mailbox for access and enter the
yuuji@0 1720 selected state.
yuuji@0 1721
yuuji@0 1722 In addition to the universal commands (CAPABILITY, NOOP, and LOGOUT),
yuuji@0 1723 the following commands are valid in the authenticated state: SELECT,
yuuji@0 1724 EXAMINE, CREATE, DELETE, RENAME, SUBSCRIBE, UNSUBSCRIBE, LIST, LSUB,
yuuji@0 1725 STATUS, and APPEND.
yuuji@0 1726
yuuji@0 1727
yuuji@0 1728
yuuji@0 1729
yuuji@0 1730
yuuji@0 1731
yuuji@0 1732
yuuji@0 1733
yuuji@0 1734
yuuji@0 1735
yuuji@0 1736
yuuji@0 1737
yuuji@0 1738 Crispin Standards Track [Page 31]
yuuji@0 1739
yuuji@0 1740 RFC 3501 IMAPv4 March 2003
yuuji@0 1741
yuuji@0 1742
yuuji@0 1743 6.3.1. SELECT Command
yuuji@0 1744
yuuji@0 1745 Arguments: mailbox name
yuuji@0 1746
yuuji@0 1747 Responses: REQUIRED untagged responses: FLAGS, EXISTS, RECENT
yuuji@0 1748 REQUIRED OK untagged responses: UNSEEN, PERMANENTFLAGS,
yuuji@0 1749 UIDNEXT, UIDVALIDITY
yuuji@0 1750
yuuji@0 1751 Result: OK - select completed, now in selected state
yuuji@0 1752 NO - select failure, now in authenticated state: no
yuuji@0 1753 such mailbox, can't access mailbox
yuuji@0 1754 BAD - command unknown or arguments invalid
yuuji@0 1755
yuuji@0 1756 The SELECT command selects a mailbox so that messages in the
yuuji@0 1757 mailbox can be accessed. Before returning an OK to the client,
yuuji@0 1758 the server MUST send the following untagged data to the client.
yuuji@0 1759 Note that earlier versions of this protocol only required the
yuuji@0 1760 FLAGS, EXISTS, and RECENT untagged data; consequently, client
yuuji@0 1761 implementations SHOULD implement default behavior for missing data
yuuji@0 1762 as discussed with the individual item.
yuuji@0 1763
yuuji@0 1764 FLAGS Defined flags in the mailbox. See the description
yuuji@0 1765 of the FLAGS response for more detail.
yuuji@0 1766
yuuji@0 1767 <n> EXISTS The number of messages in the mailbox. See the
yuuji@0 1768 description of the EXISTS response for more detail.
yuuji@0 1769
yuuji@0 1770 <n> RECENT The number of messages with the \Recent flag set.
yuuji@0 1771 See the description of the RECENT response for more
yuuji@0 1772 detail.
yuuji@0 1773
yuuji@0 1774 OK [UNSEEN <n>]
yuuji@0 1775 The message sequence number of the first unseen
yuuji@0 1776 message in the mailbox. If this is missing, the
yuuji@0 1777 client can not make any assumptions about the first
yuuji@0 1778 unseen message in the mailbox, and needs to issue a
yuuji@0 1779 SEARCH command if it wants to find it.
yuuji@0 1780
yuuji@0 1781 OK [PERMANENTFLAGS (<list of flags>)]
yuuji@0 1782 A list of message flags that the client can change
yuuji@0 1783 permanently. If this is missing, the client should
yuuji@0 1784 assume that all flags can be changed permanently.
yuuji@0 1785
yuuji@0 1786 OK [UIDNEXT <n>]
yuuji@0 1787 The next unique identifier value. Refer to section
yuuji@0 1788 2.3.1.1 for more information. If this is missing,
yuuji@0 1789 the client can not make any assumptions about the
yuuji@0 1790 next unique identifier value.
yuuji@0 1791
yuuji@0 1792
yuuji@0 1793
yuuji@0 1794 Crispin Standards Track [Page 32]
yuuji@0 1795
yuuji@0 1796 RFC 3501 IMAPv4 March 2003
yuuji@0 1797
yuuji@0 1798
yuuji@0 1799 OK [UIDVALIDITY <n>]
yuuji@0 1800 The unique identifier validity value. Refer to
yuuji@0 1801 section 2.3.1.1 for more information. If this is
yuuji@0 1802 missing, the server does not support unique
yuuji@0 1803 identifiers.
yuuji@0 1804
yuuji@0 1805 Only one mailbox can be selected at a time in a connection;
yuuji@0 1806 simultaneous access to multiple mailboxes requires multiple
yuuji@0 1807 connections. The SELECT command automatically deselects any
yuuji@0 1808 currently selected mailbox before attempting the new selection.
yuuji@0 1809 Consequently, if a mailbox is selected and a SELECT command that
yuuji@0 1810 fails is attempted, no mailbox is selected.
yuuji@0 1811
yuuji@0 1812 If the client is permitted to modify the mailbox, the server
yuuji@0 1813 SHOULD prefix the text of the tagged OK response with the
yuuji@0 1814 "[READ-WRITE]" response code.
yuuji@0 1815
yuuji@0 1816 If the client is not permitted to modify the mailbox but is
yuuji@0 1817 permitted read access, the mailbox is selected as read-only, and
yuuji@0 1818 the server MUST prefix the text of the tagged OK response to
yuuji@0 1819 SELECT with the "[READ-ONLY]" response code. Read-only access
yuuji@0 1820 through SELECT differs from the EXAMINE command in that certain
yuuji@0 1821 read-only mailboxes MAY permit the change of permanent state on a
yuuji@0 1822 per-user (as opposed to global) basis. Netnews messages marked in
yuuji@0 1823 a server-based .newsrc file are an example of such per-user
yuuji@0 1824 permanent state that can be modified with read-only mailboxes.
yuuji@0 1825
yuuji@0 1826 Example: C: A142 SELECT INBOX
yuuji@0 1827 S: * 172 EXISTS
yuuji@0 1828 S: * 1 RECENT
yuuji@0 1829 S: * OK [UNSEEN 12] Message 12 is first unseen
yuuji@0 1830 S: * OK [UIDVALIDITY 3857529045] UIDs valid
yuuji@0 1831 S: * OK [UIDNEXT 4392] Predicted next UID
yuuji@0 1832 S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
yuuji@0 1833 S: * OK [PERMANENTFLAGS (\Deleted \Seen \*)] Limited
yuuji@0 1834 S: A142 OK [READ-WRITE] SELECT completed
yuuji@0 1835
yuuji@0 1836
yuuji@0 1837
yuuji@0 1838
yuuji@0 1839
yuuji@0 1840
yuuji@0 1841
yuuji@0 1842
yuuji@0 1843
yuuji@0 1844
yuuji@0 1845
yuuji@0 1846
yuuji@0 1847
yuuji@0 1848
yuuji@0 1849
yuuji@0 1850 Crispin Standards Track [Page 33]
yuuji@0 1851
yuuji@0 1852 RFC 3501 IMAPv4 March 2003
yuuji@0 1853
yuuji@0 1854
yuuji@0 1855 6.3.2. EXAMINE Command
yuuji@0 1856
yuuji@0 1857 Arguments: mailbox name
yuuji@0 1858
yuuji@0 1859 Responses: REQUIRED untagged responses: FLAGS, EXISTS, RECENT
yuuji@0 1860 REQUIRED OK untagged responses: UNSEEN, PERMANENTFLAGS,
yuuji@0 1861 UIDNEXT, UIDVALIDITY
yuuji@0 1862
yuuji@0 1863 Result: OK - examine completed, now in selected state
yuuji@0 1864 NO - examine failure, now in authenticated state: no
yuuji@0 1865 such mailbox, can't access mailbox
yuuji@0 1866 BAD - command unknown or arguments invalid
yuuji@0 1867
yuuji@0 1868 The EXAMINE command is identical to SELECT and returns the same
yuuji@0 1869 output; however, the selected mailbox is identified as read-only.
yuuji@0 1870 No changes to the permanent state of the mailbox, including
yuuji@0 1871 per-user state, are permitted; in particular, EXAMINE MUST NOT
yuuji@0 1872 cause messages to lose the \Recent flag.
yuuji@0 1873
yuuji@0 1874 The text of the tagged OK response to the EXAMINE command MUST
yuuji@0 1875 begin with the "[READ-ONLY]" response code.
yuuji@0 1876
yuuji@0 1877 Example: C: A932 EXAMINE blurdybloop
yuuji@0 1878 S: * 17 EXISTS
yuuji@0 1879 S: * 2 RECENT
yuuji@0 1880 S: * OK [UNSEEN 8] Message 8 is first unseen
yuuji@0 1881 S: * OK [UIDVALIDITY 3857529045] UIDs valid
yuuji@0 1882 S: * OK [UIDNEXT 4392] Predicted next UID
yuuji@0 1883 S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
yuuji@0 1884 S: * OK [PERMANENTFLAGS ()] No permanent flags permitted
yuuji@0 1885 S: A932 OK [READ-ONLY] EXAMINE completed
yuuji@0 1886
yuuji@0 1887
yuuji@0 1888 6.3.3. CREATE Command
yuuji@0 1889
yuuji@0 1890 Arguments: mailbox name
yuuji@0 1891
yuuji@0 1892 Responses: no specific responses for this command
yuuji@0 1893
yuuji@0 1894 Result: OK - create completed
yuuji@0 1895 NO - create failure: can't create mailbox with that name
yuuji@0 1896 BAD - command unknown or arguments invalid
yuuji@0 1897
yuuji@0 1898 The CREATE command creates a mailbox with the given name. An OK
yuuji@0 1899 response is returned only if a new mailbox with that name has been
yuuji@0 1900 created. It is an error to attempt to create INBOX or a mailbox
yuuji@0 1901 with a name that refers to an extant mailbox. Any error in
yuuji@0 1902 creation will return a tagged NO response.
yuuji@0 1903
yuuji@0 1904
yuuji@0 1905
yuuji@0 1906 Crispin Standards Track [Page 34]
yuuji@0 1907
yuuji@0 1908 RFC 3501 IMAPv4 March 2003
yuuji@0 1909
yuuji@0 1910
yuuji@0 1911 If the mailbox name is suffixed with the server's hierarchy
yuuji@0 1912 separator character (as returned from the server by a LIST
yuuji@0 1913 command), this is a declaration that the client intends to create
yuuji@0 1914 mailbox names under this name in the hierarchy. Server
yuuji@0 1915 implementations that do not require this declaration MUST ignore
yuuji@0 1916 the declaration. In any case, the name created is without the
yuuji@0 1917 trailing hierarchy delimiter.
yuuji@0 1918
yuuji@0 1919 If the server's hierarchy separator character appears elsewhere in
yuuji@0 1920 the name, the server SHOULD create any superior hierarchical names
yuuji@0 1921 that are needed for the CREATE command to be successfully
yuuji@0 1922 completed. In other words, an attempt to create "foo/bar/zap" on
yuuji@0 1923 a server in which "/" is the hierarchy separator character SHOULD
yuuji@0 1924 create foo/ and foo/bar/ if they do not already exist.
yuuji@0 1925
yuuji@0 1926 If a new mailbox is created with the same name as a mailbox which
yuuji@0 1927 was deleted, its unique identifiers MUST be greater than any
yuuji@0 1928 unique identifiers used in the previous incarnation of the mailbox
yuuji@0 1929 UNLESS the new incarnation has a different unique identifier
yuuji@0 1930 validity value. See the description of the UID command for more
yuuji@0 1931 detail.
yuuji@0 1932
yuuji@0 1933 Example: C: A003 CREATE owatagusiam/
yuuji@0 1934 S: A003 OK CREATE completed
yuuji@0 1935 C: A004 CREATE owatagusiam/blurdybloop
yuuji@0 1936 S: A004 OK CREATE completed
yuuji@0 1937
yuuji@0 1938 Note: The interpretation of this example depends on whether
yuuji@0 1939 "/" was returned as the hierarchy separator from LIST. If
yuuji@0 1940 "/" is the hierarchy separator, a new level of hierarchy
yuuji@0 1941 named "owatagusiam" with a member called "blurdybloop" is
yuuji@0 1942 created. Otherwise, two mailboxes at the same hierarchy
yuuji@0 1943 level are created.
yuuji@0 1944
yuuji@0 1945
yuuji@0 1946 6.3.4. DELETE Command
yuuji@0 1947
yuuji@0 1948 Arguments: mailbox name
yuuji@0 1949
yuuji@0 1950 Responses: no specific responses for this command
yuuji@0 1951
yuuji@0 1952 Result: OK - delete completed
yuuji@0 1953 NO - delete failure: can't delete mailbox with that name
yuuji@0 1954 BAD - command unknown or arguments invalid
yuuji@0 1955
yuuji@0 1956
yuuji@0 1957
yuuji@0 1958
yuuji@0 1959
yuuji@0 1960
yuuji@0 1961
yuuji@0 1962 Crispin Standards Track [Page 35]
yuuji@0 1963
yuuji@0 1964 RFC 3501 IMAPv4 March 2003
yuuji@0 1965
yuuji@0 1966
yuuji@0 1967 The DELETE command permanently removes the mailbox with the given
yuuji@0 1968 name. A tagged OK response is returned only if the mailbox has
yuuji@0 1969 been deleted. It is an error to attempt to delete INBOX or a
yuuji@0 1970 mailbox name that does not exist.
yuuji@0 1971
yuuji@0 1972 The DELETE command MUST NOT remove inferior hierarchical names.
yuuji@0 1973 For example, if a mailbox "foo" has an inferior "foo.bar"
yuuji@0 1974 (assuming "." is the hierarchy delimiter character), removing
yuuji@0 1975 "foo" MUST NOT remove "foo.bar". It is an error to attempt to
yuuji@0 1976 delete a name that has inferior hierarchical names and also has
yuuji@0 1977 the \Noselect mailbox name attribute (see the description of the
yuuji@0 1978 LIST response for more details).
yuuji@0 1979
yuuji@0 1980 It is permitted to delete a name that has inferior hierarchical
yuuji@0 1981 names and does not have the \Noselect mailbox name attribute. In
yuuji@0 1982 this case, all messages in that mailbox are removed, and the name
yuuji@0 1983 will acquire the \Noselect mailbox name attribute.
yuuji@0 1984
yuuji@0 1985 The value of the highest-used unique identifier of the deleted
yuuji@0 1986 mailbox MUST be preserved so that a new mailbox created with the
yuuji@0 1987 same name will not reuse the identifiers of the former
yuuji@0 1988 incarnation, UNLESS the new incarnation has a different unique
yuuji@0 1989 identifier validity value. See the description of the UID command
yuuji@0 1990 for more detail.
yuuji@0 1991
yuuji@0 1992 Examples: C: A682 LIST "" *
yuuji@0 1993 S: * LIST () "/" blurdybloop
yuuji@0 1994 S: * LIST (\Noselect) "/" foo
yuuji@0 1995 S: * LIST () "/" foo/bar
yuuji@0 1996 S: A682 OK LIST completed
yuuji@0 1997 C: A683 DELETE blurdybloop
yuuji@0 1998 S: A683 OK DELETE completed
yuuji@0 1999 C: A684 DELETE foo
yuuji@0 2000 S: A684 NO Name "foo" has inferior hierarchical names
yuuji@0 2001 C: A685 DELETE foo/bar
yuuji@0 2002 S: A685 OK DELETE Completed
yuuji@0 2003 C: A686 LIST "" *
yuuji@0 2004 S: * LIST (\Noselect) "/" foo
yuuji@0 2005 S: A686 OK LIST completed
yuuji@0 2006 C: A687 DELETE foo
yuuji@0 2007 S: A687 OK DELETE Completed
yuuji@0 2008
yuuji@0 2009
yuuji@0 2010
yuuji@0 2011
yuuji@0 2012
yuuji@0 2013
yuuji@0 2014
yuuji@0 2015
yuuji@0 2016
yuuji@0 2017
yuuji@0 2018 Crispin Standards Track [Page 36]
yuuji@0 2019
yuuji@0 2020 RFC 3501 IMAPv4 March 2003
yuuji@0 2021
yuuji@0 2022
yuuji@0 2023 C: A82 LIST "" *
yuuji@0 2024 S: * LIST () "." blurdybloop
yuuji@0 2025 S: * LIST () "." foo
yuuji@0 2026 S: * LIST () "." foo.bar
yuuji@0 2027 S: A82 OK LIST completed
yuuji@0 2028 C: A83 DELETE blurdybloop
yuuji@0 2029 S: A83 OK DELETE completed
yuuji@0 2030 C: A84 DELETE foo
yuuji@0 2031 S: A84 OK DELETE Completed
yuuji@0 2032 C: A85 LIST "" *
yuuji@0 2033 S: * LIST () "." foo.bar
yuuji@0 2034 S: A85 OK LIST completed
yuuji@0 2035 C: A86 LIST "" %
yuuji@0 2036 S: * LIST (\Noselect) "." foo
yuuji@0 2037 S: A86 OK LIST completed
yuuji@0 2038
yuuji@0 2039
yuuji@0 2040 6.3.5. RENAME Command
yuuji@0 2041
yuuji@0 2042 Arguments: existing mailbox name
yuuji@0 2043 new mailbox name
yuuji@0 2044
yuuji@0 2045 Responses: no specific responses for this command
yuuji@0 2046
yuuji@0 2047 Result: OK - rename completed
yuuji@0 2048 NO - rename failure: can't rename mailbox with that name,
yuuji@0 2049 can't rename to mailbox with that name
yuuji@0 2050 BAD - command unknown or arguments invalid
yuuji@0 2051
yuuji@0 2052 The RENAME command changes the name of a mailbox. A tagged OK
yuuji@0 2053 response is returned only if the mailbox has been renamed. It is
yuuji@0 2054 an error to attempt to rename from a mailbox name that does not
yuuji@0 2055 exist or to a mailbox name that already exists. Any error in
yuuji@0 2056 renaming will return a tagged NO response.
yuuji@0 2057
yuuji@0 2058 If the name has inferior hierarchical names, then the inferior
yuuji@0 2059 hierarchical names MUST also be renamed. For example, a rename of
yuuji@0 2060 "foo" to "zap" will rename "foo/bar" (assuming "/" is the
yuuji@0 2061 hierarchy delimiter character) to "zap/bar".
yuuji@0 2062
yuuji@0 2063 If the server's hierarchy separator character appears in the name,
yuuji@0 2064 the server SHOULD create any superior hierarchical names that are
yuuji@0 2065 needed for the RENAME command to complete successfully. In other
yuuji@0 2066 words, an attempt to rename "foo/bar/zap" to baz/rag/zowie on a
yuuji@0 2067 server in which "/" is the hierarchy separator character SHOULD
yuuji@0 2068 create baz/ and baz/rag/ if they do not already exist.
yuuji@0 2069
yuuji@0 2070
yuuji@0 2071
yuuji@0 2072
yuuji@0 2073
yuuji@0 2074 Crispin Standards Track [Page 37]
yuuji@0 2075
yuuji@0 2076 RFC 3501 IMAPv4 March 2003
yuuji@0 2077
yuuji@0 2078
yuuji@0 2079 The value of the highest-used unique identifier of the old mailbox
yuuji@0 2080 name MUST be preserved so that a new mailbox created with the same
yuuji@0 2081 name will not reuse the identifiers of the former incarnation,
yuuji@0 2082 UNLESS the new incarnation has a different unique identifier
yuuji@0 2083 validity value. See the description of the UID command for more
yuuji@0 2084 detail.
yuuji@0 2085
yuuji@0 2086 Renaming INBOX is permitted, and has special behavior. It moves
yuuji@0 2087 all messages in INBOX to a new mailbox with the given name,
yuuji@0 2088 leaving INBOX empty. If the server implementation supports
yuuji@0 2089 inferior hierarchical names of INBOX, these are unaffected by a
yuuji@0 2090 rename of INBOX.
yuuji@0 2091
yuuji@0 2092 Examples: C: A682 LIST "" *
yuuji@0 2093 S: * LIST () "/" blurdybloop
yuuji@0 2094 S: * LIST (\Noselect) "/" foo
yuuji@0 2095 S: * LIST () "/" foo/bar
yuuji@0 2096 S: A682 OK LIST completed
yuuji@0 2097 C: A683 RENAME blurdybloop sarasoop
yuuji@0 2098 S: A683 OK RENAME completed
yuuji@0 2099 C: A684 RENAME foo zowie
yuuji@0 2100 S: A684 OK RENAME Completed
yuuji@0 2101 C: A685 LIST "" *
yuuji@0 2102 S: * LIST () "/" sarasoop
yuuji@0 2103 S: * LIST (\Noselect) "/" zowie
yuuji@0 2104 S: * LIST () "/" zowie/bar
yuuji@0 2105 S: A685 OK LIST completed
yuuji@0 2106
yuuji@0 2107 C: Z432 LIST "" *
yuuji@0 2108 S: * LIST () "." INBOX
yuuji@0 2109 S: * LIST () "." INBOX.bar
yuuji@0 2110 S: Z432 OK LIST completed
yuuji@0 2111 C: Z433 RENAME INBOX old-mail
yuuji@0 2112 S: Z433 OK RENAME completed
yuuji@0 2113 C: Z434 LIST "" *
yuuji@0 2114 S: * LIST () "." INBOX
yuuji@0 2115 S: * LIST () "." INBOX.bar
yuuji@0 2116 S: * LIST () "." old-mail
yuuji@0 2117 S: Z434 OK LIST completed
yuuji@0 2118
yuuji@0 2119
yuuji@0 2120
yuuji@0 2121
yuuji@0 2122
yuuji@0 2123
yuuji@0 2124
yuuji@0 2125
yuuji@0 2126
yuuji@0 2127
yuuji@0 2128
yuuji@0 2129
yuuji@0 2130 Crispin Standards Track [Page 38]
yuuji@0 2131
yuuji@0 2132 RFC 3501 IMAPv4 March 2003
yuuji@0 2133
yuuji@0 2134
yuuji@0 2135 6.3.6. SUBSCRIBE Command
yuuji@0 2136
yuuji@0 2137 Arguments: mailbox
yuuji@0 2138
yuuji@0 2139 Responses: no specific responses for this command
yuuji@0 2140
yuuji@0 2141 Result: OK - subscribe completed
yuuji@0 2142 NO - subscribe failure: can't subscribe to that name
yuuji@0 2143 BAD - command unknown or arguments invalid
yuuji@0 2144
yuuji@0 2145 The SUBSCRIBE command adds the specified mailbox name to the
yuuji@0 2146 server's set of "active" or "subscribed" mailboxes as returned by
yuuji@0 2147 the LSUB command. This command returns a tagged OK response only
yuuji@0 2148 if the subscription is successful.
yuuji@0 2149
yuuji@0 2150 A server MAY validate the mailbox argument to SUBSCRIBE to verify
yuuji@0 2151 that it exists. However, it MUST NOT unilaterally remove an
yuuji@0 2152 existing mailbox name from the subscription list even if a mailbox
yuuji@0 2153 by that name no longer exists.
yuuji@0 2154
yuuji@0 2155 Note: This requirement is because a server site can
yuuji@0 2156 choose to routinely remove a mailbox with a well-known
yuuji@0 2157 name (e.g., "system-alerts") after its contents expire,
yuuji@0 2158 with the intention of recreating it when new contents
yuuji@0 2159 are appropriate.
yuuji@0 2160
yuuji@0 2161
yuuji@0 2162 Example: C: A002 SUBSCRIBE #news.comp.mail.mime
yuuji@0 2163 S: A002 OK SUBSCRIBE completed
yuuji@0 2164
yuuji@0 2165
yuuji@0 2166 6.3.7. UNSUBSCRIBE Command
yuuji@0 2167
yuuji@0 2168 Arguments: mailbox name
yuuji@0 2169
yuuji@0 2170 Responses: no specific responses for this command
yuuji@0 2171
yuuji@0 2172 Result: OK - unsubscribe completed
yuuji@0 2173 NO - unsubscribe failure: can't unsubscribe that name
yuuji@0 2174 BAD - command unknown or arguments invalid
yuuji@0 2175
yuuji@0 2176 The UNSUBSCRIBE command removes the specified mailbox name from
yuuji@0 2177 the server's set of "active" or "subscribed" mailboxes as returned
yuuji@0 2178 by the LSUB command. This command returns a tagged OK response
yuuji@0 2179 only if the unsubscription is successful.
yuuji@0 2180
yuuji@0 2181 Example: C: A002 UNSUBSCRIBE #news.comp.mail.mime
yuuji@0 2182 S: A002 OK UNSUBSCRIBE completed
yuuji@0 2183
yuuji@0 2184
yuuji@0 2185
yuuji@0 2186 Crispin Standards Track [Page 39]
yuuji@0 2187
yuuji@0 2188 RFC 3501 IMAPv4 March 2003
yuuji@0 2189
yuuji@0 2190
yuuji@0 2191 6.3.8. LIST Command
yuuji@0 2192
yuuji@0 2193 Arguments: reference name
yuuji@0 2194 mailbox name with possible wildcards
yuuji@0 2195
yuuji@0 2196 Responses: untagged responses: LIST
yuuji@0 2197
yuuji@0 2198 Result: OK - list completed
yuuji@0 2199 NO - list failure: can't list that reference or name
yuuji@0 2200 BAD - command unknown or arguments invalid
yuuji@0 2201
yuuji@0 2202 The LIST command returns a subset of names from the complete set
yuuji@0 2203 of all names available to the client. Zero or more untagged LIST
yuuji@0 2204 replies are returned, containing the name attributes, hierarchy
yuuji@0 2205 delimiter, and name; see the description of the LIST reply for
yuuji@0 2206 more detail.
yuuji@0 2207
yuuji@0 2208 The LIST command SHOULD return its data quickly, without undue
yuuji@0 2209 delay. For example, it SHOULD NOT go to excess trouble to
yuuji@0 2210 calculate the \Marked or \Unmarked status or perform other
yuuji@0 2211 processing; if each name requires 1 second of processing, then a
yuuji@0 2212 list of 1200 names would take 20 minutes!
yuuji@0 2213
yuuji@0 2214 An empty ("" string) reference name argument indicates that the
yuuji@0 2215 mailbox name is interpreted as by SELECT. The returned mailbox
yuuji@0 2216 names MUST match the supplied mailbox name pattern. A non-empty
yuuji@0 2217 reference name argument is the name of a mailbox or a level of
yuuji@0 2218 mailbox hierarchy, and indicates the context in which the mailbox
yuuji@0 2219 name is interpreted.
yuuji@0 2220
yuuji@0 2221 An empty ("" string) mailbox name argument is a special request to
yuuji@0 2222 return the hierarchy delimiter and the root name of the name given
yuuji@0 2223 in the reference. The value returned as the root MAY be the empty
yuuji@0 2224 string if the reference is non-rooted or is an empty string. In
yuuji@0 2225 all cases, a hierarchy delimiter (or NIL if there is no hierarchy)
yuuji@0 2226 is returned. This permits a client to get the hierarchy delimiter
yuuji@0 2227 (or find out that the mailbox names are flat) even when no
yuuji@0 2228 mailboxes by that name currently exist.
yuuji@0 2229
yuuji@0 2230 The reference and mailbox name arguments are interpreted into a
yuuji@0 2231 canonical form that represents an unambiguous left-to-right
yuuji@0 2232 hierarchy. The returned mailbox names will be in the interpreted
yuuji@0 2233 form.
yuuji@0 2234
yuuji@0 2235
yuuji@0 2236
yuuji@0 2237
yuuji@0 2238
yuuji@0 2239
yuuji@0 2240
yuuji@0 2241
yuuji@0 2242 Crispin Standards Track [Page 40]
yuuji@0 2243
yuuji@0 2244 RFC 3501 IMAPv4 March 2003
yuuji@0 2245
yuuji@0 2246
yuuji@0 2247 Note: The interpretation of the reference argument is
yuuji@0 2248 implementation-defined. It depends upon whether the
yuuji@0 2249 server implementation has a concept of the "current
yuuji@0 2250 working directory" and leading "break out characters",
yuuji@0 2251 which override the current working directory.
yuuji@0 2252
yuuji@0 2253 For example, on a server which exports a UNIX or NT
yuuji@0 2254 filesystem, the reference argument contains the current
yuuji@0 2255 working directory, and the mailbox name argument would
yuuji@0 2256 contain the name as interpreted in the current working
yuuji@0 2257 directory.
yuuji@0 2258
yuuji@0 2259 If a server implementation has no concept of break out
yuuji@0 2260 characters, the canonical form is normally the reference
yuuji@0 2261 name appended with the mailbox name. Note that if the
yuuji@0 2262 server implements the namespace convention (section
yuuji@0 2263 5.1.2), "#" is a break out character and must be treated
yuuji@0 2264 as such.
yuuji@0 2265
yuuji@0 2266 If the reference argument is not a level of mailbox
yuuji@0 2267 hierarchy (that is, it is a \NoInferiors name), and/or
yuuji@0 2268 the reference argument does not end with the hierarchy
yuuji@0 2269 delimiter, it is implementation-dependent how this is
yuuji@0 2270 interpreted. For example, a reference of "foo/bar" and
yuuji@0 2271 mailbox name of "rag/baz" could be interpreted as
yuuji@0 2272 "foo/bar/rag/baz", "foo/barrag/baz", or "foo/rag/baz".
yuuji@0 2273 A client SHOULD NOT use such a reference argument except
yuuji@0 2274 at the explicit request of the user. A hierarchical
yuuji@0 2275 browser MUST NOT make any assumptions about server
yuuji@0 2276 interpretation of the reference unless the reference is
yuuji@0 2277 a level of mailbox hierarchy AND ends with the hierarchy
yuuji@0 2278 delimiter.
yuuji@0 2279
yuuji@0 2280 Any part of the reference argument that is included in the
yuuji@0 2281 interpreted form SHOULD prefix the interpreted form. It SHOULD
yuuji@0 2282 also be in the same form as the reference name argument. This
yuuji@0 2283 rule permits the client to determine if the returned mailbox name
yuuji@0 2284 is in the context of the reference argument, or if something about
yuuji@0 2285 the mailbox argument overrode the reference argument. Without
yuuji@0 2286 this rule, the client would have to have knowledge of the server's
yuuji@0 2287 naming semantics including what characters are "breakouts" that
yuuji@0 2288 override a naming context.
yuuji@0 2289
yuuji@0 2290
yuuji@0 2291
yuuji@0 2292
yuuji@0 2293
yuuji@0 2294
yuuji@0 2295
yuuji@0 2296
yuuji@0 2297
yuuji@0 2298 Crispin Standards Track [Page 41]
yuuji@0 2299
yuuji@0 2300 RFC 3501 IMAPv4 March 2003
yuuji@0 2301
yuuji@0 2302
yuuji@0 2303 For example, here are some examples of how references
yuuji@0 2304 and mailbox names might be interpreted on a UNIX-based
yuuji@0 2305 server:
yuuji@0 2306
yuuji@0 2307 Reference Mailbox Name Interpretation
yuuji@0 2308 ------------ ------------ --------------
yuuji@0 2309 ~smith/Mail/ foo.* ~smith/Mail/foo.*
yuuji@0 2310 archive/ % archive/%
yuuji@0 2311 #news. comp.mail.* #news.comp.mail.*
yuuji@0 2312 ~smith/Mail/ /usr/doc/foo /usr/doc/foo
yuuji@0 2313 archive/ ~fred/Mail/* ~fred/Mail/*
yuuji@0 2314
yuuji@0 2315 The first three examples demonstrate interpretations in
yuuji@0 2316 the context of the reference argument. Note that
yuuji@0 2317 "~smith/Mail" SHOULD NOT be transformed into something
yuuji@0 2318 like "/u2/users/smith/Mail", or it would be impossible
yuuji@0 2319 for the client to determine that the interpretation was
yuuji@0 2320 in the context of the reference.
yuuji@0 2321
yuuji@0 2322 The character "*" is a wildcard, and matches zero or more
yuuji@0 2323 characters at this position. The character "%" is similar to "*",
yuuji@0 2324 but it does not match a hierarchy delimiter. If the "%" wildcard
yuuji@0 2325 is the last character of a mailbox name argument, matching levels
yuuji@0 2326 of hierarchy are also returned. If these levels of hierarchy are
yuuji@0 2327 not also selectable mailboxes, they are returned with the
yuuji@0 2328 \Noselect mailbox name attribute (see the description of the LIST
yuuji@0 2329 response for more details).
yuuji@0 2330
yuuji@0 2331 Server implementations are permitted to "hide" otherwise
yuuji@0 2332 accessible mailboxes from the wildcard characters, by preventing
yuuji@0 2333 certain characters or names from matching a wildcard in certain
yuuji@0 2334 situations. For example, a UNIX-based server might restrict the
yuuji@0 2335 interpretation of "*" so that an initial "/" character does not
yuuji@0 2336 match.
yuuji@0 2337
yuuji@0 2338 The special name INBOX is included in the output from LIST, if
yuuji@0 2339 INBOX is supported by this server for this user and if the
yuuji@0 2340 uppercase string "INBOX" matches the interpreted reference and
yuuji@0 2341 mailbox name arguments with wildcards as described above. The
yuuji@0 2342 criteria for omitting INBOX is whether SELECT INBOX will return
yuuji@0 2343 failure; it is not relevant whether the user's real INBOX resides
yuuji@0 2344 on this or some other server.
yuuji@0 2345
yuuji@0 2346
yuuji@0 2347
yuuji@0 2348
yuuji@0 2349
yuuji@0 2350
yuuji@0 2351
yuuji@0 2352
yuuji@0 2353
yuuji@0 2354 Crispin Standards Track [Page 42]
yuuji@0 2355
yuuji@0 2356 RFC 3501 IMAPv4 March 2003
yuuji@0 2357
yuuji@0 2358
yuuji@0 2359 Example: C: A101 LIST "" ""
yuuji@0 2360 S: * LIST (\Noselect) "/" ""
yuuji@0 2361 S: A101 OK LIST Completed
yuuji@0 2362 C: A102 LIST #news.comp.mail.misc ""
yuuji@0 2363 S: * LIST (\Noselect) "." #news.
yuuji@0 2364 S: A102 OK LIST Completed
yuuji@0 2365 C: A103 LIST /usr/staff/jones ""
yuuji@0 2366 S: * LIST (\Noselect) "/" /
yuuji@0 2367 S: A103 OK LIST Completed
yuuji@0 2368 C: A202 LIST ~/Mail/ %
yuuji@0 2369 S: * LIST (\Noselect) "/" ~/Mail/foo
yuuji@0 2370 S: * LIST () "/" ~/Mail/meetings
yuuji@0 2371 S: A202 OK LIST completed
yuuji@0 2372
yuuji@0 2373
yuuji@0 2374 6.3.9. LSUB Command
yuuji@0 2375
yuuji@0 2376 Arguments: reference name
yuuji@0 2377 mailbox name with possible wildcards
yuuji@0 2378
yuuji@0 2379 Responses: untagged responses: LSUB
yuuji@0 2380
yuuji@0 2381 Result: OK - lsub completed
yuuji@0 2382 NO - lsub failure: can't list that reference or name
yuuji@0 2383 BAD - command unknown or arguments invalid
yuuji@0 2384
yuuji@0 2385 The LSUB command returns a subset of names from the set of names
yuuji@0 2386 that the user has declared as being "active" or "subscribed".
yuuji@0 2387 Zero or more untagged LSUB replies are returned. The arguments to
yuuji@0 2388 LSUB are in the same form as those for LIST.
yuuji@0 2389
yuuji@0 2390 The returned untagged LSUB response MAY contain different mailbox
yuuji@0 2391 flags from a LIST untagged response. If this should happen, the
yuuji@0 2392 flags in the untagged LIST are considered more authoritative.
yuuji@0 2393
yuuji@0 2394 A special situation occurs when using LSUB with the % wildcard.
yuuji@0 2395 Consider what happens if "foo/bar" (with a hierarchy delimiter of
yuuji@0 2396 "/") is subscribed but "foo" is not. A "%" wildcard to LSUB must
yuuji@0 2397 return foo, not foo/bar, in the LSUB response, and it MUST be
yuuji@0 2398 flagged with the \Noselect attribute.
yuuji@0 2399
yuuji@0 2400 The server MUST NOT unilaterally remove an existing mailbox name
yuuji@0 2401 from the subscription list even if a mailbox by that name no
yuuji@0 2402 longer exists.
yuuji@0 2403
yuuji@0 2404
yuuji@0 2405
yuuji@0 2406
yuuji@0 2407
yuuji@0 2408
yuuji@0 2409
yuuji@0 2410 Crispin Standards Track [Page 43]
yuuji@0 2411
yuuji@0 2412 RFC 3501 IMAPv4 March 2003
yuuji@0 2413
yuuji@0 2414
yuuji@0 2415 Example: C: A002 LSUB "#news." "comp.mail.*"
yuuji@0 2416 S: * LSUB () "." #news.comp.mail.mime
yuuji@0 2417 S: * LSUB () "." #news.comp.mail.misc
yuuji@0 2418 S: A002 OK LSUB completed
yuuji@0 2419 C: A003 LSUB "#news." "comp.%"
yuuji@0 2420 S: * LSUB (\NoSelect) "." #news.comp.mail
yuuji@0 2421 S: A003 OK LSUB completed
yuuji@0 2422
yuuji@0 2423
yuuji@0 2424 6.3.10. STATUS Command
yuuji@0 2425
yuuji@0 2426 Arguments: mailbox name
yuuji@0 2427 status data item names
yuuji@0 2428
yuuji@0 2429 Responses: untagged responses: STATUS
yuuji@0 2430
yuuji@0 2431 Result: OK - status completed
yuuji@0 2432 NO - status failure: no status for that name
yuuji@0 2433 BAD - command unknown or arguments invalid
yuuji@0 2434
yuuji@0 2435 The STATUS command requests the status of the indicated mailbox.
yuuji@0 2436 It does not change the currently selected mailbox, nor does it
yuuji@0 2437 affect the state of any messages in the queried mailbox (in
yuuji@0 2438 particular, STATUS MUST NOT cause messages to lose the \Recent
yuuji@0 2439 flag).
yuuji@0 2440
yuuji@0 2441 The STATUS command provides an alternative to opening a second
yuuji@0 2442 IMAP4rev1 connection and doing an EXAMINE command on a mailbox to
yuuji@0 2443 query that mailbox's status without deselecting the current
yuuji@0 2444 mailbox in the first IMAP4rev1 connection.
yuuji@0 2445
yuuji@0 2446 Unlike the LIST command, the STATUS command is not guaranteed to
yuuji@0 2447 be fast in its response. Under certain circumstances, it can be
yuuji@0 2448 quite slow. In some implementations, the server is obliged to
yuuji@0 2449 open the mailbox read-only internally to obtain certain status
yuuji@0 2450 information. Also unlike the LIST command, the STATUS command
yuuji@0 2451 does not accept wildcards.
yuuji@0 2452
yuuji@0 2453 Note: The STATUS command is intended to access the
yuuji@0 2454 status of mailboxes other than the currently selected
yuuji@0 2455 mailbox. Because the STATUS command can cause the
yuuji@0 2456 mailbox to be opened internally, and because this
yuuji@0 2457 information is available by other means on the selected
yuuji@0 2458 mailbox, the STATUS command SHOULD NOT be used on the
yuuji@0 2459 currently selected mailbox.
yuuji@0 2460
yuuji@0 2461
yuuji@0 2462
yuuji@0 2463
yuuji@0 2464
yuuji@0 2465
yuuji@0 2466 Crispin Standards Track [Page 44]
yuuji@0 2467
yuuji@0 2468 RFC 3501 IMAPv4 March 2003
yuuji@0 2469
yuuji@0 2470
yuuji@0 2471 The STATUS command MUST NOT be used as a "check for new
yuuji@0 2472 messages in the selected mailbox" operation (refer to
yuuji@0 2473 sections 7, 7.3.1, and 7.3.2 for more information about
yuuji@0 2474 the proper method for new message checking).
yuuji@0 2475
yuuji@0 2476 Because the STATUS command is not guaranteed to be fast
yuuji@0 2477 in its results, clients SHOULD NOT expect to be able to
yuuji@0 2478 issue many consecutive STATUS commands and obtain
yuuji@0 2479 reasonable performance.
yuuji@0 2480
yuuji@0 2481 The currently defined status data items that can be requested are:
yuuji@0 2482
yuuji@0 2483 MESSAGES
yuuji@0 2484 The number of messages in the mailbox.
yuuji@0 2485
yuuji@0 2486 RECENT
yuuji@0 2487 The number of messages with the \Recent flag set.
yuuji@0 2488
yuuji@0 2489 UIDNEXT
yuuji@0 2490 The next unique identifier value of the mailbox. Refer to
yuuji@0 2491 section 2.3.1.1 for more information.
yuuji@0 2492
yuuji@0 2493 UIDVALIDITY
yuuji@0 2494 The unique identifier validity value of the mailbox. Refer to
yuuji@0 2495 section 2.3.1.1 for more information.
yuuji@0 2496
yuuji@0 2497 UNSEEN
yuuji@0 2498 The number of messages which do not have the \Seen flag set.
yuuji@0 2499
yuuji@0 2500
yuuji@0 2501 Example: C: A042 STATUS blurdybloop (UIDNEXT MESSAGES)
yuuji@0 2502 S: * STATUS blurdybloop (MESSAGES 231 UIDNEXT 44292)
yuuji@0 2503 S: A042 OK STATUS completed
yuuji@0 2504
yuuji@0 2505
yuuji@0 2506
yuuji@0 2507
yuuji@0 2508
yuuji@0 2509
yuuji@0 2510
yuuji@0 2511
yuuji@0 2512
yuuji@0 2513
yuuji@0 2514
yuuji@0 2515
yuuji@0 2516
yuuji@0 2517
yuuji@0 2518
yuuji@0 2519
yuuji@0 2520
yuuji@0 2521
yuuji@0 2522 Crispin Standards Track [Page 45]
yuuji@0 2523
yuuji@0 2524 RFC 3501 IMAPv4 March 2003
yuuji@0 2525
yuuji@0 2526
yuuji@0 2527 6.3.11. APPEND Command
yuuji@0 2528
yuuji@0 2529 Arguments: mailbox name
yuuji@0 2530 OPTIONAL flag parenthesized list
yuuji@0 2531 OPTIONAL date/time string
yuuji@0 2532 message literal
yuuji@0 2533
yuuji@0 2534 Responses: no specific responses for this command
yuuji@0 2535
yuuji@0 2536 Result: OK - append completed
yuuji@0 2537 NO - append error: can't append to that mailbox, error
yuuji@0 2538 in flags or date/time or message text
yuuji@0 2539 BAD - command unknown or arguments invalid
yuuji@0 2540
yuuji@0 2541 The APPEND command appends the literal argument as a new message
yuuji@0 2542 to the end of the specified destination mailbox. This argument
yuuji@0 2543 SHOULD be in the format of an [RFC-2822] message. 8-bit
yuuji@0 2544 characters are permitted in the message. A server implementation
yuuji@0 2545 that is unable to preserve 8-bit data properly MUST be able to
yuuji@0 2546 reversibly convert 8-bit APPEND data to 7-bit using a [MIME-IMB]
yuuji@0 2547 content transfer encoding.
yuuji@0 2548
yuuji@0 2549 Note: There MAY be exceptions, e.g., draft messages, in
yuuji@0 2550 which required [RFC-2822] header lines are omitted in
yuuji@0 2551 the message literal argument to APPEND. The full
yuuji@0 2552 implications of doing so MUST be understood and
yuuji@0 2553 carefully weighed.
yuuji@0 2554
yuuji@0 2555 If a flag parenthesized list is specified, the flags SHOULD be set
yuuji@0 2556 in the resulting message; otherwise, the flag list of the
yuuji@0 2557 resulting message is set to empty by default. In either case, the
yuuji@0 2558 Recent flag is also set.
yuuji@0 2559
yuuji@0 2560 If a date-time is specified, the internal date SHOULD be set in
yuuji@0 2561 the resulting message; otherwise, the internal date of the
yuuji@0 2562 resulting message is set to the current date and time by default.
yuuji@0 2563
yuuji@0 2564 If the append is unsuccessful for any reason, the mailbox MUST be
yuuji@0 2565 restored to its state before the APPEND attempt; no partial
yuuji@0 2566 appending is permitted.
yuuji@0 2567
yuuji@0 2568 If the destination mailbox does not exist, a server MUST return an
yuuji@0 2569 error, and MUST NOT automatically create the mailbox. Unless it
yuuji@0 2570 is certain that the destination mailbox can not be created, the
yuuji@0 2571 server MUST send the response code "[TRYCREATE]" as the prefix of
yuuji@0 2572 the text of the tagged NO response. This gives a hint to the
yuuji@0 2573 client that it can attempt a CREATE command and retry the APPEND
yuuji@0 2574 if the CREATE is successful.
yuuji@0 2575
yuuji@0 2576
yuuji@0 2577
yuuji@0 2578 Crispin Standards Track [Page 46]
yuuji@0 2579
yuuji@0 2580 RFC 3501 IMAPv4 March 2003
yuuji@0 2581
yuuji@0 2582
yuuji@0 2583 If the mailbox is currently selected, the normal new message
yuuji@0 2584 actions SHOULD occur. Specifically, the server SHOULD notify the
yuuji@0 2585 client immediately via an untagged EXISTS response. If the server
yuuji@0 2586 does not do so, the client MAY issue a NOOP command (or failing
yuuji@0 2587 that, a CHECK command) after one or more APPEND commands.
yuuji@0 2588
yuuji@0 2589 Example: C: A003 APPEND saved-messages (\Seen) {310}
yuuji@0 2590 S: + Ready for literal data
yuuji@0 2591 C: Date: Mon, 7 Feb 1994 21:52:25 -0800 (PST)
yuuji@0 2592 C: From: Fred Foobar <foobar@Blurdybloop.COM>
yuuji@0 2593 C: Subject: afternoon meeting
yuuji@0 2594 C: To: mooch@owatagu.siam.edu
yuuji@0 2595 C: Message-Id: <B27397-0100000@Blurdybloop.COM>
yuuji@0 2596 C: MIME-Version: 1.0
yuuji@0 2597 C: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
yuuji@0 2598 C:
yuuji@0 2599 C: Hello Joe, do you think we can meet at 3:30 tomorrow?
yuuji@0 2600 C:
yuuji@0 2601 S: A003 OK APPEND completed
yuuji@0 2602
yuuji@0 2603 Note: The APPEND command is not used for message delivery,
yuuji@0 2604 because it does not provide a mechanism to transfer [SMTP]
yuuji@0 2605 envelope information.
yuuji@0 2606
yuuji@0 2607 6.4. Client Commands - Selected State
yuuji@0 2608
yuuji@0 2609 In the selected state, commands that manipulate messages in a mailbox
yuuji@0 2610 are permitted.
yuuji@0 2611
yuuji@0 2612 In addition to the universal commands (CAPABILITY, NOOP, and LOGOUT),
yuuji@0 2613 and the authenticated state commands (SELECT, EXAMINE, CREATE,
yuuji@0 2614 DELETE, RENAME, SUBSCRIBE, UNSUBSCRIBE, LIST, LSUB, STATUS, and
yuuji@0 2615 APPEND), the following commands are valid in the selected state:
yuuji@0 2616 CHECK, CLOSE, EXPUNGE, SEARCH, FETCH, STORE, COPY, and UID.
yuuji@0 2617
yuuji@0 2618 6.4.1. CHECK Command
yuuji@0 2619
yuuji@0 2620 Arguments: none
yuuji@0 2621
yuuji@0 2622 Responses: no specific responses for this command
yuuji@0 2623
yuuji@0 2624 Result: OK - check completed
yuuji@0 2625 BAD - command unknown or arguments invalid
yuuji@0 2626
yuuji@0 2627 The CHECK command requests a checkpoint of the currently selected
yuuji@0 2628 mailbox. A checkpoint refers to any implementation-dependent
yuuji@0 2629 housekeeping associated with the mailbox (e.g., resolving the
yuuji@0 2630 server's in-memory state of the mailbox with the state on its
yuuji@0 2631
yuuji@0 2632
yuuji@0 2633
yuuji@0 2634 Crispin Standards Track [Page 47]
yuuji@0 2635
yuuji@0 2636 RFC 3501 IMAPv4 March 2003
yuuji@0 2637
yuuji@0 2638
yuuji@0 2639 disk) that is not normally executed as part of each command. A
yuuji@0 2640 checkpoint MAY take a non-instantaneous amount of real time to
yuuji@0 2641 complete. If a server implementation has no such housekeeping
yuuji@0 2642 considerations, CHECK is equivalent to NOOP.
yuuji@0 2643
yuuji@0 2644 There is no guarantee that an EXISTS untagged response will happen
yuuji@0 2645 as a result of CHECK. NOOP, not CHECK, SHOULD be used for new
yuuji@0 2646 message polling.
yuuji@0 2647
yuuji@0 2648 Example: C: FXXZ CHECK
yuuji@0 2649 S: FXXZ OK CHECK Completed
yuuji@0 2650
yuuji@0 2651
yuuji@0 2652 6.4.2. CLOSE Command
yuuji@0 2653
yuuji@0 2654 Arguments: none
yuuji@0 2655
yuuji@0 2656 Responses: no specific responses for this command
yuuji@0 2657
yuuji@0 2658 Result: OK - close completed, now in authenticated state
yuuji@0 2659 BAD - command unknown or arguments invalid
yuuji@0 2660
yuuji@0 2661 The CLOSE command permanently removes all messages that have the
yuuji@0 2662 \Deleted flag set from the currently selected mailbox, and returns
yuuji@0 2663 to the authenticated state from the selected state. No untagged
yuuji@0 2664 EXPUNGE responses are sent.
yuuji@0 2665
yuuji@0 2666 No messages are removed, and no error is given, if the mailbox is
yuuji@0 2667 selected by an EXAMINE command or is otherwise selected read-only.
yuuji@0 2668
yuuji@0 2669 Even if a mailbox is selected, a SELECT, EXAMINE, or LOGOUT
yuuji@0 2670 command MAY be issued without previously issuing a CLOSE command.
yuuji@0 2671 The SELECT, EXAMINE, and LOGOUT commands implicitly close the
yuuji@0 2672 currently selected mailbox without doing an expunge. However,
yuuji@0 2673 when many messages are deleted, a CLOSE-LOGOUT or CLOSE-SELECT
yuuji@0 2674 sequence is considerably faster than an EXPUNGE-LOGOUT or
yuuji@0 2675 EXPUNGE-SELECT because no untagged EXPUNGE responses (which the
yuuji@0 2676 client would probably ignore) are sent.
yuuji@0 2677
yuuji@0 2678 Example: C: A341 CLOSE
yuuji@0 2679 S: A341 OK CLOSE completed
yuuji@0 2680
yuuji@0 2681
yuuji@0 2682
yuuji@0 2683
yuuji@0 2684
yuuji@0 2685
yuuji@0 2686
yuuji@0 2687
yuuji@0 2688
yuuji@0 2689
yuuji@0 2690 Crispin Standards Track [Page 48]
yuuji@0 2691
yuuji@0 2692 RFC 3501 IMAPv4 March 2003
yuuji@0 2693
yuuji@0 2694
yuuji@0 2695 6.4.3. EXPUNGE Command
yuuji@0 2696
yuuji@0 2697 Arguments: none
yuuji@0 2698
yuuji@0 2699 Responses: untagged responses: EXPUNGE
yuuji@0 2700
yuuji@0 2701 Result: OK - expunge completed
yuuji@0 2702 NO - expunge failure: can't expunge (e.g., permission
yuuji@0 2703 denied)
yuuji@0 2704 BAD - command unknown or arguments invalid
yuuji@0 2705
yuuji@0 2706 The EXPUNGE command permanently removes all messages that have the
yuuji@0 2707 \Deleted flag set from the currently selected mailbox. Before
yuuji@0 2708 returning an OK to the client, an untagged EXPUNGE response is
yuuji@0 2709 sent for each message that is removed.
yuuji@0 2710
yuuji@0 2711 Example: C: A202 EXPUNGE
yuuji@0 2712 S: * 3 EXPUNGE
yuuji@0 2713 S: * 3 EXPUNGE
yuuji@0 2714 S: * 5 EXPUNGE
yuuji@0 2715 S: * 8 EXPUNGE
yuuji@0 2716 S: A202 OK EXPUNGE completed
yuuji@0 2717
yuuji@0 2718 Note: In this example, messages 3, 4, 7, and 11 had the
yuuji@0 2719 \Deleted flag set. See the description of the EXPUNGE
yuuji@0 2720 response for further explanation.
yuuji@0 2721
yuuji@0 2722
yuuji@0 2723 6.4.4. SEARCH Command
yuuji@0 2724
yuuji@0 2725 Arguments: OPTIONAL [CHARSET] specification
yuuji@0 2726 searching criteria (one or more)
yuuji@0 2727
yuuji@0 2728 Responses: REQUIRED untagged response: SEARCH
yuuji@0 2729
yuuji@0 2730 Result: OK - search completed
yuuji@0 2731 NO - search error: can't search that [CHARSET] or
yuuji@0 2732 criteria
yuuji@0 2733 BAD - command unknown or arguments invalid
yuuji@0 2734
yuuji@0 2735 The SEARCH command searches the mailbox for messages that match
yuuji@0 2736 the given searching criteria. Searching criteria consist of one
yuuji@0 2737 or more search keys. The untagged SEARCH response from the server
yuuji@0 2738 contains a listing of message sequence numbers corresponding to
yuuji@0 2739 those messages that match the searching criteria.
yuuji@0 2740
yuuji@0 2741
yuuji@0 2742
yuuji@0 2743
yuuji@0 2744
yuuji@0 2745
yuuji@0 2746 Crispin Standards Track [Page 49]
yuuji@0 2747
yuuji@0 2748 RFC 3501 IMAPv4 March 2003
yuuji@0 2749
yuuji@0 2750
yuuji@0 2751 When multiple keys are specified, the result is the intersection
yuuji@0 2752 (AND function) of all the messages that match those keys. For
yuuji@0 2753 example, the criteria DELETED FROM "SMITH" SINCE 1-Feb-1994 refers
yuuji@0 2754 to all deleted messages from Smith that were placed in the mailbox
yuuji@0 2755 since February 1, 1994. A search key can also be a parenthesized
yuuji@0 2756 list of one or more search keys (e.g., for use with the OR and NOT
yuuji@0 2757 keys).
yuuji@0 2758
yuuji@0 2759 Server implementations MAY exclude [MIME-IMB] body parts with
yuuji@0 2760 terminal content media types other than TEXT and MESSAGE from
yuuji@0 2761 consideration in SEARCH matching.
yuuji@0 2762
yuuji@0 2763 The OPTIONAL [CHARSET] specification consists of the word
yuuji@0 2764 "CHARSET" followed by a registered [CHARSET]. It indicates the
yuuji@0 2765 [CHARSET] of the strings that appear in the search criteria.
yuuji@0 2766 [MIME-IMB] content transfer encodings, and [MIME-HDRS] strings in
yuuji@0 2767 [RFC-2822]/[MIME-IMB] headers, MUST be decoded before comparing
yuuji@0 2768 text in a [CHARSET] other than US-ASCII. US-ASCII MUST be
yuuji@0 2769 supported; other [CHARSET]s MAY be supported.
yuuji@0 2770
yuuji@0 2771 If the server does not support the specified [CHARSET], it MUST
yuuji@0 2772 return a tagged NO response (not a BAD). This response SHOULD
yuuji@0 2773 contain the BADCHARSET response code, which MAY list the
yuuji@0 2774 [CHARSET]s supported by the server.
yuuji@0 2775
yuuji@0 2776 In all search keys that use strings, a message matches the key if
yuuji@0 2777 the string is a substring of the field. The matching is
yuuji@0 2778 case-insensitive.
yuuji@0 2779
yuuji@0 2780 The defined search keys are as follows. Refer to the Formal
yuuji@0 2781 Syntax section for the precise syntactic definitions of the
yuuji@0 2782 arguments.
yuuji@0 2783
yuuji@0 2784 <sequence set>
yuuji@0 2785 Messages with message sequence numbers corresponding to the
yuuji@0 2786 specified message sequence number set.
yuuji@0 2787
yuuji@0 2788 ALL
yuuji@0 2789 All messages in the mailbox; the default initial key for
yuuji@0 2790 ANDing.
yuuji@0 2791
yuuji@0 2792 ANSWERED
yuuji@0 2793 Messages with the \Answered flag set.
yuuji@0 2794
yuuji@0 2795
yuuji@0 2796
yuuji@0 2797
yuuji@0 2798
yuuji@0 2799
yuuji@0 2800
yuuji@0 2801
yuuji@0 2802 Crispin Standards Track [Page 50]
yuuji@0 2803
yuuji@0 2804 RFC 3501 IMAPv4 March 2003
yuuji@0 2805
yuuji@0 2806
yuuji@0 2807 BCC <string>
yuuji@0 2808 Messages that contain the specified string in the envelope
yuuji@0 2809 structure's BCC field.
yuuji@0 2810
yuuji@0 2811 BEFORE <date>
yuuji@0 2812 Messages whose internal date (disregarding time and timezone)
yuuji@0 2813 is earlier than the specified date.
yuuji@0 2814
yuuji@0 2815 BODY <string>
yuuji@0 2816 Messages that contain the specified string in the body of the
yuuji@0 2817 message.
yuuji@0 2818
yuuji@0 2819 CC <string>
yuuji@0 2820 Messages that contain the specified string in the envelope
yuuji@0 2821 structure's CC field.
yuuji@0 2822
yuuji@0 2823 DELETED
yuuji@0 2824 Messages with the \Deleted flag set.
yuuji@0 2825
yuuji@0 2826 DRAFT
yuuji@0 2827 Messages with the \Draft flag set.
yuuji@0 2828
yuuji@0 2829 FLAGGED
yuuji@0 2830 Messages with the \Flagged flag set.
yuuji@0 2831
yuuji@0 2832 FROM <string>
yuuji@0 2833 Messages that contain the specified string in the envelope
yuuji@0 2834 structure's FROM field.
yuuji@0 2835
yuuji@0 2836 HEADER <field-name> <string>
yuuji@0 2837 Messages that have a header with the specified field-name (as
yuuji@0 2838 defined in [RFC-2822]) and that contains the specified string
yuuji@0 2839 in the text of the header (what comes after the colon). If the
yuuji@0 2840 string to search is zero-length, this matches all messages that
yuuji@0 2841 have a header line with the specified field-name regardless of
yuuji@0 2842 the contents.
yuuji@0 2843
yuuji@0 2844 KEYWORD <flag>
yuuji@0 2845 Messages with the specified keyword flag set.
yuuji@0 2846
yuuji@0 2847 LARGER <n>
yuuji@0 2848 Messages with an [RFC-2822] size larger than the specified
yuuji@0 2849 number of octets.
yuuji@0 2850
yuuji@0 2851 NEW
yuuji@0 2852 Messages that have the \Recent flag set but not the \Seen flag.
yuuji@0 2853 This is functionally equivalent to "(RECENT UNSEEN)".
yuuji@0 2854
yuuji@0 2855
yuuji@0 2856
yuuji@0 2857
yuuji@0 2858 Crispin Standards Track [Page 51]
yuuji@0 2859
yuuji@0 2860 RFC 3501 IMAPv4 March 2003
yuuji@0 2861
yuuji@0 2862
yuuji@0 2863 NOT <search-key>
yuuji@0 2864 Messages that do not match the specified search key.
yuuji@0 2865
yuuji@0 2866 OLD
yuuji@0 2867 Messages that do not have the \Recent flag set. This is
yuuji@0 2868 functionally equivalent to "NOT RECENT" (as opposed to "NOT
yuuji@0 2869 NEW").
yuuji@0 2870
yuuji@0 2871 ON <date>
yuuji@0 2872 Messages whose internal date (disregarding time and timezone)
yuuji@0 2873 is within the specified date.
yuuji@0 2874
yuuji@0 2875 OR <search-key1> <search-key2>
yuuji@0 2876 Messages that match either search key.
yuuji@0 2877
yuuji@0 2878 RECENT
yuuji@0 2879 Messages that have the \Recent flag set.
yuuji@0 2880
yuuji@0 2881 SEEN
yuuji@0 2882 Messages that have the \Seen flag set.
yuuji@0 2883
yuuji@0 2884 SENTBEFORE <date>
yuuji@0 2885 Messages whose [RFC-2822] Date: header (disregarding time and
yuuji@0 2886 timezone) is earlier than the specified date.
yuuji@0 2887
yuuji@0 2888 SENTON <date>
yuuji@0 2889 Messages whose [RFC-2822] Date: header (disregarding time and
yuuji@0 2890 timezone) is within the specified date.
yuuji@0 2891
yuuji@0 2892 SENTSINCE <date>
yuuji@0 2893 Messages whose [RFC-2822] Date: header (disregarding time and
yuuji@0 2894 timezone) is within or later than the specified date.
yuuji@0 2895
yuuji@0 2896 SINCE <date>
yuuji@0 2897 Messages whose internal date (disregarding time and timezone)
yuuji@0 2898 is within or later than the specified date.
yuuji@0 2899
yuuji@0 2900 SMALLER <n>
yuuji@0 2901 Messages with an [RFC-2822] size smaller than the specified
yuuji@0 2902 number of octets.
yuuji@0 2903
yuuji@0 2904
yuuji@0 2905
yuuji@0 2906
yuuji@0 2907
yuuji@0 2908
yuuji@0 2909
yuuji@0 2910
yuuji@0 2911
yuuji@0 2912
yuuji@0 2913
yuuji@0 2914 Crispin Standards Track [Page 52]
yuuji@0 2915
yuuji@0 2916 RFC 3501 IMAPv4 March 2003
yuuji@0 2917
yuuji@0 2918
yuuji@0 2919 SUBJECT <string>
yuuji@0 2920 Messages that contain the specified string in the envelope
yuuji@0 2921 structure's SUBJECT field.
yuuji@0 2922
yuuji@0 2923 TEXT <string>
yuuji@0 2924 Messages that contain the specified string in the header or
yuuji@0 2925 body of the message.
yuuji@0 2926
yuuji@0 2927 TO <string>
yuuji@0 2928 Messages that contain the specified string in the envelope
yuuji@0 2929 structure's TO field.
yuuji@0 2930
yuuji@0 2931 UID <sequence set>
yuuji@0 2932 Messages with unique identifiers corresponding to the specified
yuuji@0 2933 unique identifier set. Sequence set ranges are permitted.
yuuji@0 2934
yuuji@0 2935 UNANSWERED
yuuji@0 2936 Messages that do not have the \Answered flag set.
yuuji@0 2937
yuuji@0 2938 UNDELETED
yuuji@0 2939 Messages that do not have the \Deleted flag set.
yuuji@0 2940
yuuji@0 2941 UNDRAFT
yuuji@0 2942 Messages that do not have the \Draft flag set.
yuuji@0 2943
yuuji@0 2944 UNFLAGGED
yuuji@0 2945 Messages that do not have the \Flagged flag set.
yuuji@0 2946
yuuji@0 2947 UNKEYWORD <flag>
yuuji@0 2948 Messages that do not have the specified keyword flag set.
yuuji@0 2949
yuuji@0 2950 UNSEEN
yuuji@0 2951 Messages that do not have the \Seen flag set.
yuuji@0 2952
yuuji@0 2953
yuuji@0 2954
yuuji@0 2955
yuuji@0 2956
yuuji@0 2957
yuuji@0 2958
yuuji@0 2959
yuuji@0 2960
yuuji@0 2961
yuuji@0 2962
yuuji@0 2963
yuuji@0 2964
yuuji@0 2965
yuuji@0 2966
yuuji@0 2967
yuuji@0 2968
yuuji@0 2969
yuuji@0 2970 Crispin Standards Track [Page 53]
yuuji@0 2971
yuuji@0 2972 RFC 3501 IMAPv4 March 2003
yuuji@0 2973
yuuji@0 2974
yuuji@0 2975 Example: C: A282 SEARCH FLAGGED SINCE 1-Feb-1994 NOT FROM "Smith"
yuuji@0 2976 S: * SEARCH 2 84 882
yuuji@0 2977 S: A282 OK SEARCH completed
yuuji@0 2978 C: A283 SEARCH TEXT "string not in mailbox"
yuuji@0 2979 S: * SEARCH
yuuji@0 2980 S: A283 OK SEARCH completed
yuuji@0 2981 C: A284 SEARCH CHARSET UTF-8 TEXT {6}
yuuji@0 2982 C: XXXXXX
yuuji@0 2983 S: * SEARCH 43
yuuji@0 2984 S: A284 OK SEARCH completed
yuuji@0 2985
yuuji@0 2986 Note: Since this document is restricted to 7-bit ASCII
yuuji@0 2987 text, it is not possible to show actual UTF-8 data. The
yuuji@0 2988 "XXXXXX" is a placeholder for what would be 6 octets of
yuuji@0 2989 8-bit data in an actual transaction.
yuuji@0 2990
yuuji@0 2991
yuuji@0 2992 6.4.5. FETCH Command
yuuji@0 2993
yuuji@0 2994 Arguments: sequence set
yuuji@0 2995 message data item names or macro
yuuji@0 2996
yuuji@0 2997 Responses: untagged responses: FETCH
yuuji@0 2998
yuuji@0 2999 Result: OK - fetch completed
yuuji@0 3000 NO - fetch error: can't fetch that data
yuuji@0 3001 BAD - command unknown or arguments invalid
yuuji@0 3002
yuuji@0 3003 The FETCH command retrieves data associated with a message in the
yuuji@0 3004 mailbox. The data items to be fetched can be either a single atom
yuuji@0 3005 or a parenthesized list.
yuuji@0 3006
yuuji@0 3007 Most data items, identified in the formal syntax under the
yuuji@0 3008 msg-att-static rule, are static and MUST NOT change for any
yuuji@0 3009 particular message. Other data items, identified in the formal
yuuji@0 3010 syntax under the msg-att-dynamic rule, MAY change, either as a
yuuji@0 3011 result of a STORE command or due to external events.
yuuji@0 3012
yuuji@0 3013 For example, if a client receives an ENVELOPE for a
yuuji@0 3014 message when it already knows the envelope, it can
yuuji@0 3015 safely ignore the newly transmitted envelope.
yuuji@0 3016
yuuji@0 3017 There are three macros which specify commonly-used sets of data
yuuji@0 3018 items, and can be used instead of data items. A macro must be
yuuji@0 3019 used by itself, and not in conjunction with other macros or data
yuuji@0 3020 items.
yuuji@0 3021
yuuji@0 3022
yuuji@0 3023
yuuji@0 3024
yuuji@0 3025
yuuji@0 3026 Crispin Standards Track [Page 54]
yuuji@0 3027
yuuji@0 3028 RFC 3501 IMAPv4 March 2003
yuuji@0 3029
yuuji@0 3030
yuuji@0 3031 ALL
yuuji@0 3032 Macro equivalent to: (FLAGS INTERNALDATE RFC822.SIZE ENVELOPE)
yuuji@0 3033
yuuji@0 3034 FAST
yuuji@0 3035 Macro equivalent to: (FLAGS INTERNALDATE RFC822.SIZE)
yuuji@0 3036
yuuji@0 3037 FULL
yuuji@0 3038 Macro equivalent to: (FLAGS INTERNALDATE RFC822.SIZE ENVELOPE
yuuji@0 3039 BODY)
yuuji@0 3040
yuuji@0 3041 The currently defined data items that can be fetched are:
yuuji@0 3042
yuuji@0 3043 BODY
yuuji@0 3044 Non-extensible form of BODYSTRUCTURE.
yuuji@0 3045
yuuji@0 3046 BODY[<section>]<<partial>>
yuuji@0 3047 The text of a particular body section. The section
yuuji@0 3048 specification is a set of zero or more part specifiers
yuuji@0 3049 delimited by periods. A part specifier is either a part number
yuuji@0 3050 or one of the following: HEADER, HEADER.FIELDS,
yuuji@0 3051 HEADER.FIELDS.NOT, MIME, and TEXT. An empty section
yuuji@0 3052 specification refers to the entire message, including the
yuuji@0 3053 header.
yuuji@0 3054
yuuji@0 3055 Every message has at least one part number. Non-[MIME-IMB]
yuuji@0 3056 messages, and non-multipart [MIME-IMB] messages with no
yuuji@0 3057 encapsulated message, only have a part 1.
yuuji@0 3058
yuuji@0 3059 Multipart messages are assigned consecutive part numbers, as
yuuji@0 3060 they occur in the message. If a particular part is of type
yuuji@0 3061 message or multipart, its parts MUST be indicated by a period
yuuji@0 3062 followed by the part number within that nested multipart part.
yuuji@0 3063
yuuji@0 3064 A part of type MESSAGE/RFC822 also has nested part numbers,
yuuji@0 3065 referring to parts of the MESSAGE part's body.
yuuji@0 3066
yuuji@0 3067 The HEADER, HEADER.FIELDS, HEADER.FIELDS.NOT, and TEXT part
yuuji@0 3068 specifiers can be the sole part specifier or can be prefixed by
yuuji@0 3069 one or more numeric part specifiers, provided that the numeric
yuuji@0 3070 part specifier refers to a part of type MESSAGE/RFC822. The
yuuji@0 3071 MIME part specifier MUST be prefixed by one or more numeric
yuuji@0 3072 part specifiers.
yuuji@0 3073
yuuji@0 3074 The HEADER, HEADER.FIELDS, and HEADER.FIELDS.NOT part
yuuji@0 3075 specifiers refer to the [RFC-2822] header of the message or of
yuuji@0 3076 an encapsulated [MIME-IMT] MESSAGE/RFC822 message.
yuuji@0 3077 HEADER.FIELDS and HEADER.FIELDS.NOT are followed by a list of
yuuji@0 3078 field-name (as defined in [RFC-2822]) names, and return a
yuuji@0 3079
yuuji@0 3080
yuuji@0 3081
yuuji@0 3082 Crispin Standards Track [Page 55]
yuuji@0 3083
yuuji@0 3084 RFC 3501 IMAPv4 March 2003
yuuji@0 3085
yuuji@0 3086
yuuji@0 3087 subset of the header. The subset returned by HEADER.FIELDS
yuuji@0 3088 contains only those header fields with a field-name that
yuuji@0 3089 matches one of the names in the list; similarly, the subset
yuuji@0 3090 returned by HEADER.FIELDS.NOT contains only the header fields
yuuji@0 3091 with a non-matching field-name. The field-matching is
yuuji@0 3092 case-insensitive but otherwise exact. Subsetting does not
yuuji@0 3093 exclude the [RFC-2822] delimiting blank line between the header
yuuji@0 3094 and the body; the blank line is included in all header fetches,
yuuji@0 3095 except in the case of a message which has no body and no blank
yuuji@0 3096 line.
yuuji@0 3097
yuuji@0 3098 The MIME part specifier refers to the [MIME-IMB] header for
yuuji@0 3099 this part.
yuuji@0 3100
yuuji@0 3101 The TEXT part specifier refers to the text body of the message,
yuuji@0 3102 omitting the [RFC-2822] header.
yuuji@0 3103
yuuji@0 3104 Here is an example of a complex message with some of its
yuuji@0 3105 part specifiers:
yuuji@0 3106
yuuji@0 3107 HEADER ([RFC-2822] header of the message)
yuuji@0 3108 TEXT ([RFC-2822] text body of the message) MULTIPART/MIXED
yuuji@0 3109 1 TEXT/PLAIN
yuuji@0 3110 2 APPLICATION/OCTET-STREAM
yuuji@0 3111 3 MESSAGE/RFC822
yuuji@0 3112 3.HEADER ([RFC-2822] header of the message)
yuuji@0 3113 3.TEXT ([RFC-2822] text body of the message) MULTIPART/MIXED
yuuji@0 3114 3.1 TEXT/PLAIN
yuuji@0 3115 3.2 APPLICATION/OCTET-STREAM
yuuji@0 3116 4 MULTIPART/MIXED
yuuji@0 3117 4.1 IMAGE/GIF
yuuji@0 3118 4.1.MIME ([MIME-IMB] header for the IMAGE/GIF)
yuuji@0 3119 4.2 MESSAGE/RFC822
yuuji@0 3120 4.2.HEADER ([RFC-2822] header of the message)
yuuji@0 3121 4.2.TEXT ([RFC-2822] text body of the message) MULTIPART/MIXED
yuuji@0 3122 4.2.1 TEXT/PLAIN
yuuji@0 3123 4.2.2 MULTIPART/ALTERNATIVE
yuuji@0 3124 4.2.2.1 TEXT/PLAIN
yuuji@0 3125 4.2.2.2 TEXT/RICHTEXT
yuuji@0 3126
yuuji@0 3127
yuuji@0 3128 It is possible to fetch a substring of the designated text.
yuuji@0 3129 This is done by appending an open angle bracket ("<"), the
yuuji@0 3130 octet position of the first desired octet, a period, the
yuuji@0 3131 maximum number of octets desired, and a close angle bracket
yuuji@0 3132 (">") to the part specifier. If the starting octet is beyond
yuuji@0 3133 the end of the text, an empty string is returned.
yuuji@0 3134
yuuji@0 3135
yuuji@0 3136
yuuji@0 3137
yuuji@0 3138 Crispin Standards Track [Page 56]
yuuji@0 3139
yuuji@0 3140 RFC 3501 IMAPv4 March 2003
yuuji@0 3141
yuuji@0 3142
yuuji@0 3143 Any partial fetch that attempts to read beyond the end of the
yuuji@0 3144 text is truncated as appropriate. A partial fetch that starts
yuuji@0 3145 at octet 0 is returned as a partial fetch, even if this
yuuji@0 3146 truncation happened.
yuuji@0 3147
yuuji@0 3148 Note: This means that BODY[]<0.2048> of a 1500-octet message
yuuji@0 3149 will return BODY[]<0> with a literal of size 1500, not
yuuji@0 3150 BODY[].
yuuji@0 3151
yuuji@0 3152 Note: A substring fetch of a HEADER.FIELDS or
yuuji@0 3153 HEADER.FIELDS.NOT part specifier is calculated after
yuuji@0 3154 subsetting the header.
yuuji@0 3155
yuuji@0 3156 The \Seen flag is implicitly set; if this causes the flags to
yuuji@0 3157 change, they SHOULD be included as part of the FETCH responses.
yuuji@0 3158
yuuji@0 3159 BODY.PEEK[<section>]<<partial>>
yuuji@0 3160 An alternate form of BODY[<section>] that does not implicitly
yuuji@0 3161 set the \Seen flag.
yuuji@0 3162
yuuji@0 3163 BODYSTRUCTURE
yuuji@0 3164 The [MIME-IMB] body structure of the message. This is computed
yuuji@0 3165 by the server by parsing the [MIME-IMB] header fields in the
yuuji@0 3166 [RFC-2822] header and [MIME-IMB] headers.
yuuji@0 3167
yuuji@0 3168 ENVELOPE
yuuji@0 3169 The envelope structure of the message. This is computed by the
yuuji@0 3170 server by parsing the [RFC-2822] header into the component
yuuji@0 3171 parts, defaulting various fields as necessary.
yuuji@0 3172
yuuji@0 3173 FLAGS
yuuji@0 3174 The flags that are set for this message.
yuuji@0 3175
yuuji@0 3176 INTERNALDATE
yuuji@0 3177 The internal date of the message.
yuuji@0 3178
yuuji@0 3179 RFC822
yuuji@0 3180 Functionally equivalent to BODY[], differing in the syntax of
yuuji@0 3181 the resulting untagged FETCH data (RFC822 is returned).
yuuji@0 3182
yuuji@0 3183 RFC822.HEADER
yuuji@0 3184 Functionally equivalent to BODY.PEEK[HEADER], differing in the
yuuji@0 3185 syntax of the resulting untagged FETCH data (RFC822.HEADER is
yuuji@0 3186 returned).
yuuji@0 3187
yuuji@0 3188 RFC822.SIZE
yuuji@0 3189 The [RFC-2822] size of the message.
yuuji@0 3190
yuuji@0 3191
yuuji@0 3192
yuuji@0 3193
yuuji@0 3194 Crispin Standards Track [Page 57]
yuuji@0 3195
yuuji@0 3196 RFC 3501 IMAPv4 March 2003
yuuji@0 3197
yuuji@0 3198
yuuji@0 3199 RFC822.TEXT
yuuji@0 3200 Functionally equivalent to BODY[TEXT], differing in the syntax
yuuji@0 3201 of the resulting untagged FETCH data (RFC822.TEXT is returned).
yuuji@0 3202
yuuji@0 3203 UID
yuuji@0 3204 The unique identifier for the message.
yuuji@0 3205
yuuji@0 3206
yuuji@0 3207 Example: C: A654 FETCH 2:4 (FLAGS BODY[HEADER.FIELDS (DATE FROM)])
yuuji@0 3208 S: * 2 FETCH ....
yuuji@0 3209 S: * 3 FETCH ....
yuuji@0 3210 S: * 4 FETCH ....
yuuji@0 3211 S: A654 OK FETCH completed
yuuji@0 3212
yuuji@0 3213
yuuji@0 3214 6.4.6. STORE Command
yuuji@0 3215
yuuji@0 3216 Arguments: sequence set
yuuji@0 3217 message data item name
yuuji@0 3218 value for message data item
yuuji@0 3219
yuuji@0 3220 Responses: untagged responses: FETCH
yuuji@0 3221
yuuji@0 3222 Result: OK - store completed
yuuji@0 3223 NO - store error: can't store that data
yuuji@0 3224 BAD - command unknown or arguments invalid
yuuji@0 3225
yuuji@0 3226 The STORE command alters data associated with a message in the
yuuji@0 3227 mailbox. Normally, STORE will return the updated value of the
yuuji@0 3228 data with an untagged FETCH response. A suffix of ".SILENT" in
yuuji@0 3229 the data item name prevents the untagged FETCH, and the server
yuuji@0 3230 SHOULD assume that the client has determined the updated value
yuuji@0 3231 itself or does not care about the updated value.
yuuji@0 3232
yuuji@0 3233 Note: Regardless of whether or not the ".SILENT" suffix
yuuji@0 3234 was used, the server SHOULD send an untagged FETCH
yuuji@0 3235 response if a change to a message's flags from an
yuuji@0 3236 external source is observed. The intent is that the
yuuji@0 3237 status of the flags is determinate without a race
yuuji@0 3238 condition.
yuuji@0 3239
yuuji@0 3240
yuuji@0 3241
yuuji@0 3242
yuuji@0 3243
yuuji@0 3244
yuuji@0 3245
yuuji@0 3246
yuuji@0 3247
yuuji@0 3248
yuuji@0 3249
yuuji@0 3250 Crispin Standards Track [Page 58]
yuuji@0 3251
yuuji@0 3252 RFC 3501 IMAPv4 March 2003
yuuji@0 3253
yuuji@0 3254
yuuji@0 3255 The currently defined data items that can be stored are:
yuuji@0 3256
yuuji@0 3257 FLAGS <flag list>
yuuji@0 3258 Replace the flags for the message (other than \Recent) with the
yuuji@0 3259 argument. The new value of the flags is returned as if a FETCH
yuuji@0 3260 of those flags was done.
yuuji@0 3261
yuuji@0 3262 FLAGS.SILENT <flag list>
yuuji@0 3263 Equivalent to FLAGS, but without returning a new value.
yuuji@0 3264
yuuji@0 3265 +FLAGS <flag list>
yuuji@0 3266 Add the argument to the flags for the message. The new value
yuuji@0 3267 of the flags is returned as if a FETCH of those flags was done.
yuuji@0 3268
yuuji@0 3269 +FLAGS.SILENT <flag list>
yuuji@0 3270 Equivalent to +FLAGS, but without returning a new value.
yuuji@0 3271
yuuji@0 3272 -FLAGS <flag list>
yuuji@0 3273 Remove the argument from the flags for the message. The new
yuuji@0 3274 value of the flags is returned as if a FETCH of those flags was
yuuji@0 3275 done.
yuuji@0 3276
yuuji@0 3277 -FLAGS.SILENT <flag list>
yuuji@0 3278 Equivalent to -FLAGS, but without returning a new value.
yuuji@0 3279
yuuji@0 3280
yuuji@0 3281 Example: C: A003 STORE 2:4 +FLAGS (\Deleted)
yuuji@0 3282 S: * 2 FETCH (FLAGS (\Deleted \Seen))
yuuji@0 3283 S: * 3 FETCH (FLAGS (\Deleted))
yuuji@0 3284 S: * 4 FETCH (FLAGS (\Deleted \Flagged \Seen))
yuuji@0 3285 S: A003 OK STORE completed
yuuji@0 3286
yuuji@0 3287
yuuji@0 3288 6.4.7. COPY Command
yuuji@0 3289
yuuji@0 3290 Arguments: sequence set
yuuji@0 3291 mailbox name
yuuji@0 3292
yuuji@0 3293 Responses: no specific responses for this command
yuuji@0 3294
yuuji@0 3295 Result: OK - copy completed
yuuji@0 3296 NO - copy error: can't copy those messages or to that
yuuji@0 3297 name
yuuji@0 3298 BAD - command unknown or arguments invalid
yuuji@0 3299
yuuji@0 3300
yuuji@0 3301
yuuji@0 3302
yuuji@0 3303
yuuji@0 3304
yuuji@0 3305
yuuji@0 3306 Crispin Standards Track [Page 59]
yuuji@0 3307
yuuji@0 3308 RFC 3501 IMAPv4 March 2003
yuuji@0 3309
yuuji@0 3310
yuuji@0 3311 The COPY command copies the specified message(s) to the end of the
yuuji@0 3312 specified destination mailbox. The flags and internal date of the
yuuji@0 3313 message(s) SHOULD be preserved, and the Recent flag SHOULD be set,
yuuji@0 3314 in the copy.
yuuji@0 3315
yuuji@0 3316 If the destination mailbox does not exist, a server SHOULD return
yuuji@0 3317 an error. It SHOULD NOT automatically create the mailbox. Unless
yuuji@0 3318 it is certain that the destination mailbox can not be created, the
yuuji@0 3319 server MUST send the response code "[TRYCREATE]" as the prefix of
yuuji@0 3320 the text of the tagged NO response. This gives a hint to the
yuuji@0 3321 client that it can attempt a CREATE command and retry the COPY if
yuuji@0 3322 the CREATE is successful.
yuuji@0 3323
yuuji@0 3324 If the COPY command is unsuccessful for any reason, server
yuuji@0 3325 implementations MUST restore the destination mailbox to its state
yuuji@0 3326 before the COPY attempt.
yuuji@0 3327
yuuji@0 3328 Example: C: A003 COPY 2:4 MEETING
yuuji@0 3329 S: A003 OK COPY completed
yuuji@0 3330
yuuji@0 3331
yuuji@0 3332 6.4.8. UID Command
yuuji@0 3333
yuuji@0 3334 Arguments: command name
yuuji@0 3335 command arguments
yuuji@0 3336
yuuji@0 3337 Responses: untagged responses: FETCH, SEARCH
yuuji@0 3338
yuuji@0 3339 Result: OK - UID command completed
yuuji@0 3340 NO - UID command error
yuuji@0 3341 BAD - command unknown or arguments invalid
yuuji@0 3342
yuuji@0 3343 The UID command has two forms. In the first form, it takes as its
yuuji@0 3344 arguments a COPY, FETCH, or STORE command with arguments
yuuji@0 3345 appropriate for the associated command. However, the numbers in
yuuji@0 3346 the sequence set argument are unique identifiers instead of
yuuji@0 3347 message sequence numbers. Sequence set ranges are permitted, but
yuuji@0 3348 there is no guarantee that unique identifiers will be contiguous.
yuuji@0 3349
yuuji@0 3350 A non-existent unique identifier is ignored without any error
yuuji@0 3351 message generated. Thus, it is possible for a UID FETCH command
yuuji@0 3352 to return an OK without any data or a UID COPY or UID STORE to
yuuji@0 3353 return an OK without performing any operations.
yuuji@0 3354
yuuji@0 3355 In the second form, the UID command takes a SEARCH command with
yuuji@0 3356 SEARCH command arguments. The interpretation of the arguments is
yuuji@0 3357 the same as with SEARCH; however, the numbers returned in a SEARCH
yuuji@0 3358 response for a UID SEARCH command are unique identifiers instead
yuuji@0 3359
yuuji@0 3360
yuuji@0 3361
yuuji@0 3362 Crispin Standards Track [Page 60]
yuuji@0 3363
yuuji@0 3364 RFC 3501 IMAPv4 March 2003
yuuji@0 3365
yuuji@0 3366
yuuji@0 3367 of message sequence numbers. For example, the command UID SEARCH
yuuji@0 3368 1:100 UID 443:557 returns the unique identifiers corresponding to
yuuji@0 3369 the intersection of two sequence sets, the message sequence number
yuuji@0 3370 range 1:100 and the UID range 443:557.
yuuji@0 3371
yuuji@0 3372 Note: in the above example, the UID range 443:557
yuuji@0 3373 appears. The same comment about a non-existent unique
yuuji@0 3374 identifier being ignored without any error message also
yuuji@0 3375 applies here. Hence, even if neither UID 443 or 557
yuuji@0 3376 exist, this range is valid and would include an existing
yuuji@0 3377 UID 495.
yuuji@0 3378
yuuji@0 3379 Also note that a UID range of 559:* always includes the
yuuji@0 3380 UID of the last message in the mailbox, even if 559 is
yuuji@0 3381 higher than any assigned UID value. This is because the
yuuji@0 3382 contents of a range are independent of the order of the
yuuji@0 3383 range endpoints. Thus, any UID range with * as one of
yuuji@0 3384 the endpoints indicates at least one message (the
yuuji@0 3385 message with the highest numbered UID), unless the
yuuji@0 3386 mailbox is empty.
yuuji@0 3387
yuuji@0 3388 The number after the "*" in an untagged FETCH response is always a
yuuji@0 3389 message sequence number, not a unique identifier, even for a UID
yuuji@0 3390 command response. However, server implementations MUST implicitly
yuuji@0 3391 include the UID message data item as part of any FETCH response
yuuji@0 3392 caused by a UID command, regardless of whether a UID was specified
yuuji@0 3393 as a message data item to the FETCH.
yuuji@0 3394
yuuji@0 3395
yuuji@0 3396 Note: The rule about including the UID message data item as part
yuuji@0 3397 of a FETCH response primarily applies to the UID FETCH and UID
yuuji@0 3398 STORE commands, including a UID FETCH command that does not
yuuji@0 3399 include UID as a message data item. Although it is unlikely that
yuuji@0 3400 the other UID commands will cause an untagged FETCH, this rule
yuuji@0 3401 applies to these commands as well.
yuuji@0 3402
yuuji@0 3403 Example: C: A999 UID FETCH 4827313:4828442 FLAGS
yuuji@0 3404 S: * 23 FETCH (FLAGS (\Seen) UID 4827313)
yuuji@0 3405 S: * 24 FETCH (FLAGS (\Seen) UID 4827943)
yuuji@0 3406 S: * 25 FETCH (FLAGS (\Seen) UID 4828442)
yuuji@0 3407 S: A999 OK UID FETCH completed
yuuji@0 3408
yuuji@0 3409
yuuji@0 3410
yuuji@0 3411
yuuji@0 3412
yuuji@0 3413
yuuji@0 3414
yuuji@0 3415
yuuji@0 3416
yuuji@0 3417
yuuji@0 3418 Crispin Standards Track [Page 61]
yuuji@0 3419
yuuji@0 3420 RFC 3501 IMAPv4 March 2003
yuuji@0 3421
yuuji@0 3422
yuuji@0 3423 6.5. Client Commands - Experimental/Expansion
yuuji@0 3424
yuuji@0 3425
yuuji@0 3426 6.5.1. X<atom> Command
yuuji@0 3427
yuuji@0 3428 Arguments: implementation defined
yuuji@0 3429
yuuji@0 3430 Responses: implementation defined
yuuji@0 3431
yuuji@0 3432 Result: OK - command completed
yuuji@0 3433 NO - failure
yuuji@0 3434 BAD - command unknown or arguments invalid
yuuji@0 3435
yuuji@0 3436 Any command prefixed with an X is an experimental command.
yuuji@0 3437 Commands which are not part of this specification, a standard or
yuuji@0 3438 standards-track revision of this specification, or an
yuuji@0 3439 IESG-approved experimental protocol, MUST use the X prefix.
yuuji@0 3440
yuuji@0 3441 Any added untagged responses issued by an experimental command
yuuji@0 3442 MUST also be prefixed with an X. Server implementations MUST NOT
yuuji@0 3443 send any such untagged responses, unless the client requested it
yuuji@0 3444 by issuing the associated experimental command.
yuuji@0 3445
yuuji@0 3446 Example: C: a441 CAPABILITY
yuuji@0 3447 S: * CAPABILITY IMAP4rev1 XPIG-LATIN
yuuji@0 3448 S: a441 OK CAPABILITY completed
yuuji@0 3449 C: A442 XPIG-LATIN
yuuji@0 3450 S: * XPIG-LATIN ow-nay eaking-spay ig-pay atin-lay
yuuji@0 3451 S: A442 OK XPIG-LATIN ompleted-cay
yuuji@0 3452
yuuji@0 3453 7. Server Responses
yuuji@0 3454
yuuji@0 3455 Server responses are in three forms: status responses, server data,
yuuji@0 3456 and command continuation request. The information contained in a
yuuji@0 3457 server response, identified by "Contents:" in the response
yuuji@0 3458 descriptions below, is described by function, not by syntax. The
yuuji@0 3459 precise syntax of server responses is described in the Formal Syntax
yuuji@0 3460 section.
yuuji@0 3461
yuuji@0 3462 The client MUST be prepared to accept any response at all times.
yuuji@0 3463
yuuji@0 3464 Status responses can be tagged or untagged. Tagged status responses
yuuji@0 3465 indicate the completion result (OK, NO, or BAD status) of a client
yuuji@0 3466 command, and have a tag matching the command.
yuuji@0 3467
yuuji@0 3468 Some status responses, and all server data, are untagged. An
yuuji@0 3469 untagged response is indicated by the token "*" instead of a tag.
yuuji@0 3470 Untagged status responses indicate server greeting, or server status
yuuji@0 3471
yuuji@0 3472
yuuji@0 3473
yuuji@0 3474 Crispin Standards Track [Page 62]
yuuji@0 3475
yuuji@0 3476 RFC 3501 IMAPv4 March 2003
yuuji@0 3477
yuuji@0 3478
yuuji@0 3479 that does not indicate the completion of a command (for example, an
yuuji@0 3480 impending system shutdown alert). For historical reasons, untagged
yuuji@0 3481 server data responses are also called "unsolicited data", although
yuuji@0 3482 strictly speaking, only unilateral server data is truly
yuuji@0 3483 "unsolicited".
yuuji@0 3484
yuuji@0 3485 Certain server data MUST be recorded by the client when it is
yuuji@0 3486 received; this is noted in the description of that data. Such data
yuuji@0 3487 conveys critical information which affects the interpretation of all
yuuji@0 3488 subsequent commands and responses (e.g., updates reflecting the
yuuji@0 3489 creation or destruction of messages).
yuuji@0 3490
yuuji@0 3491 Other server data SHOULD be recorded for later reference; if the
yuuji@0 3492 client does not need to record the data, or if recording the data has
yuuji@0 3493 no obvious purpose (e.g., a SEARCH response when no SEARCH command is
yuuji@0 3494 in progress), the data SHOULD be ignored.
yuuji@0 3495
yuuji@0 3496 An example of unilateral untagged server data occurs when the IMAP
yuuji@0 3497 connection is in the selected state. In the selected state, the
yuuji@0 3498 server checks the mailbox for new messages as part of command
yuuji@0 3499 execution. Normally, this is part of the execution of every command;
yuuji@0 3500 hence, a NOOP command suffices to check for new messages. If new
yuuji@0 3501 messages are found, the server sends untagged EXISTS and RECENT
yuuji@0 3502 responses reflecting the new size of the mailbox. Server
yuuji@0 3503 implementations that offer multiple simultaneous access to the same
yuuji@0 3504 mailbox SHOULD also send appropriate unilateral untagged FETCH and
yuuji@0 3505 EXPUNGE responses if another agent changes the state of any message
yuuji@0 3506 flags or expunges any messages.
yuuji@0 3507
yuuji@0 3508 Command continuation request responses use the token "+" instead of a
yuuji@0 3509 tag. These responses are sent by the server to indicate acceptance
yuuji@0 3510 of an incomplete client command and readiness for the remainder of
yuuji@0 3511 the command.
yuuji@0 3512
yuuji@0 3513 7.1. Server Responses - Status Responses
yuuji@0 3514
yuuji@0 3515 Status responses are OK, NO, BAD, PREAUTH and BYE. OK, NO, and BAD
yuuji@0 3516 can be tagged or untagged. PREAUTH and BYE are always untagged.
yuuji@0 3517
yuuji@0 3518 Status responses MAY include an OPTIONAL "response code". A response
yuuji@0 3519 code consists of data inside square brackets in the form of an atom,
yuuji@0 3520 possibly followed by a space and arguments. The response code
yuuji@0 3521 contains additional information or status codes for client software
yuuji@0 3522 beyond the OK/NO/BAD condition, and are defined when there is a
yuuji@0 3523 specific action that a client can take based upon the additional
yuuji@0 3524 information.
yuuji@0 3525
yuuji@0 3526
yuuji@0 3527
yuuji@0 3528
yuuji@0 3529
yuuji@0 3530 Crispin Standards Track [Page 63]
yuuji@0 3531
yuuji@0 3532 RFC 3501 IMAPv4 March 2003
yuuji@0 3533
yuuji@0 3534
yuuji@0 3535 The currently defined response codes are:
yuuji@0 3536
yuuji@0 3537 ALERT
yuuji@0 3538
yuuji@0 3539 The human-readable text contains a special alert that MUST be
yuuji@0 3540 presented to the user in a fashion that calls the user's
yuuji@0 3541 attention to the message.
yuuji@0 3542
yuuji@0 3543 BADCHARSET
yuuji@0 3544
yuuji@0 3545 Optionally followed by a parenthesized list of charsets. A
yuuji@0 3546 SEARCH failed because the given charset is not supported by
yuuji@0 3547 this implementation. If the optional list of charsets is
yuuji@0 3548 given, this lists the charsets that are supported by this
yuuji@0 3549 implementation.
yuuji@0 3550
yuuji@0 3551 CAPABILITY
yuuji@0 3552
yuuji@0 3553 Followed by a list of capabilities. This can appear in the
yuuji@0 3554 initial OK or PREAUTH response to transmit an initial
yuuji@0 3555 capabilities list. This makes it unnecessary for a client to
yuuji@0 3556 send a separate CAPABILITY command if it recognizes this
yuuji@0 3557 response.
yuuji@0 3558
yuuji@0 3559 PARSE
yuuji@0 3560
yuuji@0 3561 The human-readable text represents an error in parsing the
yuuji@0 3562 [RFC-2822] header or [MIME-IMB] headers of a message in the
yuuji@0 3563 mailbox.
yuuji@0 3564
yuuji@0 3565 PERMANENTFLAGS
yuuji@0 3566
yuuji@0 3567 Followed by a parenthesized list of flags, indicates which of
yuuji@0 3568 the known flags the client can change permanently. Any flags
yuuji@0 3569 that are in the FLAGS untagged response, but not the
yuuji@0 3570 PERMANENTFLAGS list, can not be set permanently. If the client
yuuji@0 3571 attempts to STORE a flag that is not in the PERMANENTFLAGS
yuuji@0 3572 list, the server will either ignore the change or store the
yuuji@0 3573 state change for the remainder of the current session only.
yuuji@0 3574 The PERMANENTFLAGS list can also include the special flag \*,
yuuji@0 3575 which indicates that it is possible to create new keywords by
yuuji@0 3576 attempting to store those flags in the mailbox.
yuuji@0 3577
yuuji@0 3578
yuuji@0 3579
yuuji@0 3580
yuuji@0 3581
yuuji@0 3582
yuuji@0 3583
yuuji@0 3584
yuuji@0 3585
yuuji@0 3586 Crispin Standards Track [Page 64]
yuuji@0 3587
yuuji@0 3588 RFC 3501 IMAPv4 March 2003
yuuji@0 3589
yuuji@0 3590
yuuji@0 3591 READ-ONLY
yuuji@0 3592
yuuji@0 3593 The mailbox is selected read-only, or its access while selected
yuuji@0 3594 has changed from read-write to read-only.
yuuji@0 3595
yuuji@0 3596 READ-WRITE
yuuji@0 3597
yuuji@0 3598 The mailbox is selected read-write, or its access while
yuuji@0 3599 selected has changed from read-only to read-write.
yuuji@0 3600
yuuji@0 3601 TRYCREATE
yuuji@0 3602
yuuji@0 3603 An APPEND or COPY attempt is failing because the target mailbox
yuuji@0 3604 does not exist (as opposed to some other reason). This is a
yuuji@0 3605 hint to the client that the operation can succeed if the
yuuji@0 3606 mailbox is first created by the CREATE command.
yuuji@0 3607
yuuji@0 3608 UIDNEXT
yuuji@0 3609
yuuji@0 3610 Followed by a decimal number, indicates the next unique
yuuji@0 3611 identifier value. Refer to section 2.3.1.1 for more
yuuji@0 3612 information.
yuuji@0 3613
yuuji@0 3614 UIDVALIDITY
yuuji@0 3615
yuuji@0 3616 Followed by a decimal number, indicates the unique identifier
yuuji@0 3617 validity value. Refer to section 2.3.1.1 for more information.
yuuji@0 3618
yuuji@0 3619 UNSEEN
yuuji@0 3620
yuuji@0 3621 Followed by a decimal number, indicates the number of the first
yuuji@0 3622 message without the \Seen flag set.
yuuji@0 3623
yuuji@0 3624 Additional response codes defined by particular client or server
yuuji@0 3625 implementations SHOULD be prefixed with an "X" until they are
yuuji@0 3626 added to a revision of this protocol. Client implementations
yuuji@0 3627 SHOULD ignore response codes that they do not recognize.
yuuji@0 3628
yuuji@0 3629 7.1.1. OK Response
yuuji@0 3630
yuuji@0 3631 Contents: OPTIONAL response code
yuuji@0 3632 human-readable text
yuuji@0 3633
yuuji@0 3634 The OK response indicates an information message from the server.
yuuji@0 3635 When tagged, it indicates successful completion of the associated
yuuji@0 3636 command. The human-readable text MAY be presented to the user as
yuuji@0 3637 an information message. The untagged form indicates an
yuuji@0 3638
yuuji@0 3639
yuuji@0 3640
yuuji@0 3641
yuuji@0 3642 Crispin Standards Track [Page 65]
yuuji@0 3643
yuuji@0 3644 RFC 3501 IMAPv4 March 2003
yuuji@0 3645
yuuji@0 3646
yuuji@0 3647 information-only message; the nature of the information MAY be
yuuji@0 3648 indicated by a response code.
yuuji@0 3649
yuuji@0 3650 The untagged form is also used as one of three possible greetings
yuuji@0 3651 at connection startup. It indicates that the connection is not
yuuji@0 3652 yet authenticated and that a LOGIN command is needed.
yuuji@0 3653
yuuji@0 3654 Example: S: * OK IMAP4rev1 server ready
yuuji@0 3655 C: A001 LOGIN fred blurdybloop
yuuji@0 3656 S: * OK [ALERT] System shutdown in 10 minutes
yuuji@0 3657 S: A001 OK LOGIN Completed
yuuji@0 3658
yuuji@0 3659
yuuji@0 3660 7.1.2. NO Response
yuuji@0 3661
yuuji@0 3662 Contents: OPTIONAL response code
yuuji@0 3663 human-readable text
yuuji@0 3664
yuuji@0 3665 The NO response indicates an operational error message from the
yuuji@0 3666 server. When tagged, it indicates unsuccessful completion of the
yuuji@0 3667 associated command. The untagged form indicates a warning; the
yuuji@0 3668 command can still complete successfully. The human-readable text
yuuji@0 3669 describes the condition.
yuuji@0 3670
yuuji@0 3671 Example: C: A222 COPY 1:2 owatagusiam
yuuji@0 3672 S: * NO Disk is 98% full, please delete unnecessary data
yuuji@0 3673 S: A222 OK COPY completed
yuuji@0 3674 C: A223 COPY 3:200 blurdybloop
yuuji@0 3675 S: * NO Disk is 98% full, please delete unnecessary data
yuuji@0 3676 S: * NO Disk is 99% full, please delete unnecessary data
yuuji@0 3677 S: A223 NO COPY failed: disk is full
yuuji@0 3678
yuuji@0 3679
yuuji@0 3680 7.1.3. BAD Response
yuuji@0 3681
yuuji@0 3682 Contents: OPTIONAL response code
yuuji@0 3683 human-readable text
yuuji@0 3684
yuuji@0 3685 The BAD response indicates an error message from the server. When
yuuji@0 3686 tagged, it reports a protocol-level error in the client's command;
yuuji@0 3687 the tag indicates the command that caused the error. The untagged
yuuji@0 3688 form indicates a protocol-level error for which the associated
yuuji@0 3689 command can not be determined; it can also indicate an internal
yuuji@0 3690 server failure. The human-readable text describes the condition.
yuuji@0 3691
yuuji@0 3692
yuuji@0 3693
yuuji@0 3694
yuuji@0 3695
yuuji@0 3696
yuuji@0 3697
yuuji@0 3698 Crispin Standards Track [Page 66]
yuuji@0 3699
yuuji@0 3700 RFC 3501 IMAPv4 March 2003
yuuji@0 3701
yuuji@0 3702
yuuji@0 3703 Example: C: ...very long command line...
yuuji@0 3704 S: * BAD Command line too long
yuuji@0 3705 C: ...empty line...
yuuji@0 3706 S: * BAD Empty command line
yuuji@0 3707 C: A443 EXPUNGE
yuuji@0 3708 S: * BAD Disk crash, attempting salvage to a new disk!
yuuji@0 3709 S: * OK Salvage successful, no data lost
yuuji@0 3710 S: A443 OK Expunge completed
yuuji@0 3711
yuuji@0 3712
yuuji@0 3713 7.1.4. PREAUTH Response
yuuji@0 3714
yuuji@0 3715 Contents: OPTIONAL response code
yuuji@0 3716 human-readable text
yuuji@0 3717
yuuji@0 3718 The PREAUTH response is always untagged, and is one of three
yuuji@0 3719 possible greetings at connection startup. It indicates that the
yuuji@0 3720 connection has already been authenticated by external means; thus
yuuji@0 3721 no LOGIN command is needed.
yuuji@0 3722
yuuji@0 3723 Example: S: * PREAUTH IMAP4rev1 server logged in as Smith
yuuji@0 3724
yuuji@0 3725
yuuji@0 3726 7.1.5. BYE Response
yuuji@0 3727
yuuji@0 3728 Contents: OPTIONAL response code
yuuji@0 3729 human-readable text
yuuji@0 3730
yuuji@0 3731 The BYE response is always untagged, and indicates that the server
yuuji@0 3732 is about to close the connection. The human-readable text MAY be
yuuji@0 3733 displayed to the user in a status report by the client. The BYE
yuuji@0 3734 response is sent under one of four conditions:
yuuji@0 3735
yuuji@0 3736 1) as part of a normal logout sequence. The server will close
yuuji@0 3737 the connection after sending the tagged OK response to the
yuuji@0 3738 LOGOUT command.
yuuji@0 3739
yuuji@0 3740 2) as a panic shutdown announcement. The server closes the
yuuji@0 3741 connection immediately.
yuuji@0 3742
yuuji@0 3743 3) as an announcement of an inactivity autologout. The server
yuuji@0 3744 closes the connection immediately.
yuuji@0 3745
yuuji@0 3746 4) as one of three possible greetings at connection startup,
yuuji@0 3747 indicating that the server is not willing to accept a
yuuji@0 3748 connection from this client. The server closes the
yuuji@0 3749 connection immediately.
yuuji@0 3750
yuuji@0 3751
yuuji@0 3752
yuuji@0 3753
yuuji@0 3754 Crispin Standards Track [Page 67]
yuuji@0 3755
yuuji@0 3756 RFC 3501 IMAPv4 March 2003
yuuji@0 3757
yuuji@0 3758
yuuji@0 3759 The difference between a BYE that occurs as part of a normal
yuuji@0 3760 LOGOUT sequence (the first case) and a BYE that occurs because of
yuuji@0 3761 a failure (the other three cases) is that the connection closes
yuuji@0 3762 immediately in the failure case. In all cases the client SHOULD
yuuji@0 3763 continue to read response data from the server until the
yuuji@0 3764 connection is closed; this will ensure that any pending untagged
yuuji@0 3765 or completion responses are read and processed.
yuuji@0 3766
yuuji@0 3767 Example: S: * BYE Autologout; idle for too long
yuuji@0 3768
yuuji@0 3769 7.2. Server Responses - Server and Mailbox Status
yuuji@0 3770
yuuji@0 3771 These responses are always untagged. This is how server and mailbox
yuuji@0 3772 status data are transmitted from the server to the client. Many of
yuuji@0 3773 these responses typically result from a command with the same name.
yuuji@0 3774
yuuji@0 3775 7.2.1. CAPABILITY Response
yuuji@0 3776
yuuji@0 3777 Contents: capability listing
yuuji@0 3778
yuuji@0 3779 The CAPABILITY response occurs as a result of a CAPABILITY
yuuji@0 3780 command. The capability listing contains a space-separated
yuuji@0 3781 listing of capability names that the server supports. The
yuuji@0 3782 capability listing MUST include the atom "IMAP4rev1".
yuuji@0 3783
yuuji@0 3784 In addition, client and server implementations MUST implement the
yuuji@0 3785 STARTTLS, LOGINDISABLED, and AUTH=PLAIN (described in [IMAP-TLS])
yuuji@0 3786 capabilities. See the Security Considerations section for
yuuji@0 3787 important information.
yuuji@0 3788
yuuji@0 3789 A capability name which begins with "AUTH=" indicates that the
yuuji@0 3790 server supports that particular authentication mechanism.
yuuji@0 3791
yuuji@0 3792 The LOGINDISABLED capability indicates that the LOGIN command is
yuuji@0 3793 disabled, and that the server will respond with a tagged NO
yuuji@0 3794 response to any attempt to use the LOGIN command even if the user
yuuji@0 3795 name and password are valid. An IMAP client MUST NOT issue the
yuuji@0 3796 LOGIN command if the server advertises the LOGINDISABLED
yuuji@0 3797 capability.
yuuji@0 3798
yuuji@0 3799 Other capability names indicate that the server supports an
yuuji@0 3800 extension, revision, or amendment to the IMAP4rev1 protocol.
yuuji@0 3801 Server responses MUST conform to this document until the client
yuuji@0 3802 issues a command that uses the associated capability.
yuuji@0 3803
yuuji@0 3804 Capability names MUST either begin with "X" or be standard or
yuuji@0 3805 standards-track IMAP4rev1 extensions, revisions, or amendments
yuuji@0 3806 registered with IANA. A server MUST NOT offer unregistered or
yuuji@0 3807
yuuji@0 3808
yuuji@0 3809
yuuji@0 3810 Crispin Standards Track [Page 68]
yuuji@0 3811
yuuji@0 3812 RFC 3501 IMAPv4 March 2003
yuuji@0 3813
yuuji@0 3814
yuuji@0 3815 non-standard capability names, unless such names are prefixed with
yuuji@0 3816 an "X".
yuuji@0 3817
yuuji@0 3818 Client implementations SHOULD NOT require any capability name
yuuji@0 3819 other than "IMAP4rev1", and MUST ignore any unknown capability
yuuji@0 3820 names.
yuuji@0 3821
yuuji@0 3822 A server MAY send capabilities automatically, by using the
yuuji@0 3823 CAPABILITY response code in the initial PREAUTH or OK responses,
yuuji@0 3824 and by sending an updated CAPABILITY response code in the tagged
yuuji@0 3825 OK response as part of a successful authentication. It is
yuuji@0 3826 unnecessary for a client to send a separate CAPABILITY command if
yuuji@0 3827 it recognizes these automatic capabilities.
yuuji@0 3828
yuuji@0 3829 Example: S: * CAPABILITY IMAP4rev1 STARTTLS AUTH=GSSAPI XPIG-LATIN
yuuji@0 3830
yuuji@0 3831
yuuji@0 3832 7.2.2. LIST Response
yuuji@0 3833
yuuji@0 3834 Contents: name attributes
yuuji@0 3835 hierarchy delimiter
yuuji@0 3836 name
yuuji@0 3837
yuuji@0 3838 The LIST response occurs as a result of a LIST command. It
yuuji@0 3839 returns a single name that matches the LIST specification. There
yuuji@0 3840 can be multiple LIST responses for a single LIST command.
yuuji@0 3841
yuuji@0 3842 Four name attributes are defined:
yuuji@0 3843
yuuji@0 3844 \Noinferiors
yuuji@0 3845 It is not possible for any child levels of hierarchy to exist
yuuji@0 3846 under this name; no child levels exist now and none can be
yuuji@0 3847 created in the future.
yuuji@0 3848
yuuji@0 3849 \Noselect
yuuji@0 3850 It is not possible to use this name as a selectable mailbox.
yuuji@0 3851
yuuji@0 3852 \Marked
yuuji@0 3853 The mailbox has been marked "interesting" by the server; the
yuuji@0 3854 mailbox probably contains messages that have been added since
yuuji@0 3855 the last time the mailbox was selected.
yuuji@0 3856
yuuji@0 3857 \Unmarked
yuuji@0 3858 The mailbox does not contain any additional messages since the
yuuji@0 3859 last time the mailbox was selected.
yuuji@0 3860
yuuji@0 3861
yuuji@0 3862
yuuji@0 3863
yuuji@0 3864
yuuji@0 3865
yuuji@0 3866 Crispin Standards Track [Page 69]
yuuji@0 3867
yuuji@0 3868 RFC 3501 IMAPv4 March 2003
yuuji@0 3869
yuuji@0 3870
yuuji@0 3871 If it is not feasible for the server to determine whether or not
yuuji@0 3872 the mailbox is "interesting", or if the name is a \Noselect name,
yuuji@0 3873 the server SHOULD NOT send either \Marked or \Unmarked.
yuuji@0 3874
yuuji@0 3875 The hierarchy delimiter is a character used to delimit levels of
yuuji@0 3876 hierarchy in a mailbox name. A client can use it to create child
yuuji@0 3877 mailboxes, and to search higher or lower levels of naming
yuuji@0 3878 hierarchy. All children of a top-level hierarchy node MUST use
yuuji@0 3879 the same separator character. A NIL hierarchy delimiter means
yuuji@0 3880 that no hierarchy exists; the name is a "flat" name.
yuuji@0 3881
yuuji@0 3882 The name represents an unambiguous left-to-right hierarchy, and
yuuji@0 3883 MUST be valid for use as a reference in LIST and LSUB commands.
yuuji@0 3884 Unless \Noselect is indicated, the name MUST also be valid as an
yuuji@0 3885 argument for commands, such as SELECT, that accept mailbox names.
yuuji@0 3886
yuuji@0 3887 Example: S: * LIST (\Noselect) "/" ~/Mail/foo
yuuji@0 3888
yuuji@0 3889
yuuji@0 3890 7.2.3. LSUB Response
yuuji@0 3891
yuuji@0 3892 Contents: name attributes
yuuji@0 3893 hierarchy delimiter
yuuji@0 3894 name
yuuji@0 3895
yuuji@0 3896 The LSUB response occurs as a result of an LSUB command. It
yuuji@0 3897 returns a single name that matches the LSUB specification. There
yuuji@0 3898 can be multiple LSUB responses for a single LSUB command. The
yuuji@0 3899 data is identical in format to the LIST response.
yuuji@0 3900
yuuji@0 3901 Example: S: * LSUB () "." #news.comp.mail.misc
yuuji@0 3902
yuuji@0 3903
yuuji@0 3904 7.2.4 STATUS Response
yuuji@0 3905
yuuji@0 3906 Contents: name
yuuji@0 3907 status parenthesized list
yuuji@0 3908
yuuji@0 3909 The STATUS response occurs as a result of an STATUS command. It
yuuji@0 3910 returns the mailbox name that matches the STATUS specification and
yuuji@0 3911 the requested mailbox status information.
yuuji@0 3912
yuuji@0 3913 Example: S: * STATUS blurdybloop (MESSAGES 231 UIDNEXT 44292)
yuuji@0 3914
yuuji@0 3915
yuuji@0 3916
yuuji@0 3917
yuuji@0 3918
yuuji@0 3919
yuuji@0 3920
yuuji@0 3921
yuuji@0 3922 Crispin Standards Track [Page 70]
yuuji@0 3923
yuuji@0 3924 RFC 3501 IMAPv4 March 2003
yuuji@0 3925
yuuji@0 3926
yuuji@0 3927 7.2.5. SEARCH Response
yuuji@0 3928
yuuji@0 3929 Contents: zero or more numbers
yuuji@0 3930
yuuji@0 3931 The SEARCH response occurs as a result of a SEARCH or UID SEARCH
yuuji@0 3932 command. The number(s) refer to those messages that match the
yuuji@0 3933 search criteria. For SEARCH, these are message sequence numbers;
yuuji@0 3934 for UID SEARCH, these are unique identifiers. Each number is
yuuji@0 3935 delimited by a space.
yuuji@0 3936
yuuji@0 3937 Example: S: * SEARCH 2 3 6
yuuji@0 3938
yuuji@0 3939
yuuji@0 3940 7.2.6. FLAGS Response
yuuji@0 3941
yuuji@0 3942 Contents: flag parenthesized list
yuuji@0 3943
yuuji@0 3944 The FLAGS response occurs as a result of a SELECT or EXAMINE
yuuji@0 3945 command. The flag parenthesized list identifies the flags (at a
yuuji@0 3946 minimum, the system-defined flags) that are applicable for this
yuuji@0 3947 mailbox. Flags other than the system flags can also exist,
yuuji@0 3948 depending on server implementation.
yuuji@0 3949
yuuji@0 3950 The update from the FLAGS response MUST be recorded by the client.
yuuji@0 3951
yuuji@0 3952 Example: S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
yuuji@0 3953
yuuji@0 3954
yuuji@0 3955 7.3. Server Responses - Mailbox Size
yuuji@0 3956
yuuji@0 3957 These responses are always untagged. This is how changes in the size
yuuji@0 3958 of the mailbox are transmitted from the server to the client.
yuuji@0 3959 Immediately following the "*" token is a number that represents a
yuuji@0 3960 message count.
yuuji@0 3961
yuuji@0 3962 7.3.1. EXISTS Response
yuuji@0 3963
yuuji@0 3964 Contents: none
yuuji@0 3965
yuuji@0 3966 The EXISTS response reports the number of messages in the mailbox.
yuuji@0 3967 This response occurs as a result of a SELECT or EXAMINE command,
yuuji@0 3968 and if the size of the mailbox changes (e.g., new messages).
yuuji@0 3969
yuuji@0 3970 The update from the EXISTS response MUST be recorded by the
yuuji@0 3971 client.
yuuji@0 3972
yuuji@0 3973 Example: S: * 23 EXISTS
yuuji@0 3974
yuuji@0 3975
yuuji@0 3976
yuuji@0 3977
yuuji@0 3978 Crispin Standards Track [Page 71]
yuuji@0 3979
yuuji@0 3980 RFC 3501 IMAPv4 March 2003
yuuji@0 3981
yuuji@0 3982
yuuji@0 3983 7.3.2. RECENT Response
yuuji@0 3984
yuuji@0 3985 Contents: none
yuuji@0 3986
yuuji@0 3987 The RECENT response reports the number of messages with the
yuuji@0 3988 \Recent flag set. This response occurs as a result of a SELECT or
yuuji@0 3989 EXAMINE command, and if the size of the mailbox changes (e.g., new
yuuji@0 3990 messages).
yuuji@0 3991
yuuji@0 3992 Note: It is not guaranteed that the message sequence
yuuji@0 3993 numbers of recent messages will be a contiguous range of
yuuji@0 3994 the highest n messages in the mailbox (where n is the
yuuji@0 3995 value reported by the RECENT response). Examples of
yuuji@0 3996 situations in which this is not the case are: multiple
yuuji@0 3997 clients having the same mailbox open (the first session
yuuji@0 3998 to be notified will see it as recent, others will
yuuji@0 3999 probably see it as non-recent), and when the mailbox is
yuuji@0 4000 re-ordered by a non-IMAP agent.
yuuji@0 4001
yuuji@0 4002 The only reliable way to identify recent messages is to
yuuji@0 4003 look at message flags to see which have the \Recent flag
yuuji@0 4004 set, or to do a SEARCH RECENT.
yuuji@0 4005
yuuji@0 4006 The update from the RECENT response MUST be recorded by the
yuuji@0 4007 client.
yuuji@0 4008
yuuji@0 4009 Example: S: * 5 RECENT
yuuji@0 4010
yuuji@0 4011
yuuji@0 4012 7.4. Server Responses - Message Status
yuuji@0 4013
yuuji@0 4014 These responses are always untagged. This is how message data are
yuuji@0 4015 transmitted from the server to the client, often as a result of a
yuuji@0 4016 command with the same name. Immediately following the "*" token is a
yuuji@0 4017 number that represents a message sequence number.
yuuji@0 4018
yuuji@0 4019 7.4.1. EXPUNGE Response
yuuji@0 4020
yuuji@0 4021 Contents: none
yuuji@0 4022
yuuji@0 4023 The EXPUNGE response reports that the specified message sequence
yuuji@0 4024 number has been permanently removed from the mailbox. The message
yuuji@0 4025 sequence number for each successive message in the mailbox is
yuuji@0 4026 immediately decremented by 1, and this decrement is reflected in
yuuji@0 4027 message sequence numbers in subsequent responses (including other
yuuji@0 4028 untagged EXPUNGE responses).
yuuji@0 4029
yuuji@0 4030
yuuji@0 4031
yuuji@0 4032
yuuji@0 4033
yuuji@0 4034 Crispin Standards Track [Page 72]
yuuji@0 4035
yuuji@0 4036 RFC 3501 IMAPv4 March 2003
yuuji@0 4037
yuuji@0 4038
yuuji@0 4039 The EXPUNGE response also decrements the number of messages in the
yuuji@0 4040 mailbox; it is not necessary to send an EXISTS response with the
yuuji@0 4041 new value.
yuuji@0 4042
yuuji@0 4043 As a result of the immediate decrement rule, message sequence
yuuji@0 4044 numbers that appear in a set of successive EXPUNGE responses
yuuji@0 4045 depend upon whether the messages are removed starting from lower
yuuji@0 4046 numbers to higher numbers, or from higher numbers to lower
yuuji@0 4047 numbers. For example, if the last 5 messages in a 9-message
yuuji@0 4048 mailbox are expunged, a "lower to higher" server will send five
yuuji@0 4049 untagged EXPUNGE responses for message sequence number 5, whereas
yuuji@0 4050 a "higher to lower server" will send successive untagged EXPUNGE
yuuji@0 4051 responses for message sequence numbers 9, 8, 7, 6, and 5.
yuuji@0 4052
yuuji@0 4053 An EXPUNGE response MUST NOT be sent when no command is in
yuuji@0 4054 progress, nor while responding to a FETCH, STORE, or SEARCH
yuuji@0 4055 command. This rule is necessary to prevent a loss of
yuuji@0 4056 synchronization of message sequence numbers between client and
yuuji@0 4057 server. A command is not "in progress" until the complete command
yuuji@0 4058 has been received; in particular, a command is not "in progress"
yuuji@0 4059 during the negotiation of command continuation.
yuuji@0 4060
yuuji@0 4061 Note: UID FETCH, UID STORE, and UID SEARCH are different
yuuji@0 4062 commands from FETCH, STORE, and SEARCH. An EXPUNGE
yuuji@0 4063 response MAY be sent during a UID command.
yuuji@0 4064
yuuji@0 4065 The update from the EXPUNGE response MUST be recorded by the
yuuji@0 4066 client.
yuuji@0 4067
yuuji@0 4068 Example: S: * 44 EXPUNGE
yuuji@0 4069
yuuji@0 4070
yuuji@0 4071 7.4.2. FETCH Response
yuuji@0 4072
yuuji@0 4073 Contents: message data
yuuji@0 4074
yuuji@0 4075 The FETCH response returns data about a message to the client.
yuuji@0 4076 The data are pairs of data item names and their values in
yuuji@0 4077 parentheses. This response occurs as the result of a FETCH or
yuuji@0 4078 STORE command, as well as by unilateral server decision (e.g.,
yuuji@0 4079 flag updates).
yuuji@0 4080
yuuji@0 4081 The current data items are:
yuuji@0 4082
yuuji@0 4083 BODY
yuuji@0 4084 A form of BODYSTRUCTURE without extension data.
yuuji@0 4085
yuuji@0 4086
yuuji@0 4087
yuuji@0 4088
yuuji@0 4089
yuuji@0 4090 Crispin Standards Track [Page 73]
yuuji@0 4091
yuuji@0 4092 RFC 3501 IMAPv4 March 2003
yuuji@0 4093
yuuji@0 4094
yuuji@0 4095 BODY[<section>]<<origin octet>>
yuuji@0 4096 A string expressing the body contents of the specified section.
yuuji@0 4097 The string SHOULD be interpreted by the client according to the
yuuji@0 4098 content transfer encoding, body type, and subtype.
yuuji@0 4099
yuuji@0 4100 If the origin octet is specified, this string is a substring of
yuuji@0 4101 the entire body contents, starting at that origin octet. This
yuuji@0 4102 means that BODY[]<0> MAY be truncated, but BODY[] is NEVER
yuuji@0 4103 truncated.
yuuji@0 4104
yuuji@0 4105 Note: The origin octet facility MUST NOT be used by a server
yuuji@0 4106 in a FETCH response unless the client specifically requested
yuuji@0 4107 it by means of a FETCH of a BODY[<section>]<<partial>> data
yuuji@0 4108 item.
yuuji@0 4109
yuuji@0 4110 8-bit textual data is permitted if a [CHARSET] identifier is
yuuji@0 4111 part of the body parameter parenthesized list for this section.
yuuji@0 4112 Note that headers (part specifiers HEADER or MIME, or the
yuuji@0 4113 header portion of a MESSAGE/RFC822 part), MUST be 7-bit; 8-bit
yuuji@0 4114 characters are not permitted in headers. Note also that the
yuuji@0 4115 [RFC-2822] delimiting blank line between the header and the
yuuji@0 4116 body is not affected by header line subsetting; the blank line
yuuji@0 4117 is always included as part of header data, except in the case
yuuji@0 4118 of a message which has no body and no blank line.
yuuji@0 4119
yuuji@0 4120 Non-textual data such as binary data MUST be transfer encoded
yuuji@0 4121 into a textual form, such as BASE64, prior to being sent to the
yuuji@0 4122 client. To derive the original binary data, the client MUST
yuuji@0 4123 decode the transfer encoded string.
yuuji@0 4124
yuuji@0 4125 BODYSTRUCTURE
yuuji@0 4126 A parenthesized list that describes the [MIME-IMB] body
yuuji@0 4127 structure of a message. This is computed by the server by
yuuji@0 4128 parsing the [MIME-IMB] header fields, defaulting various fields
yuuji@0 4129 as necessary.
yuuji@0 4130
yuuji@0 4131 For example, a simple text message of 48 lines and 2279 octets
yuuji@0 4132 can have a body structure of: ("TEXT" "PLAIN" ("CHARSET"
yuuji@0 4133 "US-ASCII") NIL NIL "7BIT" 2279 48)
yuuji@0 4134
yuuji@0 4135 Multiple parts are indicated by parenthesis nesting. Instead
yuuji@0 4136 of a body type as the first element of the parenthesized list,
yuuji@0 4137 there is a sequence of one or more nested body structures. The
yuuji@0 4138 second element of the parenthesized list is the multipart
yuuji@0 4139 subtype (mixed, digest, parallel, alternative, etc.).
yuuji@0 4140
yuuji@0 4141
yuuji@0 4142
yuuji@0 4143
yuuji@0 4144
yuuji@0 4145
yuuji@0 4146 Crispin Standards Track [Page 74]
yuuji@0 4147
yuuji@0 4148 RFC 3501 IMAPv4 March 2003
yuuji@0 4149
yuuji@0 4150
yuuji@0 4151 For example, a two part message consisting of a text and a
yuuji@0 4152 BASE64-encoded text attachment can have a body structure of:
yuuji@0 4153 (("TEXT" "PLAIN" ("CHARSET" "US-ASCII") NIL NIL "7BIT" 1152
yuuji@0 4154 23)("TEXT" "PLAIN" ("CHARSET" "US-ASCII" "NAME" "cc.diff")
yuuji@0 4155 "<960723163407.20117h@cac.washington.edu>" "Compiler diff"
yuuji@0 4156 "BASE64" 4554 73) "MIXED")
yuuji@0 4157
yuuji@0 4158 Extension data follows the multipart subtype. Extension data
yuuji@0 4159 is never returned with the BODY fetch, but can be returned with
yuuji@0 4160 a BODYSTRUCTURE fetch. Extension data, if present, MUST be in
yuuji@0 4161 the defined order. The extension data of a multipart body part
yuuji@0 4162 are in the following order:
yuuji@0 4163
yuuji@0 4164 body parameter parenthesized list
yuuji@0 4165 A parenthesized list of attribute/value pairs [e.g., ("foo"
yuuji@0 4166 "bar" "baz" "rag") where "bar" is the value of "foo", and
yuuji@0 4167 "rag" is the value of "baz"] as defined in [MIME-IMB].
yuuji@0 4168
yuuji@0 4169 body disposition
yuuji@0 4170 A parenthesized list, consisting of a disposition type
yuuji@0 4171 string, followed by a parenthesized list of disposition
yuuji@0 4172 attribute/value pairs as defined in [DISPOSITION].
yuuji@0 4173
yuuji@0 4174 body language
yuuji@0 4175 A string or parenthesized list giving the body language
yuuji@0 4176 value as defined in [LANGUAGE-TAGS].
yuuji@0 4177
yuuji@0 4178 body location
yuuji@0 4179 A string list giving the body content URI as defined in
yuuji@0 4180 [LOCATION].
yuuji@0 4181
yuuji@0 4182 Any following extension data are not yet defined in this
yuuji@0 4183 version of the protocol. Such extension data can consist of
yuuji@0 4184 zero or more NILs, strings, numbers, or potentially nested
yuuji@0 4185 parenthesized lists of such data. Client implementations that
yuuji@0 4186 do a BODYSTRUCTURE fetch MUST be prepared to accept such
yuuji@0 4187 extension data. Server implementations MUST NOT send such
yuuji@0 4188 extension data until it has been defined by a revision of this
yuuji@0 4189 protocol.
yuuji@0 4190
yuuji@0 4191 The basic fields of a non-multipart body part are in the
yuuji@0 4192 following order:
yuuji@0 4193
yuuji@0 4194 body type
yuuji@0 4195 A string giving the content media type name as defined in
yuuji@0 4196 [MIME-IMB].
yuuji@0 4197
yuuji@0 4198
yuuji@0 4199
yuuji@0 4200
yuuji@0 4201
yuuji@0 4202 Crispin Standards Track [Page 75]
yuuji@0 4203
yuuji@0 4204 RFC 3501 IMAPv4 March 2003
yuuji@0 4205
yuuji@0 4206
yuuji@0 4207 body subtype
yuuji@0 4208 A string giving the content subtype name as defined in
yuuji@0 4209 [MIME-IMB].
yuuji@0 4210
yuuji@0 4211 body parameter parenthesized list
yuuji@0 4212 A parenthesized list of attribute/value pairs [e.g., ("foo"
yuuji@0 4213 "bar" "baz" "rag") where "bar" is the value of "foo" and
yuuji@0 4214 "rag" is the value of "baz"] as defined in [MIME-IMB].
yuuji@0 4215
yuuji@0 4216 body id
yuuji@0 4217 A string giving the content id as defined in [MIME-IMB].
yuuji@0 4218
yuuji@0 4219 body description
yuuji@0 4220 A string giving the content description as defined in
yuuji@0 4221 [MIME-IMB].
yuuji@0 4222
yuuji@0 4223 body encoding
yuuji@0 4224 A string giving the content transfer encoding as defined in
yuuji@0 4225 [MIME-IMB].
yuuji@0 4226
yuuji@0 4227 body size
yuuji@0 4228 A number giving the size of the body in octets. Note that
yuuji@0 4229 this size is the size in its transfer encoding and not the
yuuji@0 4230 resulting size after any decoding.
yuuji@0 4231
yuuji@0 4232 A body type of type MESSAGE and subtype RFC822 contains,
yuuji@0 4233 immediately after the basic fields, the envelope structure,
yuuji@0 4234 body structure, and size in text lines of the encapsulated
yuuji@0 4235 message.
yuuji@0 4236
yuuji@0 4237 A body type of type TEXT contains, immediately after the basic
yuuji@0 4238 fields, the size of the body in text lines. Note that this
yuuji@0 4239 size is the size in its content transfer encoding and not the
yuuji@0 4240 resulting size after any decoding.
yuuji@0 4241
yuuji@0 4242 Extension data follows the basic fields and the type-specific
yuuji@0 4243 fields listed above. Extension data is never returned with the
yuuji@0 4244 BODY fetch, but can be returned with a BODYSTRUCTURE fetch.
yuuji@0 4245 Extension data, if present, MUST be in the defined order.
yuuji@0 4246
yuuji@0 4247 The extension data of a non-multipart body part are in the
yuuji@0 4248 following order:
yuuji@0 4249
yuuji@0 4250 body MD5
yuuji@0 4251 A string giving the body MD5 value as defined in [MD5].
yuuji@0 4252
yuuji@0 4253
yuuji@0 4254
yuuji@0 4255
yuuji@0 4256
yuuji@0 4257
yuuji@0 4258 Crispin Standards Track [Page 76]
yuuji@0 4259
yuuji@0 4260 RFC 3501 IMAPv4 March 2003
yuuji@0 4261
yuuji@0 4262
yuuji@0 4263 body disposition
yuuji@0 4264 A parenthesized list with the same content and function as
yuuji@0 4265 the body disposition for a multipart body part.
yuuji@0 4266
yuuji@0 4267 body language
yuuji@0 4268 A string or parenthesized list giving the body language
yuuji@0 4269 value as defined in [LANGUAGE-TAGS].
yuuji@0 4270
yuuji@0 4271 body location
yuuji@0 4272 A string list giving the body content URI as defined in
yuuji@0 4273 [LOCATION].
yuuji@0 4274
yuuji@0 4275 Any following extension data are not yet defined in this
yuuji@0 4276 version of the protocol, and would be as described above under
yuuji@0 4277 multipart extension data.
yuuji@0 4278
yuuji@0 4279 ENVELOPE
yuuji@0 4280 A parenthesized list that describes the envelope structure of a
yuuji@0 4281 message. This is computed by the server by parsing the
yuuji@0 4282 [RFC-2822] header into the component parts, defaulting various
yuuji@0 4283 fields as necessary.
yuuji@0 4284
yuuji@0 4285 The fields of the envelope structure are in the following
yuuji@0 4286 order: date, subject, from, sender, reply-to, to, cc, bcc,
yuuji@0 4287 in-reply-to, and message-id. The date, subject, in-reply-to,
yuuji@0 4288 and message-id fields are strings. The from, sender, reply-to,
yuuji@0 4289 to, cc, and bcc fields are parenthesized lists of address
yuuji@0 4290 structures.
yuuji@0 4291
yuuji@0 4292 An address structure is a parenthesized list that describes an
yuuji@0 4293 electronic mail address. The fields of an address structure
yuuji@0 4294 are in the following order: personal name, [SMTP]
yuuji@0 4295 at-domain-list (source route), mailbox name, and host name.
yuuji@0 4296
yuuji@0 4297 [RFC-2822] group syntax is indicated by a special form of
yuuji@0 4298 address structure in which the host name field is NIL. If the
yuuji@0 4299 mailbox name field is also NIL, this is an end of group marker
yuuji@0 4300 (semi-colon in RFC 822 syntax). If the mailbox name field is
yuuji@0 4301 non-NIL, this is a start of group marker, and the mailbox name
yuuji@0 4302 field holds the group name phrase.
yuuji@0 4303
yuuji@0 4304 If the Date, Subject, In-Reply-To, and Message-ID header lines
yuuji@0 4305 are absent in the [RFC-2822] header, the corresponding member
yuuji@0 4306 of the envelope is NIL; if these header lines are present but
yuuji@0 4307 empty the corresponding member of the envelope is the empty
yuuji@0 4308 string.
yuuji@0 4309
yuuji@0 4310
yuuji@0 4311
yuuji@0 4312
yuuji@0 4313
yuuji@0 4314 Crispin Standards Track [Page 77]
yuuji@0 4315
yuuji@0 4316 RFC 3501 IMAPv4 March 2003
yuuji@0 4317
yuuji@0 4318
yuuji@0 4319 Note: some servers may return a NIL envelope member in the
yuuji@0 4320 "present but empty" case. Clients SHOULD treat NIL and
yuuji@0 4321 empty string as identical.
yuuji@0 4322
yuuji@0 4323 Note: [RFC-2822] requires that all messages have a valid
yuuji@0 4324 Date header. Therefore, the date member in the envelope can
yuuji@0 4325 not be NIL or the empty string.
yuuji@0 4326
yuuji@0 4327 Note: [RFC-2822] requires that the In-Reply-To and
yuuji@0 4328 Message-ID headers, if present, have non-empty content.
yuuji@0 4329 Therefore, the in-reply-to and message-id members in the
yuuji@0 4330 envelope can not be the empty string.
yuuji@0 4331
yuuji@0 4332 If the From, To, cc, and bcc header lines are absent in the
yuuji@0 4333 [RFC-2822] header, or are present but empty, the corresponding
yuuji@0 4334 member of the envelope is NIL.
yuuji@0 4335
yuuji@0 4336 If the Sender or Reply-To lines are absent in the [RFC-2822]
yuuji@0 4337 header, or are present but empty, the server sets the
yuuji@0 4338 corresponding member of the envelope to be the same value as
yuuji@0 4339 the from member (the client is not expected to know to do
yuuji@0 4340 this).
yuuji@0 4341
yuuji@0 4342 Note: [RFC-2822] requires that all messages have a valid
yuuji@0 4343 From header. Therefore, the from, sender, and reply-to
yuuji@0 4344 members in the envelope can not be NIL.
yuuji@0 4345
yuuji@0 4346 FLAGS
yuuji@0 4347 A parenthesized list of flags that are set for this message.
yuuji@0 4348
yuuji@0 4349 INTERNALDATE
yuuji@0 4350 A string representing the internal date of the message.
yuuji@0 4351
yuuji@0 4352 RFC822
yuuji@0 4353 Equivalent to BODY[].
yuuji@0 4354
yuuji@0 4355 RFC822.HEADER
yuuji@0 4356 Equivalent to BODY[HEADER]. Note that this did not result in
yuuji@0 4357 \Seen being set, because RFC822.HEADER response data occurs as
yuuji@0 4358 a result of a FETCH of RFC822.HEADER. BODY[HEADER] response
yuuji@0 4359 data occurs as a result of a FETCH of BODY[HEADER] (which sets
yuuji@0 4360 \Seen) or BODY.PEEK[HEADER] (which does not set \Seen).
yuuji@0 4361
yuuji@0 4362 RFC822.SIZE
yuuji@0 4363 A number expressing the [RFC-2822] size of the message.
yuuji@0 4364
yuuji@0 4365
yuuji@0 4366
yuuji@0 4367
yuuji@0 4368
yuuji@0 4369
yuuji@0 4370 Crispin Standards Track [Page 78]
yuuji@0 4371
yuuji@0 4372 RFC 3501 IMAPv4 March 2003
yuuji@0 4373
yuuji@0 4374
yuuji@0 4375 RFC822.TEXT
yuuji@0 4376 Equivalent to BODY[TEXT].
yuuji@0 4377
yuuji@0 4378 UID
yuuji@0 4379 A number expressing the unique identifier of the message.
yuuji@0 4380
yuuji@0 4381
yuuji@0 4382 Example: S: * 23 FETCH (FLAGS (\Seen) RFC822.SIZE 44827)
yuuji@0 4383
yuuji@0 4384
yuuji@0 4385 7.5. Server Responses - Command Continuation Request
yuuji@0 4386
yuuji@0 4387 The command continuation request response is indicated by a "+" token
yuuji@0 4388 instead of a tag. This form of response indicates that the server is
yuuji@0 4389 ready to accept the continuation of a command from the client. The
yuuji@0 4390 remainder of this response is a line of text.
yuuji@0 4391
yuuji@0 4392 This response is used in the AUTHENTICATE command to transmit server
yuuji@0 4393 data to the client, and request additional client data. This
yuuji@0 4394 response is also used if an argument to any command is a literal.
yuuji@0 4395
yuuji@0 4396 The client is not permitted to send the octets of the literal unless
yuuji@0 4397 the server indicates that it is expected. This permits the server to
yuuji@0 4398 process commands and reject errors on a line-by-line basis. The
yuuji@0 4399 remainder of the command, including the CRLF that terminates a
yuuji@0 4400 command, follows the octets of the literal. If there are any
yuuji@0 4401 additional command arguments, the literal octets are followed by a
yuuji@0 4402 space and those arguments.
yuuji@0 4403
yuuji@0 4404 Example: C: A001 LOGIN {11}
yuuji@0 4405 S: + Ready for additional command text
yuuji@0 4406 C: FRED FOOBAR {7}
yuuji@0 4407 S: + Ready for additional command text
yuuji@0 4408 C: fat man
yuuji@0 4409 S: A001 OK LOGIN completed
yuuji@0 4410 C: A044 BLURDYBLOOP {102856}
yuuji@0 4411 S: A044 BAD No such command as "BLURDYBLOOP"
yuuji@0 4412
yuuji@0 4413
yuuji@0 4414
yuuji@0 4415
yuuji@0 4416
yuuji@0 4417
yuuji@0 4418
yuuji@0 4419
yuuji@0 4420
yuuji@0 4421
yuuji@0 4422
yuuji@0 4423
yuuji@0 4424
yuuji@0 4425
yuuji@0 4426 Crispin Standards Track [Page 79]
yuuji@0 4427
yuuji@0 4428 RFC 3501 IMAPv4 March 2003
yuuji@0 4429
yuuji@0 4430
yuuji@0 4431 8. Sample IMAP4rev1 connection
yuuji@0 4432
yuuji@0 4433 The following is a transcript of an IMAP4rev1 connection. A long
yuuji@0 4434 line in this sample is broken for editorial clarity.
yuuji@0 4435
yuuji@0 4436 S: * OK IMAP4rev1 Service Ready
yuuji@0 4437 C: a001 login mrc secret
yuuji@0 4438 S: a001 OK LOGIN completed
yuuji@0 4439 C: a002 select inbox
yuuji@0 4440 S: * 18 EXISTS
yuuji@0 4441 S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
yuuji@0 4442 S: * 2 RECENT
yuuji@0 4443 S: * OK [UNSEEN 17] Message 17 is the first unseen message
yuuji@0 4444 S: * OK [UIDVALIDITY 3857529045] UIDs valid
yuuji@0 4445 S: a002 OK [READ-WRITE] SELECT completed
yuuji@0 4446 C: a003 fetch 12 full
yuuji@0 4447 S: * 12 FETCH (FLAGS (\Seen) INTERNALDATE "17-Jul-1996 02:44:25 -0700"
yuuji@0 4448 RFC822.SIZE 4286 ENVELOPE ("Wed, 17 Jul 1996 02:23:25 -0700 (PDT)"
yuuji@0 4449 "IMAP4rev1 WG mtg summary and minutes"
yuuji@0 4450 (("Terry Gray" NIL "gray" "cac.washington.edu"))
yuuji@0 4451 (("Terry Gray" NIL "gray" "cac.washington.edu"))
yuuji@0 4452 (("Terry Gray" NIL "gray" "cac.washington.edu"))
yuuji@0 4453 ((NIL NIL "imap" "cac.washington.edu"))
yuuji@0 4454 ((NIL NIL "minutes" "CNRI.Reston.VA.US")
yuuji@0 4455 ("John Klensin" NIL "KLENSIN" "MIT.EDU")) NIL NIL
yuuji@0 4456 "<B27397-0100000@cac.washington.edu>")
yuuji@0 4457 BODY ("TEXT" "PLAIN" ("CHARSET" "US-ASCII") NIL NIL "7BIT" 3028
yuuji@0 4458 92))
yuuji@0 4459 S: a003 OK FETCH completed
yuuji@0 4460 C: a004 fetch 12 body[header]
yuuji@0 4461 S: * 12 FETCH (BODY[HEADER] {342}
yuuji@0 4462 S: Date: Wed, 17 Jul 1996 02:23:25 -0700 (PDT)
yuuji@0 4463 S: From: Terry Gray <gray@cac.washington.edu>
yuuji@0 4464 S: Subject: IMAP4rev1 WG mtg summary and minutes
yuuji@0 4465 S: To: imap@cac.washington.edu
yuuji@0 4466 S: cc: minutes@CNRI.Reston.VA.US, John Klensin <KLENSIN@MIT.EDU>
yuuji@0 4467 S: Message-Id: <B27397-0100000@cac.washington.edu>
yuuji@0 4468 S: MIME-Version: 1.0
yuuji@0 4469 S: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
yuuji@0 4470 S:
yuuji@0 4471 S: )
yuuji@0 4472 S: a004 OK FETCH completed
yuuji@0 4473 C: a005 store 12 +flags \deleted
yuuji@0 4474 S: * 12 FETCH (FLAGS (\Seen \Deleted))
yuuji@0 4475 S: a005 OK +FLAGS completed
yuuji@0 4476 C: a006 logout
yuuji@0 4477 S: * BYE IMAP4rev1 server terminating connection
yuuji@0 4478 S: a006 OK LOGOUT completed
yuuji@0 4479
yuuji@0 4480
yuuji@0 4481
yuuji@0 4482 Crispin Standards Track [Page 80]
yuuji@0 4483
yuuji@0 4484 RFC 3501 IMAPv4 March 2003
yuuji@0 4485
yuuji@0 4486
yuuji@0 4487 9. Formal Syntax
yuuji@0 4488
yuuji@0 4489 The following syntax specification uses the Augmented Backus-Naur
yuuji@0 4490 Form (ABNF) notation as specified in [ABNF].
yuuji@0 4491
yuuji@0 4492 In the case of alternative or optional rules in which a later rule
yuuji@0 4493 overlaps an earlier rule, the rule which is listed earlier MUST take
yuuji@0 4494 priority. For example, "\Seen" when parsed as a flag is the \Seen
yuuji@0 4495 flag name and not a flag-extension, even though "\Seen" can be parsed
yuuji@0 4496 as a flag-extension. Some, but not all, instances of this rule are
yuuji@0 4497 noted below.
yuuji@0 4498
yuuji@0 4499 Note: [ABNF] rules MUST be followed strictly; in
yuuji@0 4500 particular:
yuuji@0 4501
yuuji@0 4502 (1) Except as noted otherwise, all alphabetic characters
yuuji@0 4503 are case-insensitive. The use of upper or lower case
yuuji@0 4504 characters to define token strings is for editorial clarity
yuuji@0 4505 only. Implementations MUST accept these strings in a
yuuji@0 4506 case-insensitive fashion.
yuuji@0 4507
yuuji@0 4508 (2) In all cases, SP refers to exactly one space. It is
yuuji@0 4509 NOT permitted to substitute TAB, insert additional spaces,
yuuji@0 4510 or otherwise treat SP as being equivalent to LWSP.
yuuji@0 4511
yuuji@0 4512 (3) The ASCII NUL character, %x00, MUST NOT be used at any
yuuji@0 4513 time.
yuuji@0 4514
yuuji@0 4515 address = "(" addr-name SP addr-adl SP addr-mailbox SP
yuuji@0 4516 addr-host ")"
yuuji@0 4517
yuuji@0 4518 addr-adl = nstring
yuuji@0 4519 ; Holds route from [RFC-2822] route-addr if
yuuji@0 4520 ; non-NIL
yuuji@0 4521
yuuji@0 4522 addr-host = nstring
yuuji@0 4523 ; NIL indicates [RFC-2822] group syntax.
yuuji@0 4524 ; Otherwise, holds [RFC-2822] domain name
yuuji@0 4525
yuuji@0 4526 addr-mailbox = nstring
yuuji@0 4527 ; NIL indicates end of [RFC-2822] group; if
yuuji@0 4528 ; non-NIL and addr-host is NIL, holds
yuuji@0 4529 ; [RFC-2822] group name.
yuuji@0 4530 ; Otherwise, holds [RFC-2822] local-part
yuuji@0 4531 ; after removing [RFC-2822] quoting
yuuji@0 4532
yuuji@0 4533
yuuji@0 4534
yuuji@0 4535
yuuji@0 4536
yuuji@0 4537
yuuji@0 4538 Crispin Standards Track [Page 81]
yuuji@0 4539
yuuji@0 4540 RFC 3501 IMAPv4 March 2003
yuuji@0 4541
yuuji@0 4542
yuuji@0 4543 addr-name = nstring
yuuji@0 4544 ; If non-NIL, holds phrase from [RFC-2822]
yuuji@0 4545 ; mailbox after removing [RFC-2822] quoting
yuuji@0 4546
yuuji@0 4547 append = "APPEND" SP mailbox [SP flag-list] [SP date-time] SP
yuuji@0 4548 literal
yuuji@0 4549
yuuji@0 4550 astring = 1*ASTRING-CHAR / string
yuuji@0 4551
yuuji@0 4552 ASTRING-CHAR = ATOM-CHAR / resp-specials
yuuji@0 4553
yuuji@0 4554 atom = 1*ATOM-CHAR
yuuji@0 4555
yuuji@0 4556 ATOM-CHAR = <any CHAR except atom-specials>
yuuji@0 4557
yuuji@0 4558 atom-specials = "(" / ")" / "{" / SP / CTL / list-wildcards /
yuuji@0 4559 quoted-specials / resp-specials
yuuji@0 4560
yuuji@0 4561 authenticate = "AUTHENTICATE" SP auth-type *(CRLF base64)
yuuji@0 4562
yuuji@0 4563 auth-type = atom
yuuji@0 4564 ; Defined by [SASL]
yuuji@0 4565
yuuji@0 4566 base64 = *(4base64-char) [base64-terminal]
yuuji@0 4567
yuuji@0 4568 base64-char = ALPHA / DIGIT / "+" / "/"
yuuji@0 4569 ; Case-sensitive
yuuji@0 4570
yuuji@0 4571 base64-terminal = (2base64-char "==") / (3base64-char "=")
yuuji@0 4572
yuuji@0 4573 body = "(" (body-type-1part / body-type-mpart) ")"
yuuji@0 4574
yuuji@0 4575 body-extension = nstring / number /
yuuji@0 4576 "(" body-extension *(SP body-extension) ")"
yuuji@0 4577 ; Future expansion. Client implementations
yuuji@0 4578 ; MUST accept body-extension fields. Server
yuuji@0 4579 ; implementations MUST NOT generate
yuuji@0 4580 ; body-extension fields except as defined by
yuuji@0 4581 ; future standard or standards-track
yuuji@0 4582 ; revisions of this specification.
yuuji@0 4583
yuuji@0 4584 body-ext-1part = body-fld-md5 [SP body-fld-dsp [SP body-fld-lang
yuuji@0 4585 [SP body-fld-loc *(SP body-extension)]]]
yuuji@0 4586 ; MUST NOT be returned on non-extensible
yuuji@0 4587 ; "BODY" fetch
yuuji@0 4588
yuuji@0 4589
yuuji@0 4590
yuuji@0 4591
yuuji@0 4592
yuuji@0 4593
yuuji@0 4594 Crispin Standards Track [Page 82]
yuuji@0 4595
yuuji@0 4596 RFC 3501 IMAPv4 March 2003
yuuji@0 4597
yuuji@0 4598
yuuji@0 4599 body-ext-mpart = body-fld-param [SP body-fld-dsp [SP body-fld-lang
yuuji@0 4600 [SP body-fld-loc *(SP body-extension)]]]
yuuji@0 4601 ; MUST NOT be returned on non-extensible
yuuji@0 4602 ; "BODY" fetch
yuuji@0 4603
yuuji@0 4604 body-fields = body-fld-param SP body-fld-id SP body-fld-desc SP
yuuji@0 4605 body-fld-enc SP body-fld-octets
yuuji@0 4606
yuuji@0 4607 body-fld-desc = nstring
yuuji@0 4608
yuuji@0 4609 body-fld-dsp = "(" string SP body-fld-param ")" / nil
yuuji@0 4610
yuuji@0 4611 body-fld-enc = (DQUOTE ("7BIT" / "8BIT" / "BINARY" / "BASE64"/
yuuji@0 4612 "QUOTED-PRINTABLE") DQUOTE) / string
yuuji@0 4613
yuuji@0 4614 body-fld-id = nstring
yuuji@0 4615
yuuji@0 4616 body-fld-lang = nstring / "(" string *(SP string) ")"
yuuji@0 4617
yuuji@0 4618 body-fld-loc = nstring
yuuji@0 4619
yuuji@0 4620 body-fld-lines = number
yuuji@0 4621
yuuji@0 4622 body-fld-md5 = nstring
yuuji@0 4623
yuuji@0 4624 body-fld-octets = number
yuuji@0 4625
yuuji@0 4626 body-fld-param = "(" string SP string *(SP string SP string) ")" / nil
yuuji@0 4627
yuuji@0 4628 body-type-1part = (body-type-basic / body-type-msg / body-type-text)
yuuji@0 4629 [SP body-ext-1part]
yuuji@0 4630
yuuji@0 4631 body-type-basic = media-basic SP body-fields
yuuji@0 4632 ; MESSAGE subtype MUST NOT be "RFC822"
yuuji@0 4633
yuuji@0 4634 body-type-mpart = 1*body SP media-subtype
yuuji@0 4635 [SP body-ext-mpart]
yuuji@0 4636
yuuji@0 4637 body-type-msg = media-message SP body-fields SP envelope
yuuji@0 4638 SP body SP body-fld-lines
yuuji@0 4639
yuuji@0 4640 body-type-text = media-text SP body-fields SP body-fld-lines
yuuji@0 4641
yuuji@0 4642 capability = ("AUTH=" auth-type) / atom
yuuji@0 4643 ; New capabilities MUST begin with "X" or be
yuuji@0 4644 ; registered with IANA as standard or
yuuji@0 4645 ; standards-track
yuuji@0 4646
yuuji@0 4647
yuuji@0 4648
yuuji@0 4649
yuuji@0 4650 Crispin Standards Track [Page 83]
yuuji@0 4651
yuuji@0 4652 RFC 3501 IMAPv4 March 2003
yuuji@0 4653
yuuji@0 4654
yuuji@0 4655 capability-data = "CAPABILITY" *(SP capability) SP "IMAP4rev1"
yuuji@0 4656 *(SP capability)
yuuji@0 4657 ; Servers MUST implement the STARTTLS, AUTH=PLAIN,
yuuji@0 4658 ; and LOGINDISABLED capabilities
yuuji@0 4659 ; Servers which offer RFC 1730 compatibility MUST
yuuji@0 4660 ; list "IMAP4" as the first capability.
yuuji@0 4661
yuuji@0 4662 CHAR8 = %x01-ff
yuuji@0 4663 ; any OCTET except NUL, %x00
yuuji@0 4664
yuuji@0 4665 command = tag SP (command-any / command-auth / command-nonauth /
yuuji@0 4666 command-select) CRLF
yuuji@0 4667 ; Modal based on state
yuuji@0 4668
yuuji@0 4669 command-any = "CAPABILITY" / "LOGOUT" / "NOOP" / x-command
yuuji@0 4670 ; Valid in all states
yuuji@0 4671
yuuji@0 4672 command-auth = append / create / delete / examine / list / lsub /
yuuji@0 4673 rename / select / status / subscribe / unsubscribe
yuuji@0 4674 ; Valid only in Authenticated or Selected state
yuuji@0 4675
yuuji@0 4676 command-nonauth = login / authenticate / "STARTTLS"
yuuji@0 4677 ; Valid only when in Not Authenticated state
yuuji@0 4678
yuuji@0 4679 command-select = "CHECK" / "CLOSE" / "EXPUNGE" / copy / fetch / store /
yuuji@0 4680 uid / search
yuuji@0 4681 ; Valid only when in Selected state
yuuji@0 4682
yuuji@0 4683 continue-req = "+" SP (resp-text / base64) CRLF
yuuji@0 4684
yuuji@0 4685 copy = "COPY" SP sequence-set SP mailbox
yuuji@0 4686
yuuji@0 4687 create = "CREATE" SP mailbox
yuuji@0 4688 ; Use of INBOX gives a NO error
yuuji@0 4689
yuuji@0 4690 date = date-text / DQUOTE date-text DQUOTE
yuuji@0 4691
yuuji@0 4692 date-day = 1*2DIGIT
yuuji@0 4693 ; Day of month
yuuji@0 4694
yuuji@0 4695 date-day-fixed = (SP DIGIT) / 2DIGIT
yuuji@0 4696 ; Fixed-format version of date-day
yuuji@0 4697
yuuji@0 4698 date-month = "Jan" / "Feb" / "Mar" / "Apr" / "May" / "Jun" /
yuuji@0 4699 "Jul" / "Aug" / "Sep" / "Oct" / "Nov" / "Dec"
yuuji@0 4700
yuuji@0 4701 date-text = date-day "-" date-month "-" date-year
yuuji@0 4702
yuuji@0 4703
yuuji@0 4704
yuuji@0 4705
yuuji@0 4706 Crispin Standards Track [Page 84]
yuuji@0 4707
yuuji@0 4708 RFC 3501 IMAPv4 March 2003
yuuji@0 4709
yuuji@0 4710
yuuji@0 4711 date-year = 4DIGIT
yuuji@0 4712
yuuji@0 4713 date-time = DQUOTE date-day-fixed "-" date-month "-" date-year
yuuji@0 4714 SP time SP zone DQUOTE
yuuji@0 4715
yuuji@0 4716 delete = "DELETE" SP mailbox
yuuji@0 4717 ; Use of INBOX gives a NO error
yuuji@0 4718
yuuji@0 4719 digit-nz = %x31-39
yuuji@0 4720 ; 1-9
yuuji@0 4721
yuuji@0 4722 envelope = "(" env-date SP env-subject SP env-from SP
yuuji@0 4723 env-sender SP env-reply-to SP env-to SP env-cc SP
yuuji@0 4724 env-bcc SP env-in-reply-to SP env-message-id ")"
yuuji@0 4725
yuuji@0 4726 env-bcc = "(" 1*address ")" / nil
yuuji@0 4727
yuuji@0 4728 env-cc = "(" 1*address ")" / nil
yuuji@0 4729
yuuji@0 4730 env-date = nstring
yuuji@0 4731
yuuji@0 4732 env-from = "(" 1*address ")" / nil
yuuji@0 4733
yuuji@0 4734 env-in-reply-to = nstring
yuuji@0 4735
yuuji@0 4736 env-message-id = nstring
yuuji@0 4737
yuuji@0 4738 env-reply-to = "(" 1*address ")" / nil
yuuji@0 4739
yuuji@0 4740 env-sender = "(" 1*address ")" / nil
yuuji@0 4741
yuuji@0 4742 env-subject = nstring
yuuji@0 4743
yuuji@0 4744 env-to = "(" 1*address ")" / nil
yuuji@0 4745
yuuji@0 4746 examine = "EXAMINE" SP mailbox
yuuji@0 4747
yuuji@0 4748 fetch = "FETCH" SP sequence-set SP ("ALL" / "FULL" / "FAST" /
yuuji@0 4749 fetch-att / "(" fetch-att *(SP fetch-att) ")")
yuuji@0 4750
yuuji@0 4751 fetch-att = "ENVELOPE" / "FLAGS" / "INTERNALDATE" /
yuuji@0 4752 "RFC822" [".HEADER" / ".SIZE" / ".TEXT"] /
yuuji@0 4753 "BODY" ["STRUCTURE"] / "UID" /
yuuji@0 4754 "BODY" section ["<" number "." nz-number ">"] /
yuuji@0 4755 "BODY.PEEK" section ["<" number "." nz-number ">"]
yuuji@0 4756
yuuji@0 4757
yuuji@0 4758
yuuji@0 4759
yuuji@0 4760
yuuji@0 4761
yuuji@0 4762 Crispin Standards Track [Page 85]
yuuji@0 4763
yuuji@0 4764 RFC 3501 IMAPv4 March 2003
yuuji@0 4765
yuuji@0 4766
yuuji@0 4767 flag = "\Answered" / "\Flagged" / "\Deleted" /
yuuji@0 4768 "\Seen" / "\Draft" / flag-keyword / flag-extension
yuuji@0 4769 ; Does not include "\Recent"
yuuji@0 4770
yuuji@0 4771 flag-extension = "\" atom
yuuji@0 4772 ; Future expansion. Client implementations
yuuji@0 4773 ; MUST accept flag-extension flags. Server
yuuji@0 4774 ; implementations MUST NOT generate
yuuji@0 4775 ; flag-extension flags except as defined by
yuuji@0 4776 ; future standard or standards-track
yuuji@0 4777 ; revisions of this specification.
yuuji@0 4778
yuuji@0 4779 flag-fetch = flag / "\Recent"
yuuji@0 4780
yuuji@0 4781 flag-keyword = atom
yuuji@0 4782
yuuji@0 4783 flag-list = "(" [flag *(SP flag)] ")"
yuuji@0 4784
yuuji@0 4785 flag-perm = flag / "\*"
yuuji@0 4786
yuuji@0 4787 greeting = "*" SP (resp-cond-auth / resp-cond-bye) CRLF
yuuji@0 4788
yuuji@0 4789 header-fld-name = astring
yuuji@0 4790
yuuji@0 4791 header-list = "(" header-fld-name *(SP header-fld-name) ")"
yuuji@0 4792
yuuji@0 4793 list = "LIST" SP mailbox SP list-mailbox
yuuji@0 4794
yuuji@0 4795 list-mailbox = 1*list-char / string
yuuji@0 4796
yuuji@0 4797 list-char = ATOM-CHAR / list-wildcards / resp-specials
yuuji@0 4798
yuuji@0 4799 list-wildcards = "%" / "*"
yuuji@0 4800
yuuji@0 4801 literal = "{" number "}" CRLF *CHAR8
yuuji@0 4802 ; Number represents the number of CHAR8s
yuuji@0 4803
yuuji@0 4804 login = "LOGIN" SP userid SP password
yuuji@0 4805
yuuji@0 4806 lsub = "LSUB" SP mailbox SP list-mailbox
yuuji@0 4807
yuuji@0 4808
yuuji@0 4809
yuuji@0 4810
yuuji@0 4811
yuuji@0 4812
yuuji@0 4813
yuuji@0 4814
yuuji@0 4815
yuuji@0 4816
yuuji@0 4817
yuuji@0 4818 Crispin Standards Track [Page 86]
yuuji@0 4819
yuuji@0 4820 RFC 3501 IMAPv4 March 2003
yuuji@0 4821
yuuji@0 4822
yuuji@0 4823 mailbox = "INBOX" / astring
yuuji@0 4824 ; INBOX is case-insensitive. All case variants of
yuuji@0 4825 ; INBOX (e.g., "iNbOx") MUST be interpreted as INBOX
yuuji@0 4826 ; not as an astring. An astring which consists of
yuuji@0 4827 ; the case-insensitive sequence "I" "N" "B" "O" "X"
yuuji@0 4828 ; is considered to be INBOX and not an astring.
yuuji@0 4829 ; Refer to section 5.1 for further
yuuji@0 4830 ; semantic details of mailbox names.
yuuji@0 4831
yuuji@0 4832 mailbox-data = "FLAGS" SP flag-list / "LIST" SP mailbox-list /
yuuji@0 4833 "LSUB" SP mailbox-list / "SEARCH" *(SP nz-number) /
yuuji@0 4834 "STATUS" SP mailbox SP "(" [status-att-list] ")" /
yuuji@0 4835 number SP "EXISTS" / number SP "RECENT"
yuuji@0 4836
yuuji@0 4837 mailbox-list = "(" [mbx-list-flags] ")" SP
yuuji@0 4838 (DQUOTE QUOTED-CHAR DQUOTE / nil) SP mailbox
yuuji@0 4839
yuuji@0 4840 mbx-list-flags = *(mbx-list-oflag SP) mbx-list-sflag
yuuji@0 4841 *(SP mbx-list-oflag) /
yuuji@0 4842 mbx-list-oflag *(SP mbx-list-oflag)
yuuji@0 4843
yuuji@0 4844 mbx-list-oflag = "\Noinferiors" / flag-extension
yuuji@0 4845 ; Other flags; multiple possible per LIST response
yuuji@0 4846
yuuji@0 4847 mbx-list-sflag = "\Noselect" / "\Marked" / "\Unmarked"
yuuji@0 4848 ; Selectability flags; only one per LIST response
yuuji@0 4849
yuuji@0 4850 media-basic = ((DQUOTE ("APPLICATION" / "AUDIO" / "IMAGE" /
yuuji@0 4851 "MESSAGE" / "VIDEO") DQUOTE) / string) SP
yuuji@0 4852 media-subtype
yuuji@0 4853 ; Defined in [MIME-IMT]
yuuji@0 4854
yuuji@0 4855 media-message = DQUOTE "MESSAGE" DQUOTE SP DQUOTE "RFC822" DQUOTE
yuuji@0 4856 ; Defined in [MIME-IMT]
yuuji@0 4857
yuuji@0 4858 media-subtype = string
yuuji@0 4859 ; Defined in [MIME-IMT]
yuuji@0 4860
yuuji@0 4861 media-text = DQUOTE "TEXT" DQUOTE SP media-subtype
yuuji@0 4862 ; Defined in [MIME-IMT]
yuuji@0 4863
yuuji@0 4864 message-data = nz-number SP ("EXPUNGE" / ("FETCH" SP msg-att))
yuuji@0 4865
yuuji@0 4866 msg-att = "(" (msg-att-dynamic / msg-att-static)
yuuji@0 4867 *(SP (msg-att-dynamic / msg-att-static)) ")"
yuuji@0 4868
yuuji@0 4869 msg-att-dynamic = "FLAGS" SP "(" [flag-fetch *(SP flag-fetch)] ")"
yuuji@0 4870 ; MAY change for a message
yuuji@0 4871
yuuji@0 4872
yuuji@0 4873
yuuji@0 4874 Crispin Standards Track [Page 87]
yuuji@0 4875
yuuji@0 4876 RFC 3501 IMAPv4 March 2003
yuuji@0 4877
yuuji@0 4878
yuuji@0 4879 msg-att-static = "ENVELOPE" SP envelope / "INTERNALDATE" SP date-time /
yuuji@0 4880 "RFC822" [".HEADER" / ".TEXT"] SP nstring /
yuuji@0 4881 "RFC822.SIZE" SP number /
yuuji@0 4882 "BODY" ["STRUCTURE"] SP body /
yuuji@0 4883 "BODY" section ["<" number ">"] SP nstring /
yuuji@0 4884 "UID" SP uniqueid
yuuji@0 4885 ; MUST NOT change for a message
yuuji@0 4886
yuuji@0 4887 nil = "NIL"
yuuji@0 4888
yuuji@0 4889 nstring = string / nil
yuuji@0 4890
yuuji@0 4891 number = 1*DIGIT
yuuji@0 4892 ; Unsigned 32-bit integer
yuuji@0 4893 ; (0 <= n < 4,294,967,296)
yuuji@0 4894
yuuji@0 4895 nz-number = digit-nz *DIGIT
yuuji@0 4896 ; Non-zero unsigned 32-bit integer
yuuji@0 4897 ; (0 < n < 4,294,967,296)
yuuji@0 4898
yuuji@0 4899 password = astring
yuuji@0 4900
yuuji@0 4901 quoted = DQUOTE *QUOTED-CHAR DQUOTE
yuuji@0 4902
yuuji@0 4903 QUOTED-CHAR = <any TEXT-CHAR except quoted-specials> /
yuuji@0 4904 "\" quoted-specials
yuuji@0 4905
yuuji@0 4906 quoted-specials = DQUOTE / "\"
yuuji@0 4907
yuuji@0 4908 rename = "RENAME" SP mailbox SP mailbox
yuuji@0 4909 ; Use of INBOX as a destination gives a NO error
yuuji@0 4910
yuuji@0 4911 response = *(continue-req / response-data) response-done
yuuji@0 4912
yuuji@0 4913 response-data = "*" SP (resp-cond-state / resp-cond-bye /
yuuji@0 4914 mailbox-data / message-data / capability-data) CRLF
yuuji@0 4915
yuuji@0 4916 response-done = response-tagged / response-fatal
yuuji@0 4917
yuuji@0 4918 response-fatal = "*" SP resp-cond-bye CRLF
yuuji@0 4919 ; Server closes connection immediately
yuuji@0 4920
yuuji@0 4921 response-tagged = tag SP resp-cond-state CRLF
yuuji@0 4922
yuuji@0 4923 resp-cond-auth = ("OK" / "PREAUTH") SP resp-text
yuuji@0 4924 ; Authentication condition
yuuji@0 4925
yuuji@0 4926
yuuji@0 4927
yuuji@0 4928
yuuji@0 4929
yuuji@0 4930 Crispin Standards Track [Page 88]
yuuji@0 4931
yuuji@0 4932 RFC 3501 IMAPv4 March 2003
yuuji@0 4933
yuuji@0 4934
yuuji@0 4935 resp-cond-bye = "BYE" SP resp-text
yuuji@0 4936
yuuji@0 4937 resp-cond-state = ("OK" / "NO" / "BAD") SP resp-text
yuuji@0 4938 ; Status condition
yuuji@0 4939
yuuji@0 4940 resp-specials = "]"
yuuji@0 4941
yuuji@0 4942 resp-text = ["[" resp-text-code "]" SP] text
yuuji@0 4943
yuuji@0 4944 resp-text-code = "ALERT" /
yuuji@0 4945 "BADCHARSET" [SP "(" astring *(SP astring) ")" ] /
yuuji@0 4946 capability-data / "PARSE" /
yuuji@0 4947 "PERMANENTFLAGS" SP "("
yuuji@0 4948 [flag-perm *(SP flag-perm)] ")" /
yuuji@0 4949 "READ-ONLY" / "READ-WRITE" / "TRYCREATE" /
yuuji@0 4950 "UIDNEXT" SP nz-number / "UIDVALIDITY" SP nz-number /
yuuji@0 4951 "UNSEEN" SP nz-number /
yuuji@0 4952 atom [SP 1*<any TEXT-CHAR except "]">]
yuuji@0 4953
yuuji@0 4954 search = "SEARCH" [SP "CHARSET" SP astring] 1*(SP search-key)
yuuji@0 4955 ; CHARSET argument to MUST be registered with IANA
yuuji@0 4956
yuuji@0 4957 search-key = "ALL" / "ANSWERED" / "BCC" SP astring /
yuuji@0 4958 "BEFORE" SP date / "BODY" SP astring /
yuuji@0 4959 "CC" SP astring / "DELETED" / "FLAGGED" /
yuuji@0 4960 "FROM" SP astring / "KEYWORD" SP flag-keyword /
yuuji@0 4961 "NEW" / "OLD" / "ON" SP date / "RECENT" / "SEEN" /
yuuji@0 4962 "SINCE" SP date / "SUBJECT" SP astring /
yuuji@0 4963 "TEXT" SP astring / "TO" SP astring /
yuuji@0 4964 "UNANSWERED" / "UNDELETED" / "UNFLAGGED" /
yuuji@0 4965 "UNKEYWORD" SP flag-keyword / "UNSEEN" /
yuuji@0 4966 ; Above this line were in [IMAP2]
yuuji@0 4967 "DRAFT" / "HEADER" SP header-fld-name SP astring /
yuuji@0 4968 "LARGER" SP number / "NOT" SP search-key /
yuuji@0 4969 "OR" SP search-key SP search-key /
yuuji@0 4970 "SENTBEFORE" SP date / "SENTON" SP date /
yuuji@0 4971 "SENTSINCE" SP date / "SMALLER" SP number /
yuuji@0 4972 "UID" SP sequence-set / "UNDRAFT" / sequence-set /
yuuji@0 4973 "(" search-key *(SP search-key) ")"
yuuji@0 4974
yuuji@0 4975 section = "[" [section-spec] "]"
yuuji@0 4976
yuuji@0 4977 section-msgtext = "HEADER" / "HEADER.FIELDS" [".NOT"] SP header-list /
yuuji@0 4978 "TEXT"
yuuji@0 4979 ; top-level or MESSAGE/RFC822 part
yuuji@0 4980
yuuji@0 4981 section-part = nz-number *("." nz-number)
yuuji@0 4982 ; body part nesting
yuuji@0 4983
yuuji@0 4984
yuuji@0 4985
yuuji@0 4986 Crispin Standards Track [Page 89]
yuuji@0 4987
yuuji@0 4988 RFC 3501 IMAPv4 March 2003
yuuji@0 4989
yuuji@0 4990
yuuji@0 4991 section-spec = section-msgtext / (section-part ["." section-text])
yuuji@0 4992
yuuji@0 4993 section-text = section-msgtext / "MIME"
yuuji@0 4994 ; text other than actual body part (headers, etc.)
yuuji@0 4995
yuuji@0 4996 select = "SELECT" SP mailbox
yuuji@0 4997
yuuji@0 4998 seq-number = nz-number / "*"
yuuji@0 4999 ; message sequence number (COPY, FETCH, STORE
yuuji@0 5000 ; commands) or unique identifier (UID COPY,
yuuji@0 5001 ; UID FETCH, UID STORE commands).
yuuji@0 5002 ; * represents the largest number in use. In
yuuji@0 5003 ; the case of message sequence numbers, it is
yuuji@0 5004 ; the number of messages in a non-empty mailbox.
yuuji@0 5005 ; In the case of unique identifiers, it is the
yuuji@0 5006 ; unique identifier of the last message in the
yuuji@0 5007 ; mailbox or, if the mailbox is empty, the
yuuji@0 5008 ; mailbox's current UIDNEXT value.
yuuji@0 5009 ; The server should respond with a tagged BAD
yuuji@0 5010 ; response to a command that uses a message
yuuji@0 5011 ; sequence number greater than the number of
yuuji@0 5012 ; messages in the selected mailbox. This
yuuji@0 5013 ; includes "*" if the selected mailbox is empty.
yuuji@0 5014
yuuji@0 5015 seq-range = seq-number ":" seq-number
yuuji@0 5016 ; two seq-number values and all values between
yuuji@0 5017 ; these two regardless of order.
yuuji@0 5018 ; Example: 2:4 and 4:2 are equivalent and indicate
yuuji@0 5019 ; values 2, 3, and 4.
yuuji@0 5020 ; Example: a unique identifer sequence range of
yuuji@0 5021 ; 3291:* includes the UID of the last message in
yuuji@0 5022 ; the mailbox, even if that value is less than 3291.
yuuji@0 5023
yuuji@0 5024 sequence-set = (seq-number / seq-range) *("," sequence-set)
yuuji@0 5025 ; set of seq-number values, regardless of order.
yuuji@0 5026 ; Servers MAY coalesce overlaps and/or execute the
yuuji@0 5027 ; sequence in any order.
yuuji@0 5028 ; Example: a message sequence number set of
yuuji@0 5029 ; 2,4:7,9,12:* for a mailbox with 15 messages is
yuuji@0 5030 ; equivalent to 2,4,5,6,7,9,12,13,14,15
yuuji@0 5031 ; Example: a message sequence number set of *:4,5:7
yuuji@0 5032 ; for a mailbox with 10 messages is equivalent to
yuuji@0 5033 ; 10,9,8,7,6,5,4,5,6,7 and MAY be reordered and
yuuji@0 5034 ; overlap coalesced to be 4,5,6,7,8,9,10.
yuuji@0 5035
yuuji@0 5036 status = "STATUS" SP mailbox SP
yuuji@0 5037 "(" status-att *(SP status-att) ")"
yuuji@0 5038
yuuji@0 5039
yuuji@0 5040
yuuji@0 5041
yuuji@0 5042 Crispin Standards Track [Page 90]
yuuji@0 5043
yuuji@0 5044 RFC 3501 IMAPv4 March 2003
yuuji@0 5045
yuuji@0 5046
yuuji@0 5047 status-att = "MESSAGES" / "RECENT" / "UIDNEXT" / "UIDVALIDITY" /
yuuji@0 5048 "UNSEEN"
yuuji@0 5049
yuuji@0 5050 status-att-list = status-att SP number *(SP status-att SP number)
yuuji@0 5051
yuuji@0 5052 store = "STORE" SP sequence-set SP store-att-flags
yuuji@0 5053
yuuji@0 5054 store-att-flags = (["+" / "-"] "FLAGS" [".SILENT"]) SP
yuuji@0 5055 (flag-list / (flag *(SP flag)))
yuuji@0 5056
yuuji@0 5057 string = quoted / literal
yuuji@0 5058
yuuji@0 5059 subscribe = "SUBSCRIBE" SP mailbox
yuuji@0 5060
yuuji@0 5061 tag = 1*<any ASTRING-CHAR except "+">
yuuji@0 5062
yuuji@0 5063 text = 1*TEXT-CHAR
yuuji@0 5064
yuuji@0 5065 TEXT-CHAR = <any CHAR except CR and LF>
yuuji@0 5066
yuuji@0 5067 time = 2DIGIT ":" 2DIGIT ":" 2DIGIT
yuuji@0 5068 ; Hours minutes seconds
yuuji@0 5069
yuuji@0 5070 uid = "UID" SP (copy / fetch / search / store)
yuuji@0 5071 ; Unique identifiers used instead of message
yuuji@0 5072 ; sequence numbers
yuuji@0 5073
yuuji@0 5074 uniqueid = nz-number
yuuji@0 5075 ; Strictly ascending
yuuji@0 5076
yuuji@0 5077 unsubscribe = "UNSUBSCRIBE" SP mailbox
yuuji@0 5078
yuuji@0 5079 userid = astring
yuuji@0 5080
yuuji@0 5081 x-command = "X" atom <experimental command arguments>
yuuji@0 5082
yuuji@0 5083 zone = ("+" / "-") 4DIGIT
yuuji@0 5084 ; Signed four-digit value of hhmm representing
yuuji@0 5085 ; hours and minutes east of Greenwich (that is,
yuuji@0 5086 ; the amount that the given time differs from
yuuji@0 5087 ; Universal Time). Subtracting the timezone
yuuji@0 5088 ; from the given time will give the UT form.
yuuji@0 5089 ; The Universal Time zone is "+0000".
yuuji@0 5090
yuuji@0 5091
yuuji@0 5092
yuuji@0 5093
yuuji@0 5094
yuuji@0 5095
yuuji@0 5096
yuuji@0 5097
yuuji@0 5098 Crispin Standards Track [Page 91]
yuuji@0 5099
yuuji@0 5100 RFC 3501 IMAPv4 March 2003
yuuji@0 5101
yuuji@0 5102
yuuji@0 5103 10. Author's Note
yuuji@0 5104
yuuji@0 5105 This document is a revision or rewrite of earlier documents, and
yuuji@0 5106 supercedes the protocol specification in those documents: RFC 2060,
yuuji@0 5107 RFC 1730, unpublished IMAP2bis.TXT document, RFC 1176, and RFC 1064.
yuuji@0 5108
yuuji@0 5109 11. Security Considerations
yuuji@0 5110
yuuji@0 5111 IMAP4rev1 protocol transactions, including electronic mail data, are
yuuji@0 5112 sent in the clear over the network unless protection from snooping is
yuuji@0 5113 negotiated. This can be accomplished either by the use of STARTTLS,
yuuji@0 5114 negotiated privacy protection in the AUTHENTICATE command, or some
yuuji@0 5115 other protection mechanism.
yuuji@0 5116
yuuji@0 5117 11.1. STARTTLS Security Considerations
yuuji@0 5118
yuuji@0 5119 The specification of the STARTTLS command and LOGINDISABLED
yuuji@0 5120 capability in this document replaces that in [IMAP-TLS]. [IMAP-TLS]
yuuji@0 5121 remains normative for the PLAIN [SASL] authenticator.
yuuji@0 5122
yuuji@0 5123 IMAP client and server implementations MUST implement the
yuuji@0 5124 TLS_RSA_WITH_RC4_128_MD5 [TLS] cipher suite, and SHOULD implement the
yuuji@0 5125 TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA [TLS] cipher suite. This is
yuuji@0 5126 important as it assures that any two compliant implementations can be
yuuji@0 5127 configured to interoperate. All other cipher suites are OPTIONAL.
yuuji@0 5128 Note that this is a change from section 2.1 of [IMAP-TLS].
yuuji@0 5129
yuuji@0 5130 During the [TLS] negotiation, the client MUST check its understanding
yuuji@0 5131 of the server hostname against the server's identity as presented in
yuuji@0 5132 the server Certificate message, in order to prevent man-in-the-middle
yuuji@0 5133 attacks. If the match fails, the client SHOULD either ask for
yuuji@0 5134 explicit user confirmation, or terminate the connection and indicate
yuuji@0 5135 that the server's identity is suspect. Matching is performed
yuuji@0 5136 according to these rules:
yuuji@0 5137
yuuji@0 5138 The client MUST use the server hostname it used to open the
yuuji@0 5139 connection as the value to compare against the server name
yuuji@0 5140 as expressed in the server certificate. The client MUST
yuuji@0 5141 NOT use any form of the server hostname derived from an
yuuji@0 5142 insecure remote source (e.g., insecure DNS lookup). CNAME
yuuji@0 5143 canonicalization is not done.
yuuji@0 5144
yuuji@0 5145 If a subjectAltName extension of type dNSName is present in
yuuji@0 5146 the certificate, it SHOULD be used as the source of the
yuuji@0 5147 server's identity.
yuuji@0 5148
yuuji@0 5149 Matching is case-insensitive.
yuuji@0 5150
yuuji@0 5151
yuuji@0 5152
yuuji@0 5153
yuuji@0 5154 Crispin Standards Track [Page 92]
yuuji@0 5155
yuuji@0 5156 RFC 3501 IMAPv4 March 2003
yuuji@0 5157
yuuji@0 5158
yuuji@0 5159 A "*" wildcard character MAY be used as the left-most name
yuuji@0 5160 component in the certificate. For example, *.example.com
yuuji@0 5161 would match a.example.com, foo.example.com, etc. but would
yuuji@0 5162 not match example.com.
yuuji@0 5163
yuuji@0 5164 If the certificate contains multiple names (e.g., more than
yuuji@0 5165 one dNSName field), then a match with any one of the fields
yuuji@0 5166 is considered acceptable.
yuuji@0 5167
yuuji@0 5168 Both the client and server MUST check the result of the STARTTLS
yuuji@0 5169 command and subsequent [TLS] negotiation to see whether acceptable
yuuji@0 5170 authentication or privacy was achieved.
yuuji@0 5171
yuuji@0 5172 11.2. Other Security Considerations
yuuji@0 5173
yuuji@0 5174 A server error message for an AUTHENTICATE command which fails due to
yuuji@0 5175 invalid credentials SHOULD NOT detail why the credentials are
yuuji@0 5176 invalid.
yuuji@0 5177
yuuji@0 5178 Use of the LOGIN command sends passwords in the clear. This can be
yuuji@0 5179 avoided by using the AUTHENTICATE command with a [SASL] mechanism
yuuji@0 5180 that does not use plaintext passwords, by first negotiating
yuuji@0 5181 encryption via STARTTLS or some other protection mechanism.
yuuji@0 5182
yuuji@0 5183 A server implementation MUST implement a configuration that, at the
yuuji@0 5184 time of authentication, requires:
yuuji@0 5185 (1) The STARTTLS command has been negotiated.
yuuji@0 5186 OR
yuuji@0 5187 (2) Some other mechanism that protects the session from password
yuuji@0 5188 snooping has been provided.
yuuji@0 5189 OR
yuuji@0 5190 (3) The following measures are in place:
yuuji@0 5191 (a) The LOGINDISABLED capability is advertised, and [SASL]
yuuji@0 5192 mechanisms (such as PLAIN) using plaintext passwords are NOT
yuuji@0 5193 advertised in the CAPABILITY list.
yuuji@0 5194 AND
yuuji@0 5195 (b) The LOGIN command returns an error even if the password is
yuuji@0 5196 correct.
yuuji@0 5197 AND
yuuji@0 5198 (c) The AUTHENTICATE command returns an error with all [SASL]
yuuji@0 5199 mechanisms that use plaintext passwords, even if the password
yuuji@0 5200 is correct.
yuuji@0 5201
yuuji@0 5202 A server error message for a failing LOGIN command SHOULD NOT specify
yuuji@0 5203 that the user name, as opposed to the password, is invalid.
yuuji@0 5204
yuuji@0 5205 A server SHOULD have mechanisms in place to limit or delay failed
yuuji@0 5206 AUTHENTICATE/LOGIN attempts.
yuuji@0 5207
yuuji@0 5208
yuuji@0 5209
yuuji@0 5210 Crispin Standards Track [Page 93]
yuuji@0 5211
yuuji@0 5212 RFC 3501 IMAPv4 March 2003
yuuji@0 5213
yuuji@0 5214
yuuji@0 5215 Additional security considerations are discussed in the section
yuuji@0 5216 discussing the AUTHENTICATE and LOGIN commands.
yuuji@0 5217
yuuji@0 5218 12. IANA Considerations
yuuji@0 5219
yuuji@0 5220 IMAP4 capabilities are registered by publishing a standards track or
yuuji@0 5221 IESG approved experimental RFC. The registry is currently located
yuuji@0 5222 at:
yuuji@0 5223
yuuji@0 5224 http://www.iana.org/assignments/imap4-capabilities
yuuji@0 5225
yuuji@0 5226 As this specification revises the STARTTLS and LOGINDISABLED
yuuji@0 5227 extensions previously defined in [IMAP-TLS], the registry will be
yuuji@0 5228 updated accordingly.
yuuji@0 5229
yuuji@0 5230
yuuji@0 5231
yuuji@0 5232
yuuji@0 5233
yuuji@0 5234
yuuji@0 5235
yuuji@0 5236
yuuji@0 5237
yuuji@0 5238
yuuji@0 5239
yuuji@0 5240
yuuji@0 5241
yuuji@0 5242
yuuji@0 5243
yuuji@0 5244
yuuji@0 5245
yuuji@0 5246
yuuji@0 5247
yuuji@0 5248
yuuji@0 5249
yuuji@0 5250
yuuji@0 5251
yuuji@0 5252
yuuji@0 5253
yuuji@0 5254
yuuji@0 5255
yuuji@0 5256
yuuji@0 5257
yuuji@0 5258
yuuji@0 5259
yuuji@0 5260
yuuji@0 5261
yuuji@0 5262
yuuji@0 5263
yuuji@0 5264
yuuji@0 5265
yuuji@0 5266 Crispin Standards Track [Page 94]
yuuji@0 5267
yuuji@0 5268 RFC 3501 IMAPv4 March 2003
yuuji@0 5269
yuuji@0 5270
yuuji@0 5271 Appendices
yuuji@0 5272
yuuji@0 5273 A. Normative References
yuuji@0 5274
yuuji@0 5275 The following documents contain definitions or specifications that
yuuji@0 5276 are necessary to understand this document properly:
yuuji@0 5277 [ABNF] Crocker, D. and P. Overell, "Augmented BNF for
yuuji@0 5278 Syntax Specifications: ABNF", RFC 2234,
yuuji@0 5279 November 1997.
yuuji@0 5280
yuuji@0 5281 [ANONYMOUS] Newman, C., "Anonymous SASL Mechanism", RFC
yuuji@0 5282 2245, November 1997.
yuuji@0 5283
yuuji@0 5284 [CHARSET] Freed, N. and J. Postel, "IANA Character Set
yuuji@0 5285 Registration Procedures", RFC 2978, October
yuuji@0 5286 2000.
yuuji@0 5287
yuuji@0 5288 [DIGEST-MD5] Leach, P. and C. Newman, "Using Digest
yuuji@0 5289 Authentication as a SASL Mechanism", RFC 2831,
yuuji@0 5290 May 2000.
yuuji@0 5291
yuuji@0 5292 [DISPOSITION] Troost, R., Dorner, S. and K. Moore,
yuuji@0 5293 "Communicating Presentation Information in
yuuji@0 5294 Internet Messages: The Content-Disposition
yuuji@0 5295 Header", RFC 2183, August 1997.
yuuji@0 5296
yuuji@0 5297 [IMAP-TLS] Newman, C., "Using TLS with IMAP, POP3 and
yuuji@0 5298 ACAP", RFC 2595, June 1999.
yuuji@0 5299
yuuji@0 5300 [KEYWORDS] Bradner, S., "Key words for use in RFCs to
yuuji@0 5301 Indicate Requirement Levels", BCP 14, RFC 2119,
yuuji@0 5302 March 1997.
yuuji@0 5303
yuuji@0 5304 [LANGUAGE-TAGS] Alvestrand, H., "Tags for the Identification of
yuuji@0 5305 Languages", BCP 47, RFC 3066, January 2001.
yuuji@0 5306
yuuji@0 5307 [LOCATION] Palme, J., Hopmann, A. and N. Shelness, "MIME
yuuji@0 5308 Encapsulation of Aggregate Documents, such as
yuuji@0 5309 HTML (MHTML)", RFC 2557, March 1999.
yuuji@0 5310
yuuji@0 5311 [MD5] Myers, J. and M. Rose, "The Content-MD5 Header
yuuji@0 5312 Field", RFC 1864, October 1995.
yuuji@0 5313
yuuji@0 5314
yuuji@0 5315
yuuji@0 5316
yuuji@0 5317
yuuji@0 5318
yuuji@0 5319
yuuji@0 5320
yuuji@0 5321
yuuji@0 5322 Crispin Standards Track [Page 95]
yuuji@0 5323
yuuji@0 5324 RFC 3501 IMAPv4 March 2003
yuuji@0 5325
yuuji@0 5326
yuuji@0 5327 [MIME-HDRS] Moore, K., "MIME (Multipurpose Internet Mail
yuuji@0 5328 Extensions) Part Three: Message Header
yuuji@0 5329 Extensions for Non-ASCII Text", RFC 2047,
yuuji@0 5330 November 1996.
yuuji@0 5331
yuuji@0 5332 [MIME-IMB] Freed, N. and N. Borenstein, "MIME
yuuji@0 5333 (Multipurpose Internet Mail Extensions) Part
yuuji@0 5334 One: Format of Internet Message Bodies", RFC
yuuji@0 5335 2045, November 1996.
yuuji@0 5336
yuuji@0 5337 [MIME-IMT] Freed, N. and N. Borenstein, "MIME
yuuji@0 5338 (Multipurpose Internet Mail Extensions) Part
yuuji@0 5339 Two: Media Types", RFC 2046, November 1996.
yuuji@0 5340
yuuji@0 5341 [RFC-2822] Resnick, P., "Internet Message Format", RFC
yuuji@0 5342 2822, April 2001.
yuuji@0 5343
yuuji@0 5344 [SASL] Myers, J., "Simple Authentication and Security
yuuji@0 5345 Layer (SASL)", RFC 2222, October 1997.
yuuji@0 5346
yuuji@0 5347 [TLS] Dierks, T. and C. Allen, "The TLS Protocol
yuuji@0 5348 Version 1.0", RFC 2246, January 1999.
yuuji@0 5349
yuuji@0 5350 [UTF-7] Goldsmith, D. and M. Davis, "UTF-7: A Mail-Safe
yuuji@0 5351 Transformation Format of Unicode", RFC 2152,
yuuji@0 5352 May 1997.
yuuji@0 5353
yuuji@0 5354 The following documents describe quality-of-implementation issues
yuuji@0 5355 that should be carefully considered when implementing this protocol:
yuuji@0 5356
yuuji@0 5357 [IMAP-IMPLEMENTATION] Leiba, B., "IMAP Implementation
yuuji@0 5358 Recommendations", RFC 2683, September 1999.
yuuji@0 5359
yuuji@0 5360 [IMAP-MULTIACCESS] Gahrns, M., "IMAP4 Multi-Accessed Mailbox
yuuji@0 5361 Practice", RFC 2180, July 1997.
yuuji@0 5362
yuuji@0 5363 A.1 Informative References
yuuji@0 5364
yuuji@0 5365 The following documents describe related protocols:
yuuji@0 5366
yuuji@0 5367 [IMAP-DISC] Austein, R., "Synchronization Operations for
yuuji@0 5368 Disconnected IMAP4 Clients", Work in Progress.
yuuji@0 5369
yuuji@0 5370 [IMAP-MODEL] Crispin, M., "Distributed Electronic Mail
yuuji@0 5371 Models in IMAP4", RFC 1733, December 1994.
yuuji@0 5372
yuuji@0 5373
yuuji@0 5374
yuuji@0 5375
yuuji@0 5376
yuuji@0 5377
yuuji@0 5378 Crispin Standards Track [Page 96]
yuuji@0 5379
yuuji@0 5380 RFC 3501 IMAPv4 March 2003
yuuji@0 5381
yuuji@0 5382
yuuji@0 5383 [ACAP] Newman, C. and J. Myers, "ACAP -- Application
yuuji@0 5384 Configuration Access Protocol", RFC 2244,
yuuji@0 5385 November 1997.
yuuji@0 5386
yuuji@0 5387 [SMTP] Klensin, J., "Simple Mail Transfer Protocol",
yuuji@0 5388 STD 10, RFC 2821, April 2001.
yuuji@0 5389
yuuji@0 5390 The following documents are historical or describe historical aspects
yuuji@0 5391 of this protocol:
yuuji@0 5392
yuuji@0 5393 [IMAP-COMPAT] Crispin, M., "IMAP4 Compatibility with
yuuji@0 5394 IMAP2bis", RFC 2061, December 1996.
yuuji@0 5395
yuuji@0 5396 [IMAP-HISTORICAL] Crispin, M., "IMAP4 Compatibility with IMAP2
yuuji@0 5397 and IMAP2bis", RFC 1732, December 1994.
yuuji@0 5398
yuuji@0 5399 [IMAP-OBSOLETE] Crispin, M., "Internet Message Access Protocol
yuuji@0 5400 - Obsolete Syntax", RFC 2062, December 1996.
yuuji@0 5401
yuuji@0 5402 [IMAP2] Crispin, M., "Interactive Mail Access Protocol
yuuji@0 5403 - Version 2", RFC 1176, August 1990.
yuuji@0 5404
yuuji@0 5405 [RFC-822] Crocker, D., "Standard for the Format of ARPA
yuuji@0 5406 Internet Text Messages", STD 11, RFC 822,
yuuji@0 5407 August 1982.
yuuji@0 5408
yuuji@0 5409 [RFC-821] Postel, J., "Simple Mail Transfer Protocol",
yuuji@0 5410 STD 10, RFC 821, August 1982.
yuuji@0 5411
yuuji@0 5412 B. Changes from RFC 2060
yuuji@0 5413
yuuji@0 5414 1) Clarify description of unique identifiers and their semantics.
yuuji@0 5415
yuuji@0 5416 2) Fix the SELECT description to clarify that UIDVALIDITY is required
yuuji@0 5417 in the SELECT and EXAMINE responses.
yuuji@0 5418
yuuji@0 5419 3) Added an example of a failing search.
yuuji@0 5420
yuuji@0 5421 4) Correct store-att-flags: "#flag" should be "1#flag".
yuuji@0 5422
yuuji@0 5423 5) Made search and section rules clearer.
yuuji@0 5424
yuuji@0 5425 6) Correct the STORE example.
yuuji@0 5426
yuuji@0 5427 7) Correct "BASE645" misspelling.
yuuji@0 5428
yuuji@0 5429 8) Remove extraneous close parenthesis in example of two-part message
yuuji@0 5430 with text and BASE64 attachment.
yuuji@0 5431
yuuji@0 5432
yuuji@0 5433
yuuji@0 5434 Crispin Standards Track [Page 97]
yuuji@0 5435
yuuji@0 5436 RFC 3501 IMAPv4 March 2003
yuuji@0 5437
yuuji@0 5438
yuuji@0 5439 9) Remove obsolete "MAILBOX" response from mailbox-data.
yuuji@0 5440
yuuji@0 5441 10) A spurious "<" in the rule for mailbox-data was removed.
yuuji@0 5442
yuuji@0 5443 11) Add CRLF to continue-req.
yuuji@0 5444
yuuji@0 5445 12) Specifically exclude "]" from the atom in resp-text-code.
yuuji@0 5446
yuuji@0 5447 13) Clarify that clients and servers should adhere strictly to the
yuuji@0 5448 protocol syntax.
yuuji@0 5449
yuuji@0 5450 14) Emphasize in 5.2 that EXISTS can not be used to shrink a mailbox.
yuuji@0 5451
yuuji@0 5452 15) Add NEWNAME to resp-text-code.
yuuji@0 5453
yuuji@0 5454 16) Clarify that the empty string, not NIL, is used as arguments to
yuuji@0 5455 LIST.
yuuji@0 5456
yuuji@0 5457 17) Clarify that NIL can be returned as a hierarchy delimiter for the
yuuji@0 5458 empty string mailbox name argument if the mailbox namespace is flat.
yuuji@0 5459
yuuji@0 5460 18) Clarify that addr-mailbox and addr-name have RFC-2822 quoting
yuuji@0 5461 removed.
yuuji@0 5462
yuuji@0 5463 19) Update UTF-7 reference.
yuuji@0 5464
yuuji@0 5465 20) Fix example in 6.3.11.
yuuji@0 5466
yuuji@0 5467 21) Clarify that non-existent UIDs are ignored.
yuuji@0 5468
yuuji@0 5469 22) Update DISPOSITION reference.
yuuji@0 5470
yuuji@0 5471 23) Expand state diagram.
yuuji@0 5472
yuuji@0 5473 24) Clarify that partial fetch responses are only returned in
yuuji@0 5474 response to a partial fetch command.
yuuji@0 5475
yuuji@0 5476 25) Add UIDNEXT response code. Correct UIDVALIDITY definition
yuuji@0 5477 reference.
yuuji@0 5478
yuuji@0 5479 26) Further clarification of "can" vs. "MAY".
yuuji@0 5480
yuuji@0 5481 27) Reference RFC-2119.
yuuji@0 5482
yuuji@0 5483 28) Clarify that superfluous shifts are not permitted in modified
yuuji@0 5484 UTF-7.
yuuji@0 5485
yuuji@0 5486 29) Clarify that there are no implicit shifts in modified UTF-7.
yuuji@0 5487
yuuji@0 5488
yuuji@0 5489
yuuji@0 5490 Crispin Standards Track [Page 98]
yuuji@0 5491
yuuji@0 5492 RFC 3501 IMAPv4 March 2003
yuuji@0 5493
yuuji@0 5494
yuuji@0 5495 30) Clarify that "INBOX" in a mailbox name is always INBOX, even if
yuuji@0 5496 it is given as a string.
yuuji@0 5497
yuuji@0 5498 31) Add missing open parenthesis in media-basic grammar rule.
yuuji@0 5499
yuuji@0 5500 32) Correct attribute syntax in mailbox-data.
yuuji@0 5501
yuuji@0 5502 33) Add UIDNEXT to EXAMINE responses.
yuuji@0 5503
yuuji@0 5504 34) Clarify UNSEEN, PERMANENTFLAGS, UIDVALIDITY, and UIDNEXT
yuuji@0 5505 responses in SELECT and EXAMINE. They are required now, but weren't
yuuji@0 5506 in older versions.
yuuji@0 5507
yuuji@0 5508 35) Update references with RFC numbers.
yuuji@0 5509
yuuji@0 5510 36) Flush text-mime2.
yuuji@0 5511
yuuji@0 5512 37) Clarify that modified UTF-7 names must be case-sensitive and that
yuuji@0 5513 violating the convention should be avoided.
yuuji@0 5514
yuuji@0 5515 38) Correct UID FETCH example.
yuuji@0 5516
yuuji@0 5517 39) Clarify UID FETCH, UID STORE, and UID SEARCH vs. untagged EXPUNGE
yuuji@0 5518 responses.
yuuji@0 5519
yuuji@0 5520 40) Clarify the use of the word "convention".
yuuji@0 5521
yuuji@0 5522 41) Clarify that a command is not "in progress" until it has been
yuuji@0 5523 fully received (specifically, that a command is not "in progress"
yuuji@0 5524 during command continuation negotiation).
yuuji@0 5525
yuuji@0 5526 42) Clarify envelope defaulting.
yuuji@0 5527
yuuji@0 5528 43) Clarify that SP means one and only one space character.
yuuji@0 5529
yuuji@0 5530 44) Forbid silly states in LIST response.
yuuji@0 5531
yuuji@0 5532 45) Clarify that the ENVELOPE, INTERNALDATE, RFC822*, BODY*, and UID
yuuji@0 5533 for a message is static.
yuuji@0 5534
yuuji@0 5535 46) Add BADCHARSET response code.
yuuji@0 5536
yuuji@0 5537 47) Update formal syntax to [ABNF] conventions.
yuuji@0 5538
yuuji@0 5539 48) Clarify trailing hierarchy delimiter in CREATE semantics.
yuuji@0 5540
yuuji@0 5541 49) Clarify that the "blank line" is the [RFC-2822] delimiting blank
yuuji@0 5542 line.
yuuji@0 5543
yuuji@0 5544
yuuji@0 5545
yuuji@0 5546 Crispin Standards Track [Page 99]
yuuji@0 5547
yuuji@0 5548 RFC 3501 IMAPv4 March 2003
yuuji@0 5549
yuuji@0 5550
yuuji@0 5551 50) Clarify that RENAME should also create hierarchy as needed for
yuuji@0 5552 the command to complete.
yuuji@0 5553
yuuji@0 5554 51) Fix body-ext-mpart to not require language if disposition
yuuji@0 5555 present.
yuuji@0 5556
yuuji@0 5557 52) Clarify the RFC822.HEADER response.
yuuji@0 5558
yuuji@0 5559 53) Correct missing space after charset astring in search.
yuuji@0 5560
yuuji@0 5561 54) Correct missing quote for BADCHARSET in resp-text-code.
yuuji@0 5562
yuuji@0 5563 55) Clarify that ALL, FAST, and FULL preclude any other data items
yuuji@0 5564 appearing.
yuuji@0 5565
yuuji@0 5566 56) Clarify semantics of reference argument in LIST.
yuuji@0 5567
yuuji@0 5568 57) Clarify that a null string for SEARCH HEADER X-FOO means any
yuuji@0 5569 message with a header line with a field-name of X-FOO regardless of
yuuji@0 5570 the text of the header.
yuuji@0 5571
yuuji@0 5572 58) Specifically reserve 8-bit mailbox names for future use as UTF-8.
yuuji@0 5573
yuuji@0 5574 59) It is not an error for the client to store a flag that is not in
yuuji@0 5575 the PERMANENTFLAGS list; however, the server will either ignore the
yuuji@0 5576 change or make the change in the session only.
yuuji@0 5577
yuuji@0 5578 60) Correct/clarify the text regarding superfluous shifts.
yuuji@0 5579
yuuji@0 5580 61) Correct typographic errors in the "Changes" section.
yuuji@0 5581
yuuji@0 5582 62) Clarify that STATUS must not be used to check for new messages in
yuuji@0 5583 the selected mailbox
yuuji@0 5584
yuuji@0 5585 63) Clarify LSUB behavior with "%" wildcard.
yuuji@0 5586
yuuji@0 5587 64) Change AUTHORIZATION to AUTHENTICATE in section 7.5.
yuuji@0 5588
yuuji@0 5589 65) Clarify description of multipart body type.
yuuji@0 5590
yuuji@0 5591 66) Clarify that STORE FLAGS does not affect \Recent.
yuuji@0 5592
yuuji@0 5593 67) Change "west" to "east" in description of timezone.
yuuji@0 5594
yuuji@0 5595 68) Clarify that commands which break command pipelining must wait
yuuji@0 5596 for a completion result response.
yuuji@0 5597
yuuji@0 5598 69) Clarify that EXAMINE does not affect \Recent.
yuuji@0 5599
yuuji@0 5600
yuuji@0 5601
yuuji@0 5602 Crispin Standards Track [Page 100]
yuuji@0 5603
yuuji@0 5604 RFC 3501 IMAPv4 March 2003
yuuji@0 5605
yuuji@0 5606
yuuji@0 5607 70) Make description of MIME structure consistent.
yuuji@0 5608
yuuji@0 5609 71) Clarify that date searches disregard the time and timezone of the
yuuji@0 5610 INTERNALDATE or Date: header. In other words, "ON 13-APR-2000" means
yuuji@0 5611 messages with an INTERNALDATE text which starts with "13-APR-2000",
yuuji@0 5612 even if timezone differential from the local timezone is sufficient
yuuji@0 5613 to move that INTERNALDATE into the previous or next day.
yuuji@0 5614
yuuji@0 5615 72) Clarify that the header fetches don't add a blank line if one
yuuji@0 5616 isn't in the [RFC-2822] message.
yuuji@0 5617
yuuji@0 5618 73) Clarify (in discussion of UIDs) that messages are immutable.
yuuji@0 5619
yuuji@0 5620 74) Add an example of CHARSET searching.
yuuji@0 5621
yuuji@0 5622 75) Clarify in SEARCH that keywords are a type of flag.
yuuji@0 5623
yuuji@0 5624 76) Clarify the mandatory nature of the SELECT data responses.
yuuji@0 5625
yuuji@0 5626 77) Add optional CAPABILITY response code in the initial OK or
yuuji@0 5627 PREAUTH.
yuuji@0 5628
yuuji@0 5629 78) Add note that server can send an untagged CAPABILITY command as
yuuji@0 5630 part of the responses to AUTHENTICATE and LOGIN.
yuuji@0 5631
yuuji@0 5632 79) Remove statement about it being unnecessary to issue a CAPABILITY
yuuji@0 5633 command more than once in a connection. That statement is no longer
yuuji@0 5634 true.
yuuji@0 5635
yuuji@0 5636 80) Clarify that untagged EXPUNGE decrements the number of messages
yuuji@0 5637 in the mailbox.
yuuji@0 5638
yuuji@0 5639 81) Fix definition of "body" (concatenation has tighter binding than
yuuji@0 5640 alternation).
yuuji@0 5641
yuuji@0 5642 82) Add a new "Special Notes to Implementors" section with reference
yuuji@0 5643 to [IMAP-IMPLEMENTATION].
yuuji@0 5644
yuuji@0 5645 83) Clarify that an untagged CAPABILITY response to an AUTHENTICATE
yuuji@0 5646 command should only be done if a security layer was not negotiated.
yuuji@0 5647
yuuji@0 5648 84) Change the definition of atom to exclude "]". Update astring to
yuuji@0 5649 include "]" for compatiblity with the past. Remove resp-text-atom.
yuuji@0 5650
yuuji@0 5651 85) Remove NEWNAME. It can't work because mailbox names can be
yuuji@0 5652 literals and can include "]". Functionality can be addressed via
yuuji@0 5653 referrals.
yuuji@0 5654
yuuji@0 5655
yuuji@0 5656
yuuji@0 5657
yuuji@0 5658 Crispin Standards Track [Page 101]
yuuji@0 5659
yuuji@0 5660 RFC 3501 IMAPv4 March 2003
yuuji@0 5661
yuuji@0 5662
yuuji@0 5663 86) Move modified UTF-7 rationale in order to have more logical
yuuji@0 5664 paragraph flow.
yuuji@0 5665
yuuji@0 5666 87) Clarify UID uniqueness guarantees with the use of MUST.
yuuji@0 5667
yuuji@0 5668 88) Note that clients should read response data until the connection
yuuji@0 5669 is closed instead of immediately closing on a BYE.
yuuji@0 5670
yuuji@0 5671 89) Change RFC-822 references to RFC-2822.
yuuji@0 5672
yuuji@0 5673 90) Clarify that RFC-2822 should be followed instead of RFC-822.
yuuji@0 5674
yuuji@0 5675 91) Change recommendation of optional automatic capabilities in LOGIN
yuuji@0 5676 and AUTHENTICATE to use the CAPABILITY response code in the tagged
yuuji@0 5677 OK. This is more interoperable than an unsolicited untagged
yuuji@0 5678 CAPABILITY response.
yuuji@0 5679
yuuji@0 5680 92) STARTTLS and AUTH=PLAIN are mandatory to implement; add
yuuji@0 5681 recommendations for other [SASL] mechanisms.
yuuji@0 5682
yuuji@0 5683 93) Clarify that a "connection" (as opposed to "server" or "command")
yuuji@0 5684 is in one of the four states.
yuuji@0 5685
yuuji@0 5686 94) Clarify that a failed or rejected command does not change state.
yuuji@0 5687
yuuji@0 5688 95) Split references between normative and informative.
yuuji@0 5689
yuuji@0 5690 96) Discuss authentication failure issues in security section.
yuuji@0 5691
yuuji@0 5692 97) Clarify that a data item is not necessarily of only one data
yuuji@0 5693 type.
yuuji@0 5694
yuuji@0 5695 98) Clarify that sequence ranges are independent of order.
yuuji@0 5696
yuuji@0 5697 99) Change an example to clarify that superfluous shifts in
yuuji@0 5698 Modified-UTF7 can not be fixed just by omitting the shift. The
yuuji@0 5699 entire string must be recalculated.
yuuji@0 5700
yuuji@0 5701 100) Change Envelope Structure definition since [RFC-2822] uses
yuuji@0 5702 "envelope" to refer to the [SMTP] envelope and not the envelope data
yuuji@0 5703 that appears in the [RFC-2822] header.
yuuji@0 5704
yuuji@0 5705 101) Expand on RFC822.HEADER response data vs. BODY[HEADER].
yuuji@0 5706
yuuji@0 5707 102) Clarify Logout state semantics, change ASCII art.
yuuji@0 5708
yuuji@0 5709 103) Security changes to comply with IESG requirements.
yuuji@0 5710
yuuji@0 5711
yuuji@0 5712
yuuji@0 5713
yuuji@0 5714 Crispin Standards Track [Page 102]
yuuji@0 5715
yuuji@0 5716 RFC 3501 IMAPv4 March 2003
yuuji@0 5717
yuuji@0 5718
yuuji@0 5719 104) Add definition for body URI.
yuuji@0 5720
yuuji@0 5721 105) Break sequence range definition into three rules, with rewritten
yuuji@0 5722 descriptions for each.
yuuji@0 5723
yuuji@0 5724 106) Move STARTTLS and LOGINDISABLED here from [IMAP-TLS].
yuuji@0 5725
yuuji@0 5726 107) Add IANA Considerations section.
yuuji@0 5727
yuuji@0 5728 108) Clarify valid client assumptions for new message UIDs vs.
yuuji@0 5729 UIDNEXT.
yuuji@0 5730
yuuji@0 5731 109) Clarify that changes to permanentflags affect concurrent
yuuji@0 5732 sessions as well as subsequent sessions.
yuuji@0 5733
yuuji@0 5734 110) Clarify that authenticated state can be entered by the CLOSE
yuuji@0 5735 command.
yuuji@0 5736
yuuji@0 5737 111) Emphasize that SELECT and EXAMINE are the exceptions to the rule
yuuji@0 5738 that a failing command does not change state.
yuuji@0 5739
yuuji@0 5740 112) Clarify that newly-appended messages have the Recent flag set.
yuuji@0 5741
yuuji@0 5742 113) Clarify that newly-copied messages SHOULD have the Recent flag
yuuji@0 5743 set.
yuuji@0 5744
yuuji@0 5745 114) Clarify that UID commands always return the UID in FETCH
yuuji@0 5746 responses.
yuuji@0 5747
yuuji@0 5748 C. Key Word Index
yuuji@0 5749
yuuji@0 5750 +FLAGS <flag list> (store command data item) ............... 59
yuuji@0 5751 +FLAGS.SILENT <flag list> (store command data item) ........ 59
yuuji@0 5752 -FLAGS <flag list> (store command data item) ............... 59
yuuji@0 5753 -FLAGS.SILENT <flag list> (store command data item) ........ 59
yuuji@0 5754 ALERT (response code) ...................................... 64
yuuji@0 5755 ALL (fetch item) ........................................... 55
yuuji@0 5756 ALL (search key) ........................................... 50
yuuji@0 5757 ANSWERED (search key) ...................................... 50
yuuji@0 5758 APPEND (command) ........................................... 45
yuuji@0 5759 AUTHENTICATE (command) ..................................... 27
yuuji@0 5760 BAD (response) ............................................. 66
yuuji@0 5761 BADCHARSET (response code) ................................. 64
yuuji@0 5762 BCC <string> (search key) .................................. 51
yuuji@0 5763 BEFORE <date> (search key) ................................. 51
yuuji@0 5764 BODY (fetch item) .......................................... 55
yuuji@0 5765 BODY (fetch result) ........................................ 73
yuuji@0 5766 BODY <string> (search key) ................................. 51
yuuji@0 5767
yuuji@0 5768
yuuji@0 5769
yuuji@0 5770 Crispin Standards Track [Page 103]
yuuji@0 5771
yuuji@0 5772 RFC 3501 IMAPv4 March 2003
yuuji@0 5773
yuuji@0 5774
yuuji@0 5775 BODY.PEEK[<section>]<<partial>> (fetch item) ............... 57
yuuji@0 5776 BODYSTRUCTURE (fetch item) ................................. 57
yuuji@0 5777 BODYSTRUCTURE (fetch result) ............................... 74
yuuji@0 5778 BODY[<section>]<<origin octet>> (fetch result) ............. 74
yuuji@0 5779 BODY[<section>]<<partial>> (fetch item) .................... 55
yuuji@0 5780 BYE (response) ............................................. 67
yuuji@0 5781 Body Structure (message attribute) ......................... 12
yuuji@0 5782 CAPABILITY (command) ....................................... 24
yuuji@0 5783 CAPABILITY (response code) ................................. 64
yuuji@0 5784 CAPABILITY (response) ...................................... 68
yuuji@0 5785 CC <string> (search key) ................................... 51
yuuji@0 5786 CHECK (command) ............................................ 47
yuuji@0 5787 CLOSE (command) ............................................ 48
yuuji@0 5788 COPY (command) ............................................. 59
yuuji@0 5789 CREATE (command) ........................................... 34
yuuji@0 5790 DELETE (command) ........................................... 35
yuuji@0 5791 DELETED (search key) ....................................... 51
yuuji@0 5792 DRAFT (search key) ......................................... 51
yuuji@0 5793 ENVELOPE (fetch item) ...................................... 57
yuuji@0 5794 ENVELOPE (fetch result) .................................... 77
yuuji@0 5795 EXAMINE (command) .......................................... 33
yuuji@0 5796 EXISTS (response) .......................................... 71
yuuji@0 5797 EXPUNGE (command) .......................................... 48
yuuji@0 5798 EXPUNGE (response) ......................................... 72
yuuji@0 5799 Envelope Structure (message attribute) ..................... 12
yuuji@0 5800 FAST (fetch item) .......................................... 55
yuuji@0 5801 FETCH (command) ............................................ 54
yuuji@0 5802 FETCH (response) ........................................... 73
yuuji@0 5803 FLAGGED (search key) ....................................... 51
yuuji@0 5804 FLAGS (fetch item) ......................................... 57
yuuji@0 5805 FLAGS (fetch result) ....................................... 78
yuuji@0 5806 FLAGS (response) ........................................... 71
yuuji@0 5807 FLAGS <flag list> (store command data item) ................ 59
yuuji@0 5808 FLAGS.SILENT <flag list> (store command data item) ......... 59
yuuji@0 5809 FROM <string> (search key) ................................. 51
yuuji@0 5810 FULL (fetch item) .......................................... 55
yuuji@0 5811 Flags (message attribute) .................................. 11
yuuji@0 5812 HEADER (part specifier) .................................... 55
yuuji@0 5813 HEADER <field-name> <string> (search key) .................. 51
yuuji@0 5814 HEADER.FIELDS <header-list> (part specifier) ............... 55
yuuji@0 5815 HEADER.FIELDS.NOT <header-list> (part specifier) ........... 55
yuuji@0 5816 INTERNALDATE (fetch item) .................................. 57
yuuji@0 5817 INTERNALDATE (fetch result) ................................ 78
yuuji@0 5818 Internal Date (message attribute) .......................... 12
yuuji@0 5819 KEYWORD <flag> (search key) ................................ 51
yuuji@0 5820 Keyword (type of flag) ..................................... 11
yuuji@0 5821 LARGER <n> (search key) .................................... 51
yuuji@0 5822 LIST (command) ............................................. 40
yuuji@0 5823
yuuji@0 5824
yuuji@0 5825
yuuji@0 5826 Crispin Standards Track [Page 104]
yuuji@0 5827
yuuji@0 5828 RFC 3501 IMAPv4 March 2003
yuuji@0 5829
yuuji@0 5830
yuuji@0 5831 LIST (response) ............................................ 69
yuuji@0 5832 LOGIN (command) ............................................ 30
yuuji@0 5833 LOGOUT (command) ........................................... 25
yuuji@0 5834 LSUB (command) ............................................. 43
yuuji@0 5835 LSUB (response) ............................................ 70
yuuji@0 5836 MAY (specification requirement term) ....................... 4
yuuji@0 5837 MESSAGES (status item) ..................................... 45
yuuji@0 5838 MIME (part specifier) ...................................... 56
yuuji@0 5839 MUST (specification requirement term) ...................... 4
yuuji@0 5840 MUST NOT (specification requirement term) .................. 4
yuuji@0 5841 Message Sequence Number (message attribute) ................ 10
yuuji@0 5842 NEW (search key) ........................................... 51
yuuji@0 5843 NO (response) .............................................. 66
yuuji@0 5844 NOOP (command) ............................................. 25
yuuji@0 5845 NOT <search-key> (search key) .............................. 52
yuuji@0 5846 OK (response) .............................................. 65
yuuji@0 5847 OLD (search key) ........................................... 52
yuuji@0 5848 ON <date> (search key) ..................................... 52
yuuji@0 5849 OPTIONAL (specification requirement term) .................. 4
yuuji@0 5850 OR <search-key1> <search-key2> (search key) ................ 52
yuuji@0 5851 PARSE (response code) ...................................... 64
yuuji@0 5852 PERMANENTFLAGS (response code) ............................. 64
yuuji@0 5853 PREAUTH (response) ......................................... 67
yuuji@0 5854 Permanent Flag (class of flag) ............................. 12
yuuji@0 5855 READ-ONLY (response code) .................................. 65
yuuji@0 5856 READ-WRITE (response code) ................................. 65
yuuji@0 5857 RECENT (response) .......................................... 72
yuuji@0 5858 RECENT (search key) ........................................ 52
yuuji@0 5859 RECENT (status item) ....................................... 45
yuuji@0 5860 RENAME (command) ........................................... 37
yuuji@0 5861 REQUIRED (specification requirement term) .................. 4
yuuji@0 5862 RFC822 (fetch item) ........................................ 57
yuuji@0 5863 RFC822 (fetch result) ...................................... 78
yuuji@0 5864 RFC822.HEADER (fetch item) ................................. 57
yuuji@0 5865 RFC822.HEADER (fetch result) ............................... 78
yuuji@0 5866 RFC822.SIZE (fetch item) ................................... 57
yuuji@0 5867 RFC822.SIZE (fetch result) ................................. 78
yuuji@0 5868 RFC822.TEXT (fetch item) ................................... 58
yuuji@0 5869 RFC822.TEXT (fetch result) ................................. 79
yuuji@0 5870 SEARCH (command) ........................................... 49
yuuji@0 5871 SEARCH (response) .......................................... 71
yuuji@0 5872 SEEN (search key) .......................................... 52
yuuji@0 5873 SELECT (command) ........................................... 31
yuuji@0 5874 SENTBEFORE <date> (search key) ............................. 52
yuuji@0 5875 SENTON <date> (search key) ................................. 52
yuuji@0 5876 SENTSINCE <date> (search key) .............................. 52
yuuji@0 5877 SHOULD (specification requirement term) .................... 4
yuuji@0 5878 SHOULD NOT (specification requirement term) ................ 4
yuuji@0 5879
yuuji@0 5880
yuuji@0 5881
yuuji@0 5882 Crispin Standards Track [Page 105]
yuuji@0 5883
yuuji@0 5884 RFC 3501 IMAPv4 March 2003
yuuji@0 5885
yuuji@0 5886
yuuji@0 5887 SINCE <date> (search key) .................................. 52
yuuji@0 5888 SMALLER <n> (search key) ................................... 52
yuuji@0 5889 STARTTLS (command) ......................................... 27
yuuji@0 5890 STATUS (command) ........................................... 44
yuuji@0 5891 STATUS (response) .......................................... 70
yuuji@0 5892 STORE (command) ............................................ 58
yuuji@0 5893 SUBJECT <string> (search key) .............................. 53
yuuji@0 5894 SUBSCRIBE (command) ........................................ 38
yuuji@0 5895 Session Flag (class of flag) ............................... 12
yuuji@0 5896 System Flag (type of flag) ................................. 11
yuuji@0 5897 TEXT (part specifier) ...................................... 56
yuuji@0 5898 TEXT <string> (search key) ................................. 53
yuuji@0 5899 TO <string> (search key) ................................... 53
yuuji@0 5900 TRYCREATE (response code) .................................. 65
yuuji@0 5901 UID (command) .............................................. 60
yuuji@0 5902 UID (fetch item) ........................................... 58
yuuji@0 5903 UID (fetch result) ......................................... 79
yuuji@0 5904 UID <sequence set> (search key) ............................ 53
yuuji@0 5905 UIDNEXT (response code) .................................... 65
yuuji@0 5906 UIDNEXT (status item) ...................................... 45
yuuji@0 5907 UIDVALIDITY (response code) ................................ 65
yuuji@0 5908 UIDVALIDITY (status item) .................................. 45
yuuji@0 5909 UNANSWERED (search key) .................................... 53
yuuji@0 5910 UNDELETED (search key) ..................................... 53
yuuji@0 5911 UNDRAFT (search key) ....................................... 53
yuuji@0 5912 UNFLAGGED (search key) ..................................... 53
yuuji@0 5913 UNKEYWORD <flag> (search key) .............................. 53
yuuji@0 5914 UNSEEN (response code) ..................................... 65
yuuji@0 5915 UNSEEN (search key) ........................................ 53
yuuji@0 5916 UNSEEN (status item) ....................................... 45
yuuji@0 5917 UNSUBSCRIBE (command) ...................................... 39
yuuji@0 5918 Unique Identifier (UID) (message attribute) ................ 8
yuuji@0 5919 X<atom> (command) .......................................... 62
yuuji@0 5920 [RFC-2822] Size (message attribute) ........................ 12
yuuji@0 5921 \Answered (system flag) .................................... 11
yuuji@0 5922 \Deleted (system flag) ..................................... 11
yuuji@0 5923 \Draft (system flag) ....................................... 11
yuuji@0 5924 \Flagged (system flag) ..................................... 11
yuuji@0 5925 \Marked (mailbox name attribute) ........................... 69
yuuji@0 5926 \Noinferiors (mailbox name attribute) ...................... 69
yuuji@0 5927 \Noselect (mailbox name attribute) ......................... 69
yuuji@0 5928 \Recent (system flag) ...................................... 11
yuuji@0 5929 \Seen (system flag) ........................................ 11
yuuji@0 5930 \Unmarked (mailbox name attribute) ......................... 69
yuuji@0 5931
yuuji@0 5932
yuuji@0 5933
yuuji@0 5934
yuuji@0 5935
yuuji@0 5936
yuuji@0 5937
yuuji@0 5938 Crispin Standards Track [Page 106]
yuuji@0 5939
yuuji@0 5940 RFC 3501 IMAPv4 March 2003
yuuji@0 5941
yuuji@0 5942
yuuji@0 5943 Author's Address
yuuji@0 5944
yuuji@0 5945 Mark R. Crispin
yuuji@0 5946 Networks and Distributed Computing
yuuji@0 5947 University of Washington
yuuji@0 5948 4545 15th Avenue NE
yuuji@0 5949 Seattle, WA 98105-4527
yuuji@0 5950
yuuji@0 5951 Phone: (206) 543-5762
yuuji@0 5952
yuuji@0 5953 EMail: MRC@CAC.Washington.EDU
yuuji@0 5954
yuuji@0 5955
yuuji@0 5956
yuuji@0 5957
yuuji@0 5958
yuuji@0 5959
yuuji@0 5960
yuuji@0 5961
yuuji@0 5962
yuuji@0 5963
yuuji@0 5964
yuuji@0 5965
yuuji@0 5966
yuuji@0 5967
yuuji@0 5968
yuuji@0 5969
yuuji@0 5970
yuuji@0 5971
yuuji@0 5972
yuuji@0 5973
yuuji@0 5974
yuuji@0 5975
yuuji@0 5976
yuuji@0 5977
yuuji@0 5978
yuuji@0 5979
yuuji@0 5980
yuuji@0 5981
yuuji@0 5982
yuuji@0 5983
yuuji@0 5984
yuuji@0 5985
yuuji@0 5986
yuuji@0 5987
yuuji@0 5988
yuuji@0 5989
yuuji@0 5990
yuuji@0 5991
yuuji@0 5992
yuuji@0 5993
yuuji@0 5994 Crispin Standards Track [Page 107]
yuuji@0 5995
yuuji@0 5996 RFC 3501 IMAPv4 March 2003
yuuji@0 5997
yuuji@0 5998
yuuji@0 5999 Full Copyright Statement
yuuji@0 6000
yuuji@0 6001 Copyright (C) The Internet Society (2003). All Rights Reserved.
yuuji@0 6002
yuuji@0 6003 This document and translations of it may be copied and furnished to
yuuji@0 6004 others, and derivative works that comment on or otherwise explain it
yuuji@0 6005 or assist in its implementation may be prepared, copied, published
yuuji@0 6006 and distributed, in whole or in part, without restriction of any
yuuji@0 6007 kind, provided that the above copyright notice and this paragraph are
yuuji@0 6008 included on all such copies and derivative works. However, this
yuuji@0 6009 document itself may not be modified in any way, such as by removing
yuuji@0 6010 the copyright notice or references to the Internet Society or other
yuuji@0 6011 Internet organizations, except as needed for the purpose of
yuuji@0 6012 developing Internet standards in which case the procedures for
yuuji@0 6013 copyrights defined in the Internet Standards process must be
yuuji@0 6014 followed, or as required to translate it into languages other than
yuuji@0 6015 English.
yuuji@0 6016
yuuji@0 6017 The limited permissions granted above are perpetual and will not be
yuuji@0 6018 revoked by the Internet Society or its successors or assigns. v This
yuuji@0 6019 document and the information contained herein is provided on an "AS
yuuji@0 6020 IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK
yuuji@0 6021 FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT
yuuji@0 6022 LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL
yuuji@0 6023 NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY
yuuji@0 6024 OR FITNESS FOR A PARTICULAR PURPOSE.
yuuji@0 6025
yuuji@0 6026 Acknowledgement
yuuji@0 6027
yuuji@0 6028 Funding for the RFC Editor function is currently provided by the
yuuji@0 6029 Internet Society.
yuuji@0 6030
yuuji@0 6031
yuuji@0 6032
yuuji@0 6033
yuuji@0 6034
yuuji@0 6035
yuuji@0 6036
yuuji@0 6037
yuuji@0 6038
yuuji@0 6039
yuuji@0 6040
yuuji@0 6041
yuuji@0 6042
yuuji@0 6043
yuuji@0 6044
yuuji@0 6045
yuuji@0 6046
yuuji@0 6047
yuuji@0 6048
yuuji@0 6049
yuuji@0 6050 Crispin Standards Track [Page 108]
yuuji@0 6051
yuuji@0 6052

UW-IMAP'd extensions by yuuji