EML — Quoted-Printable: ISO-8859-1 Body
A quoted-printable text/plain message in iso-8859-1 whose body is single-byte ISO-8859-1 rather than UTF-8, so each umlaut is one octet. It is the exact twin of the base64 message beside it: both decode to the same 176 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: Rueckfrage zur Bestellung 4711 (SAMPLE)
Date: Sat, 07 Feb 2026 09:15:00 -0800
Message-ID: <p7-cte-qp-latin1@brightside.example>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Hallo Sam,
R=FCckfrage zur Bestellung Nr. 4711: die Gr=F6=DFe der Kartons ist zu gro=
=DF
f=FCr unser Lager. K=F6nnen Sie die H=E4lfte in kleineren Kisten schicken?
Viele Gr=FC=DFe,
Maya
Specifications
- Wave
- p7
- Seed
- 20260807
- Charset
- iso-8859-1
- Decoded Bytes
- 176
- Line Endings
- CRLF (RFC 5322)
- Twin Decodes Identically
- true
- Content Transfer Encoding
- quoted-printable
- Encoded Lines
- 8
Testing contract
Expected to pass- Scenario
- Decode a quoted-printable iso-8859-1 body that is single-byte ISO-8859-1 rather than UTF-8, so each umlaut is one octet and compare it to its base64 twin.
- Expected result
- The decoder yields the same 176 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: ISO-8859-1 Body” 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-latin1.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.