Message Disposition Notification
obsoleted by
- rfc-8098 — Message Disposition Notification
obsoletes
- rfc-2298 — An Extensible Message Format for Message Disposition Notifications
updated by
- rfc-5337 — Internationalized Delivery Status and Disposition Notifications
- rfc-6533 — Internationalized Delivery Status and Disposition Notifications
updates
Extracted elements (30)
A separate Disposition-Notification-To header (distinct from the message From) is provided to allow a third party to receive MDNs, supporting delegation and automated processing scenarios. This richer functionality than most foreign mail systems requires special gateway handling when the notification address differs from the sender.
The dispositions "denied" and "failed", and the modifiers "warning", "superseded", "expired", and "mailbox-terminated" present in RFC 2298 were removed from RFC 3798 because they saw no actual implementation or usage, simplifying the specification to match deployed reality.
User consent is strongly recommended before sending an MDN because privacy concerns have historically been raised about read-receipt mechanisms. The user may grant consent per-message via a dialog, globally via a preference, or globally refuse MDNs. This balances the utility of delivery confirmation against recipient privacy.
For message/partial fragmented messages, the Disposition-Notification-To, Disposition-Notification-Options, and Original-Recipient headers SHOULD be placed in the inner/enclosed message, not in the fragment headers. RFC 2046 section 5.2.2.1 is amended to append these headers to the reassembled message.
When gatewaying MDN requests into foreign mail systems that lack a separate notification address, if the Disposition-Notification-To address differs from SMTP MAIL FROM, the MDN request SHOULD NOT be gatewayed and SHOULD be silently dropped to avoid unintended behavior.
When gatewaying MDNs from foreign systems (e.g., X.400), the MDN-Gateway field MUST identify the gateway. The gateway must attempt to translate Reporting-UA, Final-Recipient, and Disposition fields; additional information may be carried in extension fields with names identifying the foreign protocol (e.g., "X400-*").
A user agent MUST NOT issue more than one MDN on behalf of each particular recipient. Once an MDN has been issued for a recipient, no further MDNs may be issued even if another disposition is performed.
Address comparison for determining whether Disposition-Notification-To matches Return-Path MUST be case-sensitive for the local-part and case-insensitive for the domain part.
An MDN MUST NOT itself contain a Disposition-Notification-To header, and MUST NOT be generated in response to another MDN. This prevents MDN loops.
Encrypted message text, if returned at all in part 3 of the MDN multipart/report, MUST be returned only in its original encrypted form. An unencrypted return would reveal confidential content.
MDN extension field names and disposition modifier names not beginning with "X-" MUST be registered with IANA and described in a standards-track or IESG-approved experimental RFC. Names beginning with "X-" are reserved for experimental use.
MDNs SHOULD NOT be sent automatically if the address in the Disposition-Notification-To header differs from the address in the Return-Path header; user confirmation SHOULD be obtained, or if not possible, the MDN SHOULD NOT be sent.
MUAs and gateways MUST NOT generate the Original-Recipient field of an MDN unless the mail protocols provide the address originally specified by the sender at submission time; ordinary SMTP does not make that guarantee.
The envelope sender address (SMTP MAIL FROM) of the MDN MUST be null (<>), ensuring no DSN or other delivery notification is sent in response to the MDN.
The MDN MUST be addressed (in both message header and transport envelope) to the address(es) in the Disposition-Notification-To header of the original message. The From field MUST contain the address of the person for whom the MDN is issued.
The Original-Message-ID field MUST be present if the original message contained a Message-ID header. The Disposition field MUST be present in every MDN.
MDN requests can be used to monitor mail-reading habits. Propagating Disposition-Notification-To to mailing list members reveals subscriber addresses to the original sender. Headers returned in part 3 of the MDN may expose internal hostnames or network topology behind a firewall.
An MDN is a MIME message with a top-level content-type of multipart/report (report-type=disposition-notification). It consists of: (a) a human-readable explanation, (b) a message/disposition-notification body, and optionally (c) the original message or a portion thereof.
The Disposition field indicates the action performed: disposition-mode (action-mode "/" sending-mode) ";" disposition-type ["/" disposition-modifier]. Action-mode is "manual-action" or "automatic-action"; sending-mode is "MDN-sent-manually" or "MDN-sent-automatically"; disposition-type is "displayed" or "deleted".
The Disposition-Notification-Options header provides extensible parameters to control MDN generation. Parameters have an importance of "required" or "optional"; if a required parameter is not understood, the MUA MUST NOT generate an MDN with any disposition type other than "failed".
The Disposition-Notification-To header requests an MDN from the recipient's MUA. Its syntax is: "Disposition-Notification-To" ":" mailbox *("," mailbox). Its presence is a request only; recipients are always free to silently ignore it.
The Final-Recipient field identifies the recipient for whom the MDN is issued and MUST be present. Its generic-address subfield MUST contain the mailbox address as it was when the MDN was generated, and the case of alphabetic characters MUST be preserved.
The MDN-Gateway field identifies the gateway or MTA that translated a foreign disposition notification into MDN format. It MUST appear in any MDN translated by a gateway and MUST NOT appear otherwise. Syntax: "MDN-Gateway" ":" mta-name-type ";" mta-name.
The Original-Recipient header, inserted by the delivering MTA using ORCPT information from the SMTP RCPT TO command, carries the original recipient address so it can be returned in MDNs. Its syntax is: "Original-Recipient" ":" address-type ";" generic-address.
The Reporting-UA field is optional but recommended; it identifies the MUA that performed the disposition. For Internet Mail UAs it should include both the DNS name of the MUA instance and the product name (e.g., "pc.example.com; Foomail 97.1").
IANA maintains three registries defined by this document: (1) Disposition-Notification-Options header parameter names, (2) disposition modifier names used in the Disposition field, and (3) MDN extension field names. Registration requires a standards-track or IESG-approved experimental RFC.
MDNs do not provide non-repudiation or proof of delivery. MDNs may be lost in transit, forged, or bypassed; they cannot be relied upon as a guarantee that a message was or was not seen by the recipient.
MDNs may be forged as easily as ordinary Internet email. Threats include falsified disposition notifications (reporting a disposition that did not occur) and unsolicited MDNs. Automatic processors should minimize damage from denial-of-service attacks.
The MDN request mechanism enables mail bombing: an attacker can send messages to unsuspecting recipients with a forged Disposition-Notification-To address, causing automatic MDN generation that floods the target mailbox. MDNs SHOULD NOT be sent automatically when the notification address differs from the envelope MAIL FROM.
The message/disposition-notification body is formatted as RFC 2822 header fields with this structure: optional Reporting-UA, optional MDN-Gateway, optional Original-Recipient, required Final-Recipient, optional Original-Message-ID, required Disposition, followed by zero or more Failure, Error, Warning, and extension fields, each terminated by CRLF.