EML/MIME Import Doctor
Paste raw .eml (RFC 822 / MIME) source, or upload a .eml file, and see exactly which constructs will behave differently — or break outright — across mail clients and importers: Outlook, Gmail import, Apple Mail, Thunderbird and generic IMAP-based tools.
Processed locally in your browser. Your file is never uploaded.
How to use this calculator
- Paste raw .eml source, or upload a .eml file — nothing leaves your browser.
- Select "Check import compatibility".
- Review each flagged construct: what makes it non-portable, and which mail clients/importers disagree.
- Use the offered rewrite where one is available — CRLF line-ending normalization and RFC 2047 header encoding are both safe, mechanical fixes; the rest are explained because a safe automatic fix can't be guessed.
Assumptions
- Recognises eight specific portability-relevant constructs: missing/malformed multipart boundaries, a missing MIME-Version header on a message that uses MIME structure, a Content-Transfer-Encoding that doesn't match the actual body, un-encoded non-ASCII header values, lines exceeding RFC 5322's 998-octet limit, bare-LF line endings, duplicate critical headers, and boundary strings short/generic enough to risk colliding with real content.
- This is a line-aware RFC 822/MIME parser built specifically for this tool, not a full mail-parsing library — it recognises header folding and multipart boundary structure well enough to support these checks, and nothing beyond that.
- "Critical headers" checked for duplication are Content-Type, From, To, Subject, MIME-Version, Content-Transfer-Encoding, Message-ID and Date.
Methodology
The raw text is parsed into headers (with RFC 822 folding unfolded) and a MIME part tree (using each part's own Content-Type boundary parameter to locate delimiter lines), then checked against documented RFC 5322/2045-2049/2047 requirements and known real-world mail client/importer leniency differences. A rewrite is offered only when it is mechanically safe and unambiguous: normalizing line endings to CRLF, and RFC 2047-encoding a raw non-ASCII header value (both are lossless, deterministic transformations). Everything else — a missing boundary, a transfer-encoding mismatch, an overlong line, a weak boundary string — is flagged with an explanation rather than guessed at, because a wrong automatic fix to a real email file is worse than no fix.
Worked example
A multipart Content-Type with no boundary parameter
Inputs: Content-Type: multipart/mixed (no boundary="...")
Result: Every strict MIME parser needs the boundary parameter to know where one part ends and the next begins. Flagged as an error — this breaks parsing everywhere, not just on stricter clients — with no automatic fix, since a boundary value can't be invented safely.
Bare-LF line endings throughout the file
Inputs: Headers and body separated by "\n" instead of "\r\n"
Result: RFC 5322 requires CRLF line endings; some strict parsers mis-parse or reject bare-LF text, though most modern clients normalize automatically. Flagged as info, with a safe rewrite that normalizes every line ending to CRLF.
A Subject header containing raw non-ASCII bytes
Inputs: Subject: Café meetup notes
Result: RFC 822/5322 headers are technically 7-bit ASCII only; the correct portable form is an RFC 2047 encoded word. Flagged as a warning, with a safe rewrite to "Subject: =?UTF-8?B?...?=" that's lossless and deterministic.
Practical guidance
- Always include a boundary parameter on a multipart Content-Type, and make sure every part in the body actually uses "--boundary" (and closes with "--boundary--") — a mismatch here breaks parsing outright, not just cosmetically.
- Include "MIME-Version: 1.0" on any message using MIME features, even though some clients infer it — it costs nothing and removes an entire category of ambiguity.
- Prefer a long, random-looking boundary string (most real mail clients generate one 20+ characters long) — a short one risks colliding with genuine body content.
- If a message must contain non-ASCII header text, use RFC 2047 encoded words rather than raw UTF-8 bytes in the header — this tool can generate that encoding for you safely.
Common mistakes
- Assuming a bare-LF .eml file will "just work" everywhere because it opens fine in one modern mail client — some strict/older parsers require CRLF and will mis-parse or reject it.
- Treating a Content-Transfer-Encoding declaration as decorative — a part declared "base64" that isn't actually valid base64 will fail to decode in strict clients and may render as silent garbage in lenient ones.
FAQs
Why is a missing boundary parameter an error, but a missing MIME-Version only a warning?
A missing boundary breaks every strict parser's ability to locate the message's parts at all — there's no ambiguity, it simply fails. A missing MIME-Version is a real RFC 2045 violation, but many lenient clients successfully infer MIME handling from the other headers anyway, so the practical impact is narrower.
Why does the tool rewrite non-ASCII headers but not fix a missing boundary?
RFC 2047 encoding a header value is a deterministic, lossless transformation of the exact bytes already present — nothing is guessed. Inventing a boundary value, or deciding which of two duplicate headers to keep, requires knowing intent this tool doesn't have.
Does this tool decode attachments or show their content?
No — it only inspects headers and structural markers (boundaries, encoding declarations, line lengths) to explain portability issues. It never decodes or displays attachment content beyond a short excerpt needed to explain a specific problem, such as the first invalid character found in a malformed base64 block.