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