EML — Quoted-Printable: Trailing Whitespace
A quoted-printable text/plain message in utf-8 whose body ends lines with spaces and tabs that quoted-printable must encode as =20 and =09. It is the exact twin of the base64 message beside it: both decode to the same 193 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: Lines that end in whitespace (SAMPLE)
Date: Sat, 07 Feb 2026 09:05:00 -0800
Message-ID: <p7-cte-qp-trailing@brightside.example>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Trailing whitespace survives base64 and must be encoded in quoted-printable=
.
This line ends with two spaces. =20
This line ends with a tab.=09
Interior spaces and tabs stay literal.
Maya
Specifications
- Wave
- p7
- Seed
- 20260807
- Charset
- utf-8
- Decoded Bytes
- 193
- Line Endings
- CRLF (RFC 5322)
- Twin Decodes Identically
- true
- Content Transfer Encoding
- quoted-printable
- Encoded Lines
- 7
Testing contract
Expected to pass- Scenario
- Decode a quoted-printable utf-8 body that ends lines with spaces and tabs that quoted-printable must encode as =20 and =09 and compare it to its base64 twin.
- Expected result
- The decoder yields the same 193 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: Trailing Whitespace” 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-trailing-whitespace.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.