PMDF System Manager's Guide
Previous Contents Index

19.3.1 Requesting Delivery or Read Receipts

You can request a delivery receipt for a specific recipient listed in a single IN% construct by including the string 


(delivery-receipt)
in the construct adjacent to the address. (Strings enclosed in parentheses are RFC 822 comments and won't otherwise affect the address.) For example, you might use an address of the form 


IN%"postmaster@ymir.claremont.edu (delivery-receipt)"
to request delivery confirmation on a message to postmaster@ymir.claremont.edu.

This string will, by default, cause a delivery receipt request to be inserted into the message header of all copies of the message sent to recipients listed in that IN% construct. Other recipients will not be affected. The exact form of the delivery receipt request depends on the destination of the message. Delivery receipt requests appear as a Delivery-receipt-to: header in messages PMDF delivers to VMS MAIL mailboxes. Alternatively, PMDF can be configured to generate NOTARY (non-header) delivery receipt requests rather than any header requesting a delivery receipt; see Section 19.3.2.

The string 


(read-receipt)
requests a read receipt. It operates in a similar fashion to the delivery receipt mechanism described above. PMDF will convert any read receipt requests it receives into delivery receipt requests when it knows that the mail user agent to which the mail is being delivered cannot honor a read receipt request (when delivering to VMS MAIL, for example). Read receipt requests appear as a Disposition-notification-to: header in messages PMDF delivers to VMS MAIL mailboxes. 2

Note
The phrases delivery-receipt and read-receipt appearing within the parentheses are actually configurable via settings in the PMDF option file. The system administrator responsible for configuring PMDF determines the phrases used at a given site and can elect to change them from the defaults described here.

In the PMDF MAIL user agent, the /DELIVERY_RECEIPT and /READ_RECEIPT qualifiers of the SEND, FORWARD, and REPLY commands provide an alternate way to request receipts on a per-message basis.

Receipts are sent to the message originator by default. You can request that receipts for messages you originate be sent to a different address by defining the PMDF_DELIVERY_RECEIPT_TO logical to translate to the RFC 822 address to which you prefer that delivery receipts be sent. If you define this logical, receipts will be requested by default (no need to specify anything special in the address). You can then suppress the generation of delivery receipt requests by adding a 


(no-delivery-receipt)
comment in the IN% construct. Similarly, the PMDF_READ_RECEIPT_TO logical can be used to specify the address to which read receipts should be sent. If set, it also causes read receipt requests to be generated by default, and the comment 


(no-read-receipt)
can be used to suppress the generation of read receipt requests.

Note
The use of the PMDF_DELIVERY_RECEIPT_TO and PMDF_READ_RECEIPT_TO logicals is deprecated, since they unconditionally generate old style header receipt requests, rather than the newer sorts of requests in use on the Internet. That is, PMDF_DELIVERY_RECEIPT_TO unconditionally results in use of a Delivery-receipt-to: header, rather than a non-header NOTARY delivery receipt requestion, while PMDF_READ_RECEIPT_TO results in a Read-receipt-to: header, rather than the newer Disposition-notification-to: header.

Warning
Be very circumspect in the use of the PMDF_DELIVERY_RECEIPT_TO and PMDF_READ_RECEIPT_TO logicals. In general, you do not want to leave them constantly defined (unless they are defined to be "<>". At issue here is the danger of accidentally posting mail with an attached receipt request to a large mailing list. While many mailing lists will properly block such requests, quite a few do not and instead pass the request on to each and every list member. In such a case, as many as one receipt per list member will be generated (some addressees can be using mailers which ignore receipt requests). For a large mailing list with thousands of members, this means that your system can be flooded with mail.

Note

2 The Disposition-notification-to: header is defined in RFC 2298. Versions of PMDF prior to PMDF V5.2 used a Read-receipt-to: header.

Previous Next Contents Index