--- /dev/null
+
+
+
+
+
+
+Network Working Group A. Melnikov
+Request for Comments: 3503 ACI Worldwide/MessagingDirect
+Category: Standards Track March 2003
+
+
+ Message Disposition Notification (MDN) profile for
+ Internet Message Access Protocol (IMAP)
+
+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 RFC
+ 2298 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Melnikov Standards Track [Page 1]
+\f
+RFC 3503 MDN profile for IMAP March 2003
+
+
+Table of Contents
+
+ 1. Conventions Used in this Document............................. 2
+ 2. Introduction and Overview..................................... 2
+ 3. Client behavior............................................... 3
+ 3.1. Client behavior when receiving a message................. 5
+ 3.2. Client behavior when copying a message................... 5
+ 3.3. Client behavior when sending a message................... 5
+ 3.4. Client behavior when saving a temporary message.......... 5
+ 4. Server behavior............................................... 5
+ 4.1. Server that supports arbitrary keywords.................. 5
+ 4.2. Server that supports only $MDNSent keyword............... 5
+ 4.3. Interaction with IMAP ACL extension...................... 6
+ 5. Examples...................................................... 6
+ 6. Security Considerations....................................... 7
+ 7. Formal Syntax................................................. 7
+ 8. Acknowledgments............................................... 7
+ 9. Normative References.......................................... 8
+ 10. Author's Address.............................................. 8
+ 11. Full Copyright Statement...................................... 9
+
+1. Conventions Used in this Document
+
+ "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"
+ [KEYWORDS].
+
+2. Introduction and Overview
+
+ This memo defines an additional [IMAP4] mailbox keyword that allows
+ multiple Mail User Agents (MUAs) to know if a requested receipt
+ notification was sent.
+
+ Message Disposition Notification [MDN] 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 [MDN], 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.
+
+
+
+
+Melnikov Standards Track [Page 2]
+\f
+RFC 3503 MDN profile for IMAP March 2003
+
+
+ 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.
+
+3. Client behavior
+
+ 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 [MDN].
+
+ -- 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.
+
+
+
+
+Melnikov Standards Track [Page 3]
+\f
+RFC 3503 MDN profile for IMAP March 2003
+
+
+ -- 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 [IMAP4], "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.
+
+
+
+
+Melnikov Standards Track [Page 4]
+\f
+RFC 3503 MDN profile for IMAP March 2003
+
+
+3.1. Client behavior when receiving a message
+
+ 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 section 3 for details on client behavior when
+ receiving a message.
+
+3.2. Client behavior when copying a message
+
+ 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.
+
+3.3. Client behavior when sending a message
+
+ 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.
+
+3.4. Client behavior when saving a temporary message
+
+ When saving an unfinished message to any folder client MUST set
+ $MDNSent keyword to prevent another client from sending MDN for the
+ message.
+
+4. Server behavior
+
+ Server implementors that want to follow this specification must
+ insure that their server complies with either section 4.1 or section
+ 4.2. If the server also supports the IMAP [ACL] extension, it MUST
+ also comply with the section 4.3.
+
+4.1. Server that supports arbitrary keywords
+
+ No changes are required from the server to make it compatible with
+ the extension described in this document if it supports arbitrary
+ keywords.
+
+4.2. Server that supports only $MDNSent keyword
+
+ 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.
+
+
+
+
+
+Melnikov Standards Track [Page 5]
+\f
+RFC 3503 MDN profile for IMAP March 2003
+
+
+4.3. Interaction with IMAP ACL extension
+
+ Any server that conforms to either 4.1 or 4.2 and also supports the
+ IMAP [ACL] 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 [ACL].
+
+5. Examples
+
+ 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
+
+
+
+
+
+
+Melnikov Standards Track [Page 6]
+\f
+RFC 3503 MDN profile for IMAP March 2003
+
+
+ 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
+
+6. Security Considerations
+
+ There are no known security issues with this extension, not found in
+ [MDN] and/or [IMAP4].
+
+ Section 4.3 changes ACL checking requirements on an IMAP server that
+ implements IMAP [ACL] extension.
+
+7. Formal Syntax
+
+ The following syntax specification uses the augmented Backus-Naur
+ Form (BNF) notation as specified in [RFC-822], as modified by
+ [IMAP4]. Non-terminals referenced, but not defined below, are as
+ defined by [IMAP4].
+
+ 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
+
+8. Acknowledgments
+
+ 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.
+
+
+
+
+Melnikov Standards Track [Page 7]
+\f
+RFC 3503 MDN profile for IMAP March 2003
+
+
+9. Normative References
+
+ [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [MDN] Fajman, R., "An Extensible Message Format for Message
+ Disposition Notifications", RFC 2298, March 1998.
+
+ [IMAP4] Crispin, M., "Internet Message Access Protocol - Version
+ 4rev1", RFC 3501, March 2003.
+
+ [ACL] Myers, J., "IMAP4 ACL extension", RFC 2086, January 1997.
+
+10. Author's Address
+
+ Alexey Melnikov
+ ACI Worldwide/MessagingDirect
+ 59 Clarendon Road
+ Watford, Hertfordshire
+ United Kingdom, WD17 1FQ
+
+ Phone: +44 1923 81 2877
+ EMail: mel@messagingdirect.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Melnikov Standards Track [Page 8]
+\f
+RFC 3503 MDN profile for IMAP March 2003
+
+
+11. Full Copyright Statement
+
+ 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]
+\f
projects / uw-imap / commitdiff