Message Disposition Notification
obsoletes
- rfc-3798 — Message Disposition Notification
updates
- rfc-2046 — Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types
- rfc-3461 — Simple Mail Transfer Protocol (SMTP) Service Extension for Delivery Status Notifications (DSNs)
also
- std-85
Extracted elements (31)
The default action-mode MUST be `manual-action` and the default sending-mode MUST be `MDN-sent-manually` to preserve user privacy. The overall default behavior SHOULD be not to send MDNs at all without explicit user consent.
The requirement that MDNs not be sent automatically when DN-To differs from Return-Path exists to reduce the possibility of mail loops and of MDNs being weaponized for mail bombing attacks against third parties.
When a message is segmented into message/partial fragments, the Disposition-Notification-To, Disposition-Notification-Options, and Original-Recipient header fields SHOULD be placed in the inner (enclosed) message; occurrences in fragment headers are ignored and MUST NOT be copied to the reassembled message.
When gatewaying MDN requests into foreign mail systems where the notification recipient must equal the message sender (i.e., no separate DN address is supported), the MDN request SHOULD be silently dropped if DN-To differs from SMTP MAIL FROM, rather than producing unintended behavior.
A user agent MUST NOT issue more than one MDN per recipient per message. Once an MDN has been issued for a recipient, no further MDNs may be issued even if another disposition occurs.
An MDN MUST NOT itself contain a Disposition-Notification-To header field, and MUST NOT be generated in response to another MDN, preventing notification loops.
Confirmation from the user MUST be obtained (or no MDN sent) if there is no Return-Path header field in the message or if there is more than one distinct address in Disposition-Notification-To.
Disposition-notification-parameter attribute names and MDN extension field names MUST be registered with IANA using the Specification Required policy.
MDNs MUST NOT be sent automatically if the address in Disposition-Notification-To differs from the Return-Path address. In that case, user confirmation MUST be obtained; if confirmation is not possible, the MDN MUST NOT be sent.
The envelope sender address (SMTP MAIL FROM) of an MDN MUST be null (`<>`), so that no DSN or other bounce messages are generated in response to the MDN.
The MDN MUST be addressed (both message header and transport envelope) to the address(es) in the Disposition-Notification-To header field of the original message. The From header of the MDN MUST contain the address of the person for whom the MDN is issued.
The Message-ID of an MDN MUST be different from the Message-ID of the message for which it is issued.
The Original-Recipient field MUST be included in the MDN if an Original-Recipient header field is in the message or if the original recipient address is reliably available; otherwise it MUST NOT be included.
When messages are distributed to a mailing list in a newsgroup context, the Disposition-Notification-To header SHOULD be stripped by the resending/gatewaying agent, and clients seeing it SHOULD NOT generate an MDN.
MDNs can reveal sensitive information including when a message was read, which email client and OS were used, mailing-list subscriber identities, and internal network topology from returned message headers. Recipients may silently ignore MDN requests to protect privacy.
The Reporting-UA field can enable MUA fingerprinting — uniquely identifying a device when combined with other characteristics. MUAs SHOULD limit Reporting-UA detail and SHOULD NOT generate needlessly fine-grained product information.
The Disposition field is required and encodes `disposition-mode ";" disposition-type [ "/" disposition-modifier ]`. Action modes are `manual-action` or `automatic-action`; sending modes are `MDN-sent-manually` or `MDN-sent-automatically`; disposition types are `displayed`, `deleted`, `dispatched`, or `processed`.
The Disposition-Notification-Options header field provides extensible parameters to control MDN generation. Each parameter has an `attribute = importance , value` structure where importance is `required` or `optional`.
The Disposition-Notification-To header field requests an MDN from the receiving MUA. Its syntax is `"Disposition-Notification-To" ":" mailbox-list CRLF` and it MUST appear at most once in a message.
The Final-Recipient field is required in every MDN and contains the address-type and mailbox address of the recipient for whom the MDN is issued, preserving the case of alphabetic characters.
The MDN-Gateway field MUST appear in any MDN translated from a foreign messaging system and MUST NOT appear otherwise. It contains the MTA-name-type (typically `dns`) and the gateway's name.
The Original-Message-ID field MUST be present if and only if the original message contained a Message-ID header field; its value is copied from that field.
The Original-Recipient header field, inserted by the delivering MTA when ORCPT SMTP information is available, carries the original recipient address as `"Original-Recipient" ":" OWS address-type OWS ";" OWS generic-address OWS`.
The Reporting-UA field identifies the MUA that generated the MDN using `ua-name [ ";" ua-product ]`. MUAs SHOULD send it unless configured not to, but SHOULD limit detail to avoid fingerprinting and MUST NOT include advertising.
IANA maintains three MDN-related registries (all using Specification Required policy): (1) Disposition-Notification-Options header field disposition-notification-parameter names, (2) Disposition Modifier Names used in the Disposition field, and (3) MDN Extension Field Names.
MDNs can be forged as easily as ordinary Internet email. A forged spam or phishing message can include Disposition-Notification-To to trick recipients into sending MDNs revealing that addresses are active. MDN processing SHOULD only be invoked after verifying the authenticity of the triggering message.
MDNs do not provide non-repudiation or proof of delivery. Even unforgeable MDNs can be lost in transit or bypassed by the recipient, so they cannot serve as a legal guarantee that a message was seen.
The MDN request mechanism enables mail bombing: an attacker can send many messages with a false Disposition-Notification-To address, causing floods of MDNs (potentially larger than the originals) to overwhelm the target mailbox — a bandwidth amplification attack. MDNs SHOULD NOT be sent automatically when DN-To differs from MAIL FROM.
MDN generation follows a defined timeline: message delivery → MUA discovers message → MUA decides if MDN can be generated → automatic processing MDN (dispatched/processed/deleted, automatic-action/MDN-sent-automatically) → user action MDN (any disposition type, manual-action or automatic, with user permission) → no further MDNs after first one is issued.
An MDN is a `multipart/report` message with `report-type=disposition-notification`. Part 1 is human-readable text, part 2 is `message/disposition-notification`, and an optional part 3 may contain the original message in its original form (including encrypted form if applicable).
The `message/disposition-notification` body consists of named header-like fields in order: optional Reporting-UA, optional MDN-Gateway, optional Original-Recipient, required Final-Recipient, optional Original-Message-ID, required Disposition, zero or more Error fields, and zero or more extension fields.