7
Network Working Group A. Melnikov
8
Request for Comments: 3503 ACI Worldwide/MessagingDirect
9
Category: 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.
58
Melnikov Standards Track [Page 1]
60
RFC 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
84
1. 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"
94
2. 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.
114
Melnikov Standards Track [Page 2]
116
RFC 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
170
Melnikov Standards Track [Page 3]
172
RFC 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
226
Melnikov Standards Track [Page 4]
228
RFC 3503 MDN profile for IMAP March 2003
231
3.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
240
3.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
247
3.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
253
3.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.
266
4.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
272
4.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.
282
Melnikov Standards Track [Page 5]
284
RFC 3503 MDN profile for IMAP March 2003
287
4.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
338
Melnikov Standards Track [Page 6]
340
RFC 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
358
6. 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
394
Melnikov Standards Track [Page 7]
396
RFC 3503 MDN profile for IMAP March 2003
399
9. 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
450
Melnikov Standards Track [Page 8]
452
RFC 3503 MDN profile for IMAP March 2003
455
11. 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
506
Melnikov Standards Track [Page 9]
added
removed
imap/docs/rfc/rfc3503.txt
