1.1 --- /dev/null	Thu Jan 01 00:00:00 1970 +0000
     1.2 +++ b/docs/rfc/rfc3503.txt	Mon Sep 14 15:17:45 2009 +0900
     1.3 @@ -0,0 +1,507 @@
     1.4 +
     1.5 +
     1.6 +
     1.7 +
     1.8 +
     1.9 +
    1.10 +Network Working Group                                        A. Melnikov
    1.11 +Request for Comments: 3503                 ACI Worldwide/MessagingDirect
    1.12 +Category: Standards Track                                     March 2003
    1.13 +
    1.14 +
    1.15 +          Message Disposition Notification (MDN) profile for
    1.16 +                Internet Message Access Protocol (IMAP)
    1.17 +
    1.18 +Status of this Memo
    1.19 +
    1.20 +   This document specifies an Internet standards track protocol for the
    1.21 +   Internet community, and requests discussion and suggestions for
    1.22 +   improvements.  Please refer to the current edition of the "Internet
    1.23 +   Official Protocol Standards" (STD 1) for the standardization state
    1.24 +   and status of this protocol.  Distribution of this memo is unlimited.
    1.25 +
    1.26 +Copyright Notice
    1.27 +
    1.28 +   Copyright (C) The Internet Society (2003).  All Rights Reserved.
    1.29 +
    1.30 +Abstract
    1.31 +
    1.32 +   The Message Disposition Notification (MDN) facility defined in RFC
    1.33 +   2298 provides a means by which a message can request that message
    1.34 +   processing by the recipient be acknowledged as well as a format to be
    1.35 +   used for such acknowledgements.  However, it doesn't describe how
    1.36 +   multiple Mail User Agents (MUAs) should handle the generation of MDNs
    1.37 +   in an Internet Message Access Protocol (IMAP4) environment.
    1.38 +
    1.39 +   This document describes how to handle MDNs in such an environment and
    1.40 +   provides guidelines for implementers of IMAP4 that want to add MDN
    1.41 +   support to their products.
    1.42 +
    1.43 +
    1.44 +
    1.45 +
    1.46 +
    1.47 +
    1.48 +
    1.49 +
    1.50 +
    1.51 +
    1.52 +
    1.53 +
    1.54 +
    1.55 +
    1.56 +
    1.57 +
    1.58 +
    1.59 +
    1.60 +
    1.61 +Melnikov                    Standards Track                     [Page 1]
    1.62 +
    1.63 +RFC 3503                  MDN profile for IMAP                March 2003
    1.64 +
    1.65 +
    1.66 +Table of Contents
    1.67 +
    1.68 +   1.  Conventions Used in this Document.............................  2
    1.69 +   2.  Introduction and Overview.....................................  2
    1.70 +   3.  Client behavior...............................................  3
    1.71 +       3.1. Client behavior when receiving a message.................  5
    1.72 +       3.2. Client behavior when copying a message...................  5
    1.73 +       3.3. Client behavior when sending a message...................  5
    1.74 +       3.4. Client behavior when saving a temporary message..........  5
    1.75 +   4.  Server behavior...............................................  5
    1.76 +       4.1. Server that supports arbitrary keywords..................  5
    1.77 +       4.2. Server that supports only $MDNSent keyword...............  5
    1.78 +       4.3. Interaction with IMAP ACL extension......................  6
    1.79 +   5.  Examples......................................................  6
    1.80 +   6.  Security Considerations.......................................  7
    1.81 +   7.  Formal Syntax.................................................  7
    1.82 +   8.  Acknowledgments...............................................  7
    1.83 +   9.  Normative References..........................................  8
    1.84 +   10. Author's Address..............................................  8
    1.85 +   11. Full Copyright Statement......................................  9
    1.86 +
    1.87 +1.  Conventions Used in this Document
    1.88 +
    1.89 +   "C:" and "S:" in examples show lines sent by the client and server
    1.90 +   respectively.
    1.91 +
    1.92 +   The keywords "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" in
    1.93 +   this document when typed in uppercase are to be interpreted as
    1.94 +   defined in "Key words for use in RFCs to Indicate Requirement Levels"
    1.95 +   [KEYWORDS].
    1.96 +
    1.97 +2.  Introduction and Overview
    1.98 +
    1.99 +   This memo defines an additional [IMAP4] mailbox keyword that allows
   1.100 +   multiple Mail User Agents (MUAs) to know if a requested receipt
   1.101 +   notification was sent.
   1.102 +
   1.103 +   Message Disposition Notification [MDN] does not require any special
   1.104 +   support of IMAP in the case where a user has access to the mailstore
   1.105 +   from only one computer and is using a single MUA.  In this case, the
   1.106 +   MUA behaves as described in [MDN], i.e., the MUA performs automatic
   1.107 +   processing and generates corresponding MDNs, it performs requested
   1.108 +   action and, with the user's permission, sends appropriate MDNs.  The
   1.109 +   MUA will not send MDN twice because the MUA keeps track of sent
   1.110 +   notifications in a local configuration.  However, that does not work
   1.111 +   when IMAP is used to access the same mailstore from different
   1.112 +   locations or is using different MUAs.
   1.113 +
   1.114 +
   1.115 +
   1.116 +
   1.117 +Melnikov                    Standards Track                     [Page 2]
   1.118 +
   1.119 +RFC 3503                  MDN profile for IMAP                March 2003
   1.120 +
   1.121 +
   1.122 +   This document defines a new special purpose mailbox keyword $MDNSent
   1.123 +   that must be used by MUAs.  It does not define any new command or
   1.124 +   response for IMAP, but describes a technique that MUAs should use to
   1.125 +   achieve interoperability.
   1.126 +
   1.127 +   When a client opens a mailbox for the first time, it verifies that
   1.128 +   the server is capable of storing the $MDNSent keyword by examining
   1.129 +   the PERMANENTFLAGS response code.  In order to support MDN in IMAP, a
   1.130 +   server MUST support either the $MDNSent keyword, or arbitrary message
   1.131 +   keywords.
   1.132 +
   1.133 +3.  Client behavior
   1.134 +
   1.135 +   The use of IMAP requires few additional steps in mail processing on
   1.136 +   the client side.  The following timeline modifies the timeline found
   1.137 +   in Section 4 of [MDN].
   1.138 +
   1.139 +   -- User composes message.
   1.140 +
   1.141 +   -- User tells MUA to send message.
   1.142 +
   1.143 +   -- MUA passes message to MSA (original recipient information passed
   1.144 +      along).  MUA [optionally] saves message to a folder for sent mail
   1.145 +      with $MDNSent flag set.
   1.146 +
   1.147 +   -- MSA sends message to MTA.
   1.148 +
   1.149 +   -- Final MTA receives message.
   1.150 +
   1.151 +   -- Final MTA delivers message to MUA (possibly generating DSN).
   1.152 +
   1.153 +   -- MUA logs into IMAP server, opens mailbox, verifies if mailbox can
   1.154 +      store $MDNSent keyword by examining PERMANENTFLAGS response.
   1.155 +
   1.156 +   -- MUA performs automatic processing and generates corresponding MDNs
   1.157 +      ("dispatched", "processed", "deleted", "denied" or "failed"
   1.158 +      disposition type with "automatic-action" and "MDN-sent-
   1.159 +      automatically" disposition modes) for messages that do not have
   1.160 +      $MDNSent keyword, or \Draft flag set. (*)
   1.161 +
   1.162 +   -- MUA sets the $MDNSent keyword for every message that required an
   1.163 +      automatic MDN to be sent, whether or not the MDN was sent.
   1.164 +
   1.165 +   -- MUA displays a list of messages to user.
   1.166 +
   1.167 +   -- User selects a message and requests that some action be performed
   1.168 +      on it.
   1.169 +
   1.170 +
   1.171 +
   1.172 +
   1.173 +Melnikov                    Standards Track                     [Page 3]
   1.174 +
   1.175 +RFC 3503                  MDN profile for IMAP                March 2003
   1.176 +
   1.177 +
   1.178 +   -- MUA performs requested action and, with user's permission, sends
   1.179 +      appropriate MDN ("displayed", "dispatched", "processed",
   1.180 +      "deleted", "denied" or "failed" disposition type with "manual-
   1.181 +      action" and "MDN-sent-manually" or "MDN-sent-automatically"
   1.182 +      disposition mode).  If the generated MDN is saved to a mailbox
   1.183 +      with the APPEND command, the client MUST specify the $MDNSent
   1.184 +      keyword in the APPEND.
   1.185 +
   1.186 +   -- MUA sets the $MDNSent keyword for all messages for which the user
   1.187 +      confirmed the dispatching of disposition (or was explicitly
   1.188 +      prohibited to do so).
   1.189 +
   1.190 +   -- User possibly performs other actions on message, but no further
   1.191 +      MDNs are generated.
   1.192 +
   1.193 +   (*) Note: MUA MUST NOT use \Recent flag as an indicator that it
   1.194 +       should send MDN, because according to [IMAP4], "If multiple
   1.195 +       connections have the same mailbox selected simultaneously, it is
   1.196 +       undefined which of these connections will see newly-arrived
   1.197 +       messages with \Recent set and which will see it without \Recent
   1.198 +       set".  Thus, using \Recent as an indicator will cause
   1.199 +       unpredictable client behavior with different IMAP4 servers.
   1.200 +       However, the client MAY use \Seen flag as one of the indicators
   1.201 +       that MDN must not be sent.  The client MUST NOT use any other
   1.202 +       standard flags, like \Draft or \Answered, to indicate that MDN
   1.203 +       was previously sent, because they have different well known
   1.204 +       meaning.  In any case, in the presence of the $MDNSent keyword,
   1.205 +       the client MUST ignore all other flags or keywords for the
   1.206 +       purpose of generating an MDN and MUST NOT send the MDN.
   1.207 +
   1.208 +   When the client opens a mailbox for the first time, it must verify
   1.209 +   that the server supports the $MDNSent keyword, or arbitrary message
   1.210 +   keywords by examining PERMANENTFLAGS response code.
   1.211 +
   1.212 +   The client MUST NOT try to set the $MDNSent keyword if the server is
   1.213 +   incapable of storing it permanently.
   1.214 +
   1.215 +   The client MUST be prepared to receive NO from the server as the
   1.216 +   result of STORE $MDNSent when the server advertises the support of
   1.217 +   storing arbitrary keywords, because the server may limit the number
   1.218 +   of message keywords it can store in a particular mailbox.  A client
   1.219 +   SHOULD NOT send MDN if it fails to store the $MDNSent keyword.
   1.220 +
   1.221 +   Once the $MDNSent keyword is set, it MUST NOT be unset by a client.
   1.222 +   The client MAY set the $MDNSent keyword when a user denies sending
   1.223 +   the notification.  This prohibits all other MUAs from sending MDN for
   1.224 +   this message.
   1.225 +
   1.226 +
   1.227 +
   1.228 +
   1.229 +Melnikov                    Standards Track                     [Page 4]
   1.230 +
   1.231 +RFC 3503                  MDN profile for IMAP                March 2003
   1.232 +
   1.233 +
   1.234 +3.1.  Client behavior when receiving a message
   1.235 +
   1.236 +   The client MUST NOT send MDN if a message has the $MDNSent keyword
   1.237 +   set.  It also MUST NOT send MDN if a message has \Draft flag, because
   1.238 +   some clients use this flag to mark a message as incomplete.
   1.239 +
   1.240 +   See the timeline in section 3 for details on client behavior when
   1.241 +   receiving a message.
   1.242 +
   1.243 +3.2.  Client behavior when copying a message
   1.244 +
   1.245 +   The client SHOULD verify that $MDNSent is preserved on a COPY
   1.246 +   operation.  Furthermore, when a message is copied between servers
   1.247 +   with the APPEND command, the client MUST set the $MDNSent keyword
   1.248 +   correctly.
   1.249 +
   1.250 +3.3.  Client behavior when sending a message
   1.251 +
   1.252 +   When saving a sent message to any folder, the client MUST set the
   1.253 +   $MDNSent keyword to prevent another client from sending MDN for the
   1.254 +   message.
   1.255 +
   1.256 +3.4.  Client behavior when saving a temporary message
   1.257 +
   1.258 +   When saving an unfinished message to any folder client MUST set
   1.259 +   $MDNSent keyword to prevent another client from sending MDN for the
   1.260 +   message.
   1.261 +
   1.262 +4.  Server behavior
   1.263 +
   1.264 +   Server implementors that want to follow this specification must
   1.265 +   insure that their server complies with either section 4.1 or section
   1.266 +   4.2.  If the server also supports the IMAP [ACL] extension, it MUST
   1.267 +   also comply with the section 4.3.
   1.268 +
   1.269 +4.1.  Server that supports arbitrary keywords
   1.270 +
   1.271 +   No changes are required from the server to make it compatible with
   1.272 +   the extension described in this document if it supports arbitrary
   1.273 +   keywords.
   1.274 +
   1.275 +4.2.  Server that supports only $MDNSent keyword
   1.276 +
   1.277 +   Servers that support only the $MDNSent keyword MUST preserve it on
   1.278 +   the COPY operation.  It is also expected that a server that supports
   1.279 +   SEARCH <flag> will also support the SEARCH KEYWORD $MDNSent.
   1.280 +
   1.281 +
   1.282 +
   1.283 +
   1.284 +
   1.285 +Melnikov                    Standards Track                     [Page 5]
   1.286 +
   1.287 +RFC 3503                  MDN profile for IMAP                March 2003
   1.288 +
   1.289 +
   1.290 +4.3.  Interaction with IMAP ACL extension
   1.291 +
   1.292 +   Any server that conforms to either 4.1 or 4.2 and also supports the
   1.293 +   IMAP [ACL] extension, SHOULD preserve the $MDNSent keyword on COPY
   1.294 +   even if the client does not have 'w' right.  This will prevent the
   1.295 +   generation of a duplicated MDN for the same message.  Note that the
   1.296 +   server MUST still check if the client has rights to perform the COPY
   1.297 +   operation on a message according to [ACL].
   1.298 +
   1.299 +5.  Examples
   1.300 +
   1.301 +   1) MUA opens mailbox for the first time.
   1.302 +
   1.303 +   a) The server supports storing of arbitrary keywords
   1.304 +
   1.305 +   C: a100 select INBOX
   1.306 +   S: * FLAGS (\Flagged \Draft \Deleted \Seen)
   1.307 +   S: * OK [PERMANENTFLAGS (\Flagged \Draft \Deleted \Seen \*)]
   1.308 +   S: * 5 EXISTS
   1.309 +   S: * 3 RECENT
   1.310 +   S: * OK [UIDVALIDITY 894294713]
   1.311 +   S: a100 OK [READ-WRITE] Completed
   1.312 +
   1.313 +   b) The server supports storing of the $MDNSent keyword
   1.314 +
   1.315 +   C: a100 select INBOX
   1.316 +   S: * FLAGS (\Flagged \Draft \Deleted \Seen $MDNSent)
   1.317 +   S: * OK [PERMANENTFLAGS (\Flagged \Draft \Deleted \Seen $MDNSent)]
   1.318 +   S: * 5 EXISTS
   1.319 +   S: * 3 RECENT
   1.320 +   S: * OK [UIDVALIDITY 894294713]
   1.321 +   S: a100 OK [READ-WRITE] Completed
   1.322 +
   1.323 +   2) The MUA successfully sets the $MDNSent keyword
   1.324 +
   1.325 +   C: a200 STORE 4 +FLAGS ($MDNSent)
   1.326 +   S: * 4 FETCH (FLAGS (\Flagged \Seen $MDNSent))
   1.327 +   S: * FLAGS ($MDNSent \Flagged \Deleted \Draft \Seen)
   1.328 +   S: * OK [PERMANENTFLAGS ($MDNSent \Flagged \Deleted \Draft \Seen \*)]
   1.329 +   S: a200 OK STORE completed
   1.330 +
   1.331 +   3) The server refuses to store the $MDNSent keyword
   1.332 +
   1.333 +   C: a200 STORE 4 +FLAGS ($MDNSent)
   1.334 +   S: a200 NO STORE failed : no space left to store $MDNSent keyword
   1.335 +
   1.336 +
   1.337 +
   1.338 +
   1.339 +
   1.340 +
   1.341 +Melnikov                    Standards Track                     [Page 6]
   1.342 +
   1.343 +RFC 3503                  MDN profile for IMAP                March 2003
   1.344 +
   1.345 +
   1.346 +   4) All clients and servers MUST treat the $MDNSent keyword as case
   1.347 +   insensitive in all operations, as stated in [IMAP].
   1.348 +
   1.349 +   C: a300 FETCH 1:* FLAGS
   1.350 +   S: * 1 FETCH (FLAGS (\Seen))
   1.351 +   S: * 2 FETCH (FLAGS (\Answered \Seen $MdnSENt))
   1.352 +   S: * 3 FETCH (FLAGS ())
   1.353 +   S: * 4 FETCH (FLAGS (\Flagged \Seen $MdnSENT))
   1.354 +   S: * 5 FETCH (FLAGS ($MDNSent))
   1.355 +   S: * 6 FETCH (FLAGS (\Recent))
   1.356 +   S: a300 OK FETCH completed
   1.357 +   C: a400 SEARCH KEYWORDS $mdnsent
   1.358 +   S: * SEARCH 2 4 5
   1.359 +   S: a400 OK SEARCH completed
   1.360 +
   1.361 +6.  Security Considerations
   1.362 +
   1.363 +   There are no known security issues with this extension, not found in
   1.364 +   [MDN] and/or [IMAP4].
   1.365 +
   1.366 +   Section 4.3 changes ACL checking requirements on an IMAP server that
   1.367 +   implements IMAP [ACL] extension.
   1.368 +
   1.369 +7.  Formal Syntax
   1.370 +
   1.371 +   The following syntax specification uses the augmented Backus-Naur
   1.372 +   Form (BNF) notation as specified in [RFC-822], as modified by
   1.373 +   [IMAP4].  Non-terminals referenced, but not defined below, are as
   1.374 +   defined by [IMAP4].
   1.375 +
   1.376 +   Except as noted otherwise, all alphabetic characters are case-
   1.377 +   insensitive.  The use of upper or lower case characters to define
   1.378 +   token strings is for editorial clarity only.  Implementations MUST
   1.379 +   accept these strings in a case-insensitive fashion.
   1.380 +
   1.381 +   flag_keyword    ::= "$MDNSent" / other_keywords
   1.382 +
   1.383 +   other_keywords  ::= atom
   1.384 +
   1.385 +8.  Acknowledgments
   1.386 +
   1.387 +   This document is the product of discussions that took place on the
   1.388 +   IMAP mailing list.  Special gratitude to Cyrus Daboo and Randall
   1.389 +   Gellens for reviewing the document.
   1.390 +
   1.391 +   Thank you to my father who as he has helped to make me what I am.  I
   1.392 +   miss you terribly.
   1.393 +
   1.394 +
   1.395 +
   1.396 +
   1.397 +Melnikov                    Standards Track                     [Page 7]
   1.398 +
   1.399 +RFC 3503                  MDN profile for IMAP                March 2003
   1.400 +
   1.401 +
   1.402 +9.  Normative References
   1.403 +
   1.404 +   [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
   1.405 +              Requirement Levels", BCP 14, RFC 2119, March 1997.
   1.406 +
   1.407 +   [MDN]      Fajman, R., "An Extensible Message Format for Message
   1.408 +              Disposition Notifications", RFC 2298, March 1998.
   1.409 +
   1.410 +   [IMAP4]    Crispin, M., "Internet Message Access Protocol - Version
   1.411 +              4rev1", RFC 3501, March 2003.
   1.412 +
   1.413 +   [ACL]      Myers, J., "IMAP4 ACL extension", RFC 2086, January 1997.
   1.414 +
   1.415 +10.  Author's Address
   1.416 +
   1.417 +   Alexey Melnikov
   1.418 +   ACI Worldwide/MessagingDirect
   1.419 +   59 Clarendon Road
   1.420 +   Watford, Hertfordshire
   1.421 +   United Kingdom, WD17 1FQ
   1.422 +
   1.423 +   Phone: +44 1923 81 2877
   1.424 +   EMail: mel@messagingdirect.com
   1.425 +
   1.426 +
   1.427 +
   1.428 +
   1.429 +
   1.430 +
   1.431 +
   1.432 +
   1.433 +
   1.434 +
   1.435 +
   1.436 +
   1.437 +
   1.438 +
   1.439 +
   1.440 +
   1.441 +
   1.442 +
   1.443 +
   1.444 +
   1.445 +
   1.446 +
   1.447 +
   1.448 +
   1.449 +
   1.450 +
   1.451 +
   1.452 +
   1.453 +Melnikov                    Standards Track                     [Page 8]
   1.454 +
   1.455 +RFC 3503                  MDN profile for IMAP                March 2003
   1.456 +
   1.457 +
   1.458 +11.  Full Copyright Statement
   1.459 +
   1.460 +   Copyright (C) The Internet Society (2003).  All Rights Reserved.
   1.461 +
   1.462 +   This document and translations of it may be copied and furnished to
   1.463 +   others, and derivative works that comment on or otherwise explain it
   1.464 +   or assist in its implementation may be prepared, copied, published
   1.465 +   and distributed, in whole or in part, without restriction of any
   1.466 +   kind, provided that the above copyright notice and this paragraph are
   1.467 +   included on all such copies and derivative works.  However, this
   1.468 +   document itself may not be modified in any way, such as by removing
   1.469 +   the copyright notice or references to the Internet Society or other
   1.470 +   Internet organizations, except as needed for the purpose of
   1.471 +   developing Internet standards in which case the procedures for
   1.472 +   copyrights defined in the Internet Standards process must be
   1.473 +   followed, or as required to translate it into languages other than
   1.474 +   English.
   1.475 +
   1.476 +   The limited permissions granted above are perpetual and will not be
   1.477 +   revoked by the Internet Society or its successors or assigns.
   1.478 +
   1.479 +   This document and the information contained herein is provided on an
   1.480 +   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   1.481 +   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   1.482 +   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   1.483 +   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   1.484 +   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
   1.485 +
   1.486 +Acknowledgement
   1.487 +
   1.488 +   Funding for the RFC Editor function is currently provided by the
   1.489 +   Internet Society.
   1.490 +
   1.491 +
   1.492 +
   1.493 +
   1.494 +
   1.495 +
   1.496 +
   1.497 +
   1.498 +
   1.499 +
   1.500 +
   1.501 +
   1.502 +
   1.503 +
   1.504 +
   1.505 +
   1.506 +
   1.507 +
   1.508 +
   1.509 +Melnikov                    Standards Track                     [Page 9]
   1.510 +