idnits 2.17.1 draft-melnikov-imap-mdn-00.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([IMAP4], [MDN]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (7 August 1998) is 9387 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'ACAP' is mentioned on line 97, but not defined == Missing Reference: 'UIDVALIDITY 894294713' is mentioned on line 191, but not defined == Missing Reference: 'RFC-822' is mentioned on line 210, but not defined ** Obsolete undefined reference: RFC 822 (Obsoleted by RFC 2822) ** Obsolete normative reference: RFC 2298 (ref. 'MDN') (Obsoleted by RFC 3798) ** Obsolete normative reference: RFC 2060 (ref. 'IMAP4') (Obsoleted by RFC 3501) Summary: 12 errors (**), 0 flaws (~~), 6 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft: MDN profile for IMAP A. Melnikov 3 Document: draft-melnikov-imap-mdn-00.txt Epsylon Technologies 4 Expires: 7 February 1999 7 August 1998 6 MDN profile for IMAP 8 Status of this Memo 10 This document is an Internet-Draft. Internet-Drafts are working 11 documents of the Internet Engineering Task Force (IETF), its areas, 12 and its working groups. Note that other groups may also distribute 13 working documents as Internet-Drafts. 15 Internet-Drafts are draft documents valid for a maximum of six months 16 and may be updated, replaced, or obsoleted by other documents at any 17 time. It is inappropriate to use Internet-Drafts as reference 18 material or to cite them other than as "work in progress." 20 To learn the current status of any Internet-Draft, please check the 21 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 22 Directories on ds.internic.net (US East Coast), nic.nordu.net 23 (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific 24 Rim). 26 A revised version of this draft document will be submitted to the RFC 27 editor as an Proposed Standard for the Internet Community. Discussion 28 and suggestions for improvement are requested, and should be sent to 29 the IMAP4 Mailing list (imap@CAC.Washington.EDU). To subscribe to the 30 list, send email to with the text 31 "subscribe imap YourName" in the body of the message. This document 32 will expire before 6 February 1999. Distribution of this memo is 33 unlimited. 35 Copyright Notice 37 Copyright (C) The Internet Society 1998. All Rights Reserved. 39 00. To do 41 a. More about server requirements. 42 b. Client timeline for COPY and APPEND operations. 43 c. More examples. 44 d. Acknowledgements. 46 1. Abstract 48 Message Disposition Notification [MDN], also known as 49 'acknowledgements' or 'receipt notifications' is one of the widely 50 used features of X.400 and the proprietary 'LAN-based' messaging 51 systems. [MDN] defines how this functionality may be supported by 52 Internet Mail, however it doesn't describe how multiple Mail User 53 Agents (MUAs) may use MDN together with the Internet Message Access 54 Protocol [IMAP4]. 56 This document should be considered as guidelines for implementers of 57 the Internet Message Access Protocol [IMAP4] that want to add MDN 58 support to their products. 60 2. Conventions Used in this Document 62 "C:" and "S:" in examples show lines sent by the client and server 63 respectively. 65 The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" 66 in this document are to be interpreted as defined in "Key words for 67 use in RFCs to Indicate Requirement Levels" [KEYWORDS]. 69 3. Introduction and Overview 71 This memo defines an extension to the Internet Message Access 72 Protocol that allows multiple Mail User Agents (MUAs) to know if a 73 requested receipt notification was sent or not. 75 Message Disposition Notification [MDN] does not require any special 76 support of IMAP in the case where a user has access to the mailstore 77 only from one computer and using a single MUA. In this case the MUA 78 behaves as described in [MDN], i.e., the MUA performs automatic 79 processing and generates corresponding MDNs, then it performs 80 requested action and, with the user's permission, sends appropriate 81 MDNs. The MUA will not send MDN twice, because the MUA keeps track of 82 sent notifications in a local configuration. However this doesn't 83 work when IMAP is used to access the mailstore from different 84 locations or using different MUAs. 86 This document defines a new special purpose mailbox keyword $MDNSent 87 that must be used by MUAs. It doesn't define any new command or 88 response for IMAP, but describes a technique that MUAs should use to 89 achieve interoperability. 91 When a client opens a mailbox for the first time it verifies that the 92 server is capable of storing the $MDNSent keyword by examining the 93 PERMANENTFLAGS response code. In order to support MDN in IMAP a 94 server MUST support either the $MDNSent keyword, or arbitrary message 95 keywords. When a server does not support either custom message 96 keywords, nor $MDNSent keyword MUA should use other protocols such as 97 Application Configuration Access Protocol [ACAP]. 99 4. Client behavior 101 The use of IMAP requires few additional steps in mail processing. The 102 following timeline modifies the timeline found in Section 4 of [MDN]. 104 -- User composes message 106 -- User tells MUA to send message 108 -- MUA passes message to MTA (original recipient information passed 109 along) 111 -- MTA sends message to next MTA 113 -- Final MTA receives message 115 -- Final MTA delivers message to MUA (possibly generating DSN) 117 -- MUA logs into IMAP server, opens mailbox, verifies if mailbox 118 can store $MDNSent keyword. 120 -- MUA performs automatic processing and generates corresponding 121 MDNs ("dispatched", "processed", "deleted", "denied" or "failed" 122 disposition type with "automatic-action" and 123 "MDN-sent-automatically" disposition modes) for messages that 124 don't have $MDNSent keyword set. 126 -- MUA sets $MDNSent keyword for all such messages. 128 -- MUA displays list of messages to user. 130 -- User selects a message and requests that some action be 131 performed on it. 133 -- MUA performs requested action and, with user's permission, sends 134 appropriate MDN ("displayed", "dispatched", "processed", 135 "deleted", "denied" or "failed" disposition type with 136 "manual-action" and "MDN-sent-manually" or 137 "MDN-sent-automatically" disposition mode). 139 -- MUA sets $MDNSent keyword for all message for which user 140 confirmed the dispatching of disposition (or explicitly 141 prohibited to do this). 143 -- User possibly performs other actions on message, but no further 144 MDNs are generated. 146 When the client opens a mailbox for the first time it must verify 147 that the server supports or $MDNSent keyword, or arbitrary message 148 keywords by examining PERMANENTFLAGS response code. 150 Client MUST NOT try to set $MDNSent keyword if the server is 151 incapable of storing it permanently. 153 Client MUST be prepared to receive NO from the server as the result 154 of STORE $MDNSent when server advertises that it supports the storage 155 of arbitrary keywords, because message keywords are limited 156 resources. 158 Once $MDNSent keyword is set it MUST NOT be unset by the client. The 159 client MAY set $MDNSent keyword when user denied sending the 160 notification. This prohibits all other MUA from sending MDN for this 161 message. 163 The client SHOULD verify that $MDNSent is preserved on COPY 164 operation. Furthermore when message is copied between servers with 165 APPEND command client MUST set correctly the $MDNSent keyword. At 166 least client MUST verify that $MDNSent keyword is supported by target 167 mailbox. 169 5. Server behavior 171 5.1. Server that supports arbitrary keywords 173 No changes required from server to make it compatible with extension 174 described in this document if it supports arbitrary keywords. 176 5.2. Server that supports only $MDNSent keyword 178 Servers that support only the $MDNSent keyword MUST preserve it on 179 COPY operation. It is also expected that server that supports SEARCH 180 will also support SEARCH KEYWORD $MDNSent. 182 6. Examples 184 MUA opens mailbox for the first time. 186 C: a100 select INBOX 187 S: * FLAGS (\Flagged \Draft \Deleted \Seen) 188 S: * OK [PERMANENTFLAGS (\Flagged \Draft \Deleted \Seen \*)] 189 S: * 5 EXISTS 190 S: * 3 RECENT 191 S: * OK [UIDVALIDITY 894294713] 192 S: a100 OK [READ-WRITE] Completed 194 MUA successfully sets $MDNSent keyword 196 C: a200 STORE 4 +FLAGS ($MDNSent) 197 S: * 4 FETCH (FLAGS (\Flagged \Seen $MDNSent)) 198 S: * FLAGS ($MDNSent \Flagged \Deleted \Draft \Seen) 199 S: * OK [PERMANENTFLAGS ($MDNSent \Flagged \Deleted \Draft \Seen)] 200 S: a200 OK STORE completed 202 Server refuses to store $MDNSent keyword 204 C: a200 STORE 4 +FLAGS ($MDNSent) 205 S: a200 NO STORE failed : no place to store $MDNSent keyword 207 7. Formal Syntax 209 The following syntax specification uses the augmented Backus-Naur 210 Form (BNF) notation as specified in [RFC-822] as modified by [IMAP4]. 211 Non-terminals referenced but not defined below are as defined by 212 [IMAP4]. 214 Except as noted otherwise, all alphabetic characters are case- 215 insensitive. The use of upper or lower case characters to define 216 token strings is for editorial clarity only. Implementations MUST 217 accept these strings in a case-insensitive fashion. 219 flag_keyword ::= "$MDNSent" / other_keywords 221 other_keywords ::= atom 223 8. References 225 [MDN] Fajman, R., "Message Disposition Notifications", RFC 2298, 226 National Institutes of Health, March 1998 228 [IMAP4] Crispin, M., "Internet Message Access Protocol - Version 229 4rev1", RFC 2060, University of Washington, December 1996. 231 [KEYWORDS] Bradner, "Key words for use in RFCs to Indicate 232 Requirement Levels", RFC 2119, March 1997 234 9. Security Considerations 236 There are no known security issues with this extension, not found 237 in [MDN] and [IMAP4]. 239 10. Full Copyright Statement 241 Copyright (C) The Internet Society 1998. All Rights Reserved. 243 This document and translations of it may be copied and furnished to 244 others, and derivative works that comment on or otherwise explain it 245 or assist in its implementation may be prepared, copied, published 246 and distributed, in whole or in part, without restriction of any 247 kind, provided that the above copyright notice and this paragraph 248 are included on all such copies and derivative works. However, this 249 document itself may not be modified in any way, such as by removing 250 the copyright notice or references to the Internet Society or other 251 Internet organizations, except as needed for the purpose of 252 developing Internet standards in which case the procedures for 253 copyrights defined in the Internet Standards process must be 254 followed, or as required to translate it into languages other than 255 English. 257 The limited permissions granted above are perpetual and will not be 258 revoked by the Internet Society or its successors or assigns. 260 This document and the information contained herein is provided on an 261 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 262 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 263 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 264 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 265 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 267 11. Author's Address 269 Alexey Melnikov 270 Epsylon Technologies 271 121293, general Ermolov street, 6 - 90, 272 Moscow, Russia 274 Email: mel@demo.ru 276 Table of Contents 278 0. To do.........................................................1 279 1. Abstract......................................................2 280 2. Conventions Used in this Document.............................2 281 3. Introduction and Overview.....................................2 282 4. Client behavior...............................................3 283 5. Server behavior...............................................4 284 5.1. Server that supports arbitrary keywords......................4 285 5.2. Server that supports only $MDNSent keyword...................4 286 6. Examples......................................................4 287 7. Formal Syntax.................................................5 288 8. References....................................................5 289 9. Security Considerations.......................................5 290 10. Full Copyright Statement......................................6 291 11. Author's Address..............................................6