MIME attachments are the unsung heroes of email, letting you send more than just plain text, but their complexity often hides a surprisingly simple core purpose: universally representing diverse data types within the plain-text confines of email.
Let’s see this in action. Imagine sending an email with a PDF attachment and an inline image.
Here’s a simplified sendmail command with a MIME-encoded message:
sendmail recipient@example.com <<EOF
From: sender@example.com
To: recipient@example.com
Subject: Email with Attachments
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="----=_NextPart_1234567890abcdef"
------=_NextPart_1234567890abcdef
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
This is the plain text body of the email.
------=_NextPart_1234567890abcdef
Content-Type: application/pdf; name="document.pdf"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="document.pdf"
JVBERi0xLjQKJcfsj6IKMSAwIG9iago8PC9UeXBlL0NhdGFsb2cvUGFnZXMgMiAwIFI+PgplbmRvYmoKMiAwIG9iago8PC9UeXBlL1BhZ2VzL0NvdW50IDEvS2lkcyBbIDMgMCBSXT4+CmVuZG9iagozIDAgb2JqCjw8L1R5cGUvUGFnZS9QYXJlbnQgMiAwIFIvTWVkaWFCb3ggWzAgMCA1OTUgODQyXS9SZXNvdXJjZXM8PC9Gb250PDwvRjEgNSAwIFI+Pj4+L0NvbnRlbnRzIDQgMCBSPj4KZW5kb2JqCjQgMCBvYmoKPDwvTGVuZ3RoIDE0NT4+CnN0cmVhbQplbmRzdHJlYW0KZW5kb2JqCjUgMCBvYmoKPDwvVHlwZS9Gb250L1N1YnR5cGUvVHlwZTEvQmFzZUZvbnQvSGVsdmV0aWNhPj4KZW5kb2JqCnhyZWYKMAA1CjAwMDAwMDAwMDAgNjU1MzUgZiAKMDAwMDAwMDE0NSAwMDAwMCBuIAowMDAwMDAwMjAwIDAwMDAwIG4gCjAwMDAwMDAyNTQgMDAwMDAgbiAKMDAwMDAwMDM1NyAwMDAwMCBuIAowMDAwMDAwNDE1IDAwMDAwIG4gCXRyYWlsZXIKPDwvU2l6ZSA2L1Jvb3QgMSAwIFI+PgplbmRvYmoKc3RhcnR4cmVmCjQ5NAolJUVPRgo=
------=_NextPart_1234567890abcdef
Content-Type: image/png; name="logo.png"
Content-Transfer-Encoding: base64
Content-Disposition: inline; filename="logo.png"
iVBORw0KGgoAAAANSUhEUgAAAAUAAAAFCAYAAACNbyblAAAAHElEQVQI12P4//8/w38GIAXDIBKE0DHxgljNBAAO9TXL0Y4OHwAAAABJRU5ErkJggg==
------=_NextPart_1234567890abcdef--
EOF
The core problem MIME solves is that email, at its heart, is just a stream of 7-bit ASCII characters. Anything else—images, PDFs, rich text—needs to be encoded into that format. MIME provides a standard way to do this.
The Content-Type header is the key. For a simple text email, it’s text/plain. When you have multiple parts, you use multipart/*. multipart/mixed is the most common, meaning each part is a distinct entity. The boundary string is crucial; it’s a unique marker that tells the email client where one part ends and the next begins.
Each part then gets its own Content-Type, Content-Transfer-Encoding, and often Content-Disposition.
Content-Type: Tells the client what kind of data it is (e.g.,application/pdf,image/png,text/html).Content-Transfer-Encoding: Specifies how the data is encoded.base64is very common for binary data, as it converts arbitrary bytes into printable ASCII characters.7bitor8bitare for text.Content-Disposition: Hints to the client whether to display the content inline (like an image in a web page) or as an attachment.attachmentsuggests downloading,inlinesuggests rendering within the email.
The name parameter in Content-Type and the filename parameter in Content-Disposition are hints for the recipient’s email client, often used to name the downloaded file.
The base64 encoding itself is a simple substitution cipher. Each group of three 8-bit bytes (24 bits) is converted into four 6-bit characters from a 64-character alphabet (A-Z, a-z, 0-9, +, /). This increases the data size by about 33%, but it’s a reliable way to transmit binary data over ASCII-only channels.
The difference between attachment and inline in Content-Disposition is purely a client-side rendering decision. The underlying MIME structure is identical. A client might choose to display an inline image directly in the email body if it’s small enough or if the Content-ID header is present (which is used for embedding images within HTML email bodies, a more advanced MIME type).
The mechanism for inline images is fundamentally the same as attachments; it’s the Content-Disposition header’s value and the email client’s interpretation that differ. When you see an image embedded directly in the email body, it’s typically a multipart/related MIME type where one part is an HTML body, and other parts are the images, linked via Content-ID headers.
The next step in email complexity is handling HTML emails with embedded images, which introduces the multipart/related MIME type and the Content-ID header.