Internet Draft: MDN profile for IMAP A. Melnikov Document: draft-melnikov-imap-mdn-00.txt Epsylon Technologies Expires: 7 February 1999 7 August 1998 MDN profile for IMAP Status of this Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." To learn the current status of any Internet-Draft, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). A revised version of this draft document will be submitted to the RFC editor as an Proposed Standard for the Internet Community. Discussion and suggestions for improvement are requested, and should be sent to the IMAP4 Mailing list (imap@CAC.Washington.EDU). To subscribe to the list, send email to <listproc@u.washington.edu> with the text "subscribe imap YourName" in the body of the message. This document will expire before 6 February 1999. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society 1998. All Rights Reserved. 00. To do a. More about server requirements. b. Client timeline for COPY and APPEND operations. c. More examples. d. Acknowledgements. Melnikov Expires February 1999 [Page 1]
Internet Draft MDN profile for IMAP August 1998 1. Abstract Message Disposition Notification [MDN], also known as 'acknowledgements' or 'receipt notifications' is one of the widely used features of X.400 and the proprietary 'LAN-based' messaging systems. [MDN] defines how this functionality may be supported by Internet Mail, however it doesn't describe how multiple Mail User Agents (MUAs) may use MDN together with the Internet Message Access Protocol [IMAP4]. This document should be considered as guidelines for implementers of the Internet Message Access Protocol [IMAP4] that want to add MDN support to their products. 2. Conventions Used in this Document "C:" and "S:" in examples show lines sent by the client and server respectively. The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" in this document are to be interpreted as defined in "Key words for use in RFCs to Indicate Requirement Levels" [KEYWORDS]. 3. Introduction and Overview This memo defines an extension to the Internet Message Access Protocol that allows multiple Mail User Agents (MUAs) to know if a requested receipt notification was sent or not. Message Disposition Notification [MDN] does not require any special support of IMAP in the case where a user has access to the mailstore only from one computer and 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, then 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 this doesn't work when IMAP is used to access the mailstore from different locations or using different MUAs. This document defines a new special purpose mailbox keyword $MDNSent that must be used by MUAs. It doesn't 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 Melnikov Expires February 1999 [Page 2]
Internet Draft MDN profile for IMAP August 1998 server MUST support either the $MDNSent keyword, or arbitrary message keywords. When a server does not support either custom message keywords, nor $MDNSent keyword MUA should use other protocols such as Application Configuration Access Protocol [ACAP]. 4. Client behavior The use of IMAP requires few additional steps in mail processing. 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 MTA (original recipient information passed along) -- MTA sends message to next 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. -- 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 don't have $MDNSent keyword set. -- MUA sets $MDNSent keyword for all such messages. -- MUA displays list of messages to user. -- User selects a message and requests that some action be performed on it. -- 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). -- MUA sets $MDNSent keyword for all message for which user confirmed the dispatching of disposition (or explicitly prohibited to do this). Melnikov Expires February 1999 [Page 3]
Internet Draft MDN profile for IMAP August 1998 -- User possibly performs other actions on message, but no further MDNs are generated. When the client opens a mailbox for the first time it must verify that the server supports or $MDNSent keyword, or arbitrary message keywords by examining PERMANENTFLAGS response code. Client MUST NOT try to set $MDNSent keyword if the server is incapable of storing it permanently. Client MUST be prepared to receive NO from the server as the result of STORE $MDNSent when server advertises that it supports the storage of arbitrary keywords, because message keywords are limited resources. Once $MDNSent keyword is set it MUST NOT be unset by the client. The client MAY set $MDNSent keyword when user denied sending the notification. This prohibits all other MUA from sending MDN for this message. The client SHOULD verify that $MDNSent is preserved on COPY operation. Furthermore when message is copied between servers with APPEND command client MUST set correctly the $MDNSent keyword. At least client MUST verify that $MDNSent keyword is supported by target mailbox. 5. Server behavior 5.1. Server that supports arbitrary keywords No changes required from server to make it compatible with extension described in this document if it supports arbitrary keywords. 5.2. Server that supports only $MDNSent keyword Servers that support only the $MDNSent keyword MUST preserve it on COPY operation. It is also expected that server that supports SEARCH <flag> will also support SEARCH KEYWORD $MDNSent. 6. Examples MUA opens mailbox for the first time. C: a100 select INBOX S: * FLAGS (\Flagged \Draft \Deleted \Seen) S: * OK [PERMANENTFLAGS (\Flagged \Draft \Deleted \Seen \*)] S: * 5 EXISTS Melnikov Expires February 1999 [Page 4]
Internet Draft MDN profile for IMAP August 1998 S: * 3 RECENT S: * OK [UIDVALIDITY 894294713] S: a100 OK [READ-WRITE] Completed MUA successfully sets $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 Server refuses to store $MDNSent keyword C: a200 STORE 4 +FLAGS ($MDNSent) S: a200 NO STORE failed : no place to store $MDNSent keyword 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. References [MDN] Fajman, R., "Message Disposition Notifications", RFC 2298, National Institutes of Health, March 1998 [IMAP4] Crispin, M., "Internet Message Access Protocol - Version 4rev1", RFC 2060, University of Washington, December 1996. [KEYWORDS] Bradner, "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997 9. Security Considerations There are no known security issues with this extension, not found in [MDN] and [IMAP4]. Melnikov Expires February 1999 [Page 5]
Internet Draft MDN profile for IMAP August 1998 10. Full Copyright Statement Copyright (C) The Internet Society 1998. 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. 11. Author's Address Alexey Melnikov Epsylon Technologies 121293, general Ermolov street, 6 - 90, Moscow, Russia Email: mel@demo.ru Melnikov Expires February 1999 [Page 6]
Internet Draft MDN profile for IMAP August 1998 Table of Contents 0. To do.........................................................1 1. Abstract......................................................2 2. Conventions Used in this Document.............................2 3. Introduction and Overview.....................................2 4. Client behavior...............................................3 5. Server behavior...............................................4 5.1. Server that supports arbitrary keywords......................4 5.2. Server that supports only $MDNSent keyword...................4 6. Examples......................................................4 7. Formal Syntax.................................................5 8. References....................................................5 9. Security Considerations.......................................5 10. Full Copyright Statement......................................6 11. Author's Address..............................................6 Melnikov Expires February 1999 [Page 7]