chiark - git - mdw - qmail/blob - RFCNRUDT

   1 Notice-Requested-Upon-Delivery-To (NRUDT)
   2 D. J. Bernstein, djb@pobox.com
   3 19970201
   4
   5
   6 1. Introduction
   7
   8    The UNIX sendmail program has for many years supported a
   9    Return-Receipt-To (RRT) header field that requests a notice of
  10    successful final delivery.
  11
  12    Notice-Requested-Upon-Delivery-To (NRUDT) has the same basic
  13    function. The big difference is that RRT lists the sender's address,
  14    while NRUDT lists the recipient's address.
  15
  16    This change is critical. RRT works poorly for messages to multiple
  17    recipients, because it requests a notice from every recipient. RRT in
  18    a message to a large mailing list produces a giant, usually
  19    unintentional, flood of mail. This problem is so severe that RRT has
  20    been disabled in recent versions of sendmail.
  21
  22    NRUDT is designed to be adopted immediately, with minimal disruption,
  23    as a solution to the problems of RRT. Note that NRUDT is merely a
  24    request for notification; unlike the link-level Delivery Status
  25    Notification SMTP extension, NRUDT does not provide a guarantee of
  26    notification.
  27
  28    NRUDT is supported by the qreceipt program in the qmail package.
  29
  30
  31 2. Syntax
  32
  33    NRUDT is a field in the header of an RFC 822 mail message. It has the
  34    following syntax:
  35
  36       "Notice-Requested-Upon-Delivery-To" ":" 1#address
  37
  38    See RFC 822 for more information about header fields and addresses.
  39
  40    NRUDT requests that, upon final delivery of the message to any of the
  41    specified addresses, the sender be notified. Note that more than one
  42    address can appear in a single NRUDT header field. Multiple NRUDT
  43    header fields should not appear in a single message.
  44
  45
  46 3. Response
  47
  48    Upon successful final delivery of a message to any address listed in
  49    an NRUDT header field, the host performing delivery may, if desired,
  50    generate a success notice.
  51
  52    The success notice is similar to a failure notice as described in RFC
  53    1123. Its envelope sender is <>. Its envelope recipient is the
  54    envelope sender of the original message; however, if the envelope
  55    sender of the original message is <>, a success notice is not sent.
  56
  57    The body of the success notice does not contain a copy of the
  58    original message, but it does indicate the Message-ID of the original
  59    message, as well as the relevant recipient address.
  60
  61    A success notice may indicate delivery to several addresses. For
  62    example, given the following message:
  63
  64       (envelope) from djb@silverton.berkeley.edu
  65       (envelope) to god@heaven.af.mil, angels@heaven.af.mil
  66       Date: 1 Jan 1996 21:43:34 GMT
  67       From: "D. J. Bernstein" <djb@silverton.berkeley.edu>
  68       Message-Id: <19960101214334.8529.qmail@silverton.berkeley.edu>
  69       Notice-Requested-Upon-Delivery-To: God <god@heaven.af.mil>,
  70         angels@heaven.af.mil (You Know Who You Are)
  71       ...
  72
  73    a host may respond as follows:
  74
  75       (envelope) from <> to djb@silverton.berkeley.edu
  76       Date: 1 Jan 1996 21:43:37 GMT
  77       From: DELIVERY NOTICE SYSTEM <MAILER-DAEMON@heaven.af.mil>
  78       To: djb@silverton.berkeley.edu
  79       Subject: success notice
  80
  81       I delivered <19960101214334.8529.qmail@silverton.berkeley.edu>
  82       to the following local mailboxes:
  83
  84          god@heaven.af.mil
  85          angels@heaven.af.mil
  86
  87       Thanks for asking.
  88
  89    However, a success notice is never merged with a failure notice.