RFC 2046

RFC 2046: Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types 🎀

• RFC number: 2046 🦋
• Series: Network Working Group 💜
• Authors: N. Freed (Innosoft) and N. Borenstein (First Virtual) 🫶
• Category: Standards Track ✨
• Date: November 1996 🌸
• Obsoletes: 1521, 1522, 1590 💅
• Updates: the header doesn't list any RFCs being updated 🙈

Okay bestie, this is part 1 of an 11-part breakdown of RFC 2046, and it's the second MIME doc, all about media types 🧚 Let's get into it.

---

Status of this Memo

Okay so this doc is an Internet standards track protocol for the Internet community, and it's literally asking for discussion and suggestions 💖 If you want to know where this protocol stands in standardization, check the current "Internet Official Protocol Standards" (STD 1). Distribution is unlimited, so share it with everyone 🌈

Abstract

STD 11, RFC 822 is the classic message format. It's super detailed about US-ASCII message headers, but it basically leaves the message body as flat US-ASCII text 🙈 MIME, which is this whole set of docs, glows up the message format so you can have:

1. textual message bodies in character sets other than US-ASCII ✨
2. an extensible set of different formats for non-textual message bodies 🦋
3. multi-part message bodies 🧚
4. textual header information in character sets other than US-ASCII 💜

These docs are built on earlier work in RFC 934, STD 11, and RFC 1049, but they extend and revise it. Since RFC 822 said so little about message bodies, these docs are mostly orthogonal to RFC 822 (they sit alongside it) rather than being a revision of it 💅

The first doc, RFC 2045, covers the various headers used to describe the structure of MIME messages. This second doc, the one we're in right now, defines the general structure of the MIME media typing system and sets up an initial batch of media types 👑 The third doc, RFC 2047, describes extensions to RFC 822 so you can use non-US-ASCII text in Internet mail header fields 🌸 The fourth doc, RFC 2048, lays out the IANA registration procedures for MIME-related facilities. The fifth and final doc, RFC 2049, covers MIME conformance criteria, gives some illustrative examples of MIME message formats, and includes acknowledgements and the bibliography 🎀

These docs are revisions of RFCs 1521 and 1522, which were themselves revisions of RFCs 1341 and 1342. There's an appendix in RFC 2049 that describes the differences and changes from earlier versions 🫶

Table of Contents

   1. Introduction .........................................    3
   2. Definition of a Top-Level Media Type .................    4
   3. Overview Of The Initial Top-Level Media Types ........    4
   4. Discrete Media Type Values ...........................    6
   4.1 Text Media Type .....................................    6
   4.1.1 Representation of Line Breaks .....................    7
   4.1.2 Charset Parameter .................................    7
   4.1.3 Plain Subtype .....................................   11
   4.1.4 Unrecognized Subtypes .............................   11
   4.2 Image Media Type ....................................   11
   4.3 Audio Media Type ....................................   11
   4.4 Video Media Type ....................................   12
   4.5 Application Media Type ..............................   12
   4.5.1 Octet-Stream Subtype ..............................   13
   4.5.2 PostScript Subtype ................................   14
   4.5.3 Other Application Subtypes ........................   17
   5. Composite Media Type Values ..........................   17
   5.1 Multipart Media Type ................................   17
   5.1.1 Common Syntax .....................................   19
   5.1.2 Handling Nested Messages and Multiparts ...........   24
   5.1.3 Mixed Subtype .....................................   24
   5.1.4 Alternative Subtype ...............................   24
   5.1.5 Digest Subtype ....................................   26
   5.1.6 Parallel Subtype ..................................   27
   5.1.7 Other Multipart Subtypes ..........................   28
   5.2 Message Media Type ..................................   28
   5.2.1 RFC822 Subtype ....................................   28
   5.2.2 Partial Subtype ...................................   29
   5.2.2.1 Message Fragmentation and Reassembly ............   30
   5.2.2.2 Fragmentation and Reassembly Example ............   31
   5.2.3 External-Body Subtype .............................   33
   5.2.4 Other Message Subtypes ............................   40
   6. Experimental Media Type Values .......................   40
   7. Summary ..............................................   41
   8. Security Considerations ..............................   41
   9. Authors' Addresses ...................................   42
   A. Collected Grammar ....................................   43

1. Introduction ✨

Okay so the first doc in this set, RFC 2045, defines a bunch of header fields, including Content-Type 💖 The Content-Type field tells you what kind of data is in the body of a MIME entity. It does this by giving a media type and subtype, plus any extra auxiliary info that certain media types might need 🦋 After the type and subtype names, the rest of the header field is just a set of parameters written in attribute/value notation. The order of the parameters doesn't matter 🧚

Generally speaking, the top-level media type declares the broad kind of data, while the subtype names a specific format within that kind 💜 So a media type of image/xyz is enough to tell a user agent that the data is an image, even if the user agent has never heard of the xyz format 👑 This matters because it helps decide whether to show a user the raw data from an unrecognized subtype. That's a reasonable move for unrecognized subtypes of text, but not for unrecognized subtypes of image or audio 🙈 For this reason, registered subtypes of text, image, audio, and video SHOULD NOT contain embedded info that's really a different type. Compound formats SHOULD be represented using the multipart or application types instead 🎀

Parameters are modifiers of the media subtype, so they don't fundamentally change what the content is 🌸 Which parameters make sense depends on the media type and subtype. Most parameters belong to one specific subtype, but a given top-level media type can define parameters that apply to any subtype of that type. Parameters might be required by their defining media type or subtype, or they might be optional. MIME implementations MUST also ignore any parameters whose names they don't recognize 💅

MIME's Content-Type header field and media type mechanism was designed to be extensible on purpose 🌈 The set of media type/subtype pairs and their parameters is expected to grow a LOT over time. Several other MIME facilities, like transfer encodings and message/external-body access types, will probably get new values defined over time too 💖 To make sure all of these values get developed in an orderly, well-specified, and public way, MIME sets up a registration process. It uses the Internet Assigned Numbers Authority (IANA) as the central registry for MIME's various areas of extensibility 🫶 The registration process for those areas is described in a companion doc, RFC 2048 🦋

The initial seven standard top-level media types are defined and described in the rest of this document ⭐

2. Definition of a Top-Level Media Type 🧚

Okay so defining a top-level media type takes five things:

1. a name and a description of the type, including criteria for whether a particular type would qualify under that type ✨
2. the names and definitions of parameters, if any, that are defined for all subtypes of that type (including whether those parameters are required or optional) 💜
3. how a user agent and/or gateway should handle unknown subtypes of this type 🦋
4. general considerations on gatewaying entities of this top-level type, if any 🌸
5. any restrictions on content-transfer-encodings for entities of this top-level type 🎀

---

Part 1 of 11 is done, bestie 🫶 More parts are coming, so stay tuned for the next chunk of media types 💅🦋

3. Overview Of The Initial Top-Level Media Types ✨

okay so there are five discrete top-level media types 💅 and here they are:

1. text -- textual information 📝. The subtype "plain" is the big one. It means plain text with zero formatting commands or directives of any sort 🫶. Plain text is meant to be displayed "as-is" ✨, and you don't need any special software to get its full meaning, aside from support for the character set being used. Other subtypes are for enriched text, where app software can make the text look fancier, but that software must not be required just to get the general idea of the content 🌸. So possible "text" subtypes include any word processor format you can read without needing software that understands it 👀. Formats with embedded binary formatting info are not considered directly readable 🙈. A very simple and portable subtype, "richtext", was defined in RFC 1341, then revised in RFC 1896 under the name "enriched" 💜.
2. image -- image data 🖼️. "Image" needs a display device (like a graphical display, a graphics printer, or a FAX machine) to view the information 🦋. An initial subtype is defined for the widely-used image format JPEG. . subtypes are defined for two widely-used image formats, jpeg and gif 💖.
3. audio -- audio data 🎧. "Audio" needs an audio output device (like a speaker or a telephone) to "display" the contents 🎀. An initial subtype "basic" is defined in this document ✨.
4. video -- video data 🎬. "Video" needs the capability to display moving images, which typically means specialized hardware and software 🔥. An initial subtype "mpeg" is defined in this document 🧚.
5. application -- some other kind of data 📦. This is usually either uninterpreted binary data or information that's meant to be processed by an application 💅. The subtype "octet-stream" is for uninterpreted binary data, and in that case the simplest recommended action is to offer to write the information into a file for the user 🌈. The "PostScript" subtype is also defined for transporting PostScript material 🍓. Other expected uses for "application" include spreadsheets, data for mail-based scheduling systems, languages for "active" (computational) messaging, and word processing formats that aren't directly readable 🫶. Note that security considerations may exist for some types of application data, most notably "application/PostScript" and any form of active messaging 💀. These issues are discussed later in this document 🔒.

The two composite top-level media types are:

1. multipart -- data made up of multiple entities of independent data types 🧩. Four subtypes are initially defined. There's the basic "mixed" subtype, which specifies a generic mixed set of parts. There's "alternative" for representing the same data in multiple formats. There's "parallel" for parts meant to be viewed simultaneously. And there's "digest" for multipart entities where each part has a default type of "message/rfc822" 👑.
2. message -- an encapsulated message 💌. A body of media type "message" is itself all or a portion of some kind of message object, and those objects may or may not contain other entities in turn 🌸. The "rfc822" subtype is used when the encapsulated content is itself an RFC 822 message 📨. The "partial" subtype is defined for partial RFC 822 messages, so bodies that are thought to be too large to go through transport facilities in one piece can be fragmented and sent in pieces 🧩. Another subtype, "external-body", is defined for specifying large bodies by reference to an external data source 🔗.

It should be noted that the list of media type values given here may be augmented in time, via the mechanisms described above, and that the set of subtypes is expected to grow substantially 🌱✨.

---

4. Discrete Media Type Values 💜

okay so five of the seven initial media type values refer to discrete bodies 📦. The content of these types must be handled by non-MIME mechanisms, because they're opaque to MIME processors 🙈.

4.1. Text Media Type 📝

The "text" media type is for sending material that's mainly textual in form 💕. A "charset" parameter may be used to indicate the character set of the body text for "text" subtypes, including the subtype "text/plain", which is a generic subtype for plain text 🫶. Plain text doesn't provide for or allow formatting commands, font attribute specifications, processing instructions, interpretation directives, or content markup 🚫. It's seen simply as a linear sequence of characters, possibly interrupted by line breaks or page breaks 📄. Plain text may allow stacking several characters in the same position in the text 🔤. Plain text in scripts like Arabic and Hebrew may also include facilities that allow arbitrary mixing of text segments with opposite writing directions 🌍.

Beyond plain text, there are many formats for representing what might be known as "rich text" 🌈. An interesting thing about many of them is that they're somewhat readable even without the software that interprets them 👀. So it's useful to tell them apart from unreadable data like images, audio, or text represented in an unreadable form, right at the highest level 🧠. Without the right interpretation software, it's reasonable to show "text" subtypes to the user, but it's not reasonable to do that with most nontextual data 🙅. Formatted textual data should be represented using subtypes of "text" 💖.

4.1.1. Representation of Line Breaks 🌸

The canonical form of any MIME "text" subtype MUST always represent a line break as a CRLF sequence 🫶. Similarly, any occurrence of CRLF in MIME "text" MUST represent a line break 🔁. Use of CR and LF outside of line break sequences is also forbidden 🚫.

This rule applies regardless of format or character set or sets involved 🌏.

NOTE: The proper interpretation of line breaks when a body is displayed depends on the media type 👀. In particular, while it's appropriate to treat a line break as a transition to a new line when displaying a "text/plain" body, this treatment is actually incorrect for other subtypes of "text" like "text/enriched" [RFC-1896] 🙅. Similarly, whether or not line breaks should be added during display operations is also a function of the media type 🧠. It should not be necessary to add any line breaks to display "text/plain" correctly, whereas proper display of "text/enriched" requires the appropriate addition of line breaks ✨.

NOTE: Some protocols define a maximum line length 📏. For example, SMTP [RFC-821] allows a maximum of 998 octets before the next CRLF sequence 💌. To be transported by such protocols, data that includes too-long segments without CRLF sequences must be encoded with a suitable content-transfer-encoding 🎀.

4.1.2. Charset Parameter ✨

Okay bestie, the big character set moment for text/plain is the charset parameter 🎀. You write it like this:

Content-type: text/plain; charset=iso-8859-1

Unlike some other parameter values, the values of the charset parameter are NOT case sensitive 💖. If there's no charset parameter at all, the default character set, US-ASCII, must be assumed 🌸.

Future subtypes of "text" have to spell out whether they use a "charset" parameter at all, and they can restrict its values too 🧚. Any other "text" subtype (not "plain") should define the charset parameter the same way "text/plain" does, meaning the body is made up entirely of characters from the given charset 💅. Definers of future "text" subtypes should pay close attention to what multioctet character sets mean for their subtype 👀.

The charset parameter names a character set, using the meaning of "character set" from RFC 2045 🦋. The line break rules from the last section must also be observed, so a character set whose definition doesn't follow those rules can't be used in a MIME "text" subtype 🙅‍♀️.

There's an initial list of predefined character set names at the end of this section, and more can be registered with IANA ✨.

Other media types besides "text" subtypes are allowed to use the charset parameter the way it's defined here, just with the CRLF/line break restriction taken out 🌈. So any character set that fits the general definition of "character set" in RFC 2045 can be registered for MIME use 🫶.

NOTE: If the character set has 8-bit characters and those characters show up in the body, you need a Content-Transfer-Encoding header field and a matching encoding on the data so the body can get through mail transfer protocols like SMTP [RFC-821] 📬.

US-ASCII has had some drama 😭. There was confusion and ambiguity in its definition, and practice varied a lot. To wipe that out for good, it is strongly recommended that new user agents explicitly specify a character set as a media type parameter in the Content-Type header field 💜. "US-ASCII" doesn't mean "some random 7-bit set." It means every octet in the body must be read as a character from the US-ASCII character set 🔥. National and application-oriented versions of ISO 646 [ISO-646] are usually NOT identical to US-ASCII, so using them in Internet mail is explicitly discouraged 🙈. That's why ISO 646 isn't in this document on purpose 💅. The name "US-ASCII" points to the character set defined in ANSI X3.4-1986 [US-ASCII] ✨. The new international reference version (IRV) of the 1991 edition of ISO 646 is identical to US-ASCII 🌸. The name "ASCII" is reserved and must not be used for any purpose 🚫.

NOTE: RFC 821 explicitly says "ASCII" and points to an older version of the American Standard 📜. The whole point of a media type and character set is letting the receiver figure out exactly how the sender meant the coded message to be read. So if you assumed anything other than "strict ASCII" as the default, you'd risk sneaky, incompatible changes to what messages mean 😬. That also means messages with characters coded using other versions of ISO 646 than US-ASCII and the 1991 IRV, or using code-switching procedures (like those in ISO 2022), as well as 8bit or multiple octet character encodings, MUST use an appropriate character set specification to be consistent with MIME 🎀.

The complete US-ASCII character set is listed in ANSI X3.4-1986 📖. Control characters, including DEL (0-31, 127), don't have a defined meaning, except for the combo CRLF (US-ASCII values 13 and 10), which means "new line" 🍓. Two of them have de facto meanings that everyone uses: FF (12) usually means "start the next text at the top of a new page" 📄. TAB or HT (9) often (though not always) means "move the cursor to the next available column after the current position where the column number is a multiple of 8 (counting the first column as column 0)" ⭐. Outside of these conventions, any use of control characters or DEL in a body must either occur:

1. because a subtype of text other than "plain" specifically assigns some additional meaning, or
2. within the context of a private agreement between the sender and recipient. Such private agreements are discouraged and should be replaced by the other capabilities of this document 🙃.

NOTE: There are SO many character sets beyond US-ASCII 😩. Having a big pile of partially or totally overlapping character sets is NOT a good thing 💀. Honestly, a SINGLE character set that works universally for all of the world's languages in Internet mail would be way better 👑. Sadly, existing practice in several communities means multiple character sets are probably going to stick around for a while 🥲. So this document defines a small number of standard character sets for Internet use 🦋.

The defined charset values are:

1. US-ASCII -- as defined in ANSI X3.4-1986 [US-ASCII] 💖.
2. ISO-8859-X -- where "X" gets replaced, as needed, for the parts of ISO-8859 [ISO-8859]. Note that the ISO 646 character sets were deliberately left out in favor of their 8859 replacements, which are the designated character sets for Internet mail 🌷. As of the publication of this document, the legit values for "X" are the digits 1 through 10 🔢.

Characters in the range 128-159 have no assigned meaning in ISO-8859-X 🙅. Characters with values below 128 in ISO-8859-X mean exactly the same thing they do in US-ASCII 🫶.

Part 6 of ISO 8859 (Latin/Arabic alphabet) and part 8 (Latin/Hebrew alphabet) have characters that get written right to left and characters that get written left to right 🔄. But they don't define a canonical ordering method for showing bi-directional text 🤯. The charset values "ISO-8859-6" and "ISO-8859-8", however, say that the visual method is used [RFC-1556] 👀.

All of these character sets are used as pure 7bit or 8bit sets, with no shift or escape functions 🌈. What shift and escape sequences mean in these character sets isn't defined ❓.

The character sets above were the ones that were pretty uncontroversial while MIME was being drafted 🕊️. This document doesn't endorse any character set other than US-ASCII, and it admits that the future evolution of world character sets is still unclear 🔮.

Note that if you use a character set other than US-ASCII, it must always be explicitly specified in the Content-Type field 💅.

No character set name other than the ones defined above may be used in Internet mail, unless it has a formal specification published and is registered with IANA, or it's used by private agreement. In that second case, the character set name must begin with "X-" 🏷️.

Implementors are discouraged from defining new character sets unless it's absolutely necessary 🙏.

The "charset" parameter was mainly defined for textual data, which is why it's described in this section 📝. But non-textual data might also want to specify a charset value for some purpose. If it does, the same syntax and values should be used 🧩.

In general, composition software should always use the "lowest common denominator" character set possible 🍰. For example, if a body only has US-ASCII characters, it SHOULD be marked as US-ASCII, not ISO-8859-1. Like every ISO-8859 character set, ISO-8859-1 is a superset of US-ASCII 🌸. More generally, if a widely-used character set is a subset of another one, and a body only contains characters from that widely-used subset, it should be labelled as that subset 💜. This makes it more likely that the recipient can view the entity correctly 🎉.

4.1.3. Plain Subtype 📄

The simplest and most important subtype of "text" is "plain" 💖. It means plain text with no formatting commands or directives in it 🌷. Plain text is meant to be displayed "as-is," so you shouldn't need any interpretation of embedded formatting commands, font attribute specifications, processing instructions, interpretation directives, or content markup to display it properly ✨. The default media type for Internet mail, "text/plain; charset=us-ascii", describes what's already happening on the Internet 🌐. In other words, it's the type of body defined by RFC 822 📮.

No other "text" subtype is defined by this document 🙅‍♀️.

4.1.4. Unrecognized Subtypes 🤷‍♀️

Unrecognized subtypes of "text" should be treated as subtype "plain", as long as the MIME implementation knows how to handle the charset 🧚. Unrecognized subtypes that also specify an unrecognized charset should be treated as "application/octet-stream" 📦.

4.2. Image Media Type 🖼️

A media type of "image" means the body contains an image 🌸. The subtype names the specific image format, and these names are not case sensitive 💅. An initial subtype is "jpeg", for the JPEG format using JFIF encoding [JPEG] 📸.

The list of "image" subtypes given here is neither exclusive nor exhaustive 🦋. It's expected to grow as more types get registered with IANA, as described in RFC 2048 🌈.

Unrecognized subtypes of "image" should, at a minimum, be treated as "application/octet-stream" 💜. Implementations may optionally choose to pass image subtypes they don't specifically recognize to a secure and robust general-purpose image viewing application, if one is available 🖼️.

NOTE: Using a generic-purpose image viewing application this way inherits the security problems of the most dangerous type supported by the application 🚨😭. Be careful, bestie 🫶.

4.3. Audio Media Type 🎧

A media type of "audio" means the body contains audio data 🎶. There isn't a consensus yet on an "ideal" audio format for computers, but there's a pressing need for a format that gives interoperable behavior 🔥.

The initial subtype "basic" is specified to meet that need. It's an absolutely minimal, lowest common denominator audio format 🍓. Richer formats for higher quality and/or lower bandwidth audio are expected to be defined in a later document 🌟.

The content of the "audio/basic" subtype is single channel audio, encoded using 8bit ISDN mu-law [PCM] at a sample rate of 8000 Hz 🎙️.

Unrecognized subtypes of "audio" should, at a minimum, be treated as "application/octet-stream" 📦. Implementations may optionally choose to pass audio subtypes they don't specifically recognize to a robust general-purpose audio playing application, if one is available 🎵💖.

4.4. Video Media Type

okay so a video body is a time-varying picture 🎬✨ that can come with color and coordinated sound 🔊🦋. The word "video" is used in its most generic sense, so it's not tied to any one technology or format 💅. That means it doesn't block cute subtypes like compactly encoded animated drawings 🎨🌸. The mpeg subtype refers to video coded according to the MPEG standard [MPEG] 🎞️.

Ngl, this doc really doesn't love mixing multiple media in one body 🙅‍♀️. But lots of so-called video formats have synced audio built right in, so that's explicitly allowed for video subtypes 🫶.

Unrecognized video subtypes should at a minimum be treated as application/octet-stream 💀. Implementations may optionally pass them to a robust general-purpose video display app, if one is available 🍓🎬.

---

4.5. Application Media Type

The application type is for discrete data that doesn't fit in any of the other categories 🗂️, especially data meant to be processed by some kind of application program 💻. It's info that has to go through an application before a user can actually view or use it 👀. Expected uses include file transfer, spreadsheets, data for mail-based scheduling systems, and languages for "active" (computational) material 📅.

The active stuff is giving security problems 😭. Implementors need to understand those, and they're covered in detail under the application/PostScript media type 🔥.

For example, a meeting scheduler might define a standard format for info about proposed meeting dates 📆. An intelligent user agent would use that to chat with the user, and might then send more material based on the convo 💬. There have also been several "active" messaging languages where programs get shipped to a remote location and automatically run in the recipient's environment 🤯. Main character programming energy 👑.

Such applications may be defined as subtypes of application. This document defines two subtypes:

• octet-stream
• PostScript

The subtype of application will often be the name of the app the data is meant for, or include part of it 🧚. That does not mean any app name can be used freely as a subtype of application 🙅‍♀️.

---

4.5.1. Octet-Stream Subtype

The octet-stream subtype is for when a body contains arbitrary binary data 🤖. The parameters defined so far are:

1. TYPE: the general type or category of the binary data 🏷️. It's info for the human recipient, not for automatic processing 🙋‍♀️.
2. PADDING: the number of padding bits that were appended to the bit-stream of actual contents to make the enclosed 8bit byte-oriented data 🧩. This is super handy for enclosing a bit-stream when the total number of bits isn't a multiple of 8 🔢.

Both of these parameters are optional 🫶.

Some lore 📜: RFC 1341 defined a CONVERSIONS parameter, but it has since been removed 🪦. RFC 1341 also defined a NAME parameter, which gave a suggested file name in case the data got written to a file. That's been deprecated in anticipation of a separate Content-Disposition header field, to be defined in a later RFC 📂.

The recommended move for an implementation that receives an application/octet-stream entity is to simply offer to put the data in a file, with any Content-Transfer-Encoding undone 💾. Or it might use the data as input to a user-specified process ⚙️.

🚨 Security tea ☕: to reduce the danger of transmitting rogue programs 😈, it is strongly recommended that implementations NOT implement a path-search mechanism where an arbitrary program named in the Content-Type parameter (e.g., an interpreter= parameter) is found and executed using the message body as input. Please don't let that one slide, bestie 💀🛑

4.5.2. PostScript Subtype 📜✨

Okay bestie, so application/postscript means a PostScript program 💖. Two variants of the PostScript language are allowed right now 🖨️. The original level 1 variant is described in [POSTSCRIPT], and the newer level 2 variant is described in [POSTSCRIPT2] 💜.

Fun fact 🙈: PostScript is a registered trademark of Adobe Systems, Inc. So using the MIME media type application/postscript implies recognition of that trademark and all the rights it entails. Respect the brand, babe 💅.

PostScript has built-in labelling for the specific language features a program uses 🏷️. It's called the PostScript document structuring conventions, or DSC, and it's super general. It gives way more info than just the language level ✨. Using DSC isn't required, but it's strongly recommended as an aid to interoperability 🫶. Docs without proper structuring conventions can't be tested to see if they'll work in a given environment, so some systems may assume the worst and refuse to process unstructured documents 💀.

Running general-purpose PostScript interpreters comes with serious security risks 🚨, so implementors are discouraged from just yeeting PostScript bodies into "off-the-shelf" interpreters 🙅‍♀️. It's usually safe to send PostScript to a printer, since the potential for harm is greatly constrained by typical printer environments. Still, implementors should consider all of the following before they add interactive display of PostScript bodies to their MIME readers 👀.

Here's the tea ☕: this next bit lists some, though probably not all, of the possible problems with transporting PostScript entities.

1. Dangerous operations in the PostScript language include, but may not be limited to, the PostScript operators deletefile, renamefile, filenameforall, and file. file is only dangerous when applied to something other than standard input or output. Implementations may also define additional nonstandard file operators, and these may also pose a threat to security. filenameforall, the wildcard file search operator, may appear at first glance to be harmless. Note, however, that this operator has the potential to reveal information about what files the recipient has access to, and this information may itself be sensitive. Message senders should avoid the use of potentially dangerous file operators, since these operators are quite likely to be unavailable in secure PostScript implementations. Message receiving and displaying software should either completely disable all potentially dangerous file operators or take special care not to delegate any special authority to their operation. These operators should be viewed as being done by an outside agency when interpreting PostScript documents. Such disabling and/or checking should be done completely outside of the reach of the PostScript language itself, and care should be taken to insure that no method exists for re-enabling full-function versions of these operators.
2. The PostScript language provides facilities for exiting the normal interpreter, or server, loop 🔁. Changes made in this "outer" environment are customarily retained across documents, and in some cases may be retained semipermanently in nonvolatile memory. The operators associated with exiting the interpreter loop have the potential to interfere with subsequent document processing. As such, their unrestrained use constitutes a threat of service denial. PostScript operators that exit the interpreter loop include, but may not be limited to, the exitserver and startjob operators. Message sending software should not generate PostScript that depends on exiting the interpreter loop to operate, since the ability to exit will probably be unavailable in secure PostScript implementations. Message receiving and displaying software should completely disable the ability to make retained changes to the PostScript environment by eliminating or disabling the "startjob" and "exitserver" operations. If these operations cannot be eliminated or completely disabled, the password associated with them should at least be set to a hard-to-guess value.
3. PostScript provides operators for setting system-wide and device-specific parameters ⚙️. These parameter settings may be retained across jobs and may potentially pose a threat to the correct operation of the interpreter. The PostScript operators that set system and device parameters include, but may not be limited to, the "setsystemparams" and "setdevparams" operators. Message sending software should not generate PostScript that depends on the setting of system or device parameters to operate correctly. The ability to set these parameters will probably be unavailable in secure PostScript implementations. Message receiving and displaying software should disable the ability to change system and device parameters. If these operators cannot be completely disabled, the password associated with them should at least be set to a hard-to-guess value.
4. Some PostScript implementations provide nonstandard facilities for the direct loading and execution of machine code 🫠. Such facilities are quite obviously open to substantial abuse. Message sending software should not make use of such features. Besides being totally hardware-specific, they are also likely to be unavailable in secure implementations of PostScript. Message receiving and displaying software should not allow such operators to be used if they exist.
5. PostScript is an extensible language, and many, if not most, implementations of it provide a number of their own extensions. This document does not deal with such extensions explicitly, since they constitute an unknown factor. Message sending software should not make use of nonstandard extensions, since they are likely to be missing from some implementations. Message receiving and displaying software should make sure that any nonstandard PostScript operators are secure and don't present any kind of threat.
6. It is possible to write PostScript that consumes huge amounts of various system resources. It is also possible to write PostScript programs that loop indefinitely. Both types of programs have the potential to cause damage if sent to unsuspecting recipients. Message-sending software should avoid the construction and dissemination of such programs, which is antisocial 😤. Message receiving and displaying software should provide appropriate mechanisms to abort processing after a reasonable amount of time has elapsed. In addition, PostScript interpreters should be limited to the consumption of only a reasonable amount of any given system resource.
7. It is possible to include raw binary information inside PostScript in various forms. This is not recommended for use in Internet mail, both because it is not supported by all PostScript interpreters and because it significantly complicates the use of a MIME Content-Transfer-Encoding. (Without such binary, PostScript may typically be viewed as line-oriented data. The treatment of CRLF sequences becomes extremely problematic if binary and line-oriented data are mixed in a single PostScript data stream.)
8. Finally, bugs may exist in some PostScript interpreters, which could possibly be exploited to gain unauthorized access to a recipient's system 🚩. Apart from noting this possibility, there is no specific action to take to prevent this, apart from the timely correction of such bugs if any are found.

---

4.5.3. Other Application Subtypes 🧩

It is expected that many other subtypes of "application" will be defined in the future 🔮. MIME implementations must at a minimum treat any unrecognized subtypes as being equivalent to application/octet-stream.

5. Composite Media Type Values 🌈

The remaining two of the seven initial Content-Type values refer to composite entities 🎀. Composite entities are handled using MIME mechanisms. A MIME processor typically handles the body directly.

5.1. Multipart Media Type ✨

okay so for multipart entities 🧩, where one or more different sets of data get squished together into a single body, a "multipart" media type field must show up in the entity's header 💅. It's not optional, bestie. The body must then contain one or more body parts, each one preceded by a boundary delimiter line, and the last one followed by a closing boundary delimiter line. After its boundary delimiter line, each body part is a header area, a blank line, and a body area 🎀. So a body part is kinda like an RFC 822 message in syntax, but it means something totally different 🙈

A body part is an entity, so it is NOT to be interpreted as actually being an RFC 822 message. Like, no header fields are actually required in body parts 💀. A body part that starts with a blank line is allowed, and it's a body part where all the default values are to be assumed ✨. In that case, a missing Content-Type header usually means the body has a content-type of "text/plain; charset=US-ASCII".

The only header fields with a defined meaning for body parts are the ones whose names begin with Content-. Everything else may be ignored in body parts 🦋. Those other fields should generally be kept if at all possible, but gateways may discard them if necessary. They're allowed to show up in body parts, but nobody should depend on them. X- fields can be made for experimental or private purposes, with the understanding that the info in them may get lost at some gateways 🌸

NOTE: The distinction between an RFC 822 message and a body part is subtle, but it's super important 🔥 A gateway between Internet and X.400 mail, for example, must be able to tell the difference between a body part that contains an image and a body part that contains an encapsulated message, whose body is a JPEG image. To represent the latter, the body part must have Content-Type: message/rfc822, and its body (after the blank line) must be the encapsulated message, with its own Content-Type: image/jpeg header field. Using similar syntax makes it easier to convert messages to body parts and back again, but implementors have to understand the difference between the two 🧚 (For the special case where parts actually are messages, a "digest" subtype is also defined.)

As mentioned before, each body part is preceded by a boundary delimiter line that holds the boundary delimiter. The boundary delimiter MUST NOT appear inside any of the encapsulated parts, either on a line by itself or as the prefix of any line 🚫 This means the composing agent has to be able to pick and specify a unique boundary parameter value that doesn't have the boundary parameter value of an enclosing multipart as a prefix. It's crucial, periodt 👑

All present and future subtypes of the "multipart" type must use an identical syntax 💜 Subtypes can differ in their semantics and can add extra restrictions on syntax, but they have to conform to the required syntax for the "multipart" type. This is what makes sure that all conformant user agents can at least recognize and separate the parts of any multipart entity, even ones from an unrecognized subtype 🫶

As stated in the definition of the Content-Transfer-Encoding field [RFC 2045], no encoding other than "7bit", "8bit", or "binary" is permitted for entities of type "multipart" 🍓 The "multipart" boundary delimiters and header fields are always represented as 7bit US-ASCII in any case (though the header fields may encode non-US-ASCII header text as per RFC 2047). The data inside the body parts can be encoded on a part-by-part basis, with Content-Transfer-Encoding fields for each appropriate body part. Iconic behaviour, honestly 😭✨

5.1.1. Common Syntax ✨

okay so this is the part where we set the ground rules for every single "multipart" subtype 💅 All subtypes of multipart must use this syntax, period. There's a simple example right here, and a fancier multipart message lives in RFC 2049 if you want to see the drama 🍓

The Content-type field for multipart entities requires one parameter, "boundary" 🔑 The boundary delimiter line is then a line made up of entirely two hyphen characters ("-", decimal value 45), followed by the boundary parameter value from the Content-Type header field, then optional linear whitespace, and then a terminating CRLF. Iconic 🦋

NOTE: The hyphens are there for rough compatibility with the older RFC 934 way of encapsulating messages, and they make the boundaries easier to search for in some implementations 🔍 However, multipart messages are NOT completely compatible with RFC 934 encapsulations. In particular, they don't follow RFC 934 quoting rules for embedded lines that start with hyphens. This mechanism was picked over the RFC 934 one because that one makes lines grow with every level of quoting. Combine that growth with SMTP implementations sometimes wrapping long lines, and the RFC 934 approach just wasn't going to work if deeply-nested multipart structuring ever became a thing 💀

WARNING TO IMPLEMENTORS: The grammar for parameters on the Content-type field is such that you often need to put the boundary parameter values in quotes on the Content-type line. It's not always necessary, but it never hurts 🫶 Implementors should study the grammar carefully so they don't end up producing invalid Content-type fields. So a typical "multipart" Content-Type header field might look like this:

  Content-Type: multipart/mixed; boundary=gc0p4Jq0M2Yt08j34c0p

But the following is not valid:

  Content-Type: multipart/mixed; boundary=gc0pJq0M:08jU534c0p

(because of the colon) and must instead be represented as

  Content-Type: multipart/mixed; boundary="gc0pJq0M:08jU534c0p"

This Content-Type value means the content is made up of one or more parts. Each part has a structure that is syntactically identical to an RFC 822 message, except that its header area is allowed to be completely empty. Each part is preceded by the line

  --gc0pJq0M:08jU534c0p

The boundary delimiter MUST occur at the beginning of a line, which means right after a CRLF. The initial CRLF counts as attached to the boundary delimiter line, not as part of the part before it 🧚 The boundary may be followed by zero or more characters of linear whitespace. After that it is terminated by either another CRLF plus the header fields for the next part, or by two CRLFs, in which case the next part has no header fields at all. If there's no Content-Type field, it's assumed to be "message/rfc822" in a "multipart/digest" and "text/plain" otherwise.

NOTE: The CRLF before the boundary delimiter line is conceptually attached to the boundary, so a part is allowed to not end with a CRLF (line break). So if a body part is supposed to end with a line break, it needs two CRLFs before the boundary delimiter line. The first one belongs to the body part, and the second one belongs to the encapsulation boundary 🎀

Boundary delimiters must not appear within the encapsulated material, and must be no longer than 70 characters, not counting the two leading hyphens.

The boundary delimiter line after the last body part is a special delimiter that says no more body parts are coming 🛑 It looks just like the earlier delimiter lines, except it has two more hyphens after the boundary parameter value:

  --gc0pJq0M:08jU534c0p--

NOTE TO IMPLEMENTORS: Boundary string comparisons have to compare the boundary value with the beginning of each candidate line. An exact match of the entire candidate line is not required. It's enough for the boundary to appear in its entirety right after the CRLF 👑

There seems to be room for extra info before the first boundary delimiter line and after the final boundary delimiter line. Those areas should generally be left blank, and implementations must ignore anything that shows up before the first boundary delimiter line or after the last one 🙈

NOTE: These "preamble" and "epilogue" areas are generally not used, because parts don't get proper typing there and there aren't clear semantics for handling those areas at gateways, especially X.400 gateways. That said, rather than leaving the preamble blank, a lot of MIME implementations use it as a handy spot for an explanatory note for people reading the message with pre-MIME software. Those notes get ignored by MIME-compliant software, so everyone's happy 🌈

NOTE: Because boundary delimiters must not appear in the body parts being encapsulated, a user agent has to be careful to pick a unique boundary parameter value. The boundary parameter value in the example above could have come from an algorithm designed to produce boundary delimiters that have a very low probability of already existing in the data being encapsulated, without having to prescan the data. Other algorithms might give more "readable" boundary delimiters for a recipient with an old user agent, but they'd need more attention to the chance that the boundary delimiter could show up at the start of some line in the encapsulated part. The simplest boundary delimiter line possible is something like "---", with a closing boundary delimiter line of "-----" 🦋

As a super simple example, the following multipart message has two parts, both of them plain text. One is explicitly typed and the other is implicitly typed:

  From: Nathaniel Borenstein <nsb@bellcore.com>
  To: Ned Freed <ned@innosoft.com>
  Date: Sun, 21 Mar 1993 23:56:48 -0800 (PST)
  Subject: Sample message
  MIME-Version: 1.0
  Content-type: multipart/mixed; boundary="simple boundary"

  This is the preamble.  It is to be ignored, though it
  is a handy place for composition agents to include an
  explanatory note to non-MIME conformant readers.

  --simple boundary

  This is implicitly typed plain US-ASCII text.
  It does NOT end with a linebreak.
  --simple boundary
  Content-type: text/plain; charset=us-ascii

  This is explicitly typed plain US-ASCII text.
  It DOES end with a linebreak.

  --simple boundary--

  This is the epilogue.  It is also to be ignored.

Using a media type of "multipart" inside a body part of another "multipart" entity is explicitly allowed 🪆 In that case, for obvious reasons, you have to make sure each nested "multipart" entity uses a different boundary delimiter. See RFC 2049 for an example of nested "multipart" entities.

Using the "multipart" media type with only a single body part can be useful in certain contexts, and it's explicitly permitted 🍓

NOTE: Experience has shown that a "multipart" media type with a single body part is useful for sending non-text media types. It has the advantage of giving you the preamble as a place to put decoding instructions. Also, a bunch of SMTP gateways move or remove the MIME headers, and a clever MIME decoder can take a pretty good guess at multipart boundaries even when the Content-Type header is missing, so the message can still get decoded successfully 💅

The only mandatory global parameter for the "multipart" media type is the boundary parameter. It consists of 1 to 70 characters from a set of characters known to be very robust through mail gateways, and it must NOT end with white space. (If a boundary delimiter line appears to end with white space, that white space must be presumed to have been added by a gateway, and it must be deleted.) It's formally specified by the following BNF:

  boundary := 0*69<bchars> bcharsnospace

  bchars := bcharsnospace / " "

  bcharsnospace := DIGIT / ALPHA / "'" / "(" / ")" /
                   "+" / "_" / "," / "-" / "." /
                   "/" / ":" / "=" / "?"

Overall, the body of a "multipart" entity can be specified like this:

  dash-boundary := "--" boundary
                   ; boundary taken from the value of
                   ; boundary parameter of the
                   ; Content-Type field.

  multipart-body := [preamble CRLF]
                    dash-boundary transport-padding CRLF
                    body-part *encapsulation
                    close-delimiter transport-padding
                    [CRLF epilogue]

  transport-padding := *LWSP-char
                       ; Composers MUST NOT generate
                       ; non-zero length transport
                       ; padding, but receivers MUST
                       ; be able to handle padding
                       ; added by message transports.

  encapsulation := delimiter transport-padding
                   CRLF body-part

  delimiter := CRLF dash-boundary

  close-delimiter := delimiter "--"

  preamble := discard-text

  epilogue := discard-text

  discard-text := *(*text CRLF) *text
                  ; May be ignored or discarded.

  body-part := MIME-part-headers [CRLF *OCTET]
               ; Lines in a body-part must not start
               ; with the specified dash-boundary and
               ; the delimiter must not appear anywhere
               ; in the body part.  Note that the
               ; semantics of a body-part differ from
               ; the semantics of a message, as
               ; described in the text.

  OCTET := <any 0-255 octet value>

IMPORTANT: Free insertion of linear-white-space and RFC 822 comments between the elements shown in this BNF is NOT allowed, since this BNF doesn't specify a structured header field 🚫

NOTE: In certain transport enclaves, RFC 822 restrictions like the one that limits bodies to printable US-ASCII characters may not be in force. (That is, there may be transport domains that look like standard Internet mail transport as specified in RFC 821 and assumed by RFC 822, but without certain restrictions.) Relaxing these restrictions should be read as locally extending the definition of bodies, for example to include octets outside the US-ASCII range, as long as those extensions are supported by the transport and adequately documented in the Content- Transfer-Encoding header field. However, in no event are headers (either message headers or body part headers) allowed to contain anything other than US-ASCII characters 🌸

NOTE: Conspicuously missing from the "multipart" type is any notion of structured, related body parts. Anyone who wants more structured or integrated multipart messaging facilities is recommended to define subtypes of multipart that are syntactically identical but define relationships between the various parts. For example, subtypes of multipart could be defined that include a distinguished part, which in turn is used to specify the relationships between the other parts, probably by referring to them by their Content-ID field. Old implementations won't recognize the new subtype if this approach is used, but they'll treat it as multipart/mixed and will still be able to show the user the parts they do recognize 🎀

5.1.2. Handling Nested Messages and Multiparts ✨

okay so the message/rfc822 subtype (coming up in a later section 🦋) has no ending marker at all. It just keeps going until the data runs out. 🌊 Improperly cut-off multipart entities can also show up with no closing boundary marker, usually because some mail system glitched out 💀.

This matters a LOT when one of these lives inside another multipart structure 🪆. MIME implementations are therefore required to recognize outer-level boundary markers at ANY level of inner nesting. Checking only for the next boundary you expected is NOT enough, bestie 🙅‍♀️.

5.1.3. Mixed Subtype 🧺

The "mixed" subtype of "multipart" is for when the body parts are independent of each other but still need to be bundled in a specific order 📦. Any "multipart" subtype an implementation doesn't recognize must be treated as being of subtype "mixed" 🫶.

5.1.4. Alternative Subtype 🪞

"multipart/alternative" has the exact same syntax as "multipart/mixed", but the meaning is totally different 💅. Each body part is an "alternative" version of the SAME information. Think of it like one message wearing different outfits 👗.

Systems should recognize that the parts are interchangeable 🔁. They should pick the "best" type based on the local environment and references, and sometimes even ask the user 🙋‍♀️. Just like with "multipart/mixed", the order of the parts matters. For alternatives, the order goes from least faithful to the original content to most faithful 🎀. Generally, the best pick is the LAST part whose type the recipient's system supports 👑.

"multipart/alternative" is great for sending something fancy in a way that works ANYWHERE 🌈. Here's an example:

From: Nathaniel Borenstein <nsb@bellcore.com>
To: Ned Freed <ned@innosoft.com>
Date: Mon, 22 Mar 1993 09:41:09 -0800 (PST)
Subject: Formatted text mail
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary=boundary42

--boundary42
Content-Type: text/plain; charset=us-ascii

  ... plain text version of message goes here ...

--boundary42
Content-Type: text/enriched

  ... RFC 1896 text/enriched version of same message
      goes here ...

--boundary42
Content-Type: application/x-whatever

  ... fanciest version of same message goes here ...

--boundary42--

In this example, people whose mail apps understand "application/x-whatever" would only see the fancy version 🪄. Everyone else would only see the enriched or plain text version, depending on what their system can handle 🍓.

User agents that compose "multipart/alternative" entities must put the body parts in increasing order of preference, which means the preferred format goes LAST 📈. For fancy text, the sending user agent should put the plainest format first and the richest format last 💖. Receiving user agents should pick and display the last format they can actually show ✨. If one of the alternatives is itself a "multipart" with unrecognized sub-parts, the user agent may show that alternative, an earlier one, or both 🤷‍♀️.

NOTE: From an implementor's point of view, it might seem smarter to flip this and put the plainest alternative last 🙃. But putting the plainest alternative FIRST is the friendliest option when "multipart/alternative" entities get viewed in a non-MIME-conformant viewer 🧸. That makes things a bit harder for conformant MIME viewers, but back then, staying compatible with older mail readers was considered more important 👵.

Some user agents that can recognize more than one format may prefer to let the user choose which one to view 🎛️. That makes sense if a message has both a nicely formatted image version and an easy-to-edit text version 🖼️. The big thing is that the user should NOT automatically be shown several versions of the same data 🙅‍♀️. Either they see the last recognized version or they get to pick 💜.

THE SEMANTICS OF CONTENT-ID IN MULTIPART/ALTERNATIVE: 🆔 Each part of a "multipart/alternative" entity represents the same data, but going between the two forms might lose some information 🫠. For example, you lose info when you translate ODA to PostScript or plain text 📉. It is recommended that each part get a different Content-ID value when the two parts don't have identical information 🏷️. When the information is identical, like when several "message/external-body" parts offer different ways to reach the same data, they should share the same Content-ID value 🔗. That helps any caching on the recipient's end work better 🚀. The Content-ID values used by the parts should NOT be the same Content-ID value that describes the "multipart/alternative" as a whole, if there is one 🙈. So one Content-ID points at the "multipart/alternative" entity, and one or more other Content-IDs point at the parts inside it 🧁.

5.1.5. Digest Subtype 📰

This document defines a "digest" subtype of the "multipart" Content-Type 💌. It has the same syntax as "multipart/mixed", but the meaning is different. In a digest, the default Content-Type for a body part changes from "text/plain" to "message/rfc822" 💫. That's so the digest is easier to read, and it stays mostly compatible with RFC 934 (except for the quoting style) 📖.

Note: You CAN give a body part in a digest a Content-Type other than "message/rfc822", like a "text/plain" part describing what's in the digest. But honestly, please don't 🙅‍♀️. "multipart/digest" is meant for collections of messages 💌. If you need a "text/plain" part, put it in as a separate part of a "multipart/mixed" message instead 🧃.

A digest in this format might look something like this:

From: Moderator-Address
To: Recipient-List
Date: Mon, 22 Mar 1994 13:34:51 +0000
Subject: Internet Digest, volume 42
MIME-Version: 1.0
Content-Type: multipart/mixed;
              boundary="---- main boundary ----"

------ main boundary ----

  ...Introductory text or table of contents...

------ main boundary ----
Content-Type: multipart/digest;
              boundary="---- next message ----"

------ next message ----

From: someone-else
Date: Fri, 26 Mar 1993 11:13:32 +0200
Subject: my opinion

  ...body goes here ...

------ next message ----

From: someone-else-again
Date: Fri, 26 Mar 1993 10:07:13 -0500
Subject: my different opinion

  ... another body goes here ...

------ next message ------

------ main boundary ------

5.1.6. Parallel Subtype 🎶

This document also defines a "parallel" subtype of the "multipart" Content-Type 🎉. Its syntax matches "multipart/mixed", but it means something different. In a parallel entity, the order of the body parts does NOT matter 🌀.

Usually this type is shown by displaying all of the parts at the same time, on hardware and software that can do that 🖥️. Heads up though: composing agents should know that lots of mail readers can't do that, and will show the parts one after another anyway 🐢.

5.1.7. Other Multipart Subtypes 🧩

More "multipart" subtypes are expected in the future 🔮. MIME implementations must in general treat any unrecognized "multipart" subtype the same as "multipart/mixed" 🫧.

5.2. Message Media Type 💌

Sending mail often means wanting to wrap up another mail message inside it 🎁. That's why there's a special media type, "message", just for this 💜. The "rfc822" subtype of "message" is used to wrap up RFC 822 messages 📬.

NOTE: People have suggested defining "message" subtypes for forwarded or rejected messages 🤔. But forwarded and rejected messages can be done as multipart messages instead. The first part holds any control or descriptive info, and a second part, of type "message/rfc822", holds the forwarded or rejected message 💅. Doing it this way keeps the type info of the original message and lets it show up correctly for the recipient, so it is strongly encouraged 🫶.

Subtypes of "message" often put limits on which encodings are allowed 🔒. Those limits are described alongside each specific subtype 📝.

Mail gateways, relays, and other mail-handling agents are famously known for changing the top-level header of an RFC 822 message 🙈. They often add, remove, or reorder header fields 🔀. These actions are explicitly forbidden for the encapsulated headers inside the bodies of "message" type messages 🚫.

5.2.1. RFC822 Subtype 📮

A "message/rfc822" media type means the body holds an encapsulated message with the syntax of an RFC 822 message ✉️. But here's the twist: top-level RFC 822 messages have to include "From", "Date", and at least one destination header, and "message/rfc822" bodies DON'T have to. Instead, at least one of "From", "Subject", or "Date" must be present 🎀.

Despite the "822" in the name, a "message/rfc822" entity doesn't have to follow RFC 822 strictly 🧐. And its meaning isn't limited to what RFC 822 defines either 🌸. For example, a "message/rfc822" message could totally be a News article or a MIME message 📰✨.

Only the "7bit", "8bit", or "binary" encodings are allowed for the body of a "message/rfc822" entity 🚦. The message header fields are always US-ASCII no matter what, but the data in the body can still be encoded. If it is, the Content-Transfer-Encoding header field inside the encapsulated message reflects that 🔐. Non-US-ASCII text in an encapsulated message's headers can be written using the mechanisms in RFC 2047 🌍.

5.2.2. Partial Subtype 🧩✨

okay so the "partial" subtype is literally how you send a HUGE entity in pieces 📦 and then the receiving user agent glues it back together automatically 🫶 (it's giving IP fragmentation and reassembly vibes from the basic Internet Protocols). You'd use it when the transport agents in the middle put a size limit on each message. So "message/partial" just tells you that the body is one fragment of a bigger entity 🦋

Now here's the tea. "message" data can never be base64 or quoted-printable encoded 💀 so there's a problem if you build "message/partial" entities in an environment that supports binary or 8bit transport. The binary data gets split into several "message/partial" messages, and each one needs binary transport. If one of those hits a gateway into a 7bit world, there's no clean way to encode it, unless you wait for ALL the fragments, reassemble the inner message, and only then encode it in base64 or quoted-printable. And that's still not okay, because different fragments could go through different gateways 😭 So the rule is that entities of type "message/partial" must always have a content-transfer-encoding of 7bit, which is the default 💅 Even in environments that support binary or 8bit transport, using "8bit" or "binary" is explicitly prohibited for MIME entities of type "message/partial". And that means the inner message can't use "8bit" or "binary" encoding either 🙈

Some message transfer agents like to auto-fragment big messages, and they can use totally different thresholds. So when the pieces get reassembled, the result might itself turn out to be a partial message. That is explicitly permitted ✨

Three parameters MUST be specified in the Content-Type field of a "message/partial" 🎀 First up is "id", a unique identifier (as close to world-unique as possible) that matches the fragments together. It's basically a message-id, and if you wrap it in double quotes it can be ANY message-id, as long as it follows the BNF for "parameter" from RFC 2045 👑 Second is "number", an integer for the fragment number, showing where this piece fits in the sequence. Third is "total", another integer, giving the total number of fragments. That third one is required on the final fragment and optional (though encouraged) on the earlier ones 🌸 Also, these parameters can show up in any order, which is very chill of them 🍓

So the second piece of a 3-piece message could have either of these header fields:

  Content-Type: Message/Partial; number=2; total=3;
                id="oc=jpbe0M2Yt4s@thumper.bellcore.com"

  Content-Type: Message/Partial;
                id="oc=jpbe0M2Yt4s@thumper.bellcore.com";
                number=2

But the third piece MUST specify the total number of fragments:

  Content-Type: Message/Partial; number=3; total=3;
                id="oc=jpbe0M2Yt4s@thumper.bellcore.com"

Quick reminder that fragment numbering starts at 1, not 0 🧚 Once all the fragments are put back together, you always get a complete MIME entity. It can have its own Content-Type header field, so it could be any other data type at all 🌈

5.2.2.1. Message Fragmentation and Reassembly 🪄

The semantics of a reassembled partial message have to be those of the "inner" message, not of a message that contains the inner message. This is the whole magic trick, because you can send a big audio message in several partial pieces and it still shows up for the recipient as a plain audio message, not as an encapsulated message holding an audio message 🎧 The encapsulation is considered "transparent", which is so iconic 👑

When you generate and reassemble the pieces of a "message/partial" message, the headers of the encapsulated message have to get merged with the headers of the enclosing entities. These four rules must be observed:

(1) Fragmentation agents must split messages at line boundaries only. The reason is that splitting anywhere other than the ends of lines depends on transports being able to keep the meaning of messages that don't end with a CRLF sequence, and lots of transports just can't do that 😭

(2) All of the header fields from the initial enclosing message get copied, in order, into the new message, EXCEPT for the ones that start with Content- and the specific fields Subject, Message-ID, Encrypted, and MIME-Version.

(3) The header fields in the enclosed message that start with Content-, plus Subject, Message-ID, Encrypted, and MIME-Version, get appended, in order, to the header fields of the new message. Any other enclosed header that doesn't start with Content- (apart from Subject, Message-ID, Encrypted, and MIME-Version) gets ignored and dropped 🗑️

(4) All of the header fields from the second and any later enclosing messages get thrown away by the reassembly process 💀

5.2.2.2. Fragmentation and Reassembly Example 🎀

Say an audio message gets split into two pieces. The first piece might look something like this:

  X-Weird-Header-1: Foo
  From: Bill@host.com
  To: joe@otherhost.com
  Date: Fri, 26 Mar 1993 12:59:38 -0500 (EST)
  Subject: Audio mail (part 1 of 2)
  Message-ID: <id1@host.com>
  MIME-Version: 1.0
  Content-type: message/partial; id="ABC@host.com";

                X-Weird-Header-1: Bar
  X-Weird-Header-2: Hello
  Message-ID: <anotherid@foo.com>
  Subject: Audio mail
  MIME-Version: 1.0
  Content-type: audio/basic
  Content-transfer-encoding: base64

    ... first half of encoded audio data goes here ...

Wait, that copy got mangled. Here is the exact original of that first piece:

  X-Weird-Header-1: Foo
  From: Bill@host.com
  To: joe@otherhost.com
  Date: Fri, 26 Mar 1993 12:59:38 -0500 (EST)
  Subject: Audio mail (part 1 of 2)
  Message-ID: <id1@host.com>
  MIME-Version: 1.0
  Content-type: message/partial; id="ABC@host.com";

                number=1; total=2

  X-Weird-Header-1: Bar
  X-Weird-Header-2: Hello
  Message-ID: <anotherid@foo.com>
  Subject: Audio mail
  MIME-Version: 1.0
  Content-type: audio/basic
  Content-transfer-encoding: base64

    ... first half of encoded audio data goes here ...

And the second half might look like this:

  From: Bill@host.com
  To: joe@otherhost.com
  Date: Fri, 26 Mar 1993 12:59:38 -0500 (EST)
  Subject: Audio mail (part 2 of 2)
  MIME-Version: 1.0
  Message-ID: <id2@host.com>
  Content-type: message/partial;
                id="ABC@host.com"; number=2; total=2

    ... second half of encoded audio data goes here ...

Once the fragmented message gets reassembled, the result the user actually sees should look like this:

  X-Weird-Header-1: Foo
  From: Bill@host.com
  To: joe@otherhost.com
  Date: Fri, 26 Mar 1993 12:59:38 -0500 (EST)
  Subject: Audio mail
  Message-ID: <anotherid@foo.com>
  MIME-Version: 1.0
  Content-type: audio/basic
  Content-transfer-encoding: base64

    ... first half of encoded audio data goes here ...
    ... second half of encoded audio data goes here ...

Adding a "References" field to the headers of the second and later pieces, pointing at the Message-Id of the previous piece, can help mail readers that understand and track references 🧐 Generating those "References" fields is entirely optional, though.

Last thing: the "Encrypted" header field was made obsolete by Privacy Enhanced Messaging (PEM) [RFC-1421, RFC-1422, RFC-1423, RFC-1424]. The rules above are still believed to describe the correct way to handle it if you run into it while converting to and from "message/partial" fragments 🔒

5.2.3. External-Body Subtype 🔗

The external-body subtype says the actual body data is NOT included, just referenced 🫣 In that case the parameters describe a mechanism for getting to the external data.

When a MIME entity is of type "message/external-body", it has a header, two consecutive CRLFs, and the message header for the encapsulated message. If another pair of consecutive CRLFs shows up, that ends the encapsulated message's header. But since the encapsulated message's body is itself external, it does NOT appear in the area that follows. For example, here's a message:

  Content-type: message/external-body;
                access-type=local-file;
                name="/u/nsb/Me.jpeg"

  Content-type: image/jpeg
  Content-ID: <id42@guppylake.bellcore.com>
  Content-Transfer-Encoding: binary

  THIS IS NOT REALLY THE BODY!

That area at the end, which you could call the "phantom body", gets ignored for most external-body messages. It can hold auxiliary information for some of them though, like when the access-type is "mail-server". The only access-type defined in this document that uses the phantom body is "mail-server", but other access-types might get defined later in other specifications that use that area 🧚

The encapsulated headers in ALL "message/external-body" entities MUST include a Content-ID header field giving a unique identifier to reference the data. That identifier can be used for caching, and for recognizing when the data has arrived when the access-type is "mail-server" 💖

Quick heads up: as specified here, the tokens that describe external-body data (like file names and mail server commands) are required to be in the US-ASCII character set ⚠️

If that turns out to be a problem in practice, a new mechanism may be needed as a future extension to MIME. It could be newly defined access-types for "message/external-body", or some other mechanism entirely.

Same deal as with "message/partial": MIME entities of type "message/external-body" MUST have a content-transfer-encoding of 7bit (the default). Even in environments that support binary or 8bit transport, using "8bit" or "binary" is explicitly prohibited for entities of type "message/external-body" 🙅‍♀️

5.2.3.1. General External-Body Parameters 🎀

okay so these are the parameters that work with ANY message/external-body 💅 they're the core crew, and the ones that come with every access type:

1. ACCESS-TYPE: a word that tells you how to actually get the file or data. It's NOT case sensitive 🙈 the values include (but aren't limited to) "FTP", "ANON-FTP", "TFTP", "LOCAL-FILE", and "MAIL-SERVER". Any future values, apart from experimental ones starting with X-, MUST be registered with IANA, as described in RFC 2048. This one is totally mandatory and MUST be present on EVERY message/external-body 🔥
2. EXPIRATION: the date, written in RFC 822 date-time syntax (which RFC 1123 extended so the year can be 4 digits 🧚), after which the external data is not guaranteed to still exist. It works with ANY access-type and is ALWAYS optional 🌸
3. SIZE: the size of the data, in octets 📏 the whole point is to help the recipient decide whether it's worth spending the resources to fetch the external data. Heads up: this is the size in its canonical form, meaning before any Content-Transfer-Encoding has been applied, or after the data has been decoded 🤓 It works with ANY access-type and is ALWAYS optional ✨
4. PERMISSION: a case-insensitive field that says whether clients might also try to overwrite the data 👀 By default, or if permission is "read", the assumption is they won't, and if the data gets retrieved once, it's never needed again. If PERMISSION is "read-write", that assumption is invalid, and any local copy must be considered no more than a cache 😭 "Read" and "Read-write" are the only defined values of permission. It works with ANY access-type and is ALWAYS optional 💜

The precise semantics of the access-types defined here are described in the sections that follow 🦋

5.2.3.2. The 'ftp' and 'tftp' Access-Types 🌈

okay so an access-type of FTP or TFTP means the message body is accessible as a file using the FTP [RFC-959] or TFTP [RFC-783] protocols, respectively. For these access-types, the following additional parameters are mandatory 🫶

1. NAME: the name of the file that holds the actual body data 📁
2. SITE: a machine you can grab the file from, using the given protocol. This MUST be a fully qualified domain name, not a nickname 🙅‍♀️
3. Before any data gets retrieved using FTP, the user will generally need to be asked for a login id and a password for the machine named by the SITE parameter. For security reasons, that id and password are NOT specified as content-type parameters 🔐 they have to be obtained from the user.

In addition, the following parameters are optional 💅

1. DIRECTORY: a directory the data named by NAME should be retrieved from 🗂️
2. MODE: a case-insensitive string for the mode to use when retrieving the information 🎶 The valid values for access-type "TFTP" are "NETASCII", "OCTET", and "MAIL", as specified by the TFTP protocol [RFC-783]. The valid values for access-type "FTP" are "ASCII", "EBCDIC", "IMAGE", and "LOCALn", where n is a decimal integer, typically 8. These correspond to the representation types A, E, I, and L n as specified by the FTP protocol [RFC-959]. Note that "BINARY" and "TENEX" are not valid values for MODE, and that "OCTET" or "IMAGE" or "LOCAL8" should be used instead 🙃 IF MODE is not specified, the default value is "NETASCII" for TFTP and "ASCII" otherwise ✨

5.2.3.3. The 'anon-ftp' Access-Type 🕶️

The "anon-ftp" access-type is identical to the "ftp" access type, except that the user doesn't need to be asked for a name and password for the specified site 🙌 Instead, the ftp protocol will be used with login "anonymous" and a password that corresponds to the user's mail address 📧

5.2.3.4. The 'local-file' Access-Type 🏠

An access-type of "local-file" means the actual body is accessible as a file on the local machine 💻 Two additional parameters are defined for this access type:

1. NAME: the name of the file that holds the actual body data. This parameter is mandatory for the "local-file" access-type 📄
2. SITE: a domain specifier for a machine, or a set of machines, that are known to have access to the data file 🌐 This optional parameter describes the locality of reference for the data, meaning the site or sites where the file is expected to be visible. Asterisks may be used for wildcard matching to part of a domain name, such as "*.bellcore.com", to indicate a set of machines where the data should be directly visible 👯. A single asterisk may be used to indicate a file that is expected to be universally available, e.g., via a global file system 🌍

5.2.3.5. The 'mail-server' Access-Type 📬

The "mail-server" access-type indicates that the actual body is available from a mail server 💌 Two additional parameters are defined for this access-type:

1. SERVER: the addr-spec of the mail server the actual body data can be obtained from. This parameter is mandatory for the "mail-server" access-type 📮
2. SUBJECT: the subject to use in the mail that gets sent to obtain the data. Note that keying mail servers on Subject lines is NOT RECOMMENDED, but such mail servers are known to exist 🙈 This is an optional parameter.

Because mail servers accept a variety of syntaxes, some of which are multiline, the full command to send to a mail server is NOT included as a parameter in the content-type header field 🙅 Instead, it's provided as the "phantom body" when the media type is "message/external-body" and the access-type is mail-server 👻

Note that MIME does not define a mail server syntax. Rather, it allows the inclusion of arbitrary mail server commands in the phantom body 🧠 Implementations must include the phantom body in the body of the message they send to the mail server address to retrieve the relevant data.

Unlike other access-types, mail-server access is asynchronous and will happen at an unpredictable time in the future 😭 For this reason, it's important that there be a mechanism by which the returned data can be matched up with the original "message/external-body" entity. MIME mail servers must use the same Content-ID field on the returned message that was used in the original "message/external-body" entities, to make that matching possible 🫶

5.2.3.6. External-Body Security Issues 🚨

"Message/external-body" entities give rise to two important security issues, and we need to talk about them, bestie 💀

1. Accessing data via a "message/external-body" reference effectively results in the message recipient performing an operation that was specified by the message originator. It is therefore possible for the message originator to trick a recipient into doing something they would not have done otherwise 😱 For example, an originator could specify an action that attempts retrieval of material the recipient is not authorized to obtain, causing the recipient to unwittingly violate some security policy. For this reason, user agents capable of resolving external references must always take steps to describe the action they are to take to the recipient and ask for explicit permission prior to performing it 🛑

The 'mail-server' access-type is particularly vulnerable, because it causes the recipient to send a new message whose contents are specified by the original message's originator 📤 Given the potential for abuse, any such request messages that are constructed should contain a clear indication that they were generated automatically (e.g. in a Comments: header field) in an attempt to resolve a MIME "message/external-body" reference 🤖

2. MIME will sometimes be used in environments that provide some guarantee of message integrity and authenticity 🔏 If present, such guarantees may apply only to the actual direct content of messages. They may or may not apply to data accessed through MIME's "message/external-body" mechanism. In particular, it may be possible to subvert certain access mechanisms even when the messaging system itself is secure 👀

It should be noted that this problem exists either with or without the availability of MIME mechanisms 🙃 A casual reference to an FTP site containing a document in the text of a secure message brings up similar issues. The only difference is that MIME provides for automatic retrieval of such material, and users may place unwarranted trust in such automatic retrieval mechanisms 🥺

5.2.3.7. Examples and Further Explanations ✨

okay so when external-body teams up with "multipart/alternative" 🦋 it levels up that type so the same entity can show up in the same format but through different access mechanisms. the originator must order the parts first by preferred formats, and then by preferred access mechanisms. the recipient's viewer then checks the list for both format and access mechanism. so smart 💅

with wide-area file systems getting bigger every day, it's honestly so hard to know ahead of time which machines can reach a file directly 😭 so it can make sense to give both a file name to try directly and the name of one or more sites where the file is known to be accessible 🌸 an implementation can try to grab remote files using FTP or any other protocol, either with anonymous retrieval or by prompting the user for the name and password. if an external body is reachable through several mechanisms, the sender may include multiple "message/external-body" entities inside the body parts of an enclosing "multipart/alternative" entity. 🎀

and the external-body mechanism isn't just for file retrieval either, as the mail-server access-type shows 🧚 you could even imagine a video server for external references to video clips. literally endless possibilities 🌈

the embedded message header fields in the body of "message/external-body" data must be used to declare the media type of the external body if it's anything other than plain US-ASCII text. the external body doesn't have a header section to declare its type, so it's on those fields to do it 🙈 same deal for any Content-transfer-encoding other than "7bit", which must also be declared there. so a complete "message/external-body" message that points at a PostScript object could look like this:

From: Whomever
To: Someone
Date: Whenever
Subject: whatever
MIME-Version: 1.0
Message-ID: <id1@host.com>
Content-Type: multipart/alternative; boundary=42
Content-ID: <id001@guppylake.bellcore.com>

--42
Content-Type: message/external-body; name="BodyFormats.ps";
              site="thumper.bellcore.com"; mode="image";
              access-type=ANON-FTP; directory="pub";
              expiration="Fri, 14 Jun 1991 19:13:14 -0400 (EDT)"

Content-type: application/postscript
Content-ID: <id42@guppylake.bellcore.com>

--42
Content-Type: message/external-body; access-type=local-file;
              name="/u/nsb/writing/rfcs/RFC-MIME.ps";
              site="thumper.bellcore.com";
              expiration="Fri, 14 Jun 1991 19:13:14 -0400 (EDT)"

Content-type: application/postscript
Content-ID: <id42@guppylake.bellcore.com>

--42
Content-Type: message/external-body;
              access-type=mail-server
              server="listserv@bogus.bitnet";
              expiration="Fri, 14 Jun 1991 19:13:14 -0400 (EDT)"

Content-type: application/postscript
Content-ID: <id42@guppylake.bellcore.com>

get RFC-MIME.DOC

--42--

note that in those examples, the default Content-transfer-encoding of "7bit" is assumed for the external postscript data 🍓

like the "message/partial" type, "message/external-body" is meant to be transparent 👑 it conveys the data type in the external body rather than a message with a body of that type. so the headers on the outer and inner parts must be merged using the same rules as for "message/partial". in particular, the Content-type and Subject fields get overridden, but the From field is preserved 💜

also, since the external bodies aren't transported along with the external body reference, they don't need to follow the transport limitations that apply to the reference itself. internet mail transports may impose 7bit and line length limits, but those don't automatically apply to binary external body references. so a Content-Transfer-Encoding is not generally necessary, though it is permitted ✨

last but not least, the body of a "message/external-body" message follows the basic syntax for an RFC 822 message. anything before the first consecutive pair of CRLFs is header information, while anything after it is body information, which gets ignored for most access-types 🫶

---

5.2.4. Other Message Subtypes 💅

MIME implementations must, in general, treat unrecognized subtypes of "message" as equivalent to "application/octet-stream" 🌸

future subtypes of "message" meant for use with email should be restricted to "7bit" encoding. if that restriction isn't possible, a type other than "message" should be used instead 🎀

---

6. Experimental Media Type Values 🧪

a media type value beginning with the characters "X-" is a private value, used by consenting systems by mutual agreement 🦋 any format without a rigorous and public definition must be named with an "X-" prefix, and publicly specified values shall never begin with "X-". (older versions of the widely used Andrew system use the "X-BE2" name, so new systems should probably pick a different name 🙈)

in general, "X-" top-level types are strongly discouraged 💀 implementors should invent subtypes of existing types whenever possible. in many cases, a subtype of "application" will be more appropriate than a new top-level type 👑

---

7. Summary 🌈

the five discrete media types provide a standardized way to tag entities as "audio", "image", or several other kinds of data 🎵 the composite "multipart" and "message" media types let you mix and nest entities of different types in a single message 🧚 a distinguished parameter syntax allows further specification of data format details, especially alternate character sets ✨ extra optional header fields provide mechanisms for certain extensions many implementors find desirable 💖 and a number of useful media types are defined for general use by consenting user agents, notably "message/partial" and "message/external-body" 🫶

---

9. Security Considerations 🔐

security issues are discussed in the context of the "application/postscript" type, the "message/external-body" type, and in RFC 2048 😭 implementors should pay special attention to the security implications of any media types that can cause remote execution of actions in the recipient's environment. this is serious, bestie 💀 in such cases, the discussion of the "application/postscript" type may serve as a model for considering other media types with remote execution capabilities 🚨

---

9. Authors' Addresses 💌

for more information, the authors of this document are best contacted via Internet mail:

Ned Freed
Innosoft International, Inc.
1050 East Garvey Avenue South
West Covina, CA 91790
USA

Phone: +1 818 919 3600
Fax:   +1 818 919 3614
EMail: ned@innosoft.com


Nathaniel S. Borenstein
First Virtual Holdings
25 Washington Avenue
Morristown, NJ 07960
USA

Phone: +1 201 540 8967
Fax:   +1 201 993 3032
EMail: nsb@nsb.fv.com


MIME is a result of the work of the Internet Engineering Task Force
Working Group on RFC 822 Extensions.  The chairman of that group,
Greg Vaudreuil, may be reached at:

Gregory M. Vaudreuil
Octel Network Services
17080 Dallas Parkway
Dallas, TX 75248-1905
USA

EMail: Greg.Vaudreuil@Octel.Com

---

Appendix A -- Collected Grammar 📖

this appendix contains the complete BNF grammar for all the syntax specified by this document 🎀

by itself, though, this grammar is incomplete 🥺 it refers by name to several syntax rules that are defined by RFC 822. rather than reproduce those definitions here and risk unintentional differences between the two, this document simply refers the reader to RFC 822 for the remaining definitions. wherever a term is undefined, it refers to the RFC 822 definition 🫶

  boundary := 0*69<bchars> bcharsnospace

  bchars := bcharsnospace / " "

  bcharsnospace := DIGIT / ALPHA / "'" / "(" / ")" /
                   "+" / "_" / "," / "-" / "." /
                   "/" / ":" / "=" / "?"

  body-part := <"message" as defined in RFC 822, with all
                header fields optional, not starting with the
                specified dash-boundary, and with the
                delimiter not occurring anywhere in the
                body part.  Note that the semantics of a
                part differ from the semantics of a message,
                as described in the text.>

  close-delimiter := delimiter "--"

  dash-boundary := "--" boundary
                   ; boundary taken from the value of
                   ; boundary parameter of the
                   ; Content-Type field.

  delimiter := CRLF dash-boundary

  discard-text := *(*text CRLF)
                  ; May be ignored or discarded.

  encapsulation := delimiter transport-padding
                   CRLF body-part

  epilogue := discard-text

  multipart-body := [preamble CRLF]
                    dash-boundary transport-padding CRLF
                    body-part *encapsulation
                    close-delimiter transport-padding
                    [CRLF epilogue]

  preamble := discard-text

  transport-padding := *LWSP-char
                       ; Composers MUST NOT generate
                       ; non-zero length transport
                       ; padding, but receivers MUST
                       ; be able to handle padding
                       ; added by message transports.