Return receipt
In email, the term return receipt is somewhat misleading. When delivering a message to a recipient's computer system there is no way to force that computer system to issue an acknowledgment to the sender.
This is in contrast with a physical delivery medium in which a courier acting on behalf of the sender can honor the sender's requirements for delivery - including hand-delivery of the message to the recipient and even requiring that recipient to authenticate himself to the courier before receiving the message. This difference in capability between physical delivery systems and electronic mail causes confusion and misunderstanding. For this reason, many experts eschew the term return receipt in connection with email, in favor of less misleading terms.
However, two notification services similar to those available for physical delivery are available for e-mail. One is called Delivery Status Notifications or DSNs, and the other is termed Message Disposition Notifications or MDNs.
Delivery status notifications
DSN refers to both a service that may optionally be provided by Message Transfer Agents (MTAs) using the Simple Mail Transfer Protocol (SMTP), and a message format to be used to return indications of message delivery to the sender of that message. Specifically, the DSN SMTP service is used to request that indications of successful delivery or delivery failure (in the DSN format) be returned. Issuance of a DSN upon delivery failure is the default behavior, whereas issuance of a DSN upon successful delivery requires a specific request from the sender. Note that for various reasons, it is possible for a message to be delivered, and a DSN being returned to the sender indicating successful delivery, but the message subsequently fail to be seen by the recipient or even made available to them. The DSN SMTP extension, message format, and associated delivery status codes are specified in RFCs 3461 - 3464 + 6522.
Message disposition notifications
MDNs provide a notification of the "disposition" of a message - indicating, for example, whether it is read by a recipient, discarded before being read, etc. However for privacy reasons, and also for backward compatibility, requests for MDNs are entirely advisory in nature - i.e. recipients are free to ignore such requests. The format and usage MDNs are specified in RFC 3798.
A description of how multiple Mail User Agents (MUAs) should handle the generation of MDNs in an Internet Message Access Protocol (IMAP4) environment is provided in RFC 3503.
A non-standard but widely used way to request return receipts is with the "Return-Receipt-To:" (RRT) email header. An email address is specified as the content of the header. The first time a user opens an email message containing this header, the client will typically prompt the user whether or not to send a return receipt.
See also
- Acknowledge character
- Document automation in supply chain management & logistics
- E-mail tracking#Return-receipts
- Proof of delivery
- Web bug (which are frequently used in spamming as a way of determining which spam recipients open (and presumably read) before deleting it)
References
- K. Moore. Simple Mail Transfer Protocol (SMTP) Service Extension for Delivery Status Notifications (DSNs). RFC 3461, January 2003.
- G. Vaudreuil. The Multipart/Report Content Type for the Reporting of Mail System Administrative Messages. RFC 3462, January 2003.
- G. Vaudreuil. Enhanced Mail System Status Codes. RFC 3463, January 2003.
- K. Moore & G. Vaudreuil. An Extensible Message Format for Delivery Status Notifications. RFC 3464, January 2003.
- A. Melnikov. Message Disposition Notification (MDN) profile for Internet Message Access Protocol (IMAP). RFC 3503, March 2003.
- T. Hansen & G. Vaudreuil (editors). Message Disposition Notification. RFC 3798, May 2004.