What is a delivery receipt?

Every receipt answers one narrow question: did the message get to a particular point? The point matters. A receipt from a mail server, from a chat client, and from the application that has to act on the message confirm three different things, even if all three are shown to the user as “delivered”.

Standards are careful about this. In email, RFC 3461 says delivery means the message has been placed in the recipient’s mailbox. For mail collected later over IMAP or POP, delivery happens when the message is made available to that service, not when the recipient’s mail program fetches it. In XMPP, XEP-0184 says its receipts confirm that a message was delivered to a client, not that it was read or understood by a person.

A delivery receipt is a kind of acknowledgment that travels back to the original sender, often across several hops, rather than one exchanged between two neighbouring links.

Email splits receipts into two standards.

Delivery Status Notifications (DSNs). RFC 3461 lets the sender attach a NOTIFY parameter to each recipient. SUCCESS asks for a notice on successful delivery and FAILURE on failure. DELAY says the sender is willing to receive a notice when delivery has been delayed for an unusual time but the final outcome is not yet known. NEVER asks for no notice at all. When a message passes into a system that cannot confirm delivery, such as a mail system beyond a gateway, the server should send a “relayed” DSN instead: the sender learns the message was passed on, not that it arrived.

Message Disposition Notifications (MDNs). RFC 8098 covers what happens after delivery, such as the message being displayed, or deleted without being displayed. These are what most people call read receipts. A sender requests one with a Disposition-Notification-To header, but that is only a request: the recipient’s mail program is always free to ignore it. RFC 8098 strongly recommends asking the user’s consent before sending one and says the default should be not to send them.

XMPP follows the same split.

• XEP-0184, Message Delivery Receipts. The sender marks a message as wanting a receipt, and the recipient’s client returns an ack message saying it was received. The specification is blunt about its limits: it does not provide complete or even partial reliability, and it does not tell the sender whether the message was read, understood or processed.
• XEP-0333, Displayed Markers. A client tells the sender, or the other members of a group chat, that it has displayed messages up to a certain point. One marker covers every earlier message, so a client that shows several messages at once sends a marker only for the latest. Earlier drafts also had received and acknowledged markers. They were removed, because most implementers preferred XEP-0184’s per-message receipts and the acknowledged marker had gone unimplemented.

Receipts are easy to over-read in both directions. XEP-0184 lists reasons a sender might never get one even though the message arrived: the recipient’s client may not support receipts, the server may have delivered the message to another of the user’s clients that does not support receipts, or the recipient may simply choose not to send one. It concludes that the sender should not read meaning into a missing receipt unless the recipient has agreed to honour requests, and it recommends against resending on that basis alone.

Resending is risky anyway, because the receiver may then process the message twice. A system that retries on a missing receipt needs idempotent handling at the receiver, so a repeated message does not repeat the work.

For work that matters, such as a handover between two crews, “the device received it” is not enough. The receiving application might reject the request, crash before storing it, or need a person to approve it. So applications often define their own receipt, sent by the receiving app only after it has validated and stored the message.

Offline Protocol’s local handoff guide is one documented example. In its mesh SDK, a message_delivered event settles a send, but the guide notes that at that point the receiver may not yet have stored the record. The receiving app commits the operation locally and then sends an application receipt back over the encrypted messaging path. Delivery, local acceptance and backend commit are tracked as separate states, each with its own evidence. Delivered, accepted, committed explains why the three differ.

Receipts reveal information about the recipient. RFC 8098 notes that sending MDNs can disclose when a message was read and which mail program and operating system were used, and that it is acceptable for a mail program to silently ignore requests. XEP-0333 says clients should let people opt out of sharing displayed markers. Delivery receipts reveal something too: when the recipient’s client was reachable.