Sending MIME Email With PHP Page 2

“Okay, how do I create MIME Compliant Messages?”

With the above general description, let us now look at what exactly is in this so-called MIME Message!

The Simplest MIME Message

This message has no parts to it, i.e., no “attachments”. Nevertheless, for it to be a MIME message, it must have the necessary headers.

From: [email protected]
To: 'Alex (the Great)' <[email protected]>
Subject: Bucephalus
MIME-Version: 1.0

Hello Alexander,

How's Bucephalus doing?

This is nothing but a simple RFC-822 compliant message (text email) with the MIME header. Note
that if no Content-Type header is specified, Content-Type: text/plain; charset='us-ascii'
is assumed! Of course, it could be something slightly more complex like the following:

From: 'Alex (the Great)' <[email protected]>
To: [email protected]
Subject: re: Bucephalus
MIME-Version: 1.0
Content-Type: image/jpg;
	name='buce.jpg'
Content-Transfer-Encoding: base64
Content-Description: Take a look at him yourself

<.....base64 encoded jpg image of Bucephalus...>

“Hey, but I want to send a word document and also a picture of my doggie in the same email…!” goes one user! True enough, the sample shown above is too simple and does not have enough pulp to support the fancier and necessary aspects of modern day emailing. In fact, many mail clients will not even show the description field!

This is where we encounter what is called “multipart messages”.

Multipart Messages

This concept allows us to send multiple items in the same email. For instance, let us assume that Alexander wanted to email [email protected] a picture of his horse, with its pedigree chart along with a polished note in the email! Such a simple requirement cannot be satisfied without the concept of multipart messages. In such a situation, we create a wrapper using the Content-Type Message header to “hold” the various part of the email, so that the recipient gets the picture, the pedigree chart and the nice note!

The Content-Type header now has a value “multipart” to indicate that it is a complete email message and that the header merely encapsulates the information. Moreover, it has a subtype of “mixed” (after all an image, a pedigree chart and 7bit text message are not the same type, correct?).

Let us look at what the whole picture looks like:

From: 'Alex (the Great)' <[email protected]>
To: [email protected]
Subject: re: Bucephalus
MIME-Version: 1.0
Content-Type: multipart/mixed;
	boundary="XX-1234DED00099A";
Content-Transfer-Encoding: 7bit

This is a MIME Encoded Message

--XX-1234DED00099A
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi PHP,

Attached you will find my horse, Bucephalus', pedigree chart and photo. 

Alex

--XX-1234DED00099A
Content-Type: image/jpg;
	name="buce.jpg";
Content-Transfer-Encoding: base64
Content-Description: "A photo of Bucephalus"

<.....base64 encoded jpg image of Bucephalus...>

--XX-1234DED00099A
Content-Type: application/octet-stream;
	name="pedigree.doc"
Content-Transfer-Encoding: base64
Content-Description: "Pedigree Chart of the great horse"

<.....base64 encoded doc (pedigree.doc) of Bucephalus...>

--XX-1234DED00099A-

Phew! Looks like a lot of work, does it not? Anyway, let us go over the details:

1. if you notice the Content-Transfer-Encoding on the MIME Message Header, it says “7bit”. Since the Content-Type is multipart/mixed, the encoding has to be one of 7bit, 8bit or binary, 7bit being the widely used format.
2. A message like this has a variety of information bundled in it. How will the client “know” to differentiate between the JPG image, the document and the plain text? You will notice a boundary=”XX-1234DED00099A”; parameter after the Content-Type. This value tells apart the various contents of the mail. This is called the MIME Boundary Marker. The value for the boundary marker must be as unique as possible to avoid confusions as to the extent (scope) of the mail.
3. The “warning” message is there in order that non-MIME compliant clients can display it to the user, who might otherwise not understand the purport of a blank email
4. Now, back to the boundary marker. If you observe in the sample mail, the boundary marker (XX-1234DED00099A) occurs before ever
   y part, i.e., there is a boundary marker used between parts, however, they start with two hyphens. An important point to note is that after the last MIME part, the boundary marker not only starts with two hyphens but also ends in two hyphens. This is something that must not be left out for it defines the scope.
5. Let us look at the first two MIME message parts:

• The first is the plain text message, hence a Content-Type of text/plain and encoding of 7bit (we might have as well omitted as it is understood if not specified).
• The second is the JPEG image. It says, aptly, Content-Type: image/jpg. The name=”buce.jpg” (that appears after Content-Type and called a parameter), specifies the name of the file; this is what one will see as the attachment name in the client. If the name=”buce.jpg” were not given, the might display the description field (if given) as the name of the attachment (this is not a consistent behavior among all clients, though).

Note that the JPEG image can be displayed in the body of the email if the client is capable of displaying inline attachments. Alternatively, you can indicate to the client as to how you want the attachments to appear. For instance if there were a

Content-Disposition: attachment

header, the JPEG image will be shown as an attachment icon.