An Extensible Message Format for Message Disposition Notifications
obsoleted by
- rfc-3798 — Message Disposition Notification
Extracted elements (31)
The restriction against auto-sending MDNs when Disposition-Notification-To differs from Return-Path, or when multiple addresses are specified, is explicitly to reduce the possibility of mail loops and the use of MDNs for mail bombing attacks.
User consent is strongly recommended before sending any MDN, reflecting the privacy concerns historically associated with read-receipt functionality. The 'denied' disposition type is provided so a UA can explicitly inform the sender that disposition information will not be shared.
The MDN protocol supports gatewaying between Internet Mail and foreign systems (e.g., X.400). Foreign-originated MDNs must include the MDN-Gateway field; gateways should map foreign notification elements to MDN fields and may use extension fields (e.g., X400-*) to tunnel foreign protocol elements.
When messages use message/partial fragmentation (RFC 2046), the Disposition-Notification-To, Disposition-Notification-Options, and Original-Recipient headers SHOULD be placed in the inner/enclosed message, not in individual fragment headers. RFC 2046 Section 5.2.2.1 is amended to append these three headers to the reassembled message.
Address comparison between Disposition-Notification-To and Return-Path MUST be case-sensitive for the local-part and case-insensitive for the domain part, using only the addr-spec portion.
An MDN MUST NOT itself contain a Disposition-Notification-To header, and MUST NOT be generated in response to another MDN. This prevents mail loops.
An MDN with disposition type 'failed' MUST NOT be generated if the user has indicated MDNs are not to be sent. If user consent would be required for other dispositions, it SHOULD also be obtained before sending a 'failed' MDN.
If a Disposition-Notification-Options parameter has importance 'required' and the UA does not understand it, the UA MUST NOT generate an MDN with any disposition type other than 'failed'. A UA that does not understand an 'optional' parameter MAY generate an MDN ignoring the parameter.
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. 'X-' names are reserved for experimental use and will never be standardized.
MDNs SHOULD NOT be sent automatically if the Disposition-Notification-To address differs from the Return-Path address. User confirmation SHOULD be obtained; if unobtainable, an MDN SHOULD NOT be sent. This reduces mail loops and MDN-based mail bombing.
The MDN MUST be addressed (in both 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 message/disposition-notification content MUST use 7bit encoding to maintain readability when viewed by non-MIME mail readers.
The Message-ID of an MDN MUST differ from the Message-ID of the original message. At most one MDN may be issued per recipient; once issued, no further MDNs may be issued for that recipient even if another disposition occurs.
The Original-Message-ID field MUST be present if the original message contained a Message-ID header. The MDN-Gateway field MUST appear in any MDN translated by a gateway from a foreign system and MUST NOT appear otherwise.
The SMTP MAIL FROM (envelope sender) of an MDN MUST be null (<>), ensuring no DSN or other bounce is generated in response to an MDN.
UAs and gateways MUST NOT generate the Original-Recipient field unless the mail protocol provides the address originally specified by the sender at submission time. Ordinary SMTP does not guarantee this; RFC 1891 SMTP extension provides the mechanism.
MDNs can reveal when a message was read, expose mailing list subscribers (if Disposition-Notification-To is passed unmodified to list members), disclose internal hostnames or network topology via returned message headers, and reveal plaintext content of an encrypted message if the original is included in part 3. UAs should allow omission of optional fields and support 'denied' dispositions.
Disposition modifiers provide additional qualification: 'error' (with an Error field), 'warning' (with a Warning field), 'superseded', 'expired', and 'mailbox-terminated'. Extension modifiers not beginning with 'X-' must be IANA-registered.
The Disposition field (mandatory) encodes the action performed by the Reporting-UA. Its syntax is: disposition-mode ';' disposition-type ['/' disposition-modifier *(',' disposition-modifier)], where disposition-mode is action-mode '/' sending-mode.
The Disposition-Notification-Options header provides an extensible mechanism for passing additional control information to the recipient's UA. Parameters take the form attribute=importance,value where importance is either 'required' or 'optional'.
The Disposition-Notification-To header requests that the receiving UA issue a message disposition notification. Its value is one or more RFC 822 mailboxes. Recipients' UAs are always free to silently ignore this request.
The Final-Recipient field (mandatory) identifies the recipient for whom the MDN is being issued, using address-type ';' generic-address. It must contain the mailbox address as it existed when the MDN was generated, and alphabetic case must be preserved.
The MDN-Gateway field identifies the gateway or MTA that translated a foreign disposition notification into MDN format, using mta-name-type ';' mta-name. For Internet gateways the mta-name-type is typically 'smtp'.
The message/disposition-notification MIME content-type carries the machine-readable portion of an MDN. It must use 7bit encoding and is structured as a series of RFC 822-style header fields. It is used as the second component inside a multipart/report with report-type=disposition-notification.
The Original-Message-ID field carries the Message-ID of the original message, taken from its Message-ID header. The Failure, Error, and Warning fields carry free-text descriptions associated with the corresponding disposition type or modifier.
The Original-Recipient header, inserted by the delivering MTA, carries the original recipient address as obtained from the SMTP ORCPT parameter (RFC 1891). This allows MDNs to be correlated with messages on a per-recipient basis.
This document establishes IANA registries for: (1) Disposition-Notification-Options header parameter names, (2) disposition modifier names, and (3) MDN extension field names. Additionally, address-type and mta-name-type values are maintained by IANA (registration forms per RFC 1894).
MDNs cannot be relied upon as non-repudiation evidence. They may be lost in transit, actively forged, or the MDN issuance mechanism may be bypassed by the recipient. MDNs provide useful information but do not guarantee a message was or was not seen.
MDNs may be forged as easily as ordinary Internet email. Threats include falsified disposition notifications (reporting a disposition that never occurred) and unsolicited MDNs. Automated handlers should take precautions against denial-of-service via forged MDNs.
Disposition types are: 'displayed', 'dispatched', 'processed', 'deleted', 'denied', and 'failed'. Action modes are 'manual-action' or 'automatic-action' (mutually exclusive). Sending modes are 'MDN-sent-manually' or 'MDN-sent-automatically' (mutually exclusive).
The body of a message/disposition-notification consists of optional Reporting-UA, MDN-Gateway, and Original-Recipient fields, a mandatory Final-Recipient field, an optional Original-Message-ID field, a mandatory Disposition field, and zero or more Failure, Error, Warning, and extension fields, each terminated by CRLF.