Summary

  • RFC 2298, published in March 1998, let an email sender add Disposition-Notification-To to request a message disposition notification. The recipient’s user agent could silently ignore the request or, in the original format, send a denied disposition.
  • A returned report described a mail program’s action: displayed, dispatched, processed or deleted, among other 1998 values. The specification recommended user consent and limited each recipient’s agent to one report per message. RFC 3798 later removed the unused denied and failed values.

A sender slips a question into the envelope

Picture the office inbox of 1998. A message arrives with an ordinary subject, ordinary body and one extraordinary ambition: its sender would like news of what happens after delivery. The sender’s software writes Disposition-Notification-To into the header, with an address for the answer. Then the request crosses the network and lands in another person’s mail program. The sender controls the question. The recipient side controls the reply.

That split sits in the first pages of RFC 2298, the March 1998 standard for message disposition notifications, or MDNs. It says the header’s presence is a request. A recipient’s user agent may quietly ignore it. The original vocabulary also allowed a denied report, an explicit way to say that the recipient would keep the message’s disposition private. In the same section, the RFC strongly recommended asking the user before sending an MDN. A program might prompt for each message, follow a saved preference, remain silent by default or follow a setting that refused every request.

The format was built for machine processing. A report could say a message was displayed, dispatched, processed or deleted. These words were more precise than the familiar phrase “read receipt.” Displayed meant a user agent had shown the message to someone accessing the mailbox. Dispatched meant it had been sent onward, perhaps printed or forwarded. Processed covered work done by rules or a server. Deleted described removal. The RFC’s definitions attach each label to a handling event. “Displayed” reaches the screen; reading and understanding happen on the other side of it.

The report also carried clues about how the event arose. Its disposition mode distinguished a manual action from an automatic one, and a manually authorised report from one sent under a standing configuration. These distinctions matter because a sender might receive the same word, displayed, after very different local choices. The label describes handling. The mode describes the path by which the program produced and sent that description.

RFC 2298 treated a receipt as an event with a budget. A recipient’s user agent could issue at most one MDN for a given message on that recipient’s behalf. An MDN could not request its own MDN, and receiving one could not trigger another. The rule reads like an engineer removing two mirrors from a hallway: a small, tidy acknowledgement should not turn into an endless conversation between automatic programs.

There was a second hazard. A malicious sender could ask that the receipt go to someone else, turning innocent inbox activity into traffic aimed at a third party. RFC 2298 compared the requested MDN destination with the message’s Return-Path. If the addresses differed, or the return path was missing, or the request named several distinct destinations, it recommended confirmation or no automatic report. The text names the risk directly: mail loops and mail bombing. A “please tell me” header could become a machine for bothering a stranger if software answered it blindly.

The standard therefore placed several decisions in different hands. The sender could express interest. The recipient’s mail program interpreted the request and the message’s address context. The person using that program could grant or withhold consent through a prompt or preference. The report, if sent, described a bounded action. The network supplied a route for the answer; it did not appoint the sender as an overseer of the recipient’s attention.

There is a small historical joke in the protocol’s later revision. The original RFC had an explicit denied disposition. RFC 3798, which replaced it in May 2004, removed denied and failed, citing lack of implementation or usage. The sender’s request remained a request, and silent nonresponse remained possible. The grand stamped “NO” faded from the format; the quiet closed door survived.

The email read receipt was thus a negotiation between programs and people, written into a few headers and report fields. It could tell a sender that a recipient-side program had displayed a message. It could say a message was deleted or processed. It could also yield no report at all. The most important power in this tiny bureaucracy belonged to the side receiving the mail: the power to answer the question, or leave it sitting in the inbox.