What this RFC defines
RFC 2045 is the first of the five MIME RFCs. It defines the MIME-Version header, the Content-Type header, and the Content-Transfer-Encoding header. It establishes the framework that all subsequent MIME RFCs build on: the idea that a message body can be anything, and headers describe what it is and how it is encoded.
Where you see it in practice
The MIME-Version: 1.0 header present in every MIME email comes from this RFC. The Content-Transfer-Encoding: base64 you see on email attachments is defined in section 6.8. When a spam filter or email client cannot parse a Content-Type header correctly, the root specification it is checking against is RFC 2045.
How it connects to other RFCs
RFC 2045 is the base of the MIME suite. RFC 2046 defines the media type system, RFC 2047 handles non-ASCII headers, RFC 2048 defined registration procedures (since replaced by RFC 4288), and RFC 2049 provides conformance criteria. RFC 5322 defines the message envelope that MIME rides inside.
Current status
RFC 2045 is a current standard, published November 1996. It has not been superseded and remains the authoritative reference for MIME message structure.
The MIME-Version header
RFC 2045 introduced the MIME-Version header field, which every modern email carries as MIME-Version: 1.0. The header signals that the message follows MIME encoding rules and that Content-Type, Content-Transfer-Encoding, and related headers should be interpreted per RFC 2045-2049. Messages without this header are pre-MIME and are treated as plain text under the RFC 822 rules. Every email client, from Outlook to Gmail to command-line mail utilities, inserts MIME-Version: 1.0 by default; a message missing this header will still be delivered but rendered as if it were 1982-era mail.
Content-Transfer-Encoding options
RFC 2045 defines five transfer encodings: 7bit (pure ASCII), 8bit (8-bit bytes, requires 8BITMIME), binary (arbitrary bytes, rarely used in mail), quoted-printable (7-bit-safe encoding of mostly-ASCII text with occasional non-ASCII), and base64 (7-bit-safe encoding of binary data). The choice of encoding affects both message size and transport compatibility. Quoted-printable adds about 3% overhead for mostly-ASCII text; Base64 adds about 33% for any content. Modern MTAs handle all five, but legacy gateways and archived mail sometimes fail on 8bit or binary encodings.
Why MIME parsing is famously difficult
MIME parsing is a leading source of bugs in email libraries because the grammar is layered: RFC 2045 defines the header fields, RFC 2046 defines multipart structure, and RFC 2047 defines encoded-word syntax for non-ASCII header values. A robust parser must handle all three simultaneously, plus edge cases like nested multiparts, mismatched boundaries, missing Content-Type declarations (defaulting to text/plain per RFC 2046), and adversarial input designed to confuse security scanners. Every widely-used email library has been patched multiple times for MIME parsing vulnerabilities.
RFC 2045 (November 1996) is the base of the MIME (Multipurpose Internet Mail Extensions) family: five documents (RFC 2045 through 2049) that let email carry structured content beyond ASCII text. RFC 2045 specifically defines the Content-Type, Content-Transfer-Encoding, and MIME-Version headers. Companions: RFC 2046 defines media types (text, image, audio, multipart), RFC 2047 encoded-word for non-ASCII in headers, RFC 2048 registration procedures, RFC 2049 conformance criteria. Foundation for every email attachment, HTML message, and structured content.
RFC 2045 at a glance
| Aspect | Detail |
|---|---|
| Purpose | Define headers that describe non-ASCII, non-text, structured email content |
| Key headers | MIME-Version, Content-Type, Content-Transfer-Encoding |
| Companion RFCs | RFC 2046 media types, RFC 2047 encoded-word, RFC 2048 registration, RFC 2049 conformance |
| Encodings | 7bit (ASCII), 8bit, binary, quoted-printable, base64 |
| Enables | Attachments, HTML mail, multipart structure, character sets, video/audio inline |
| Published | November 1996 |
| Status | Foundational standard; no successor planned |
The three core MIME headers
| Header | Purpose | Example |
|---|---|---|
MIME-Version | Declare message uses MIME (always 1.0) | MIME-Version: 1.0 |
Content-Type | Media type of the content (or part) | Content-Type: text/html; charset=utf-8 |
Content-Transfer-Encoding | How the content is encoded for transport | Content-Transfer-Encoding: base64 |
Content-Transfer-Encoding values
| Encoding | Purpose | Overhead | Typical use |
|---|---|---|---|
7bit | Content is already ASCII, no encoding needed | None | Plain text ASCII messages |
8bit | Content contains 8-bit bytes, no encoding applied | None | UTF-8 bodies on 8BITMIME-capable paths |
binary | Any byte value including nulls; no line semantics | None | BINARYMIME transport only (RFC 3030) |
quoted-printable | Escape non-ASCII as =XX hex | ~20-100% for non-ASCII heavy content | Mostly-ASCII text with occasional non-ASCII |
base64 | Encode as ASCII alphabet 64 chars | ~33% | Binary attachments, images, video |
Content-Type syntax and parameters
Multipart structure (defined in RFC 2046)
Common MIME implementation mistakes
boundary="----=_NextPart_A1B2C3D4E5F6") to make accidental collision statistically impossible.Related standards and further reading
- RFC 2046: Media types and multipart structure
- RFC 2047: Encoded-word syntax for non-ASCII in headers
- RFC 2048: Registration procedures for media types
- RFC 2049: Conformance criteria and examples
- RFC 2231: MIME parameter value extensions (RFC 2231 escaping)
- RFC 3676: text/plain format=flowed (reflowable text)
- RFC 4021: Registration of mail header fields (includes MIME headers)
- Content-Type and MIME Structure: practical parsing guide
- RFC 5322 Guide: message format complement
- Message-ID Header: correlation identifier
Frequently asked questions
Why is MIME-Version always 1.0?
Historical accident. When MIME was designed, the version was expected to increment as capabilities evolved. In practice, MIME extensions (RFC 2231 parameter escaping, new media types, format=flowed, S/MIME) were added without version bumping; the ecosystem preferred backward compatibility to versioning. Modern messages MUST include MIME-Version: 1.0 per RFC 2045 to signal MIME awareness; higher values do not exist in practice.
When should I use quoted-printable vs base64?
quoted-printable for mostly-ASCII text with occasional non-ASCII: preserves human readability, moderate overhead. base64 for binary content or heavily non-ASCII text: fixed ~33% overhead, universal compatibility. Rule of thumb: text/plain or text/html with UTF-8 → quoted-printable; images, PDFs, video → base64. Most modern libraries choose automatically based on content analysis.
What is the difference between multipart/mixed and multipart/alternative?
multipart/mixed: parts are conceptually different content (message body + attachment + another attachment). Recipients see all parts. multipart/alternative: parts are different representations of the same content (plain text version + HTML version of the same message). Recipients see the best-supported version, not both. HTML emails typically use multipart/mixed[multipart/alternative[text/plain, text/html], application/pdf]: alternative pair for body, mixed wrapper to include attachments.
Can MIME content contain arbitrary binary data?
Yes, via base64 encoding over any transport, or via 8bit/binary encoding over transport that supports it (8BITMIME for 8-bit, BINARYMIME per RFC 3030 for binary). base64 is universally compatible; 8bit and binary require negotiation. For attachments (images, PDFs, video, executables), base64 is the standard choice because it works across all mail paths.
Why are MIME parsers a common source of security vulnerabilities?
MIME parsing is remarkably complex: recursive multipart nesting, encoded-word decoding in various contexts, parameter escaping per RFC 2231, header folding, canonicalization for signing. Adversarial input designed to confuse the parser (deeply nested multiparts, oversize boundaries, malformed encoded-word, boundary collisions with body content) has produced remote code execution vulnerabilities in every major email library at some point. Modern practice: use well-maintained libraries, enforce depth and size limits, sandbox content extraction, and treat MIME as untrusted input requiring defensive parsing.
About the Author
Alaa · LinkedIn
Email infrastructure specialist with 8+ years of hands-on experience in SMTP, deliverability, and email verification. I’ve configured and troubleshot mail systems across Postfix, Exchange, and cloud relays, managed IP reputation and warmup campaigns, and built verification pipelines processing millions of addresses. My work spans DNS authentication (SPF, DKIM, DMARC, BIMI), bounce handling, blocklist monitoring, and compliance frameworks including CAN-SPAM and GDPR. I write every article on SMTPedia to give email professionals, developers, and marketers the accurate, RFC-grounded reference they need.
About SMTPedia
SMTPedia is an independent email industry reference covering SMTP, IMAP, POP3, email deliverability, marketing platforms, DNS authentication, and email verification. Every article is researched from official provider documentation, IETF RFCs, and industry best practices. Settings and configurations are verified quarterly.
We are cited as a source by ChatGPT, Microsoft Copilot, and thousands of email professionals worldwide. Learn more about our editorial process.
