RFC 3798

Message Disposition Notification

📅 published May 2004, from ietf

Message Disposition Notification 💌✨

Okay bestie, this is RFC 3798, and it's called "Message Disposition Notification" 🎀. The Network Working Group put it out in May 2004 🌸. It's a Standards Track document, so it's an official internet standard, and that's giving main character energy 👑. The editors are T. Hansen, Ed. from AT&T Laboratories and G. Vaudreuil, Ed. from Lucent Technologies 💅. It obsoletes RFC 2298, which means it replaces that one, and it updates RFC 3461 and RFC 2046 🦋.

Status of this Memo 🫶

This doc lays out an Internet standards track protocol for the whole Internet community, and it's literally asking people to chat about it and send ideas for making it better 🗣️. If you want to know where this protocol sits in the standardization process, check the current edition of the "Internet Official Protocol Standards" (STD 1) 📚. Distribution of this memo is unlimited, so share it with everyone 💖

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

Abstract 🌈

So this memo defines a MIME content-type that a mail user agent (MUA) or an electronic mail gateway may use to report what happened to a message after it was successfully delivered to a recipient 📨. The content-type is meant to be machine-processable 🤖. The memo also defines extra message headers so a sender can request these Message Disposition Notifications (MDNs) 🎀. The goal is to bring Internet Mail up to speed with stuff other messaging systems already do, like X.400 and the proprietary "LAN-based" systems. People call this stuff "read receipts," "acknowledgements," or "receipt notifications" 👀. The whole thing is designed to respect privacy, which people have raised concerns about whenever these features came up before 🫶

Also, lots of messages go back and forth between the Internet and other messaging systems (like X.400 or the proprietary "LAN-based" systems) 🦋. So the MDN protocol is built to work in a multi-protocol messaging environment ✨. It carries "foreign" addresses too, not just the ones normally used in Internet Mail 🌸. On top of that, extra attributes may be defined to support "tunneling" of foreign notifications through Internet Mail 🧚

Table of Contents 📋

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
       1.1.  Purposes . . . . . . . . . . . . . . . . . . . . . . . .  3
       1.2.  Requirements . . . . . . . . . . . . . . . . . . . . . .  3
       1.3.  Terminology. . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Requesting Message Disposition Notifications . . . . . . . . .  4
       2.1.  The Disposition-Notification-To Header . . . . . . . . .  4
       2.2.  The Disposition-Notification-Options Header. . . . . . .  6
       2.3.  The Original-Recipient Header. . . . . . . . . . . . . .  7
       2.4.  Use with the Message/Partial Content Type. . . . . . . .  8
   3.  FORMAT OF A MESSAGE DISPOSITION NOTIFICATION . . . . . . . . .  8
       3.1.  The message/disposition-notification content-type. . . .  9
       3.2.  Message/disposition-notification Fields. . . . . . . . . 11
       3.3.  Extension-fields . . . . . . . . . . . . . . . . . . . . 16
   4.  Timeline of Events . . . . . . . . . . . . . . . . . . . . . . 17
   5.  Conformance and Usage Requirements . . . . . . . . . . . . . . 18
   6.  Security Considerations. . . . . . . . . . . . . . . . . . . . 19
       6.1.  Forgery. . . . . . . . . . . . . . . . . . . . . . . . . 19
       6.2.  Privacy. . . . . . . . . . . . . . . . . . . . . . . . . 19
       6.3.  Non-Repudiation. . . . . . . . . . . . . . . . . . . . . 20
       6.4.  Mail Bombing . . . . . . . . . . . . . . . . . . . . . . 20
   7.  Collected Grammar. . . . . . . . . . . . . . . . . . . . . . . 20
   8.  Guidelines for Gatewaying MDNS . . . . . . . . . . . . . . . . 22
       8.1.  Gatewaying from other mail systems to MDNs . . . . . . . 23
       8.2.  Gatewaying from MDNs to other mail systems . . . . . . . 23
       8.3.  Gatewaying of MDN-requests to other mail systems . . . . 24
   9.  Example. . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
   10. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 25
       10.1. Disposition-Notification-Options header parameter names. 26
       10.2. Disposition modifier names . . . . . . . . . . . . . . . 26
       10.3. MDN extension field names. . . . . . . . . . . . . . . . 26
   11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 27
   12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27
       12.1. Normative References . . . . . . . . . . . . . . . . . . 27
       12.2. Informative References . . . . . . . . . . . . . . . . . 28
   Appendix A - Changes from RFC 2298 . . . . . . . . . . . . . . . . 29
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29
   Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 30

1. Introduction 🎀

This memo defines a [RFC-MIME-MEDIA] content-type for message disposition notifications (MDNs) 💖. An MDN lets the sender know about several things that can happen after a message is successfully delivered ✨. That includes the message contents being displayed, the message being printed, the message being deleted without being displayed, or the recipient refusing to provide MDNs 🙈. The "message/disposition-notification" content-type defined here is meant to be used inside the "multipart/report" content type defined in [RFC-REPORT] 🧚

This memo also defines the format of the notifications, plus the [RFC-MSGFMT] headers used to request them 📝

1.1. Purposes 💅

The MDNs in this memo are expected to do a few jobs:

  • (a) Tell human beings 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 to earlier transmissions 🔍
  • (c) Pass disposition notification requests and disposition notifications back and forth between Internet Mail and "foreign" mail systems through a gateway 🌉
  • (d) Let "foreign" notifications get tunneled through a MIME-capable message system and back into the original messaging system that sent the original notification, or even over to a third messaging system 🦋
  • (e) Give language-independent, yet still fairly precise, signals about what happened to a delivered message 🫶

1.2. Requirements 📝

These purposes put the following constraints on the notification protocol:

  • (a) It must be readable by humans, and must be machine-parsable 👀
  • (b) It must provide enough information to allow message senders (or their user agents) to unambiguously associate an MDN with the message that was sent and the original recipient address for which the MDN was issued (if such information is available), even if the message was forwarded to another recipient address 📬
  • (c) It must also be able to describe the disposition of a message independent of any particular human language or of the terminology of any particular mail system 🌸
  • (d) The specification must be extensible in order to accommodate future requirements 🌈

1.3. Terminology 📖

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-KEYWORDS] 🔑

All syntax descriptions use the ABNF specified by [RFC-MSGFMT] 🧩. Inside that, the lexical tokens used below are defined as "atom", "CRLF", "mailbox", "msg-id", and "text". The following lexical tokens come from the definition of the Content-Type header in [RFC-MIME-BODY]: "attribute" and "value" 🍓

2. Requesting Message Disposition Notifications 📬

Message disposition notifications get requested by putting a Disposition-Notification-To header in the message 💌. The recipient's MUA can use extra info when it makes the MDN, and you can add Original-Recipient and/or Disposition-Notification-Options headers to the message to provide that 🫶

2.1. The Disposition-Notification-To Header ✨

okay so, to ask the receiving user agent for message disposition notifications (MDNs), you slap a Disposition-Notification-To header onto the message 💌 The syntax looks like this:

mdn-request-header = "Disposition-Notification-To" ":"
          mailbox *("," mailbox)

Just having this header is only a request for an MDN, not a demand 🙈 The recipient's user agent is always free to silently ignore it, no drama. Or, if they want to be extra clear, they can send an explicit "denied" disposition in an MDN to say no thanks 💅

An MDN MUST NOT have a Disposition-Notification-To header itself 🚫 And an MDN MUST NOT be generated in response to another MDN. No MDN chains, bestie 🙅‍♀️

A user agent MUST NOT issue more than one MDN for each recipient. So once an MDN has gone out for someone, no more MDNs for them, even if the message gets some other disposition later 🛑 BUT (and this is the plot twist) if the message gets forwarded, the forwarder might've already gotten an MDN, and the person receiving the forwarded copy can also trigger their own MDN 🦋

Internet standards usually don't tell UIs what to do, but it is strongly recommended that the user agent gets the user's consent before sending an MDN 🫶 That can happen per message, like a little popup, or globally through a preference setting. The user can also set it so MDNs are never sent, or so a "denied" MDN always goes out when someone asks 🌸

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-MSGFMT]) 👀 In that case, the user's confirmation SHOULD be obtained if it's possible to get it. If they can't be asked (like if they're offline at the time), then an MDN SHOULD NOT be sent. Lowkey cautious, but iconic 💖

Confirmation SHOULD be obtained (or no MDN sent) if there's no Return-Path header in the message, or if there's more than one distinct address in the Disposition-Notification-To header 🧚

When comparing addresses, only the addr-spec part (local-part "@" domain) counts. Ignore any phrase and route bits ✨ The comparison MUST be case-sensitive for the local-part, and case-insensitive for the domain part. Very specific, very important 💅

If the message has more than one Return-Path header, the implementation may pick one of them to compare against, or it may treat the whole thing as a failed comparison 🌈

The reason we don't auto-send an MDN when the comparison fails or when more than one address is listed? It's to help cut down on mail loops and stop MDNs from being used for mail bombing 💣 Safety first, babe 🎀

A message with a Disposition-Notification-To header SHOULD also have a Message-ID header, as specified in [RFC-MSGFMT]. This lets user agents automatically match MDNs back to their original messages 🔗

Now, if you only want MDNs for some recipients and not others, you send two copies of the message: one with a Disposition-Notification-To header, and one without 📨 Stuff like To and Cc will be the same in both copies. The recipients in each message's envelope decide who gets MDNs requested and who doesn't. If you want, the Message-ID can be identical in both copies. Also, other situations (like Bcc) already need multiple copies with slightly different headers, so mixing those with the "some but not all" MDN thing can end up with more than two copies, some with the header and some without 🍓

Messages posted to newsgroups SHOULD NOT have a Disposition-Notification-To header 📰 Not in the newsgroup, bestie.

2.2. The Disposition-Notification-Options Header 🎀

Future versions of this spec might need to give the recipient's MUA more info to control how and what MDNs get generated 🧠 That's what the Disposition-Notification-Options header is for. It's an extensible little mechanism for that. The syntax goes like this:

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

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

parameter = attribute "=" importance "," value *("," value)

importance = "required" / "optional"

A parameter with importance "required" means you NEED to interpret it to generate an MDN properly for this request 😤 If an MUA doesn't understand what a required parameter means, it MUST NOT generate an MDN with any disposition type other than "failed" in response to the request. But a parameter with importance "optional" is more chill: an MUA that doesn't understand it MAY generate an MDN anyway and just ignore the parameter's value 🌸

No parameters are defined in this specification yet. They might get defined later, in future revisions or extensions 🔮 Parameter attribute names that start with "X-" will never be defined as standard names, since they're reserved for experimental use 🧪 Any 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. (See Section 10 for a registration form 📝)

If a required parameter isn't understood or has some kind of error, the receiving MUA SHOULD issue 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 further 💀 MDNs with the "failed" disposition type and a "Failure" field MAY also be generated when other kinds of errors show up in the parameters of the Disposition-Notification-Options header 🙃

BUT (very important, bestie) an MDN with a disposition type of "failed" MUST NOT be generated if the user has said they don't want MDNs sent at all 🛑 And 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 original recipient address to be made available by the delivering MTA ✨ The delivering MTA might be able to grab this info from the ORCPT parameter of the SMTP RCPT TO command, as defined in [RFC-SMTP] and [RFC-DSN-SMTP] 🧚

[RFC-DSN-SMTP] gets amended like this: if the ORCPT info is available, the delivering MTA SHOULD insert an Original-Recipient header at the beginning of the message (along with the Return-Path header). The delivering MTA MAY delete any other Original-Recipient headers that show up in the message. The syntax of this header is:

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

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

Why bother carrying the original recipient info around and returning it in the MDN? So MDNs can be automatically matched up with the original message on a per-recipient basis 💖 That's the whole point, iykyk 🦋

2.4. Use with the Message/Partial Content Type 🧩

Using the Disposition-Notification-To, Disposition-Notification-Options, and Original-Recipient headers with the MIME message/partial content type ([RFC-MIME-MEDIA]) needs a bit more definition, so buckle up 🎢

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 the terms of [RFC-MIME-MEDIA]). These headers SHOULD NOT be used in the headers of any of the fragments themselves 🚫

When the multiple message/partial fragments get reassembled, here's the tea ☕ If these headers show up alongside the other headers of a message/partial fragment message, they pertain to an MDN that will be generated for the fragment. If these headers show up in the headers of the "inner" or "enclosed" message (using the terms of [RFC-MIME-MEDIA]), they pertain to an MDN that will be generated for the reassembled message. Section 5.2.2.1 of [RFC-MIME-MEDIA]) gets amended so that, in addition to the headers specified there, the three headers described in this specification are appended, in order, to the headers of the reassembled message 🌈 And 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 ✨

Okay so an MDN is a MIME message whose top-level content-type is multipart/report ([RFC-REPORT]) 🎀 Here's how it gets put together when multipart/report is used to send one:

  • (a) The report-type parameter of the multipart/report content is "disposition-notification" 💖
  • (b) The first component of the multipart/report is a human-readable explanation of the MDN, as described in [RFC-REPORT] 🌸
  • (c) The second component of the multipart/report is content-type message/disposition-notification, which is described in section 3.1 of this document 🦋
  • (d) If the original message (or a piece of it) is going back to the sender, it shows up as the third component of the multipart/report. Whether or not to send the message back is up to the MUA generating the MDN. BUT, for encrypted messages that request MDNs, the encrypted message text MUST be returned, if it's returned at all, and ONLY in its original encrypted form 🔐
NOTE: For MDNs 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-MSGFMT] headers that 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 that the MDN is being generated for ✨

The From field of the message header of the MDN MUST contain the address of the person the message disposition notification is being issued for 💅

The envelope sender address (aka SMTP MAIL FROM) of the MDN MUST be null (<>). That tells everyone that no Delivery Status Notification messages, or other messages saying a delivery worked or didn't, should be sent back in response to an MDN. Main character energy, but make it quiet 🤫

An MDN MUST NOT itself request an MDN. So it MUST NOT contain a Disposition-Notification-To header. No MDN-ception allowed 🚫

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 several MDNs, one per recipient 💜 However, because of the circumstances described in Section 2.1, MDNs may not be generated for some recipients who did ask for them 😭

3.1. The message/disposition-notification content-type 🎀

Here's the definition of the message/disposition-notification content-type:

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-MSGFMT] header "fields". The syntax of the message/disposition-notification content looks 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-MSGFMT], so the same conventions for continuation lines and comments apply. Notification fields can be continued onto multiple lines by starting each extra line with a SPACE or HTAB. Text in parentheses is a comment, not part of the contents of that notification field 💖 Field names are case-insensitive, so notification field names can be spelled with any mix of upper and lower case letters 🦋 Comments in notification fields may use the "encoded-word" construct defined in [RFC-MIME-HEADER] 🌸

3.1.2. "*-type" subfields 🧚

Several fields have a "-type" subfield, followed by a semicolon, followed by "*text". For these fields, the keyword in the address-type or MTA-type subfield tells you what format the address or MTA-name that follows should be in 👑

The "-type" subfields are defined 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 that host's domain name, 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 of "RFC822" and "rfc822" are the same thing 🫶

The Internet Assigned Numbers Authority (IANA) keeps a registry of address-type and mta-name-type values, 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-DSN-SMTP].) Registration forms for address-type and mta-name-type are in [RFC-DSN-FORMAT] 📚

3.2. Message/disposition-notification Fields 🍓

3.2.1. The Reporting-UA field 💅

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

ua-name = *text

ua-product = *text

Okay, so an MDN describes the disposition of a message after it's been delivered to a recipient. In every case, the Reporting-UA is the MUA that did the disposition described in the MDN ✨ This field is optional, but recommended. For Internet Mail user agents, it is recommended that this field contains both the DNS name of the particular instance of the MUA that generated the MDN, AND the name of the product 🌸 For example:

Reporting-UA:  pc.example.com; Foomail 97.1

If the reporting MUA is made of more than one component (like a base program plus plug-ins), you can show that by including a list of product names 🧩

3.2.2. The MDN-Gateway field 🌈

The MDN-Gateway field says which gateway or MTA translated a foreign (non-Internet) message disposition notification into this MDN 🌉 This field MUST appear in any MDN that a gateway translated from a foreign system into MDN format, and MUST NOT appear otherwise. No sneaking it in where it doesn't belong! 🙅

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 tells you the original recipient address, as the sender specified it, for the message the MDN is being issued for 📬 For Internet Mail messages, the value of the Original-Recipient field comes from the Original-Recipient header of the message the MDN is being generated for. If there's no Original-Recipient header in the message, then the Original-Recipient field MUST be omitted, UNLESS the same info is reliably available some other way. If there IS an Original-Recipient header in the original message (or the original recipient info is reliably available some other way), then the Original-Recipient field must be supplied. If there's more than one Original-Recipient header in the message, the MUA may pick the one to use, or act as if no Original-Recipient header is present 🤔

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

generic-address = *text

The address-type field says what type of original recipient address it is. If the message started out inside the Internet, the address-type field will normally be "rfc822", and the address will follow the syntax in [RFC-MSGFMT] 💌 The value "unknown" should be used if the Reporting MUA can't work out the type of the original recipient address from the message envelope 🕵️‍♀️

This address is the same as the one the sender provided, so it can be used to automatically match MDN reports with original messages on a per-recipient basis 🎯

3.2.4. Final-Recipient field 💖

The Final-Recipient field says which recipient the MDN is being issued for. This field MUST be present 🫶

The syntax of the field is:

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

The generic-address subfield of the Final-Recipient field MUST contain the mailbox address of the recipient (from the From header of the MDN) as it was when the MDN was generated by the MUA 📮

The Final-Recipient address might be different from the address the sender originally gave, because it may have been changed during forwarding and gatewaying into a totally unrecognizable mess 😵 But if the optional Original-Recipient field is missing, the Final-Recipient field and any returned content may be the only info left to match the MDN with a particular message recipient 🕵️

The address-type subfield says what type of address the reporting MTA expects in that context. Recipient addresses obtained via SMTP will normally be of address-type "rfc822" ✨

Mailbox addresses (including the ones used on the Internet) can be case sensitive, so the case of alphabetic characters in the address MUST be preserved 🔠 Don't you dare lowercase it!

3.2.5. Original-Message-ID field 🌸

The Original-Message-ID field says what the message-ID is for the message the MDN is being issued for. It's taken from the Message-ID header of that message 🆔 This field MUST be present if the original message contained a Message-ID header. The syntax of the field is:

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

The msg-id token is as specified in [RFC-MSGFMT] 💜

3.2.6. Disposition field 👑

The Disposition field says what action the Reporting-MUA took on behalf of the user 🎬 This field MUST be present.

The syntax for the Disposition field is:

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

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

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

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

disposition-type = "displayed"
           / "deleted"

disposition-modifier = "error"
          / disposition-modifier-extension

disposition-modifier-extension = atom

The disposition-mode, disposition-type, and disposition-modifier can be spelled with any combination of upper and lower case characters 🌈

3.2.6.1. Disposition modes 🎀

okay so the Disposition field has two modes, and they answer the question "why did this happen?" 🧐

  • "manual-action": the disposition happened because the user explicitly told the MUA to do it, not because of something automatic 🙋‍♀️
  • "automatic-action": the disposition happened because of an automatic action, not because the user gave an instruction for this particular message 🤖

"Manual-action" and "automatic-action" are mutually exclusive, bestie. One or the other MUST be specified 💅

Then there's the sending side, which is about why the MDN itself went out:

  • "MDN-sent-manually": the user explicitly gave permission for this particular MDN to be sent ✨
  • "MDN-sent-automatically": the MUA was already set up to send MDNs automatically, so this one got sent because of that setting ⚙️

"MDN-sent-manually" and "MDN-sent-automatically" are mutually exclusive too. One or the other MUST be specified 🫶

3.2.6.2. Disposition types 🦋

These are the disposition types that are defined:

  • "displayed": the MUA has displayed the message to someone reading the recipient's mailbox. There is no guarantee that the content has been read or understood, so don't get too hyped about it yet 👀
  • "deleted": the message has been deleted. The recipient may or may not have actually seen it, and they might "undelete" it later and read it anyway 🗑️

3.2.6.3. Disposition modifiers 🌸

Okay, only one modifier is defined here, and it's the extension one:

  • disposition-modifier-extension: modifiers can be defined in the future by later revisions or extensions to this spec 🔮

Names starting with "X-" will never be defined as standard values. Those are reserved for experimental use 🧪 MDN disposition value names that do NOT 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. (See Section 10 for a registration form.) 📝 If a receiving MUA doesn't understand a modifier name, the MDN MAY be silently ignored or placed in the user's mailbox without special interpretation. It MUST not cause any error message to be sent to the sender of the MDN. That part is so important, bestie 🙅‍♀️

If an MUA developer doesn't want to register what their extension modifiers mean, they can use "X-" modifiers instead. To avoid name collisions, the name of the MUA implementation should follow the "X-", like "X-Foomail-" 🏷️

It is not required that an MUA be able to generate all of the possible values of the Disposition field. No pressure, periodt 💖

A user agent MUST NOT issue more than one MDN on behalf of each particular recipient. So once an MDN has gone out for a recipient, no more MDNs may be issued for them, even if another disposition happens to the message 🚫 The exception is forwarding. If a message is forwarded, a "dispatched" MDN may be issued for the recipient doing the forwarding, and the recipient of the forwarded message may also cause an MDN to be generated. Main character energy in the chain, fr 🔁

3.2.7. Failure, Error, and Warning fields 💀

The Failure, Error, and Warning fields carry extra info as text messages, for when the "failure" disposition type, the "error" disposition modifier, and/or the "warning" disposition modifier show up. The syntax looks like this:

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

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

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

3.3. Extension-fields 🧩

More MDN fields may be defined in the future by later revisions or extensions to this spec. Extension-field names that start with "X-" will never be defined as standard fields, and they're reserved for experimental use 🔬 MDN field names that do NOT start with "X-" MUST be registered with IANA and described in a standards-track RFC or an experimental RFC approved by the IESG. (See Section 10 for a registration form.) MDN Extension-fields may be defined for these reasons:

  • (a) To tunnel extra info from foreign disposition reports through Internet MDNs. The names of these fields should start with the foreign environment's name, like X400-Physical-Forwarding-Address 🌍
  • (b) To carry diagnostic info that's specific to one particular MUA. The names should start with the MUA implementation that made the MDN, like Foomail-information 🔍

If an application developer doesn't want to register what their extension fields mean, they can use "X-" fields instead. To avoid name collisions, the name of the application implementation should follow the "X-", like "X-Foomail-Log-ID" or "X-Foomail-EDI-info" 🎀

4. Timeline of events ⏰

This timeline shows when the different events happen while a message is being processed and while MDNs are being generated. It's giving step-by-step drama 🎬

-- User composes message

-- User tells MUA to send message

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

-- MTA sends message to next MTA

-- Final MTA receives message

-- Final MTA delivers message to MUA (possibly generating a DSN)

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

-- MUA displays list of messages to user

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

-- MUA performs requested action and, with user's permission, sends
   an 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 📋

An MUA or gateway conforms to this specification if it generates MDNs according to the protocol defined in this memo ✅ It is not necessary to be able to generate all of the possible values of the Disposition field.

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 the time of submission. Ordinary SMTP doesn't guarantee that 🙃 but the SMTP extension defined in [RFC-DSN-SMTP] lets that info ride along in the envelope if it's available. The Original-Recipient header defined in this document gives the MTA a way to pass the original recipient address to the MUA 📮

Each sender-specified recipient address may result in more than one MDN. If an MDN is requested for a recipient that gets forwarded to multiple recipients of an "alias" (as defined in [RFC-DSN-SMTP], section 6.2.7.3), each of those recipients may issue an MDN 🌟

Successful distribution of a message to a mailing list exploder SHOULD be considered the final disposition of the message. A mailing list exploder MAY issue an MDN with a disposition type of "processed" and disposition modes of "automatic-action" and "MDN-sent-automatically", which says the message got forwarded to the list. In this case, the request for MDNs is not propagated to the members of the list 📬

Or, the mailing list exploder MAY issue no MDN and propagate the request for MDNs to all members of the list. That latter behavior is not recommended for any but small, closely knit lists, because it might cause large numbers of MDNs to be generated and may reveal confidential subscribers to the list 😬 The mailing list exploder MAY also direct MDNs to itself, correlate them, and produce a report to the original sender of the message 🧠

This specification places no restrictions on the processing of MDNs received by user agents or mailing lists. You do you 💅

6. Security Considerations 🔐

The following security considerations apply when using MDNs. Buckle up, this part is serious 😭

6.1. Forgery 🎭

MDNs may be forged as easily as ordinary Internet electronic mail 😱 User agents and automatic mail handling facilities (such as mail distribution list exploders) that want to make automatic use of MDNs should take appropriate precautions to minimize the potential damage from denial-of-service attacks.

Security threats related to forged MDNs include the sending of:

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

6.2. Privacy 🙈

Privacy is the other part of security, and it matters a lot 🔒 There may be cases where a message recipient doesn't want the disposition of messages addressed to them to be known, or is worried that sending MDNs may reveal other sensitive info (for example, when the message was read). In that situation, it is acceptable for the MUA to issue "denied" MDNs or to silently ignore requests for MDNs 🤫

If the Disposition-Notification-To header is passed on unmodified when a message is distributed to the subscribers of a mailing list, the subscribers to the list may be revealed to the sender of the original message by the generation of MDNs 👀

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

An unencrypted MDN could reveal confidential information about an encrypted message, especially if all or part of the original message is returned in part 3 of the multipart/report. Encrypted MDNs are not defined in this specification 🔑

In general, any optional MDN field may be omitted if the Reporting MUA site or user determines that including the field would be too great a compromise of site confidentiality. That need for confidentiality must be balanced against how useful the omitted info would be in MDNs ⚖️

In some cases, someone with access to the message stream may use the MDN request mechanism to watch the mail reading habits of a target 😳 If the target is known to generate MDN reports, they could add a disposition-notification-to field containing the envelope from address along with a source route. The source route is ignored in the comparison, so the addresses will always match. But if the source route is honored when the notification is sent, it could direct the message to some other destination 🚩 This risk can be minimized by not sending MDN's automatically 🛡️

6.3. Non-Repudiation ✨

okay bestie, MDNs do NOT give you non-repudiation with proof of delivery 😭🫶 Inside today's Internet Mail setup, the MDNs in this document are genuinely useful info for the mail user, but they can't be trusted as a guarantee that a message was or wasn't seen by the recipient. Even when nobody's forging them, they can get lost in transit 📭. And the recipient can totally sidestep the MDN mechanism in some way 🙈

if you need a possible solution for this, check out RFC 2634 [SEC-SERVICES] 🔐

6.4. Mail Bombing 💣

the MDN request mechanism opens up a new way to mailbomb a mailbox, and it's giving sneaky 👀 The MDN request notification includes an address where MDNs should be sent. An attacker could send a potentially huge batch of messages to unsuspecting third-party recipients with a fake disposition-notification-to: address 💀 If processing those requests is automatic or too simple, the target gets flooded with MDN notifications. That kind of attack can overwhelm the targeted mailbox's capacity and deny service 😭

so for that reason, MDN's SHOULD NOT be sent automatically when the disposition-notification-to: address is different from the envelope MAIL FROM address 🚫 see section 2.1 for more discussion 🎀

7. Collected Grammar 📜

NOTE: the following lexical tokens are defined in [RFC-MSGFMT]: atom, CRLF, mailbox, msg-id, text. The definitions of attribute and value are the same as in the definition of the Content-Type header in [RFC-MIME-BODY].

Message headers:

mdn-request-header =
   "Disposition-Notification-To" ":"
          mailbox *("," mailbox)

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

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

parameter = attribute "=" importance "," value *("," value)

importance = "required" / "optional"

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

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
          *( "," disposition-modifier ) ]

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

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

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

disposition-type = "displayed"
          / "deleted"

disposition-modifier =  "error" / 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: this section gives non-binding recommendations for building mail gateways that want to provide semi-transparent disposition notifications between the Internet and another electronic mail system. Specific MDN gateway requirements for a particular pair of mail systems may be defined by other documents 💖

8.1. Gatewaying from other mail systems to MDNs 📬

a mail gateway may issue an MDN to carry the contents of a "foreign" disposition notification over Internet Mail. When there are proper mappings from the foreign notification elements to MDN fields, the info can go into those MDN fields. Extra info (like whatever might be needed to tunnel the foreign notification through the Internet) can be defined in extension MDN fields. (Those fields should get names that identify the foreign mail protocol, e.g., X400-* for X.400 protocol elements 🧚)

the gateway must attempt to supply reasonable values for the Reporting-UA, Final-Recipient, and Disposition fields. These usually come from translating the values in the foreign notification into their Internet-style equivalents. Some loss of info is to be expected though 😭

the sender-specified recipient address and the original message-id, if they're in the foreign notification, should be preserved 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's possible, 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 🦋

it may be possible to gateway MDNs from the Internet into a foreign mail system. The main goal of that gatewaying is to convey disposition info in a form the destination system can actually use. A secondary goal is to allow "tunneling" of MDNs through foreign mail systems, in case the MDN can get gatewayed back into the Internet 🌈

in general, the recipient of the MDN (i.e., the sender of the original message) will want to know, for each recipient: the closest available approximation to the original recipient address, and the disposition (displayed, printed, etc.) 👑

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

if it's possible to tunnel an MDN through the destination environment, the gateway specification may define a way of preserving the MDN info in the disposition reports used by that environment ✨

8.3. Gatewaying of MDN-requests to other mail systems 🧚

by using the separate disposition-notification-to request header, this spec offers richer functionality than most, if not all, other email systems. In most other email systems, the notification recipient is the same as the message sender shown in the "from" address. There are two interesting cases when gatewaying into those systems:

  1. If the address in the disposition-notification-to header is identical to the address in the SMTP "MAIL FROM", the expected behavior will result, even if the disposition-notification-to information is lost. Systems should propagate the MDN request. 💖
  2. If the address in the disposition-notification-to header is different from the address in the SMTP "MAIL FROM", gatewaying into a foreign system without a separate notification address will result in unintended behavior. This is especially important when the message arrives via mailing list expansion software that may specifically replace the SMTP "MAIL FROM" address with an alternate address. In such cases, the MDN request should not be gatewayed and should be silently dropped. This is consistent with other forms of non-support for MDN. 🙈

9. Example 🎀

NOTE: this example is provided as illustration only, and is not considered part of the MDN protocol specification. If the example conflicts with the protocol definition above, the example is wrong 💀

likewise, the use of *-type subfield names or extension fields in this example is not to be construed as a definition for those type names or extension fields.

this is an MDN issued after a message has been displayed to the user of an Internet Mail user agent 📨

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

--RAA14128.773615765/example.com

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

--RAA14128.773615765/example.com
content-type: message/disposition-notification

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

--RAA14128.773615765/example.com
content-type: message/rfc822

[original message optionally goes here]

--RAA14128.773615765/example.com--

10. IANA Considerations 📋

this document specifies three types of parameters that must be registered with the Internet Assigned Numbers Authority (IANA) 🌸

the forms below are for registering a new parameter name for the Disposition-Notification-Options header, a new disposition modifier name, or a new MDN extension field. Each piece of info a registration form asks for can be satisfied either by putting the info on the form itself, or by including a reference to a published, publicly available specification that has the necessary info. IANA MAY reject registrations because of incomplete registration forms or incomplete specifications 🙅‍♀️

to register, fill out the applicable form below and send it via electronic mail to <IANA@IANA.ORG> 💌

10.1. 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 other non-ambiguous language.
  • (c) If parameter values are not made up entirely of graphic characters from the US-ASCII repertoire, a specification for how they are to be 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 the semantics of the parameter values.

10.2. Disposition modifier names 🦋

a registration for a disposition-modifier name (used in the Disposition field of a message/disposition-notification) 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 the semantics of the disposition modifier.

10.3. MDN extension field names 📝

okay so if you want to register a brand new MDN extension field name, you MUST include the following info 💅

  • (a) The proposed extension field name. 🏷️
  • (b) The syntax for extension values, specified using BNF, ABNF, regular expressions, or other non-ambiguous language. 🔤
  • (c) If extension-field values are not composed entirely of graphic characters from the US-ASCII repertoire, a specification for how they are to be 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 the semantics of the extension field. 📚
bestie, don't skip (d). the IESG approval and the standards track or experimental RFC reference are the receipts that prove what your field actually means 🧾

11. Acknowledgments 🫶

this document is an updated version of the original one written by Roger Fajman. his work on defining Message Disposition Notifications is so appreciated, we love a foundational legend 💖

RFC 2298 was based on the Delivery Status Notifications document [RFC-DSN-FORMAT] by Keith Moore and Greg Vaudreuil. a whole group from the IETF Receipt Working Group also contributed, and they are literally the reason this stuff exists: Harald Alvestrand, Ian Bell, Urs Eppenberger, Claus Andri Faerber, Ned Freed, Jim Galvin, Carl Hage, Mike Lake, Keith Moore, Paul Overell, Pete Resnick, and Chuck Shih. the collab energy is immaculate 👑✨

12. References 📚

12.1. Normative References 🌸

[RFC-SMTP]        Klensin, J., Ed., "Simple Mail Transfer Protocol",
                  RFC 2821, April 2001.

[RFC-MSGFMT]      Resnick, P., Ed., "Internet Message Format", RFC
                  2822, April 2001.

[RFC-MIME-BODY]   Freed, N. and N. Borenstein, "Multipurpose Internet
                  Mail Extensions (MIME) Part One: Format of Internet
                  Message Bodies", RFC 2045, November 1996.

[RFC-MIME-MEDIA]  Freed, N. and N. Borenstein, "Multipurpose Internet
                  Mail Extensions (MIME) Part Two: Media Types", RFC
                  2046, November 1996.

[RFC-MIME-HEADER] Moore, K., "MIME (Multipurpose Internet Mail
                  Extensions) Part Three: Message Header Extensions
                  for Non-ASCII Text", RFC 2047, November 1996.

[RFC-REPORT]      Vaudreuil, G., "The Multipart/Report Content Type
                  for the Reporting of Mail System Administrative
                  Messages", RFC 3462, January 2003.

[RFC-DSN-SMTP]    Moore, K., "Simple Mail Transfer Protocol (SMTP)
                  Service Extension for Delivery Status
                  Notifications", RFC 3461, January 2003.

[RFC-DSN-FORMAT]  Moore, K., and G. Vaudreuil, "An Extensible Format
                  for Delivery Status Notifications (DSNs)", RFC
                  3464, January 2003.

[RFC-KEYWORDS]    Bradner, S., "Key Words for Use in RFCs to Indicate
                  Requirement Levels", BCP 14, RFC 2119, March 1997.

12.2. Informative References 🦋

[SEC-SERVICES]    Hoffman, P., Ed., "Enhanced Security Services for
                  S/MIME", RFC 2634, June 1999.

Appendix A - Changes from RFC 2298 🎀

here's the glow-up tea ☕ from RFC 2298:

  • the document has new editors 🖊️
  • the dispositions "denied", and "failed" were removed from the document, bc nobody was implementing or using them at this time 💀
  • the disposition modifiers "warning", "superseded", "expired", "mailbox-terminated" never really got implemented, so they're deleted from this document. the extension modifier is still here, even though it's unused for now, because it's kept for future extension 🔮
  • general editorial cleanups happened too: spelling, grammar, and consistency in how terms are used. very clean girl era 🧼
  • the BNF for disposition notification options got modified so it doesn't need dummy values where they aren't otherwise needed 🧹

Authors' Addresses 💌

Tony Hansen
AT&T Laboratories
Middletown, NJ 07748
USA
Voice: +1-732-420-8934
EMail: tony+rfc3798@maillennium.att.com

Gregory M. Vaudreuil
Lucent Technologies
7291 Williamson Rd
Dallas, TX 75214
USA
Voice: +1 214 823 9325
EMail: GregV@ieee.org

the Internet Society owns the copyright here (2004!). this document is subject to the rights, licenses and restrictions in BCP 78, and except as set forth there, the authors keep all their rights. the legal fine print is serious, so here it is in full 🧾

THIS DOCUMENT AND THE INFORMATION CONTAINED HEREIN ARE PROVIDED ON AN "AS IS" BASIS AND THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.

Intellectual Property 🔐

the IETF doesn't take a position on whether any Intellectual Property Rights or other rights claimed to cover the technology in this document are valid or in scope, or on whether any license for them is available. it also doesn't say it has searched for those rights itself. the procedures for rights in RFC documents are in BCP 78 and BCP 79 🔍

copies of IPR disclosures made to the IETF Secretariat, any assurances of licenses to be made available, and the results of any attempt to get a general license or permission for implementers or users are available from the IETF's online IPR repository at http://www.ietf.org/ipr.

the IETF invites anyone to tell it about any copyrights, patents or patent applications, or other proprietary rights that may cover technology needed to implement this standard. send that info to the IETF at ietf-ipr@ietf.org 📬

Acknowledgement 💜

funding for the RFC Editor function is currently provided by the Internet Society 🌈

📦 where this page comes from