Summary

  • RFC 3503 created the shared, case-insensitive $MDNSent keyword so several mail clients using one IMAP mailbox would not emit repeated Message Disposition Notifications.
  • The keyword was deliberately broader than its name: clients set it after refusal, on sent and unfinished copies, and after some automatic decisions whether or not an MDN was sent. It proved a suppression state, not a past send or a human read.

The puzzle begins with two computers and one mailbox. On the first computer, a mail program examines a request for a disposition notification. It sends one, or the user refuses. The program records its decision in a local preference file. Later a second program opens the same mailbox from somewhere else. The second program cannot see the first program’s memory. If the message itself carries no shared state, the question can be asked again and a second notification may leave.

RFC 3503 treated this as a coordination problem, not as a new transport. Published in March 2003, it added no IMAP command and no response. It defined a special-purpose mailbox keyword, $MDNSent, and described how Mail User Agents should use it. The shared mailstore became the narrow common layer between clients that otherwise kept independent state.

The name invites a bad inference. “MDN sent” appears to describe an event that already happened. The normative behavior says something more cautious. During automatic processing, the MUA set the keyword for every message requiring the decision “whether or not the MDN was sent.” A user could explicitly refuse the notification, and the client could still set the same keyword so another MUA would not ask again. A program saving a sent-mail copy had to set it. A program saving an unfinished message had to set it. These different histories converged on one durable instruction: do not generate an MDN for this stored message.

That is why $MDNSent was a control token rather than a send receipt. Its truth was prospective. A conforming client that found it had to stop, ignore other flags and refrain from sending the MDN. Its presence did not identify which client made the decision, whether a notification object had been composed, whether submission succeeded, whether transport delivered it or whether a recipient of the original message had read anything.

Before relying on the token, the client had to ask whether the mailbox could preserve it. RFC 3503 used the PERMANENTFLAGS response to discover support for $MDNSent specifically or arbitrary keywords. Capability and execution stayed separate. A server might advertise arbitrary keywords yet reject a later STORE because the mailbox had exhausted its keyword capacity. The example returned NO and cited no space for the keyword.

The recommended response to that failure reveals the design priority. The client should not send the MDN if it could not store $MDNSent. Sending without durable shared memory might satisfy the immediate request, but it would leave another MUA free to send again. The specification preferred a missing notification to an uncontrolled duplicate. That is not exactly-once delivery. It is a fail-closed choice at one coordination boundary.

Other IMAP flags could not be casually repurposed. \Recent was forbidden as the trigger because, when several connections selected the same mailbox, which connection saw the message as recent was undefined. A local observation could not serve as shared ownership of the task. \Seen could be one indicator against sending, but it had a different established meaning. \Draft marked an incomplete message and separately barred an MDN. With $MDNSent present, however, the client had to ignore all other flags and keywords for this decision.

The state was intentionally one-way. Once set, a client must not unset $MDNSent. Removing it would restore apparent permission and reopen the duplicate risk without reconstructing the old decision. This monotonic quality made coordination simpler, but it also made the event interpretation less defensible. A permanent stop bit is not an audit log. It does not preserve who acted, when, under which consent or with which transport outcome.

Copying introduced another boundary. A client should verify that ordinary IMAP COPY preserved $MDNSent. A cross-server copy performed with APPEND had to carry the keyword correctly. A sent or unfinished message saved into a folder also received it. If the bit fell off during movement, a destination client could encounter the copied message as if no earlier suppression decision existed.

The ACL rule made that preservation unusually explicit. If a server implemented the contemporary IMAP ACL extension, it should preserve $MDNSent across COPY even when the client lacked the right to write flags, while still checking that the client had authority to perform the copy itself. Copy authorization and flag-edit authorization remained distinct. The server preserved the coordination property as part of the copied object rather than treating it as an optional later edit.

Case did not create new states. $MdnSENt, $MdnSENT and $mdnsent had to compare as the same keyword. The examples fetched mixed-case spellings and searched with another spelling. The point was not cosmetic. If two clients divided one shared state by capitalization, duplicate suppression would fail at the representation boundary.

The wider MDN system supplied different evidence. The original RFC 2298 defined a machine-processable disposition report. RFC 3798 revised it, and RFC 8098 later made the modern specification Internet Standard STD 85. Its disposition values are bounded. displayed means an MUA displayed the message to someone reading the mailbox; it does not guarantee the content was read or understood. processed may involve a rule or server and no human at all. deleted does not prove the recipient never saw the message and does not prevent later restoration.

RFC 8098 also preserves privacy and security limits. User consent is central; the default should be not to send. Address mismatches demand confirmation. MDNs can be forged, lost, exploited for mail bombing or used to disclose client details. The standard states that they provide no non-repudiation proof of delivery and cannot guarantee that a message was or was not seen. A real MDN therefore remains a typed claim with provenance and transport questions. A suppression keyword is an even narrower fact.

The keyword’s later registration made its true meaning plainer than its name. RFC 5788 described $MDNSent as a shared keyword specifying that an MDN must not be sent for the annotated message. That sentence is a prohibition, not a biography. It tells the next actor what not to do.

JMAP later tightened the join between action and state. RFC 9007 defines MDN/send, requires the client to arrange the corresponding $mdnsent update, allows the server to reject an operation that would not set the keyword, and defines mdnAlreadySent when the bit is already present. This reduces a gap between sending and coordination state in the JMAP method. It does not retroactively change RFC 3503, and it still cannot prove that a human read the original message or that a notification reached its destination.

The useful evidence ladder is therefore longer than the flag name. PERMANENTFLAGS advertises storage capability. A successful STORE records shared suppression state. A client decision may or may not construct an MDN. Submission hands a notification to mail transport. Delivery places it at the other end. A disposition field describes one claimed outcome. Human attention, comprehension and action follow separately. No lower receipt acquires the authority of a higher one.

This is a small protocol lesson with a durable institutional shape. Shared systems often need one narrow invariant: prevent repeated action by independent participants. A compact marker can do that without becoming a history, identity proof or outcome certificate. Trouble starts when its convenient label is read as more than its write rules authorize.

RFC 3503 succeeded by keeping the common layer thin. It coordinated the future behavior of clients. It did not claim to govern the recipient’s private decision, authenticate a sender, guarantee mail transport or certify attention. The honest interpretation is almost the inverse of the name: $MDNSent said stop. Sometimes nothing had been sent at all.

Sources