Sending MIME Email With PHP

Tired of sending those drab textual notifications and newsletters to your
friend and clients? Ever wanted to send attachments and/or HTML embedded email.

The answer is MIME. The ensuing few pages explain the basics of MIME, creating
MIME-compliant messages and then ends with a working class implementation of sending
MIME complaint email in PHP. Note that references to calling script, caller etc. denote
the script that uses the class we are about to develop and client/MUA etc. denote a mail
reading client or mail user agent.

Some MIME Basics

MIME stand for Multipurpose Internet Mail Extensions. MIME extends the basic text-oriented
Internet mail system in order that messages can contain binary attachments.

MIME takes advantage of the fact that RFC 822 places little restriction on the message
body content: the only stipulation is that plain ASCII text be used. Thus, MIME
messages consist of normal Internet text mail with some special RFC 822 compliant headers
and formatted bodies (with the attachments represented in a subset of ASCII). These MIME
headers give a special meaning to the presence of attachments in your mail.

Anatomy of a MIME Message

An ordinary text e-mail message contains a header portion (To: From: Subject: etc.) and a
body portion (Hello Mr., etc.). In a MIME compliant message, there are also headers involved
and not surprisingly, parts of the email called MIME parts, prefixed by special headers also.
A MIME mail is just an extension of the RFC 822 based email. It however has its own set of RFCs.

Header Fields

MIME headers are broadly classified as MIME Message Headers and MIME Part Headers, based on
their placement in an email packet.

The MIME Message Headers are:

• MIME-Version:
  This header provides the version number of MIME used. The value to be used is 1.0.
• Content-Type:
  This identifies the type of data so that it can be handled suitably. Valid types are text,
  image, audio, video, applications, multipart and message. Note that arbitrary binary
  attachments must be called application/octet-stream. Some examples of this
  header are image/jpg, application/msword, multipart/mixed, to cite a few.
• Content-Transfer-Encoding:
  This is the most important of all the headers as it shows the type of encoding performed
  on the data and is used by the client/MUA to decode the attachment. It can take one of 7bit,
  8bit, binary, quoted-printable, base64 and custom, per attachment. 7bit encoding is the
  normal encoding used on US ASCII characters, i.e., retain it as it is. 8bit and binary
  encoding are not used in general. Quoted printable is used for human-readable normal text
  if it has to be protected in transit through a gateway that will affect the formatting.
  Base64 is a common denominator and gives a lazy approach to deciding which encoding to
  use; this is normally used on binary, non-textual data. Note that any non-7bit data must be
  encoded using a scheme such it can traverse Internet mail gateways!
• Content-ID:
  This header is useful if Content-Type is message/external-body or multipart/alternative.
  This is outside the scope of this article.
• Content-Description:
  This is an optional header. Free text descriptions of the contents of any message part. The descriptions must be us-ascii.
• Content-Disposition:
  An experimental header, it is used to provide hints to the client/MUA whether to display attachments inline or as an attachment.

MIME part headers (headers that appear in the actual MIME “attachment” part), can have any of the above except the MIME-Version header. If a MIME header is part of the message block, it applies to the entire message. E.g., if Content-Transfer-Encoding appears in the Message header, it applies to the entire message body, but if it appears under a MIME part, it is applicable to only that part.