Editing MIME (section)

==Multipart messages==
The MIME multipart message contains a [[Delimiter#Content boundary|boundary]] in the header field {{code|lang=mime|Content-Type:}}; this boundary, which must not occur in any of the parts, is placed between the parts, and at the beginning and end of the body of the message, as follows:

<syntaxhighlight lang="mime">
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary=frontier

This is a message with multiple parts in MIME format.
--frontier
Content-Type: text/plain

This is the body of the message.
--frontier
Content-Type: application/octet-stream
Content-Transfer-Encoding: base64

PGh0bWw+CiAgPGhlYWQ+CiAgPC9oZWFkPgogIDxib2R5PgogICAgPHA+VGhpcyBpcyB0aGUg
Ym9keSBvZiB0aGUgbWVzc2FnZS48L3A+CiAgPC9ib2R5Pgo8L2h0bWw+Cg==
--frontier--
</syntaxhighlight>

Each part consists of its own content header (zero or more {{code|Content-}} header fields) and a body. Multipart content can be nested. The {{code|Content-Transfer-Encoding}} of a multipart type must always be "7bit", "8bit" or "binary" to avoid the complications that would be posed by multiple levels of decoding. The multipart block as a whole does not have a charset; non-ASCII characters in the part headers are handled by the [[#Encoded-Word|Encoded-Word]] system, and the part bodies can have charsets specified if appropriate for their content-type.

Notes:
* Before the first boundary is an area that is ignored by MIME-compliant clients. This area is generally used to put a message to users of old non-MIME clients.
* It is up to the sending mail client to choose a boundary string that doesn't clash with the body text. Typically this is done by inserting a long random string.
* The last boundary must have two hyphens at the end.

===Multipart subtypes===
The MIME standard defines various multipart-message subtypes, which specify the nature of the message parts and their relationship to one another. The subtype is specified in the {{code|Content-Type}} header field of the overall message. For example, a multipart MIME message using the digest subtype would have its {{code|Content-Type}} set as "multipart/digest".

The RFC initially defined four subtypes: mixed, digest, alternative and parallel. A minimally compliant application must support mixed and digest; other subtypes are optional. Applications must treat unrecognized subtypes as "multipart/mixed". Additional subtypes, such as signed and form-data, have since been separately defined in other RFCs.

====mixed====
multipart/mixed is used for sending files with different {{code|Content-Type}} header fields inline (or as attachments). If sending pictures or other easily readable files, most mail clients will display them inline (unless explicitly specified with ''Content-Disposition: attachment'' in which case offered as attachments). The default content-type for each part is "text/plain".

The type is defined in RFC 2046.<ref>[https://tools.ietf.org/html/rfc2046#section-5.1.3 RFC 2046, Section 5.1.3]</ref>

====digest====
multipart/digest is a simple way to send multiple text messages. The default content-type for each part is "message/rfc822".

The MIME type is defined in RFC 2046.<ref>[https://tools.ietf.org/html/rfc2046#section-5.1.5 RFC 2046, Section 5.1.5]</ref>

====alternative====
The multipart/alternative subtype indicates that each part is an "alternative" version of the same (or similar) content, each in a different format denoted by its "Content-Type" header. The order of the parts is significant.  RFC1341 states: ''In general, user agents that compose multipart/alternative entities should place the body parts in increasing order of preference, that is, with the preferred format last.''<ref>{{cite web|url=http://www.w3.org/Protocols/rfc1341/7_2_Multipart.html|title=RFC1341 Section 7.2 The Multipart Content-Type |website=World Wide Web Consortium |access-date=2014-07-15}}</ref>

Systems can then choose the "best" representation they are capable of processing; in general, this will be the last part that the system can understand, although other factors may affect this.

Since a client is unlikely to want to send a version that is less faithful than the plain text version, this structure places the plain text version (if present) first. This makes life easier for users of clients that do not understand multipart messages.

Most commonly, multipart/alternative is used for email with two parts, one plain text (text/plain) and one [[HTML email|HTML (text/html)]]. The plain text part provides backwards compatibility while the HTML part allows use of formatting and hyperlinks. Most email clients offer a user option to prefer plain text over HTML; this is an example of how local factors may affect how an application chooses which "best" part of the message to display.

While it is intended that each part of the message represent the same content, the standard does not require this to be enforced in any way. At one time, [[Email spam|anti-spam filters]] would only examine the text/plain part of a message,<ref name=AntiSpamOverview>{{cite journal |url=https://www.irjet.net/archives/V4/i1/IRJET-V4I169.pdf|title=Overview of Anti-spam filtering Techniques |journal=International Research Journal of Engineering and Technology |volume=4 |issue=1 |date=January 2017 |s2cid=212596952 |access-date=2020-02-20}}</ref> because it is easier to parse than the text/html part. But [[spammers]] eventually took advantage of this, creating messages with an innocuous-looking text/plain part and advertising in the text/html part. Anti-spam software eventually caught up on this trick, penalizing messages with very different text in a multipart/alternative message.<ref name=AntiSpamOverview/>

The type is defined in RFC 2046.<ref>[https://tools.ietf.org/html/rfc2046#section-5.1.4 RFC 2046, Section 5.1.4]</ref>

====related====
A multipart/related is used to indicate that each message part is a component of an aggregate whole. It is for compound objects consisting of several inter-related components{{snd}} proper display cannot be achieved by individually displaying the constituent parts. The message consists of a root part (by default, the first) which reference other parts inline, which may in turn reference other parts. Message parts are commonly referenced by ''Content-ID''. The syntax of a reference is unspecified and is instead dictated by the encoding or protocol used in the part.

One common usage of this subtype is to send a web page complete with images in a single message. The root part would contain the [[HTML]] document, and use image tags to reference images stored in the latter parts.

The type is defined in RFC 2387.

====report====
''multipart/report'' is a message type that contains data formatted for a mail server to read. It is split between a text/plain (or some other content/type easily readable) and a message/delivery-status, which contains the data formatted for the mail server to read.

The type is defined in RFC 6522.

====signed====
A multipart/signed message is used to attach a [[digital signature]] to a message. It has exactly two body parts, a body part and a signature part. The whole of the body part, including mime fields, is used to create the signature part. Many signature types are possible, like "application/pgp-signature" (RFC 3156) and "application/pkcs7-signature" ([[S/MIME]]).

The type is defined in RFC 1847.<ref>[https://tools.ietf.org/html/rfc1847#section-2.1 RFC 1847, Section 2.1]</ref>

====encrypted====
A multipart/encrypted message has two parts. The first part has control information that is needed to decrypt the application/octet-stream second part. Similar to signed messages, there are different implementations which are identified by their separate content types for the control part. The most common types are "application/pgp-encrypted" (RFC 3156) and "application/pkcs7-mime" ([[S/MIME]]).

The MIME type defined in RFC 1847.<ref>[https://tools.ietf.org/html/rfc1847#section-2.2 RFC 1847, Section 2.2]</ref>

====form-data====
The MIME type ''multipart/form-data'' is used to express values submitted through a form. Originally defined as part of [[HTML]] 4.0, it is most commonly used for submitting files with [[HTTP]]. It is specified in RFC 7578<!--Q47466965-->, superseding RFC 2388. [https://developer.mozilla.org/en-US/docs/Web/HTTP/Basics_of_HTTP/MIME_types#multipartform-data example]

====x-mixed-replace====
The content type multipart/x-mixed-replace was developed as part of a technology to emulate [[Push technology|server push]] and streaming over HTTP.

All parts of a mixed-replace message have the same semantic meaning. However, each part invalidates{{snd}} "replaces"{{snd}} the previous parts as soon as it is received completely. Clients should process the individual parts as soon as they arrive and should not wait for the whole message to finish.

Originally developed by [[Netscape]],<ref>{{Cite web|url=http://fishcam.netscape.com/assist/net_sites/pushpull.html |archive-url=https://web.archive.org/web/19981203153836/http://fishcam.netscape.com/assist/net_sites/pushpull.html |archive-date=1998-12-03 |title=An Exploration of Dynamic Documents |publisher=Netscape }}</ref> it is still supported by [[Mozilla]], [[Mozilla Firefox|Firefox]], [[Safari (web browser)|Safari]], and [[Opera (web browser)|Opera]]. It is commonly used in [[IP camera]]s as the MIME type for [[MJPEG]] streams.<ref>{{Cite web|archive-url=https://web.archive.org/web/20100511090539/http://www.deskshare.com/Resources/articles/wcm_ip_CameraSecuritySetup.aspx|archive-date=2010-05-11|url-status=live|url=http://www.deskshare.com/Resources/articles/wcm_ip_CameraSecuritySetup.aspx|publisher=DeskShare|title=WebCam Monitor setup documentation}}</ref> It was supported by Chrome for main resources until 2013 (images can still be displayed using this content type).<ref>{{Cite web|url=https://bugs.chromium.org/p/chromium/issues/detail?id=249132|title=249132 - Remove support for multipart/x-mixed-replace main resources - chromium - Monorail|website=bugs.chromium.org|language=en|access-date=2017-10-10}}</ref>

====byterange====
The multipart/byterange is used to represent noncontiguous byte ranges of a single message, it is used by HTTP when a server returns multiple byte ranges and is defined in RFC 2616.

===RFC documentation===
* {{IETF RFC|1426|link=no}}, ''SMTP Service Extension for 8bit-MIMEtransport''. [[John Klensin|J. Klensin]], [[Ned Freed|N. Freed]], [[Marshall Rose|M. Rose]], [[Einar Stefferud|E. Stefferud]], D. Crocker. February 1993.
* {{IETF RFC|1847|link=no}}, ''Security Multiparts for MIME: Multipart/Signed and Multipart/Encrypted''
* {{IETF RFC|3156|link=no}}, ''MIME Security with OpenPGP''
* {{IETF RFC|2045|link=no}}, ''MIME Part One: Format of Internet Message Bodies''
* {{IETF RFC|2046|link=no}}, ''MIME Part Two: Media Types''. N. Freed, [[Nathaniel Borenstein]]. November 1996.
* {{IETF RFC|2047|link=no}}, ''MIME Part Three: Message Header Extensions for Non-ASCII Text''. [[Keith Moore]]. November 1996.
* {{IETF RFC|4288|link=no}}, ''MIME Part Four: Media Type Specifications and Registration Procedures''.
* {{IETF RFC|4289|link=no}}, ''MIME Part Four: Registration Procedures''. N. Freed, J. Klensin. December 2005.
* {{IETF RFC|2049|link=no}}, ''MIME Part Five: Conformance Criteria and Examples''. N. Freed, N. Borenstein. November 1996.
* {{IETF RFC|2183|link=no}}, ''Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field''. Troost, R., Dorner, S. and K. Moore. August 1997.
* {{IETF RFC|2231|link=no}}, ''MIME Parameter Value and Encoded Word Extensions: Character Sets, Languages, and Continuations''. N. Freed, K. Moore. November 1997.
* {{IETF RFC|2387|link=no}}, ''The MIME Multipart/Related Content-type''
* {{IETF RFC|1521|link=no}}, ''Mechanisms for Specifying and Describing the Format of Internet Message Bodies''
* {{IETF RFC|7578|link=no}}, ''Returning Values from Forms: multipart/form-data''