Internet Draft: MDN profile for IMAP                         A. Melnikov
Document: draft-melnikov-imap-mdn-02.txt             MessagingDirect Ltd.
Expires: January 2001                                           July 2000

                           MDN profile for IMAP


Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.  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."

     The list of current Internet-Drafts can be accessed at
     http://www.ietf.org/ietf/1id-abstracts.txt

     The list of Internet-Draft Shadow Directories can be accessed at
     http://www.ietf.org/shadow.html.

   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. Distribution of
   this memo is unlimited.


00. To do list and open issues

   a. More about server requirements?
   b. Client timeline for COPY and APPEND operations?
   e. Fix page numbers in Table of Contents


Table of Contents

   0.    To do..........................................................
   1.    Abstract.......................................................
   2.    Conventions Used in this Document..............................
   3.    Introduction and Overview......................................
   4.    Client behavior................................................
   5.    Server behavior................................................
     5.1. Server that supports arbitrary keywords.......................
     5.2. Server that supports only $MDNSent keyword....................
   6.    Examples.......................................................
   7.    Formal Syntax..................................................
   8.    References.....................................................
   9.    Security Considerations........................................
  10.    Full Copyright Statement.......................................
  11.    Author's Address...............................................


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 describes the Best Current Practice of using MDN with [IMAP4]
   and 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 additional [IMAP4] mailbox keyword 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 that doesn't
   work when IMAP is used to access the same 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
   server MUST support either the $MDNSent keyword, or arbitrary message
   keywords.


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 MSA (original recipient information passed
      along)

   -- 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.

   -- 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).

   -- 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
      indicators that MDN must not be sent. 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 semantics.
      In any case, in the presence of $MDNSent keyword, the client MUST
      ignore all other flags or keywords and MUST NOT send MDN.

   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.

   The client MUST NOT try to set $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 restrict the quantity of message
   keywords it can store in a particular mailbox.

   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 a 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 the 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 a server that supports SEARCH
   <flag> will also support SEARCH KEYWORD $MDNSent.


6.   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 $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 $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 $MDNSent keyword

    C: a200 STORE 4 +FLAGS ($MDNSent)
    S: a200 NO STORE failed : no place to store $MDNSent keyword

   4). All clients and servers MUST treat $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


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].


10.  Acknowledgments

   This document is the product of discussions that took place on
   IMAP mailing list. Special gratitude to Cyrus Daboo and Randall Gellens
   for reviewing the document.


11.  Full Copyright Statement

   Copyright (C) The Internet Society 2000. 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.


12.  Author's Address

    Alexey Melnikov
    MessagingDirect Ltd.
    #900, 10185 - 115 street, Edmonton, Alberta, Canada

    Email: mel@messagingdirect.com