EML — Quoted-Printable: From-Line and Lone Dot
A quoted-printable text/plain message in utf-8 whose body starts a line with "From " and holds a lone "." line, which quoted-printable escapes as =46rom and =2E. It is the exact twin of the base64 message beside it: both decode to the same 219 octets, so a decoder can be diffed against a known-equal pair.
From: Maya Chen <maya@brightside.example>
To: Sam Rivera <sam@meridiansupply.example>
Subject: A body line starting with From (SAMPLE)
Date: Sat, 07 Feb 2026 09:20:00 -0800
Message-ID: <p7-cte-qp-fromline@brightside.example>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Sam,
The two lines below are what break naive mailbox splitters and SMTP clients=
:
=46rom here on the quoted price is fixed until 30 Jun 2026.
=2E
That lone dot is the SMTP end-of-data marker in its raw form.
Maya
Specifications
- Wave
- p7
- Seed
- 20260807
- Charset
- utf-8
- Decoded Bytes
- 219
- Line Endings
- CRLF (RFC 5322)
- Twin Decodes Identically
- true
- Content Transfer Encoding
- quoted-printable
- Encoded Lines
- 9
Testing contract
Expected to pass- Scenario
- Decode a quoted-printable utf-8 body that starts a line with "From " and holds a lone "." line, which quoted-printable escapes as =46rom and =2E and compare it to its base64 twin.
- Expected result
- The decoder yields the same 219 octets as the base64 twin, with CRLF line breaks preserved.
What is a .eml file?
An EML file is a single email message stored in the RFC 822 / MIME format — plain-text headers (From, To, Subject, Date, Message-ID) followed by the body, which may be plain text, HTML, or a multipart structure with alternative bodies and file attachments encoded in base64.
How to use this file
Use an example EML to test email header parsing, MIME decoding, HTML-part handling, attachment extraction, and EML-to-other-format conversion.
How to use this file for testing
“EML — Quoted-Printable: From-Line and Lone Dot” is a deterministic Novus Examples fixture for Email parsing, Encoding detection, Conversion testing. Standards-compliant RFC 822 messages — plain, multipart text+HTML, and with an attachment — plus an MBOX mailbox, for testing header parsing, MIME decoding, attachment extraction, and mailbox splitting.
Documented properties for this file: seed 20260807 · CRLF (RFC 5322). Compare results against paired or grouped companions on this page when present (clean↔damaged, searchable↔scanned, or format twins) so scores stay reproducible across runs.
Download the file once, keep the path stable in CI or local scripts, and treat the spec table as the contract: dimensions, seeds, field lists, and roles are intentional. Corrupt or invalid samples are labelled as such — expect parsers to fail loudly rather than silently accept them.
Email fixtures use fixed dates, message IDs, and MIME boundaries so runs are reproducible, and every address is fictional. Test header parsing, MIME decoding, attachment extraction, and EML/MBOX conversion against the documented structure.
Code examples
from email import policy
from email.parser import BytesParser
msg = BytesParser(policy=policy.default).parse(open("cte-qp-from-line.eml", "rb"))
print(msg["subject"], msg["from"])Related files
- emlEML — Attachment With No Filename At AllAn attachment with a bare Content-Disposition: attachment and no name in either header. A client has to invent a filename, and the extension it invents decides whether the saved file opens as a spreadsheet or as unknown binary.
- emlEML — CID Inline ImageA multipart/related message with an HTML body referencing a CID-inline PNG — for email client and MIME parser tests.
- emlEML — HTML Only (No Plain Alternative)A single-part text/html email with no text/plain alternative — edge case for clients that require multipart/alternative.
- emlEML — Identical Image, Inline and AttachedThe same 16x16 PNG appears twice with the same filename: once inline with a Content-ID, once as a plain attachment. Deduplicating by filename or by content hash collapses the pair and loses one of them, which is how an attachment silently disappears.
- emlEML — message/rfc822 Forward of a Multipart MessageA forward that embeds the whole original message, headers and all, as a message/rfc822 part — and that original is itself a multipart with its own attachment and threading headers. Extractors routinely stop at the message/rfc822 boundary and miss the nested file.
- emlEML — multipart/alternative in Reverse Preference OrderThe alternative parts are ordered richest-first, the opposite of what RFC 2046 requires. A client that blindly takes the last part shows plain text here and HTML everywhere else, which is exactly the intermittent-looking bug this fixture pins down.
Generated by generation/email_p7.py. Free for any use, no attribution required — license.