MIME (the Multipurpose Internet Mail Extensions) is the internet
standard for how non-text content gets encoded in an email
When the internet was young, email contained text. If you wanted to email an image, a music file, or even just a message with a different font, -- well you couldn't. It was just as well since back in those days, you'd need a whole day just to download it, and you'd be reading the message at an actual teletype terminal, which couldn't display those things anyway.
But eventually, folks decided that plain old text emails were boring: they wanted to attach memos, pictures, and express themselves with purple text and 24 point fonts. So the mysterious cabal that ran the internet in those days proposed a plan: MIME.
First, you add some new headers to your email message. The first is "MIME-Version: 1.0". That's right, it's still version 1.0. In over ten years, still not even 1.1. I guess it was either done right, or there's just not much to screw up. Either way, it's nice and stable.
The second header is Content-Type. If you've examined the HTTP protocol (and who among us hasn't, really), this one should be familiar. Yep, the web blatantly stole it from MIME. It looks something like this: "Content-Type: text/plain". The content type is always of the form type/subtype. The common types are "text", "image", "audio", "application" (for stuff that doesn't fit into the other types), and "multipart" (to allow more than one piece of content per message).
Some of the common content type/subtypes are text/plain, text/html, image/jpeg, application/x-zip-compressed, and application/msword. The multipart/mixed type is very common, too. It says the message has multiple parts, and each of those parts has its own Content-Type.
The last important header is Content-Transfer-Encoding. It indicates how the email is encoded (duh!). This is basically a hack to get around the fact that the internet used to be full of mail servers that expected text -- and only text. If the message was, for example, an image or a zip file, the mail server would still pretend it was text and hopelessly corrupt it. So MIME allows binary data to be sent as text. A side effect of this hack it that even now, a email with a 3MB attachment will usually be 4MB due to the encoding. USENET, which also uses MIME, has largely solved the bloat problem with the yEnc hack, which may eventually find its way back to email.
Next, you stick the content in the message body, just like a text message. Of course, you should encode it like you said you would in the Content-Transfer-Encoding header. The default here is "Content-Transfer-Encoding: 7bit", which is fine if you are mailing plain ASCII text, but then why are you using MIME in the first place? Other common encodings are "quoted-printable", "base64", and "8bit". Pretty straight forward.
Things get slightly more complicated if the Content-Type is multipart. In this case, the message body is divided into sections by a boundary, which is declared along with the Content-Type. For example,
Content-Type: multipart/mixed; boundary="------------090501030802000402060909"
In the body, the line ------------090501030802000402060909 separates each of the parts. In addition, each part has its own headers, and is treated just like its own email message.