RFC 2298

An Extensible Message Format for Message Disposition Notifications

📅 published March 1998, from ietf

RFC 2298: An Extensible Message Format for Message Disposition Notifications 💌✨

bestie, this is RFC 2298 🎀 It came from the Network Working Group and was written by R. Fajman of the National Institutes of Health. It's in the Standards Track category, which means it's an actual Internet standards track protocol 👑 The date is March 1998. The title block doesn't list any RFCs that it obsoletes or updates 🦋

Status of this Memo

okay so this document specifies an Internet standards track protocol for the Internet community 🌈 It also asks for discussion and suggestions for improvements 💬 If you want the current standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1) 📚 Distribution of this memo is unlimited 💖

Copyright (C) The Internet Society (1998). All Rights Reserved.

Abstract

so this memo defines a MIME content-type 🦋 A mail user agent (UA) or an electronic mail gateway can use it to report the disposition of a message after it has been successfully delivered to a recipient 📬 The content-type is meant to be machine-processable 🤖 The memo also defines extra message headers so the sender can request Message Disposition Notifications (MDNs) 🙌

the goal is to bring "read receipts," "acknowledgements," or "receipt notifications" to Internet Mail 💅 These features already live in X.400 and the proprietary "LAN-based" systems, which is giving main character energy 👑 The whole point is to do this while respecting the privacy concerns people have raised whenever this stuff came up before 🫶

a lot of messages go between the Internet and other messaging systems like X.400 or the proprietary "LAN-based" systems 🌸 So the MDN protocol is designed to work in a multi-protocol messaging environment ✨ It carries "foreign" addresses too, not just the ones normally used in Internet Mail 🧚 It can also define extra attributes to support "tunneling" of foreign notifications through Internet Mail 🚇

Table of Contents

1.   Introduction ............................................  2
2.   Requesting Message Disposition Notifications ............  3
3.   Format of a Message Disposition Notification ............  7
4.   Timeline of events ...................................... 17
5.   Conformance and Usage Requirements ...................... 18
6.   Security Considerations ................................. 19
7.   Collected Grammar ....................................... 20
8.   Guidelines for Gatewaying MDNs .......................... 22
9.   Example ................................................. 24
10.  IANA Registration Forms ................................. 25
11.  Acknowledgments ......................................... 26
12.  References .............................................. 26
13.  Author's Address ........................................ 27
14.  Copyright ............................................... 28

1. Introduction ✨

this memo defines a MIME content-type [5] for message disposition notifications (MDNs) 💌 An MDN lets the sender know about things that can happen after a message is successfully delivered 🕵️‍♀️ Examples are the message contents being displayed, the message being printed, the message being deleted without being displayed, or the recipient refusing to send MDNs 🙅‍♀️ The "message/disposition-notification" content-type defined here is meant to be used inside the "multipart/report" content type defined in RFC 1892 [7] 🎀

the memo defines the format of these notifications and the RFC 822 headers used to request them 📝

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 🧐 These are the official requirement words, so pay attention to them bestie 🫶

1.1 Purposes

the MDNs in this memo are expected to do a few jobs 💅

  • (a) Tell humans what happened to their messages after successful delivery, in a way that doesn't depend much on human language 🌍
  • (b) Let mail user agents keep track of what happened to the messages they sent, by matching returned MDNs with earlier transmissions 🗂️
  • (c) Carry disposition notification requests and disposition notifications between Internet Mail and "foreign" mail systems through a gateway 🌉
  • (d) Let "foreign" notifications be tunneled through a MIME-capable message system and back into the original messaging system that issued the original notification, or even into a third messaging system 🔁
  • (e) Allow language-independent, yet reasonably precise, indications of what happened to a message when it's delivered 🦋

1.2 Requirements

these purposes put some constraints on the notification protocol 👑

  • (a) It must be readable by humans, as well as being machine-parsable 🤓
  • (b) It must provide enough information to let message senders (or their user agents) unambiguously match an MDN with the message that was sent and the original recipient address the MDN was issued for (if that information is available), even if the message was forwarded to another recipient address 🕊️
  • (c) It must also be able to describe what happened to a message without depending on any particular human language or on the terminology of any particular mail system 🌸
  • (d) The specification must be extensible so it can handle future requirements 🌈

2. Requesting Message Disposition Notifications 🎀

message disposition notifications are requested by putting a Disposition-Notification-To header in the message 💌 If you want the recipient's UA to have more info when it makes the MDN, you can also add Original-Recipient and/or Disposition-Notification-Options headers 🧚

2.1 The Disposition-Notification-To Header

to ask the receiving user agent to send message disposition notifications, put a Disposition-Notification-To header into the message 💖 The syntax of the header, written in the ABNF of RFC 822 [2], is:

  mdn-request-header = "Disposition-Notification-To" ":" 1#mailbox

the mailbox token is defined as specified in RFC 822 [2] 📮

a Disposition-Notification-To header in a message is only a request for an MDN 🙏 The recipients' user agents are always free to quietly ignore it 🙈 Or they can send an explicit denial of the request, using the "denied" disposition in an MDN 🚫

An MDN MUST NOT have a Disposition-Notification-To header itself, and an MDN MUST NOT be generated in response to an MDN. Don't be that person 💀

At most one MDN may be issued for each particular recipient by their user agent 🫶 Once an MDN has been issued for a recipient, no more MDNs can be issued for that recipient, even if the message gets another disposition 🔒 But if a message is forwarded, an MDN may have been issued for the recipient doing the forwarding, and the recipient of the forwarded message may also cause an MDN to be generated 🔁

ngl, Internet standards usually don't tell user interfaces how to behave 🙃 Still, it's strongly recommended that the user agent gets the user's consent before sending an MDN ✨ That consent could be gotten for each message through a prompt or dialog box, or globally through a preference setting ⚙️ The user might also set it globally so MDNs are never sent, or so a "denied" MDN is always sent in response to a request for an MDN 🙅‍♀️

MDNs SHOULD NOT be sent automatically if the address in the Disposition-Notification-To header is different from the address in the Return-Path header (see RFC 822 [2]) 👀 In that case, confirmation from the user SHOULD be obtained, if that's possible 🙋‍♀️ If getting consent isn't possible (for example, because the user isn't online at the time), then an MDN SHOULD NOT be sent 💤

confirmation from the user SHOULD be obtained (or no MDN sent) if there is no Return-Path header in the message, or if there is more than one distinct address in the Disposition-Notification-To header 🧐

the addresses should be compared using only the addr-spec (local-part "@" domain) portion, leaving out any phrase and route 🔍 The comparison MUST be case-sensitive for the local-part and case-insensitive for the domain part 💅

if the message contains more than one Return-Path header, the implementation may pick one to use for the comparison, or treat the situation as a failure of the comparison 🤷‍♀️

the reason for not automatically sending an MDN when the comparison fails or more than one address is specified is to cut down on mail loops and on MDNs being used for mail bombing 🛑 That's the safety net bestie 🛡️

A message that has a Disposition-Notification-To header SHOULD also have a Message-ID header as specified in RFC 822 [2] 🪪 This lets user agents automatically match MDNs with the original messages 🎯

if you want to request MDNs for some recipients and not others, send two copies of the message: one with a Disposition-Notification-To header and one without 👯 Lots of the other headers (like To and cc) will be the same in both copies 📋 The recipients in each message envelope decide who gets MDNs requested and who doesn't 💌 If you want, the Message-ID header can be the same in both copies 🫶 Heads up that other situations (like bcc) also require sending several copies of a message with slightly different headers 🙈 Put those together with the need to request MDNs for only some recipients, and you could end up sending more than two copies, some with a Disposition-Notification-To header and some without 📨

Messages posted to newsgroups SHOULD NOT have a Disposition-Notification-To header 📰🚫

2.2 The Disposition-Notification-Options Header ✨

okay so future versions of this spec might need to give the recipient's UA extra info so it has more control over how and what MDNs get made 🎀. That's where the Disposition-Notification-Options header comes in. It's the extensible little pocket for all of that 🧚. The syntax, using the ABNF of RFC 822 [2], looks like this:

  Disposition-Notification-Options =
       "Disposition-Notification-Options" ":"
       disposition-notification-parameters

  disposition-notification-parameters = parameter *(";" parameter)

  parameter = attribute "=" importance "," 1#value

  importance = "required" / "optional"

The definitions of attribute and value are borrowed straight from the Content-Type header definition in RFC 2045 [4] 💅.

So an importance of "required" means the parameter has to be understood to generate an MDN properly 😤. If the UA doesn't understand the parameter, it MUST NOT generate an MDN with any disposition type other than "failed" in response to the request 💀. An importance of "optional" is the chill one: a UA that doesn't understand it MAY generate an MDN anyway and just ignore the value 🌸.

Nothing is defined in this spec yet 🙈. Parameters might show up later through revisions or extensions to this spec. Attribute names starting with "X-" will never become standard names, since they're reserved for experimental stuff 🧪. MDN parameter names that don't start with "X-" MUST be registered with the Internet Assigned Numbers Authority (IANA) and described in a standards-track RFC or an experimental RFC approved by the IESG. Check Section 10 for the registration form 📝.

If a required parameter isn't understood or has some kind of error, the receiving UA SHOULD send an MDN with a disposition type of "failed" (see Section 3.2.6) and include a Failure field (see Section 3.2.7) that explains the problem 😭. A "failed" MDN with a "Failure" field MAY also be generated when other kinds of errors show up in the parameters of the Disposition-Notification-Options header 🔥.

But here's the big rule 🛑: an MDN with a disposition type of "failed" MUST NOT be generated if the user has said they don't want MDNs sent. If user consent would be needed for some other disposition type's MDN, user consent SHOULD also be obtained before sending a "failed" one 🫶.

2.3 The Original-Recipient Header ✨

Email addresses can get rewritten while a message is in transit, so it's really useful for the delivering MTA to make the original recipient address available 📬. The delivering MTA might be able to pull that from the ORCPT parameter of the SMTP RCPT TO command, as defined in RFC 1891 [8]. If that info is there, the delivering MTA SHOULD insert an Original-Recipient header at the very start of the message (along with the Return-Path header) 💌. The delivering MTA MAY delete any other Original-Recipient headers in the message 🧹. The syntax, using the ABNF of RFC 822 [2], is as follows:

  original-recipient-header =
       "Original-Recipient" ":" address-type ";" generic-address

The address-type and generic-address tokens are as specified in the description of the Original-Recipient field in section 3.2.3 🔍.

Why bother carrying it and returning it in the MDN? So MDNs can be automatically matched up with the original message on a per-recipient basis 💜.

2.4 Use with the Message/Partial Content Type ✨

Using Disposition-Notification-To, Disposition-Notification-Options, and Original-Recipient together with the MIME Message/partial content type (RFC 2046 [5]) needs more definition 🧩.

When a message gets split into two or more message/partial fragments, the three headers from the paragraph above SHOULD go in the "inner" or "enclosed" message (using RFC 2046 [5] lingo) ✂️. They SHOULD NOT be used in the headers of any of the fragments themselves 🚫.

Now for the reassembly tea ☕. If these headers show up along with the other headers of a message/partial fragment, they're for an MDN made for the fragment. If they show up in the headers of the "inner" or "enclosed" message (RFC 2046 [5] terms again), they're for an MDN made for the reassembled message. Section 5.2.2.1 of RFC 2046 [5] gets amended so that, on top of the headers it already lists, the three headers from this spec get appended, in order, to the headers of the reassembled message 🧩. Any occurrences of the three headers defined here in the headers of the initial enclosing message must not be copied to the reassembled message 🙅‍♀️.

3. Format of a Message Disposition Notification ✨

An MDN is a MIME message whose top-level content-type is multipart/report (defined in RFC 1892 [7]) 📦. When a multipart/report content is used to send an MDN:

  • (a) The report-type parameter of the multipart/report content is "disposition-notification" 🏷️.
  • (b) The first component of the multipart/report has a human-readable explanation of the MDN, as described in RFC 1892 [7] 📖.
  • (c) The second component of the multipart/report is content-type message/disposition-notification, described in section 3.1 of this document 🎁.
  • (d) If the original message or part of it is going back to the sender, it shows up as the third component of the multipart/report. Whether to return the message or part of it is up to the UA generating the MDN 🤷‍♀️. However, for encrypted messages requesting MDNs, encrypted message text MUST be returned, if it's returned at all, only in its original encrypted form 🔐.
NOTE: For message disposition notifications gatewayed from foreign systems, the headers of the original message may not be available. In this case the third component of the MDN may be omitted, or it may contain "simulated" RFC 822 headers which contain equivalent information. In particular, it is very desirable to preserve the subject and date fields from the original message. 🥹

The MDN MUST be addressed (in both the message header and the transport envelope) to the address(es) from the Disposition-Notification-To header of the original message it's responding to 📮.

The From field of the MDN's message header MUST contain the address of the person the disposition notification is being issued for 🙋‍♀️.

The envelope sender address (i.e., SMTP MAIL FROM) of the MDN MUST be null (<>). That means no Delivery Status Notification messages or other messages about successful or unsuccessful delivery get sent in response to an MDN 🚫📭.

An MDN MUST NOT itself request an MDN. That is, it MUST NOT contain a Disposition-Notification-To header 🙅‍♀️.

The Message-ID header (if present) for an MDN MUST be different from the Message-ID of the message the MDN is being issued for 🆔.

Each MDN describes the disposition of exactly one message for exactly one recipient 🎯. One message submission can make multiple MDNs, one per recipient. However, because of the circumstances described in Section 2.1, MDNs may not be generated for some recipients who asked for them 🥲.

3.1 The message/disposition-notification content-type ✨

The message/disposition-notification content-type is defined like this:

  MIME type name:                message
  MIME subtype name:             disposition-notification
  Optional parameters:           none
  Encoding considerations:       "7bit" encoding is sufficient and
                                    MUST be used to maintain readability
                                    when viewed by non-MIME mail
                                    readers.
  Security considerations:       discussed in section 6 of this memo.

The message/disposition-notification report type for use in the multipart/report is "disposition-notification" 🏷️.

The body of a message/disposition-notification is one or more "fields" formatted according to the ABNF of RFC 822 header "fields" (see [2]). Using the ABNF of RFC 822, the syntax of the message/disposition-notification content goes like this:

  disposition-notification-content = [ reporting-ua-field CRLF ]
          [ mdn-gateway-field CRLF ]
          [ original-recipient-field CRLF ]
          final-recipient-field CRLF
          [ original-message-id-field CRLF ]
          disposition-field CRLF
          *( failure-field CRLF )
          *( error-field CRLF )
          *( warning-field CRLF )
          *( extension-field CRLF )

3.1.1 General conventions for fields ✨

These fields are defined by the rules of RFC 822 [2], so the same conventions for continuation lines and comments apply 🧵. A notification field can be continued onto multiple lines by starting each extra line with a SPACE or HTAB. Text in parentheses is a comment and isn't part of that notification field's contents 💬. Field names are case-insensitive, so notification field names can be spelled in any mix of upper and lower case letters 🔤. Comments in notification fields may use the "encoded-word" construct defined in RFC 2047 [6] 🌈.

3.1.2 "*-type" subfields ✨

Several fields have a "-type" subfield, then a semicolon, then "*text". For these fields, the keyword in the address-type or MTA-type subfield tells you the expected format of the address or MTA-name that follows 🔍.

The "-type" subfields work like this:

  • (a) An "address-type" specifies the format of a mailbox address. For example, Internet Mail addresses use the "rfc822" address-type 📬.
     address-type = atom
  • (b) An "MTA-name-type" specifies the format of a mail transfer agent name. For example, for an SMTP server on an Internet host, the MTA name is the domain name of that host, and the "dns" MTA-name-type is used 🖥️.
     mta-name-type = atom

Values for address-type and mta-name-type are case-insensitive, so address-type values "RFC822" and "rfc822" are equivalent 🔠.

The Internet Assigned Numbers Authority (IANA) will keep a registry of address-type and mta-name-type values, along with descriptions of what each one means, or a reference to one or more specifications that describe them. (The "rfc822" address-type is defined in RFC 1891 [8].) Registration forms for address-type and mta-name-type appear in RFC 1894 [9] 📋.

IANA will not accept registrations for any address-type name that begins with "X-". Those names are reserved for experimental use 🧪.

3.1.3 Lexical tokens imported from RFC 822 ✨

The following lexical tokens, defined in RFC 822 [2], are used in the ABNF grammar for MDNs: atom, CRLF, mailbox, msg-id, text 🧱.

3.2 Message/disposition-notification Fields ✨

3.2.1. The Reporting-UA field ✨

Okay so the Reporting-UA field is the one that tells you who did the disposition. 🦋 The grammar looks like this:

reporting-ua-field = "Reporting-UA" ":" ua-name
                     [ ";" ua-product ]

ua-name = *text

ua-product = *text

A MDN describes what happened to a message after it reached a recipient. 📬 The Reporting-UA is always the UA that actually did that disposition, no exceptions. 💅 This field is optional, but it's recommended. For Internet Mail user agents, the recommendation is to include both the DNS name of the specific UA instance that made the MDN and the product name. Here's a cute example:

Reporting-UA:  rogers-mac.dcrt.nih.gov; Foomail 97.1

If the reporting UA is made of more than one piece (like a base program plus plug-ins), you can list the product names to show that. 🧩

3.2.2. The MDN-Gateway field 🌉

The MDN-Gateway field names the gateway or MTA that turned a foreign, non-Internet disposition notification into this MDN. 🛸 Here's the deal: it MUST appear in any MDN that a gateway translated from a foreign system, and it MUST NOT appear in any other MDN. Non-negotiable! 🙅‍♀️

mdn-gateway-field = "MDN-Gateway" ":" mta-name-type ";" mta-name

mta-name = *text

For gateways into Internet Mail, the MTA-name-type will normally be "smtp", and the mta-name will be the Internet domain name of the gateway. 🌐

3.2.3. Original-Recipient field 🎯

The Original-Recipient field shows the original recipient address the sender typed in for the message this MDN is about. 💌 For Internet Mail, the value comes from the Original-Recipient header of that message. Now, the tricky bits:

  • If the message has no Original-Recipient header, the Original-Recipient field MUST be omitted, unless the same info is reliably available some other way. 🙈
  • If the original message does have an Original-Recipient header (or the info is reliably available some other way), then the Original-Recipient field must be supplied. ✨
  • If the message has more than one Original-Recipient header, the UA may pick which one to use, or it may act like there's no Original-Recipient header at all. 🤷‍♀️
original-recipient-field =
     "Original-Recipient" ":" address-type ";" generic-address

generic-address = *text

The address-type field tells you what kind of original recipient address it is. If the message started out inside the Internet, the address-type will normally be "rfc822", and the address follows the syntax from RFC 822 [2]. 📮 If the Reporting UA can't figure out the address type from the message envelope, it should use "unknown". This address is the same one the sender provided, so you can use it to automatically match MDN reports to original messages on a per-recipient basis. 🎀

3.2.4. Final-Recipient field 💖

The Final-Recipient field says which recipient the MDN is for. It MUST be present, babe. 🫶

Here's the syntax:

final-recipient-field =
     "Final-Recipient" ":" address-type ";" generic-address

The generic-address subfield MUST contain the mailbox address of the recipient (taken from the From header of the MDN) as it was when the UA generated the MDN. 📭

Heads up: the Final-Recipient address might not match what the sender originally wrote, since it can get transformed during forwarding and gatewaying into a totally unrecognizable mess. 💀 But if there's no Original-Recipient field, then the Final-Recipient field and any returned content might be the only clues you've got for matching the MDN to a specific recipient. 🕵️‍♀️

The address-type subfield tells you what kind of address the reporting MTA expects in that context. Recipient addresses that come in over SMTP will normally be address-type "rfc822". 📨

Mailbox addresses (Internet ones included) can be case sensitive, so the case of every alphabetic character in the address MUST be preserved. No messing with capitals! 🔠

3.2.5. Original-Message-ID field 🆔

The Original-Message-ID field holds the message-ID of the message this MDN is for. 🪪 It comes from the Message-ID header of that original message. This field MUST be present if the original message had a Message-ID header. Syntax:

original-message-id-field = "Original-Message-ID" ":" msg-id

The msg-id token is defined in RFC 822 [2]. 🌸

3.2.6. Disposition field 👑

The Disposition field tells you what action the Reporting-UA took on behalf of the user. 🎬 This field MUST be present, no exceptions. The syntax is:

disposition-field = "Disposition" ":" disposition-mode ";"
                    disposition-type
                    [ '/' disposition-modifier
                      *( "," dispostion-modifier ) ]

disposition-mode = action-mode "/" sending-mode

action-mode = "manual-action" / "automatic-action"

sending-mode = "MDN-sent-manually" / "MDN-sent-automatically"

disposition-type = "displayed"
                 / "dispatched"
                 / "processed"
                 / "deleted"
                 / "denied"
                 / "failed"

disposition-modifier = ( "error" / "warning" )
                     / ( "superseded" / "expired" /
                         "mailbox-terminated" )
                     / disposition-modifier-extension

disposition-modifier-extension = atom

The disposition-mode, disposition-type and disposition-modifier may be spelled with any mix of upper and lower case letters. 🌈

3.2.6.1. Disposition modes 🎭

These are the disposition modes that are defined:

  • "manual-action": The disposition type happened because the user explicitly told the UA to do it, not because of some automatic action. 🙋‍♀️
  • "automatic-action": The disposition type happened because of an automatic action, not because the user gave an explicit instruction for this message. 🤖

"manual-action" and "automatic-action" are mutually exclusive. One or the other must be specified. ⚖️

  • "MDN-sent-manually": The user explicitly gave permission for this particular MDN to be sent. ✋
  • "MDN-sent-automatically": The MDN was sent because the UA had already been set up to send them automatically. ⚙️

"MDN-sent-manually" and "MDN-sent-automatically" are mutually exclusive. One or the other must be specified. 💫

3.2.6.2. Disposition types 🦄

These are the disposition types that are defined:

  • "displayed": The UA showed the message to someone reading the recipient's mailbox. There's no guarantee the content was read or understood. 👀
  • "dispatched": The message got sent somewhere (printed, faxed, forwarded, etc.) without necessarily having been shown to the user first. The user might or might not see it later. 🖨️
  • "processed": The message got handled in some way (by rules or a server) without being shown to the user. The user might or might not see it later, or there might not even be a human behind the mailbox. 🤖💅
  • "deleted": The message got deleted. The recipient may or may not have seen it, and they could "undelete" it and read it later. 🗑️
  • "denied": The recipient doesn't want the sender to know about the message's disposition. A UA may also silently ignore message disposition requests in this situation. 🤐
  • "failed": Something went wrong that stopped the MDN from being generated properly. More details about the cause may be in a Failure field. ❌

The "failed" disposition type is NOT to be used when there's some problem processing the message other than interpreting the request for an MDN. For those cases, use "processed" or another disposition type with the right disposition modifiers instead. 🙅‍♀️

3.2.6.3 Disposition modifiers ✨

okay so the disposition modifiers are the extra tags that tell you why a disposition happened 💅 here's the full list:

"error"                            An error of some sort occurred
                                   that prevented successful
                                   processing of the message.
                                   Further information is contained
                                   in an Error field.

"warning"                          The message was successfully
                                   processed but some sort of
                                   exceptional condition occurred.
                                   Further information is contained
                                   in a Warning field.

"superseded"                       The message has been
                                   automatically rendered obsolete by
                                   another message received.  The
                                   recipient may still access and
                                   read the message later.

"expired"                          The message has reached its
                                   expiration date and has been
                                   automatically removed from the
                                   recipient's mailbox.

"mailbox-terminated"               The recipient's mailbox has been
                                   terminated and all message in it
                                   automatically removed.

                                   "Obsoleted", "expired", and
                                   "terminated" are to be used with
                                   the "deleted" disposition type and
                                   the "autoaction" and "autosent"
                                   disposition modifiers.

disposition-modifier-extension     Additional disposition modifiers
                                   may be defined in the future by
                                   later revisions or extensions to
                                   this specification.  Disposition
                                   value names beginning with "X-"
                                   will never be defined as standard
                                   values; such names are reserved
                                   for experimental use.  MDN
                                   disposition value names NOT
                                   beginning with "X-" MUST be
                                   registered with the Internet
                                   Assigned Numbers Authority (IANA)
                                   and described in a standards-
                                   track RFC or an experimental RFC
                                   approved by the IESG.  See Section
                                   10 for a registration form.  MDNs
                                   with disposition modifier names
                                   not understood by the receiving UA
                                   MAY be silently ignored or placed
                                   in the user's mailbox without
                                   special inter- pretation.  They
                                   MUST not cause any error message
                                   to be sent to the sender of the
                                   MDN.

                                   If an UA developer does not wish
                                   to register the meanings of such
                                   disposition modifier extensions,
                                   "X-" modifiers may be used for
                                   this purpose.  To avoid name
                                   collisions, the name of the UA
                                   implementation should follow the
                                   "X-", (e.g. "X-Foomail-fratzed").

so the big rule for the extension ones 🙈 anything starting with X- is always experimental and will never become standard, and any other new name has to get registered with IANA and written up in a standards-track RFC (or an experimental one the IESG approved). MDNs with modifiers your UA doesn't understand MAY be silently ignored or dropped into the user's mailbox without special treatment, but they MUST not trigger an error message back to the sender. no drama allowed 🫶

if a UA dev doesn't want to register their modifier meanings, X- is the move, and you should name it after your UA so nobody collides, like "X-Foomail-fratzed" 🦋

it is not required that a UA be able to generate every possible value of the Disposition field, so you don't have to be a perfectionist about it 🌸

now the one-and-only-one rule 👑 a UA can issue exactly one MDN per recipient. once it's sent, no more MDNs for that recipient, even if another disposition happens later. the exception is forwarding: the forwarding recipient can get a "dispatched" MDN, and the person the message was forwarded to can also trigger their own MDN.

3.2.7 Failure, Error and Warning fields 💌

these three fields are the text-message backup for when the "failure" disposition type, the "error" modifier, and/or the "warning" modifier show up. the syntax is:

  failure-field = "Failure" ":" *text

  error-field = "Error" ":" *text

  warning-field = "Warning" ":" *text

3.3 Extension fields 🧚

more MDN fields can show up later through revisions or extensions to this spec. field names starting with X- will never be standardised, since they're reserved for experiments, and any other MDN field name MUST be registered with IANA and described in a standards-track RFC or an experimental RFC approved by the IESG. Section 10 has the registration form, so go look there 💜

extension MDN fields can exist for two main reasons:

  • (a) To let extra info from foreign disposition reports get tunnelled through Internet MDNs. Names should start with the foreign environment's name, like X400-Physical-Forwarding-Address.
  • (b) To carry diagnostic info that's specific to one particular user agent (UA). Names should start with the UA implementation that made the MDN, like Foomail-information.

if an app dev doesn't want to register what their extension fields mean, X- fields work for that too. to dodge name collisions, the app's name should follow the X-, like "X-Foomail-Log-ID" or "X-EDI-info" 🎀

4. Timeline of events ⏰

this timeline shows when everything happens while a message is processed and MDNs are generated. it's giving step-by-step drama 🍓

-- User composes message

-- User tells UA to send message

-- UA passes message to MTA (original recipient information
   passed along)

-- MTA sends message to next MTA

-- Final MTA receives message

-- Final MTA delivers message to UA (possibily generating DSN)

-- UA performs automatic processing and generates corresponding
   MDNs ("dispatched", "processed", "deleted", "denied" or "failed"
   disposition type with "automatic-action" and "MDN-sent-
   automatically" disposition modes)

-- UA displays list of messages to user

-- User selects a message and requests that some action be
   performed on it.

-- UA performs requested action and, with user's permission,
   sends appropriate MDN ("displayed", "dispatched", "processed",
   "deleted", "denied" or "failed" disposition type with "manual-
   action" and "MDN-sent-manually" or "MDN-sent-automatically"
   disposition mode).

-- User possibly performs other actions on message, but no
   further MDNs are generated.

5. Conformance and Usage Requirements 📋

a UA or gateway conforms to this spec if it generates MDNs following the protocol in this memo. it's not necessary to be able to generate every possible value of the Disposition field 💖

UAs and gateways MUST NOT generate the Original-Recipient field of an MDN unless the mail protocols give you the address the sender originally specified when they submitted the message. ordinary SMTP doesn't guarantee that 😭 but the SMTP extension in RFC 1891 [8] lets that info ride along in the envelope if it's available. the Original-Recipient header in this doc is how the MTA gets the original recipient address over to the UA 🫶

one sender-specified recipient address can produce more than one MDN. if an MDN is requested for a recipient that gets forwarded to several recipients of an "alias" (as defined in RFC 1891 [8], section 6.2.7.3), each of those recipients can send its own MDN ✨

successful delivery to a mailing list exploder SHOULD be treated as the final disposition of the message. the exploder can send an MDN with the "processed" disposition type and the "automatic-action" and "MDN-sent-automatically" disposition modes, saying the message got forwarded to the list. in that case, the MDN request doesn't get passed along to the list members 🙈

or, the exploder can send no MDN and pass the MDN request along to every member of the list. this isn't recommended for anything except small, closely knit lists, because it could cause a flood of MDNs and might reveal confidential subscribers on the list 😬 it's also fine for the exploder to point MDNs at itself, correlate them, and make a report for the original sender.

this spec places no restrictions on how UAs or mailing lists process the MDNs they receive. they can do whatever they want 💅

6. Security Considerations 🔐

these security considerations apply when you use MDNs, and they are serious 💀

6.1 Forgery 🎭

MDNs can be forged just as easily as ordinary Internet email. UAs and automatic mail handling facilities (like mail distribution list exploders) that want to use MDNs automatically should take proper precautions to limit potential damage from denial-of-service attacks.

forged-MDN threats include sending:

  • (a) A falsified disposition notification when the indicated disposition of the message has not actually occurred,
  • (b) Unsolicited MDNs

6.2 Confidentiality 🤫

confidentiality is another part of security. a recipient may not want the disposition of messages addressed to them to be known, or may worry that sending MDNs could reveal other confidential info (for example, when the message was read). in that case, it's acceptable for the UA to send "denied" MDNs or to silently ignore requests for MDNs.

if the Disposition-Notification-To header gets passed on unchanged when a message is distributed to a mailing list's subscribers, those subscribers could be revealed to the original sender through the MDNs that get generated 👀

headers from the original message returned in part 3 of the multipart/report could reveal confidential info about host names and/or network topology inside a firewall 🧱

an unencrypted MDN could reveal confidential info about an encrypted message, especially if all or part of the original message gets returned in part 3 of the multipart/report. encrypted MDNs are not defined in this specification 🔒

in general, any optional MDN field can be left out if the Reporting UA site or user decides that including it would seriously compromise site confidentiality. that need for confidentiality has to be balanced against how useful the omitted info would be in the MDNs ✨

6.3 Non-Repudiation 🙈

Okay bestie, MDNs are genuinely useful for mail users 💖 but they are NOT a guarantee that a message was or was not not seen by the recipient 😭. Even when nobody forges an MDN, it can still get lost in transit. And the recipient can get around the MDN issuing mechanism in some way. So treat MDNs as a helpful hint, not proof 🫶

7. Collected Grammar 🎀

NOTE: Okay so, a few lexical tokens come straight from RFC 822: atom, CRLF, mailbox, msg-id, and text. The definitions of attribute and value match the Content-Type header in RFC 2045 [4] ✨

Here's the grammar for the message headers 🧚

mdn-request-header = "Disposition-Notification-To" ":" 1#mailbox

Disposition-Notification-Options =
     "Disposition-Notification-Options" ":"
     disposition-notification-parameters

disposition-notification-parameters = parameter *(";" parameter)

parameter = attribute "=" importance "," 1#value

importance = "required" / "optional"

original-recipient-header =
     "Original-Recipient" ":" address-type ";" generic-address

And here's the grammar for the report content 💅

disposition-notification-content = [ reporting-ua-field CRLF ]
     [ mdn-gateway-field CRLF ]
     [ original-recipient-field CRLF ]
     final-recipient-field CRLF
     [ original-message-id-field CRLF ]
     disposition-field CRLF
     *( failure-field CRLF )
     *( error-field CRLF )
     *( warning-field CRLF )
     *( extension-field CRLF )

address-type = atom

mta-name-type = atom

reporting-ua-field = "Reporting-UA" ":" ua-name
                     [ ";" ua-product ]

ua-name = *text

ua-product = *text

mdn-gateway-field = "MDN-Gateway" ":" mta-name-type ";" mta-name

mta-name = *text

original-recipient-field =
     "Original-Recipient" ":" address-type ";" generic-address

generic-address = *text

final-recipient-field =
     "Final-Recipient" ":" address-type ";" generic-address

disposition-field = "Disposition" ":" disposition-mode ";"
                    disposition-type
                    [ '/' disposition-modifier
                      *( "," dispostion-modifier ) ]

disposition-mode = action-mode "/" sending-mode

action-mode = "manual-action" / "automatic-action"

sending-mode = "MDN-sent-manually" / "MDN-sent-automatically"

disposition-type = "displayed"
                 / "dispatched"
                 / "processed"
                 / "deleted"
                 / "denied"
                 / "failed"

disposition-modifier = ( "error" / "warning" )
                     / ( "superseded" / "expired" /
                         "mailbox-terminated" )
                     / disposition-modifier-extension

disposition-modifier-extension = atom

original-message-id-field = "Original-Message-ID" ":" msg-id

failure-field = "Failure" ":" *text

error-field = "Error" ":" *text

warning-field = "Warning" ":" *text

extension-field = extension-field-name ":" *text

extension-field-name = atom

8. Guidelines for Gatewaying MDNs 🌸

NOTE: Heads up, this section is just non-binding recommendations 🦋 for mail gateways that want to pass semi-transparent disposition notifications between the Internet and some other electronic mail system. If a particular pair of mail systems needs specific MDN gateway rules, other documents can define those.

8.1 Gatewaying from other mail systems to MDNs 💌

A mail gateway can issue an MDN to carry the contents of a "foreign" disposition notification over Internet Mail. When a foreign notification element maps cleanly onto an MDN field, the info can go in that field. If extra info is needed (like stuff needed to tunnel the foreign notification through the Internet), it can go in extension MDN fields. (Those fields should be named after the foreign mail protocol, e.g. X400-* for X.400 protocol elements, so they're easy to spot 🔍)

The gateway must attempt to supply reasonable values for the Reporting-UA, Final-Recipient, and Disposition fields. Usually these come from translating the foreign values into Internet-style equivalents. Some info loss is to be expected though 😩

If the foreign notification has the sender-specified recipient address and the original message-id, those should be kept in the Original-Recipient and Original-Message-ID fields ✨

The gateway should also try to keep the "final" recipient address from the foreign system 🎯 Whenever it can, foreign protocol elements should be encoded as meaningful printable ASCII strings.

For MDNs made from foreign disposition notifications, the name of the gateway MUST appear in the MDN-Gateway field of the MDN. 🔥

8.2 Gatewaying from MDNs to other mail systems 🚀

Sometimes it's possible to gateway MDNs from the Internet into a foreign mail system. The main goal is to share disposition info in a form the destination system can actually use. A secondary goal is to let MDNs "tunnel" through foreign mail systems, so they can be gatewayed back into the Internet later 🔁

Generally, the MDN recipient (aka the sender of the original message) wants to know two things for each recipient: the closest possible match to the original recipient address, and the disposition (displayed, printed, etc.) 👀

If it's possible, the gateway should try to keep the Original-Recipient address and Original-Message-ID (if present) in the resulting foreign disposition report.

If an MDN can be tunneled through the destination environment, the gateway specification may define a way to keep the MDN info in the disposition reports that environment uses 🧁

9. Example 🍓

NOTE: This example is just for illustration and isn't part of the MDN protocol spec. If the example ever disagrees with the protocol definition above, the example is wrong 🙅‍♀️

Also, using *-type subfield names or extension fields in this example doesn't define those type names or extension fields, so don't read it that way 💅

9.1 This is an MDN issued after a message has been displayed to the user of an Internet Mail user agent. 👩‍💻

Here's what the MDN looks like 💖

Date: Wed, 20 Sep 1995 00:19:00 (EDT) -0400
From: Joe Recipient <Joe_Recipient@mega.edu>
Message-Id: <199509200019.12345@mega.edu>
Subject: Disposition notification
To: Jane Sender <Jane_Sender@huge.com>
MIME-Version: 1.0
Content-Type: multipart/report; report-type=disposition-notification;
      boundary="RAA14128.773615765/mega.edu"

--RAA14128.773615765/mega.edu

The message sent on 1995 Sep 19 at 13:30:00 (EDT) -0400 to Joe
Recipient <Joe_Recipient@mega.edu> with subject "First draft of
report" has been displayed.  This is no guarantee that the message
has been read or understood.

--RAA14128.773615765/mega.edu
content-type: message/disposition-notification

Reporting-UA: joes-pc.cs.mega.edu; Foomail 97.1
Original-Recipient: rfc822;Joe_Recipient@mega.edu
Final-Recipient: rfc822;Joe_Recipient@mega.edu
Original-Message-ID: <199509192301.23456@huge.com>
Disposition: manual-action/MDN-sent-manually; displayed

--RAA14128.773615765/mega.edu
content-type: message/rfc822

[original message goes here]

--RAA14128.773615765/mega.edu--

10. IANA Registration Forms 📝

Okay, these forms are for registering a new parameter name for the Disposition-Notification-Options header, a new disposition modifier name, or a new MDN extension field 🎀 For each piece of info a form asks for, you can either put it on the form, or point to a published, publicly available spec that has the info. IANA MAY reject registrations because of incomplete forms, imprecise specs, or inappropriate names 🙈

To register, fill out the right form below and email it to <IANA@IANA.ORG> 💌

10.1 IANA registration form for Disposition-Notification-Options header parameter names 🌈

A registration for a Disposition-Notification-Options header parameter name MUST include the following info:

(a) The proposed parameter name.

(b) The syntax for parameter values, specified using BNF, ABNF, regular expressions, or some other non-ambiguous language.

(c) If parameter values aren't made up entirely of graphic characters from the US-ASCII repertoire, a spec for how they're encoded as graphic US-ASCII characters in a Disposition-Notification-Options header.

(d) A reference to a standards track RFC or experimental RFC approved by the IESG that describes what the parameter values mean.

10.2 IANA registration form for disposition modifer names 🦋

A registration for a disposition-modifier name MUST include the following info:

(a) The proposed disposition-modifier name.

(b) A reference to a standards track RFC or experimental RFC approved by the IESG that describes what the disposition modifier means.

10.3 IANA registration form for MDN extension field names 💜

A registration for an MDN extension field name MUST include the following info:

(a) The proposed extension field name.

(b) The syntax for extension values, specified using BNF, ABNF, regular expressions, or some other non-ambiguous language.

(c) If extension field values aren't made up entirely of graphic characters from the US-ASCII repertoire, a spec for how they're encoded as graphic US-ASCII characters in a Disposition-Notification-Options header.

(d) A reference to a standards track RFC or experimental RFC approved by the IESG that describes what the extension field means.

11. Acknowledgments 🫶

This document is based on the Delivery Status Notifications document, RFC 1894 [9], by Keith Moore and Greg Vaudreuil. A big shoutout to the IETF Receipt Working Group members who helped out: Harald Alverstrand, Ian Bell, Urs Eppenberger, Claus Andri Faerber, Ned Freed, Jim Galvin, Carl Hage, Mike Lake, Keith Moore, Paul Overell, Pete Resnick, and Chuck Shih 👑

12. References 📚

  • [1] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821, August 1982.
  • [2] Crocker, D., "Standard for the Format of ARPA Internet Text Messages", STD 11, RFC 822, August 1982.
  • [3] Braden, R. (ed.), "Requirements for Internet Hosts - Application and Support", STD 3, RFC 1123, October 1989.
  • [4] Freed, N., and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
  • [5] Freed, N., and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996.
  • [6] Moore, K., "Multipurpose Internet Mail Extensions (MIME) Part Three: Message Header Extensions for Non-Ascii Text", RFC 2047, November 1996.
  • [7] Vaudreuil, G., "The Multipart/Report Content Type for the Reporting of Mail System Administrative Messages", RFC 1892, January 1996.
  • [8] Moore, K., "SMTP Service Extension for Delivery Status Notifications", RFC 1891, January 1996.
  • [9] Moore, K., and G. Vaudreuil, "An Extensible Format for Delivery Status Notifications, RFC 1894, January 1996.
  • [10] Bradner, S., "Key Words for Use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

13. Author's Address ✨

Here's where you can find Roger Fajman, the author, and his contact info. 📮🎀

Roger Fajman
National Institutes of Health
Building 12A, Room 3063
12 South Drive MSC 5659
Bethesda, Maryland 20892-5659
USA

EMail:  raf@cu.nih.gov
Phone:  +1 301 402 4265
Fax:    +1 301 480 6241

Copyright (C) The Internet Society (1998). All Rights Reserved. 🌸

Okay so, this document and any translations of it can be copied and handed out to other people. You can also make derivative works that comment on or explain it, or that help people actually implement it. Those can be prepared, copied, published, and distributed, in whole or in part, with no restrictions of any kind, as long as the copyright notice and this paragraph are on every single copy and derivative work. 🔥

BUT (and this is a big but 🙈), the document itself can't be changed in any way. You can't remove the copyright notice or the references to the Internet Society or other Internet organizations. The only exceptions are if you need it for developing Internet standards, in which case you have to follow the copyright procedures in the Internet Standards process, or if you need to translate it into a language other than English. 🌈

The limited permissions above are perpetual, which means they will never be revoked by the Internet Society or its successors or assigns. Forever and ever. 🧚💜

This document and the information in it are provided on an "AS IS" basis, and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 💀 No cap, that's the legal fine print, so read it closely. 🫶

📦 where this page comes from