rfc3503.txt (16937B)
1 2 3 4 5 6 7 Network Working Group A. Melnikov 8 Request for Comments: 3503 ACI Worldwide/MessagingDirect 9 Category: Standards Track March 2003 10 11 12 Message Disposition Notification (MDN) profile for 13 Internet Message Access Protocol (IMAP) 14 15 Status of this Memo 16 17 This document specifies an Internet standards track protocol for the 18 Internet community, and requests discussion and suggestions for 19 improvements. Please refer to the current edition of the "Internet 20 Official Protocol Standards" (STD 1) for the standardization state 21 and status of this protocol. Distribution of this memo is unlimited. 22 23 Copyright Notice 24 25 Copyright (C) The Internet Society (2003). All Rights Reserved. 26 27 Abstract 28 29 The Message Disposition Notification (MDN) facility defined in RFC 30 2298 provides a means by which a message can request that message 31 processing by the recipient be acknowledged as well as a format to be 32 used for such acknowledgements. However, it doesn't describe how 33 multiple Mail User Agents (MUAs) should handle the generation of MDNs 34 in an Internet Message Access Protocol (IMAP4) environment. 35 36 This document describes how to handle MDNs in such an environment and 37 provides guidelines for implementers of IMAP4 that want to add MDN 38 support to their products. 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 Melnikov Standards Track [Page 1] 59 60 RFC 3503 MDN profile for IMAP March 2003 61 62 63 Table of Contents 64 65 1. Conventions Used in this Document............................. 2 66 2. Introduction and Overview..................................... 2 67 3. Client behavior............................................... 3 68 3.1. Client behavior when receiving a message................. 5 69 3.2. Client behavior when copying a message................... 5 70 3.3. Client behavior when sending a message................... 5 71 3.4. Client behavior when saving a temporary message.......... 5 72 4. Server behavior............................................... 5 73 4.1. Server that supports arbitrary keywords.................. 5 74 4.2. Server that supports only $MDNSent keyword............... 5 75 4.3. Interaction with IMAP ACL extension...................... 6 76 5. Examples...................................................... 6 77 6. Security Considerations....................................... 7 78 7. Formal Syntax................................................. 7 79 8. Acknowledgments............................................... 7 80 9. Normative References.......................................... 8 81 10. Author's Address.............................................. 8 82 11. Full Copyright Statement...................................... 9 83 84 1. Conventions Used in this Document 85 86 "C:" and "S:" in examples show lines sent by the client and server 87 respectively. 88 89 The keywords "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" in 90 this document when typed in uppercase are to be interpreted as 91 defined in "Key words for use in RFCs to Indicate Requirement Levels" 92 [KEYWORDS]. 93 94 2. Introduction and Overview 95 96 This memo defines an additional [IMAP4] mailbox keyword that allows 97 multiple Mail User Agents (MUAs) to know if a requested receipt 98 notification was sent. 99 100 Message Disposition Notification [MDN] does not require any special 101 support of IMAP in the case where a user has access to the mailstore 102 from only one computer and is using a single MUA. In this case, the 103 MUA behaves as described in [MDN], i.e., the MUA performs automatic 104 processing and generates corresponding MDNs, it performs requested 105 action and, with the user's permission, sends appropriate MDNs. The 106 MUA will not send MDN twice because the MUA keeps track of sent 107 notifications in a local configuration. However, that does not work 108 when IMAP is used to access the same mailstore from different 109 locations or is using different MUAs. 110 111 112 113 114 Melnikov Standards Track [Page 2] 115 116 RFC 3503 MDN profile for IMAP March 2003 117 118 119 This document defines a new special purpose mailbox keyword $MDNSent 120 that must be used by MUAs. It does not define any new command or 121 response for IMAP, but describes a technique that MUAs should use to 122 achieve interoperability. 123 124 When a client opens a mailbox for the first time, it verifies that 125 the server is capable of storing the $MDNSent keyword by examining 126 the PERMANENTFLAGS response code. In order to support MDN in IMAP, a 127 server MUST support either the $MDNSent keyword, or arbitrary message 128 keywords. 129 130 3. Client behavior 131 132 The use of IMAP requires few additional steps in mail processing on 133 the client side. The following timeline modifies the timeline found 134 in Section 4 of [MDN]. 135 136 -- User composes message. 137 138 -- User tells MUA to send message. 139 140 -- MUA passes message to MSA (original recipient information passed 141 along). MUA [optionally] saves message to a folder for sent mail 142 with $MDNSent flag set. 143 144 -- MSA sends message to MTA. 145 146 -- Final MTA receives message. 147 148 -- Final MTA delivers message to MUA (possibly generating DSN). 149 150 -- MUA logs into IMAP server, opens mailbox, verifies if mailbox can 151 store $MDNSent keyword by examining PERMANENTFLAGS response. 152 153 -- MUA performs automatic processing and generates corresponding MDNs 154 ("dispatched", "processed", "deleted", "denied" or "failed" 155 disposition type with "automatic-action" and "MDN-sent- 156 automatically" disposition modes) for messages that do not have 157 $MDNSent keyword, or \Draft flag set. (*) 158 159 -- MUA sets the $MDNSent keyword for every message that required an 160 automatic MDN to be sent, whether or not the MDN was sent. 161 162 -- MUA displays a list of messages to user. 163 164 -- User selects a message and requests that some action be performed 165 on it. 166 167 168 169 170 Melnikov Standards Track [Page 3] 171 172 RFC 3503 MDN profile for IMAP March 2003 173 174 175 -- MUA performs requested action and, with user's permission, sends 176 appropriate MDN ("displayed", "dispatched", "processed", 177 "deleted", "denied" or "failed" disposition type with "manual- 178 action" and "MDN-sent-manually" or "MDN-sent-automatically" 179 disposition mode). If the generated MDN is saved to a mailbox 180 with the APPEND command, the client MUST specify the $MDNSent 181 keyword in the APPEND. 182 183 -- MUA sets the $MDNSent keyword for all messages for which the user 184 confirmed the dispatching of disposition (or was explicitly 185 prohibited to do so). 186 187 -- User possibly performs other actions on message, but no further 188 MDNs are generated. 189 190 (*) Note: MUA MUST NOT use \Recent flag as an indicator that it 191 should send MDN, because according to [IMAP4], "If multiple 192 connections have the same mailbox selected simultaneously, it is 193 undefined which of these connections will see newly-arrived 194 messages with \Recent set and which will see it without \Recent 195 set". Thus, using \Recent as an indicator will cause 196 unpredictable client behavior with different IMAP4 servers. 197 However, the client MAY use \Seen flag as one of the indicators 198 that MDN must not be sent. The client MUST NOT use any other 199 standard flags, like \Draft or \Answered, to indicate that MDN 200 was previously sent, because they have different well known 201 meaning. In any case, in the presence of the $MDNSent keyword, 202 the client MUST ignore all other flags or keywords for the 203 purpose of generating an MDN and MUST NOT send the MDN. 204 205 When the client opens a mailbox for the first time, it must verify 206 that the server supports the $MDNSent keyword, or arbitrary message 207 keywords by examining PERMANENTFLAGS response code. 208 209 The client MUST NOT try to set the $MDNSent keyword if the server is 210 incapable of storing it permanently. 211 212 The client MUST be prepared to receive NO from the server as the 213 result of STORE $MDNSent when the server advertises the support of 214 storing arbitrary keywords, because the server may limit the number 215 of message keywords it can store in a particular mailbox. A client 216 SHOULD NOT send MDN if it fails to store the $MDNSent keyword. 217 218 Once the $MDNSent keyword is set, it MUST NOT be unset by a client. 219 The client MAY set the $MDNSent keyword when a user denies sending 220 the notification. This prohibits all other MUAs from sending MDN for 221 this message. 222 223 224 225 226 Melnikov Standards Track [Page 4] 227 228 RFC 3503 MDN profile for IMAP March 2003 229 230 231 3.1. Client behavior when receiving a message 232 233 The client MUST NOT send MDN if a message has the $MDNSent keyword 234 set. It also MUST NOT send MDN if a message has \Draft flag, because 235 some clients use this flag to mark a message as incomplete. 236 237 See the timeline in section 3 for details on client behavior when 238 receiving a message. 239 240 3.2. Client behavior when copying a message 241 242 The client SHOULD verify that $MDNSent is preserved on a COPY 243 operation. Furthermore, when a message is copied between servers 244 with the APPEND command, the client MUST set the $MDNSent keyword 245 correctly. 246 247 3.3. Client behavior when sending a message 248 249 When saving a sent message to any folder, the client MUST set the 250 $MDNSent keyword to prevent another client from sending MDN for the 251 message. 252 253 3.4. Client behavior when saving a temporary message 254 255 When saving an unfinished message to any folder client MUST set 256 $MDNSent keyword to prevent another client from sending MDN for the 257 message. 258 259 4. Server behavior 260 261 Server implementors that want to follow this specification must 262 insure that their server complies with either section 4.1 or section 263 4.2. If the server also supports the IMAP [ACL] extension, it MUST 264 also comply with the section 4.3. 265 266 4.1. Server that supports arbitrary keywords 267 268 No changes are required from the server to make it compatible with 269 the extension described in this document if it supports arbitrary 270 keywords. 271 272 4.2. Server that supports only $MDNSent keyword 273 274 Servers that support only the $MDNSent keyword MUST preserve it on 275 the COPY operation. It is also expected that a server that supports 276 SEARCH <flag> will also support the SEARCH KEYWORD $MDNSent. 277 278 279 280 281 282 Melnikov Standards Track [Page 5] 283 284 RFC 3503 MDN profile for IMAP March 2003 285 286 287 4.3. Interaction with IMAP ACL extension 288 289 Any server that conforms to either 4.1 or 4.2 and also supports the 290 IMAP [ACL] extension, SHOULD preserve the $MDNSent keyword on COPY 291 even if the client does not have 'w' right. This will prevent the 292 generation of a duplicated MDN for the same message. Note that the 293 server MUST still check if the client has rights to perform the COPY 294 operation on a message according to [ACL]. 295 296 5. Examples 297 298 1) MUA opens mailbox for the first time. 299 300 a) The server supports storing of arbitrary keywords 301 302 C: a100 select INBOX 303 S: * FLAGS (\Flagged \Draft \Deleted \Seen) 304 S: * OK [PERMANENTFLAGS (\Flagged \Draft \Deleted \Seen \*)] 305 S: * 5 EXISTS 306 S: * 3 RECENT 307 S: * OK [UIDVALIDITY 894294713] 308 S: a100 OK [READ-WRITE] Completed 309 310 b) The server supports storing of the $MDNSent keyword 311 312 C: a100 select INBOX 313 S: * FLAGS (\Flagged \Draft \Deleted \Seen $MDNSent) 314 S: * OK [PERMANENTFLAGS (\Flagged \Draft \Deleted \Seen $MDNSent)] 315 S: * 5 EXISTS 316 S: * 3 RECENT 317 S: * OK [UIDVALIDITY 894294713] 318 S: a100 OK [READ-WRITE] Completed 319 320 2) The MUA successfully sets the $MDNSent keyword 321 322 C: a200 STORE 4 +FLAGS ($MDNSent) 323 S: * 4 FETCH (FLAGS (\Flagged \Seen $MDNSent)) 324 S: * FLAGS ($MDNSent \Flagged \Deleted \Draft \Seen) 325 S: * OK [PERMANENTFLAGS ($MDNSent \Flagged \Deleted \Draft \Seen \*)] 326 S: a200 OK STORE completed 327 328 3) The server refuses to store the $MDNSent keyword 329 330 C: a200 STORE 4 +FLAGS ($MDNSent) 331 S: a200 NO STORE failed : no space left to store $MDNSent keyword 332 333 334 335 336 337 338 Melnikov Standards Track [Page 6] 339 340 RFC 3503 MDN profile for IMAP March 2003 341 342 343 4) All clients and servers MUST treat the $MDNSent keyword as case 344 insensitive in all operations, as stated in [IMAP]. 345 346 C: a300 FETCH 1:* FLAGS 347 S: * 1 FETCH (FLAGS (\Seen)) 348 S: * 2 FETCH (FLAGS (\Answered \Seen $MdnSENt)) 349 S: * 3 FETCH (FLAGS ()) 350 S: * 4 FETCH (FLAGS (\Flagged \Seen $MdnSENT)) 351 S: * 5 FETCH (FLAGS ($MDNSent)) 352 S: * 6 FETCH (FLAGS (\Recent)) 353 S: a300 OK FETCH completed 354 C: a400 SEARCH KEYWORDS $mdnsent 355 S: * SEARCH 2 4 5 356 S: a400 OK SEARCH completed 357 358 6. Security Considerations 359 360 There are no known security issues with this extension, not found in 361 [MDN] and/or [IMAP4]. 362 363 Section 4.3 changes ACL checking requirements on an IMAP server that 364 implements IMAP [ACL] extension. 365 366 7. Formal Syntax 367 368 The following syntax specification uses the augmented Backus-Naur 369 Form (BNF) notation as specified in [RFC-822], as modified by 370 [IMAP4]. Non-terminals referenced, but not defined below, are as 371 defined by [IMAP4]. 372 373 Except as noted otherwise, all alphabetic characters are case- 374 insensitive. The use of upper or lower case characters to define 375 token strings is for editorial clarity only. Implementations MUST 376 accept these strings in a case-insensitive fashion. 377 378 flag_keyword ::= "$MDNSent" / other_keywords 379 380 other_keywords ::= atom 381 382 8. Acknowledgments 383 384 This document is the product of discussions that took place on the 385 IMAP mailing list. Special gratitude to Cyrus Daboo and Randall 386 Gellens for reviewing the document. 387 388 Thank you to my father who as he has helped to make me what I am. I 389 miss you terribly. 390 391 392 393 394 Melnikov Standards Track [Page 7] 395 396 RFC 3503 MDN profile for IMAP March 2003 397 398 399 9. Normative References 400 401 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate 402 Requirement Levels", BCP 14, RFC 2119, March 1997. 403 404 [MDN] Fajman, R., "An Extensible Message Format for Message 405 Disposition Notifications", RFC 2298, March 1998. 406 407 [IMAP4] Crispin, M., "Internet Message Access Protocol - Version 408 4rev1", RFC 3501, March 2003. 409 410 [ACL] Myers, J., "IMAP4 ACL extension", RFC 2086, January 1997. 411 412 10. Author's Address 413 414 Alexey Melnikov 415 ACI Worldwide/MessagingDirect 416 59 Clarendon Road 417 Watford, Hertfordshire 418 United Kingdom, WD17 1FQ 419 420 Phone: +44 1923 81 2877 421 EMail: mel@messagingdirect.com 422 423 424 425 426 427 428 429 430 431 432 433 434 435 436 437 438 439 440 441 442 443 444 445 446 447 448 449 450 Melnikov Standards Track [Page 8] 451 452 RFC 3503 MDN profile for IMAP March 2003 453 454 455 11. Full Copyright Statement 456 457 Copyright (C) The Internet Society (2003). All Rights Reserved. 458 459 This document and translations of it may be copied and furnished to 460 others, and derivative works that comment on or otherwise explain it 461 or assist in its implementation may be prepared, copied, published 462 and distributed, in whole or in part, without restriction of any 463 kind, provided that the above copyright notice and this paragraph are 464 included on all such copies and derivative works. However, this 465 document itself may not be modified in any way, such as by removing 466 the copyright notice or references to the Internet Society or other 467 Internet organizations, except as needed for the purpose of 468 developing Internet standards in which case the procedures for 469 copyrights defined in the Internet Standards process must be 470 followed, or as required to translate it into languages other than 471 English. 472 473 The limited permissions granted above are perpetual and will not be 474 revoked by the Internet Society or its successors or assigns. 475 476 This document and the information contained herein is provided on an 477 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 478 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 479 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 480 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 481 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 482 483 Acknowledgement 484 485 Funding for the RFC Editor function is currently provided by the 486 Internet Society. 487 488 489 490 491 492 493 494 495 496 497 498 499 500 501 502 503 504 505 506 Melnikov Standards Track [Page 9] 507