Multipart messages

Of special interest are messages with a media-type multipart. These are messages that contain one or more different sets of data in a single body.

A multipart message consists of the following parts in the order listed here:

• Header - The Content-Type is multipart. A required parameter is boundary that defines the boundary parameter value. The boundary value can be enclosed in quotes. This is always good practice, but not required. It can not exceed 70 characters. The boundary value is used to delimit each part. By making this a parameter, an application can ensure that there is no chance that the boundary value appears in any of the entities of the message.
• Preamble - This is optional and can be ignored.
• Boundary Delimiter - This is two hyphens, the boundary parameter, optional whitespace and a CRLF terminator.
• Message Part (Entity) - The entity might include a header. If it does, then this header can only include fields that describe the content and which begin with "Content-". The header is followed by a blank line, and then the body.
• Closing Delimiter - This is two hyphens, the boundary parameter, two more hyphens, optional whitespace and a CRLF terminator.
• Epilogue - This is optional and can be ignored.

Here is a sample multipart message:

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.