Programming Internet Email

Multipart Messages

What if we wanted to send both an image and a detailed explanation in the same message? To do that, we would have to create a multipart message. This involves nesting the content types; we need an outer “wrapper” to hold the two inner message parts.

To make it clear which headers refer to the wrapper and which to the nested message parts, we place the headers for the wrapper with the message headers and the others in the body, above their respective message parts.

Naturally, the wrapper’s Content-Type header needs to be a composite type (meaning either multipart or message) in order to encapsulate the other parts.

A simple multipart message, consisting of a text part and an image part might look like this:

From:  Bill Clinton <[e-mail]>
To:    Al (The Enforcer) Gore <[e-mail]>
Subject:  Map of Argentina with Description
MIME-Version: 1.0
Content-Type: multipart/mixed;
              boundary="DC8------------DC8638F443D87A7F0726DEF7"

This is a multi-part message in MIME format.
--DC8------------DC8638F443D87A7F0726DEF7
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi Al,

I finally figured out this MIME thing. Pretty cool.  I'll send you
some sax music in .au files next week!

Anyway, the attached image is really too small to get a good look at
Argentina.  Try this for a much better map:

     http://www.lonelyplanet.com/dest/sam/graphics/map-arg.htm

Then again, shouldn't the CIA have something like that?

Bill
--DC8------------DC8638F443D87A7F0726DEF7
Content-Type: image/gif; name="map_of_Argentina. gif"
Content-Transfer-Encoding: base64
Content-Disposition: inline; filename="map_of_Argentina.gif"

R01GODlhJQA1AKIAAP/////78P/omn19fQAAAAAAAAAAAAAAACwAAAAAJQA1AAAD7Qi63P5w
wEmjBCLrnQnhYCgMlwh+pkgqqeC9XrutmBm7hAK3tP3lgFcAiFKVQrGFR6kscnonTe7FAAad
GugmRu3CmiBt57fsVq3Y0VFKnpYdxPC6M7Ze4crnnHum4oN6LFJlbn5NXTN7OF5fQkN5WYow
BEN2dkGQGWJtSzqGTICJgnQuTJN/WJsojad9qXMuhIWdjXKjY4tenjo6tjVssk2gaWq3uGNX
U6ZGxseyk8SasGw3J9GRzdTQkyliHNvcPNNI4TLeKdfMvy0vMqLrItvuxfDW8ubjueDtJufz
7itICBxIsKDBgwgTKjyYAAA7
--DC8------------DC8638F443D87A7F0726DEF7--

There are several things to note on multipart messages. Each is important. Following the guidelines in this list will save you much pain!

• The MIME message header content type is a composite (multipart/mixed), therefore the content transfer encoding can only be 7bit, 8bit, or binary. Normally, it is 7bit as it is here.

• Since the message header content type is a composite, a MIME boundary marker must be given as a parameter.

• The content transfer encoding is 7bit by default since there is no Content-Transfer-Encoding header.

• The first line of the body states, in plain text, that this is a MIME message. This is for non-MIME-compliant MUAs. If that line (or something very like it) wasn’t there, any MUA that didn’t know MIME would not be able to display anything explanatory to the user.

• The next item is two hyphens (--), followed by a MIME boundary marker.^[10] Look carefully to note that it is not just the MIME boundary itself on the line! I will call this sequence of start-of-line hyphens and the boundary marker the appended MIME boundary marker from here on. It is exactly the same boundary marker as defined in the message’s Content-Type header. This boundary marker appears before and after each message part.

• Each message part has its own headers. They appear immediately after the MIME boundary marker. Normally, the Content-Type and Content-Transfer-Encoding headers are shown for clarity, even though they are optional for 7-bit US-ASCII text, as previously described.

• The last appended MIME boundary marker in the message is immediately followed by two hyphens (--). This is very important since it delimits the end of the message. Many, many people forget to do this when they first try to create a MIME message! In fact, as we shall see in the next section "Nested Body Parts,” appended MIME boundary markers have two hyphens (--) added to the end whenever they pass out of scope, not just at the end of a message.

---

^[10] This is another gotcha. Initial implementors often forget to include these leading hyphens, and the result is that a compliant MUA won’t read their messages. Be careful to remember this one.