A MIME message consists of both data and metadata. MIME metadata consists of HTTP-style headers and MIME boundary delimiters.
Each header is
a colon-separated name-value pair on a line. The ASCII sequence
the line. A sequence of these headers, called a header block, is terminated
by a blank line:
headers that are in this HTTP style can appear in a MIME document.
Some common MIME headers are described in MIME standard header fields.
The only header that must be
present is the Content-Type header. This header
specifies the type of the data in the message. If the Content-Type
value starts with
multipart, the message is a multipart MIME
message. For multipart messages the Content-Type header must also
include a boundary attribute that gives the text that is used to delimit
the message parts. Each MIME part has its own Content-Type field that
specifies the type of the data in the part. This can also be multipart,
which allows multipart messages to be nested. MIME parts with any
other Content-Type values are handled as BLOB data.
SET OutputRoot.Properties.ContentType = 'text/plain';
- The MIME headers must be properly formatted:
- Each header is a colon-separated name-value pair, on a line of
its own, terminated by the ASCII sequence
- The header line must use 7-bit ASCII.
- Semicolons are used to separate parameters:
Content-Type: Multipart/Related; boundary=MIME_boundary; type=text/xml
- A header might contain a comment in parentheses, for example:
MIME-Version: 1.0 (Generated by XYZ)
- Each header is a colon-separated name-value pair, on a line of its own, terminated by the ASCII sequence
- A line that starts with white space is treated as a continuation of the previous line. Therefore, a long header can be split across more than one line.
- If two or more headers in a header block have the same name, their values are concatenated into a comma-separated list.
- A top-level MIME Content-Type header must be available. The header is not case-sensitive. If the transport is HTTP, any Content-Type value in the HTTP header is used as the top-level Content-Type. If the transport is not HTTP, the Content-Type must appear in the initial header block of the MIME message.
- The Content-Type value is a media type followed by the / character
and a subtype. Examples of this are
multipart/related. The parser does not validate subtypes. The Content-Type value can be followed by one or more parameters that are separated by semicolons.
- If the media type of a message is multipart, a boundary attribute must provide the text that is used to delimit the separate MIME parts.
- Each individual MIME part can have its own Content-Type header. The part header can have a media type of multipart, so that multipart messages can be nested. In this case, a valid boundary attribute must be provided, and its value must be different from any that has been previously defined in the message. MIME parts that have any other Content-Type value are handled as BLOB data.
- MIME multipart boundary delimiters are represented in 7-bit ASCII.
The boundary delimiter consists of a line starting with a hyphen pair,
followed by a boundary string. This sequence must not occur within
the MIME message at any point other than as a boundary. A MIME end-delimiter
is a hyphen pair, followed by the MIME boundary string, followed by
a further hyphen pair. All delimiter lines must end in the ASCII sequence
<CR><LF>. An example of a delimited message is:
where MIME_boundary is the boundary delimiter string, and message data represents message data.
--MIME_boundary message data --MIME_boundary message data --MIME_boundary--
- The MIME media type message is not supported and results in an error at run time.
- Any preamble data (text between the initial MIME header block and the first boundary delimiter) or epilogue data (text after the final boundary delimiter) is stored in the logical tree as a value-only element. Preamble data and epilogue data can appear only as the first and last children, respectively, of a Parts node.
- The MIME parser does not support on-demand parsing and ignores the Parse Timing property. The parser does not validate MIME messages against a message model, and ignores the IBM® Integration Toolkit Validate property.
Special cases of multipart MIME
- Multipart MIME with just one part. The logical tree for the MIME part saves the Content-Type and other information as usual, but the Data element for the attachment is empty.
- Single-part MIME. For single-part MIME, the logical tree has no Parts child. The last child of the MIME tree is the Data element. The Data element is the parent of the BLOB that contains the message data.
- MIME parts with no content.
Secure MIME (S/MIME)
S/MIME is a standard for sending secure email messages. S/MIME has an outer level Content-Type of multipart/signed with parameters protocol and micalg that define the algorithms that are used to encrypt the message. One or more MIME parts can have encoded content. These parts have Content-Type values such as application/pkcs7-signature and a Content-Transfer-Encoding of base64. The MIME domain does not attempt to interpret or verify whether the message is signed.