
Notice-Requested-Upon-Delivery-To (NRUDT)

INTERNET-DRAFT   draft-bernstein-nrudt-02.txt   (expires 1 August 1997)

   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 ftp.is.co.za (Africa), nic.nordu.net (Europe),
   munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
   ftp.isi.edu (US West Coast).

Status of this memo

   This memo provides information for the Internet community. This memo
   does not specify an Internet standard of any kind. Distribution of
   this memo is unlimited.

Abstract

   The UNIX sendmail program has for many years supported a
   Return-Receipt-To (RRT) header field that requests a notice of
   successful final delivery.

   Notice-Requested-Upon-Delivery-To (NRUDT) has the same basic
   function. The big difference is that RRT lists the sender's address,
   while NRUDT lists the recipient's address.

   This change is critical. RRT works poorly for messages to multiple
   recipients, because it requests a notice from every recipient. RRT in
   a message to a large mailing list produces a giant, usually
   unintentional, flood of mail. This problem is so severe that RRT has
   been disabled in recent versions of sendmail.

   NRUDT is designed to be adopted immediately, with minimal disruption,
   as a solution to the problems of RRT. Note that NRUDT is merely a
   request for notification; unlike the link-level Delivery Status
   Notification SMTP extension, NRUDT does not provide a guarantee of
   notification.


Notice-Requested-Upon-Delivery-To (NRUDT)
D. J. Bernstein, djb@pobox.com
19970201


1. Introduction

   The UNIX sendmail program has for many years supported a
   Return-Receipt-To (RRT) header field that requests a notice of
   successful final delivery.

   Notice-Requested-Upon-Delivery-To (NRUDT) has the same basic
   function. The big difference is that RRT lists the sender's address,
   while NRUDT lists the recipient's address.

   This change is critical. RRT works poorly for messages to multiple
   recipients, because it requests a notice from every recipient. RRT in
   a message to a large mailing list produces a giant, usually
   unintentional, flood of mail. This problem is so severe that RRT has
   been disabled in recent versions of sendmail.

   NRUDT is designed to be adopted immediately, with minimal disruption,
   as a solution to the problems of RRT. Note that NRUDT is merely a
   request for notification; unlike the link-level Delivery Status
   Notification SMTP extension, NRUDT does not provide a guarantee of
   notification.

   NRUDT is supported by the qreceipt program in the qmail package.


2. Syntax

   NRUDT is a field in the header of an RFC 822 mail message. It has the
   following syntax:

      "Notice-Requested-Upon-Delivery-To" ":" 1#address

   See RFC 822 for more information about header fields and addresses.

   NRUDT requests that, upon final delivery of the message to any of the
   specified addresses, the sender be notified. Note that more than one
   address can appear in a single NRUDT header field. Multiple NRUDT
   header fields should not appear in a single message.


3. Response

   Upon successful final delivery of a message to any address listed in
   an NRUDT header field, the host performing delivery may, if desired,
   generate a success notice.

   The success notice is similar to a failure notice as described in RFC
   1123. Its envelope sender is <>. Its envelope recipient is the
   envelope sender of the original message; however, if the envelope
   sender of the original message is <>, a success notice is not sent.

   The body of the success notice does not contain a copy of the
   original message, but it does indicate the Message-ID of the original
   message, as well as the relevant recipient address.

   A success notice may indicate delivery to several addresses. For
   example, given the following message:

      (envelope) from djb@silverton.berkeley.edu 
      (envelope) to god@heaven.af.mil, angels@heaven.af.mil
      Date: 1 Jan 1996 21:43:34 GMT
      From: "D. J. Bernstein" <djb@silverton.berkeley.edu>
      Message-Id: <19960101214334.8529.qmail@silverton.berkeley.edu>
      Notice-Requested-Upon-Delivery-To: God <god@heaven.af.mil>,
        angels@heaven.af.mil (You Know Who You Are)
      ...

   a host may respond as follows:

      (envelope) from <> to djb@silverton.berkeley.edu
      Date: 1 Jan 1996 21:43:37 GMT
      From: DELIVERY NOTICE SYSTEM <MAILER-DAEMON@heaven.af.mil>
      To: djb@silverton.berkeley.edu
      Subject: success notice

      I delivered <19960101214334.8529.qmail@silverton.berkeley.edu>
      to the following local mailboxes:

         god@heaven.af.mil
         angels@heaven.af.mil

      Thanks for asking.

   However, a success notice is never merged with a failure notice.
