7Network Working Group A. Melnikov
8Request for Comments: 3503 ACI Worldwide/MessagingDirect
9Category: Standards Track March 2003
12 Message Disposition Notification (MDN) profile for
13 Internet Message Access Protocol (IMAP)
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.
25 Copyright (C) The Internet Society (2003). All Rights Reserved.
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.
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.
58Melnikov Standards Track [Page 1]
60RFC 3503 MDN profile for IMAP March 2003
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
841. Conventions Used in this Document
86 "C:" and "S:" in examples show lines sent by the client and server
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"
942. Introduction and Overview
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.
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.
114Melnikov Standards Track [Page 2]
116RFC 3503 MDN profile for IMAP March 2003
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.
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
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].
136 -- User composes message.
138 -- User tells MUA to send message.
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.
144 -- MSA sends message to MTA.
146 -- Final MTA receives message.
148 -- Final MTA delivers message to MUA (possibly generating DSN).
150 -- MUA logs into IMAP server, opens mailbox, verifies if mailbox can
151 store $MDNSent keyword by examining PERMANENTFLAGS response.
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. (*)
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.
162 -- MUA displays a list of messages to user.
164 -- User selects a message and requests that some action be performed
170Melnikov Standards Track [Page 3]
172RFC 3503 MDN profile for IMAP March 2003
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.
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).
187 -- User possibly performs other actions on message, but no further
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.
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.
209 The client MUST NOT try to set the $MDNSent keyword if the server is
210 incapable of storing it permanently.
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.
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
226Melnikov Standards Track [Page 4]
228RFC 3503 MDN profile for IMAP March 2003
2313.1. Client behavior when receiving a message
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.
237 See the timeline in section 3 for details on client behavior when
2403.2. Client behavior when copying a message
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
2473.3. Client behavior when sending a message
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
2533.4. Client behavior when saving a temporary message
255 When saving an unfinished message to any folder client MUST set
256 $MDNSent keyword to prevent another client from sending MDN for the
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.
2664.1. Server that supports arbitrary keywords
268 No changes are required from the server to make it compatible with
269 the extension described in this document if it supports arbitrary
2724.2. Server that supports only $MDNSent keyword
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.
282Melnikov Standards Track [Page 5]
284RFC 3503 MDN profile for IMAP March 2003
2874.3. Interaction with IMAP ACL extension
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].
298 1) MUA opens mailbox for the first time.
300 a) The server supports storing of arbitrary keywords
303 S: * FLAGS (\Flagged \Draft \Deleted \Seen)
304 S: * OK [PERMANENTFLAGS (\Flagged \Draft \Deleted \Seen \*)]
307 S: * OK [UIDVALIDITY 894294713]
308 S: a100 OK [READ-WRITE] Completed
310 b) The server supports storing of the $MDNSent keyword
313 S: * FLAGS (\Flagged \Draft \Deleted \Seen $MDNSent)
314 S: * OK [PERMANENTFLAGS (\Flagged \Draft \Deleted \Seen $MDNSent)]
317 S: * OK [UIDVALIDITY 894294713]
318 S: a100 OK [READ-WRITE] Completed
320 2) The MUA successfully sets the $MDNSent keyword
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
328 3) The server refuses to store the $MDNSent keyword
330 C: a200 STORE 4 +FLAGS ($MDNSent)
331 S: a200 NO STORE failed : no space left to store $MDNSent keyword
338Melnikov Standards Track [Page 6]
340RFC 3503 MDN profile for IMAP March 2003
343 4) All clients and servers MUST treat the $MDNSent keyword as case
344 insensitive in all operations, as stated in [IMAP].
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
356 S: a400 OK SEARCH completed
3586. Security Considerations
360 There are no known security issues with this extension, not found in
361 [MDN] and/or [IMAP4].
363 Section 4.3 changes ACL checking requirements on an IMAP server that
364 implements IMAP [ACL] extension.
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
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.
378 flag_keyword ::= "$MDNSent" / other_keywords
380 other_keywords ::= atom
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.
388 Thank you to my father who as he has helped to make me what I am. I
394Melnikov Standards Track [Page 7]
396RFC 3503 MDN profile for IMAP March 2003
3999. Normative References
401 [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
402 Requirement Levels", BCP 14, RFC 2119, March 1997.
404 [MDN] Fajman, R., "An Extensible Message Format for Message
405 Disposition Notifications", RFC 2298, March 1998.
407 [IMAP4] Crispin, M., "Internet Message Access Protocol - Version
408 4rev1", RFC 3501, March 2003.
410 [ACL] Myers, J., "IMAP4 ACL extension", RFC 2086, January 1997.
415 ACI Worldwide/MessagingDirect
417 Watford, Hertfordshire
418 United Kingdom, WD17 1FQ
420 Phone: +44 1923 81 2877
421 EMail: mel@messagingdirect.com
450Melnikov Standards Track [Page 8]
452RFC 3503 MDN profile for IMAP March 2003
45511. Full Copyright Statement
457 Copyright (C) The Internet Society (2003). All Rights Reserved.
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
473 The limited permissions granted above are perpetual and will not be
474 revoked by the Internet Society or its successors or assigns.
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.
485 Funding for the RFC Editor function is currently provided by the
506Melnikov Standards Track [Page 9]