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

Network Working Group                                       D. Bernstein
XXXXXXXXXXXXXXXXXXXX: NNNN                                            IR
Category: Informational                                   13 August 1996


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


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.


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.



Bernstein                                                       [Page 1]

XXX NNNN         Notice-Requested-Upon-Delivery-To           August 1996


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.










Bernstein                                                       [Page 2]

XXX NNNN         Notice-Requested-Upon-Delivery-To           August 1996


4. Security considerations

   Security issues are not discussed in this memo.


Author's address

   D. J. Bernstein

   Email:  djb@pobox.com












































Bernstein                                                       [Page 3]