Message Disposition Notification (MDN) profile for Internet Message Access Protocol (IMAP)
RFC 3503

Document Type RFC - Proposed Standard (March 2003; No errata)
Last updated 2013-03-02
Stream Legacy
Formats plain text pdf html bibtex
Stream Legacy state (None)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state RFC 3503 (Proposed Standard)
Telechat date
Responsible AD Ned Freed
IESG note published
Send notices to <mel@isode.com>
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].
Show full document text