From 7fe712882b909931088a318c08041b0e7974a000 Mon Sep 17 00:00:00 2001 From: Eduardo Chappa Date: Sat, 2 Nov 2013 02:51:18 -0600 Subject: * Update to version 2.19.1 * Upgrade UW-IMAP to Panda IMAP from https://github.com/jonabbey/panda-imap. * Replace tabs by spaces in From and Subject fields to control for size in screen of these fields. Change only in index screen display. --- imap/docs/rfc/rfc3503.txt | 507 ++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 507 insertions(+) create mode 100644 imap/docs/rfc/rfc3503.txt (limited to 'imap/docs/rfc/rfc3503.txt') diff --git a/imap/docs/rfc/rfc3503.txt b/imap/docs/rfc/rfc3503.txt new file mode 100644 index 00000000..5b82fb08 --- /dev/null +++ b/imap/docs/rfc/rfc3503.txt @@ -0,0 +1,507 @@ + + + + + + +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] + +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] + +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] + +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] + +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 will also support the SEARCH KEYWORD $MDNSent. + + + + + +Melnikov Standards Track [Page 5] + +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] + +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] + +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] + +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] + -- cgit v1.2.3-54-g00ecf