One document matched: draft-bernstein-nrudt-00.txt

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

INTERNET-DRAFT   draft-bernstein-nrudt-00.txt   (expires 1 October 1996)

   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 defines an experimental protocol for the Internet
   community. This memo does not specify an Internet standard of any
   kind. Discussion and suggestions for improvement are requested.
   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.


Network Working Group                                       D. Bernstein
XXXXXXXXXXXXXXXXXXXX: NNNN                                            IR
Category: Experimental                                      3 April 1996


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


Status of this memo

   This memo defines an experimental protocol for the Internet
   community. This memo does not specify an Internet standard of any
   kind. Discussion and suggestions for improvement are requested.
   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.


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            April 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 must be <>. Its envelope recipient should
   be the envelope sender of the original message; however, if the
   envelope sender of the original message is <>, a success notice must
   not be sent.

   The body of the success notice should not contain a copy of the
   original message, but it should 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 should not be merged with a failure notice.









Bernstein                                                       [Page 2]
 (expires 1 October 1996)
XXX NNNN         Notice-Requested-Upon-Delivery-To            April 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]