EML — multipart/alternative Whose Parts Disagree
Text and HTML alternatives that state different totals and different delivery dates. The spec says the parts must be alternative renderings of the same content, so this fixture shows what a tool extracts when they are not — the answer depends entirely on which part it picks.
From: Meridian Ops <ops@meridiansupply.example>
To: Sam Rivera <sam@meridiansupply.example>
Subject: Order NV-20714 confirmed
Date: Tue, 10 Feb 2026 08:00:00 -0800
Message-ID: <p7-alt-divergent@brightside.example>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="=_p7_alt_divergent"
--=_p7_alt_divergent
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Order NV-20714 confirmed.
2 x Filter papers 12.00
1 x Nitrile gloves 6.90
Total 18.90
Delivery: Friday 13 Feb 2026, Market Street.
--=_p7_alt_divergent
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
<html><body style=3D"font-family:Arial,sans-serif"><h2>Order NV-20714 confi=
rmed</h2><table><tr><td>2 × Filter papers</td><td>12.00</td></tr><tr>=
<td>1 × Nitrile gloves</td><td>6.90</td></tr><tr><td>Shipping</td><td=
>3.00</td></tr><tr><td><b>Total</b></td><td><b>21.90</b></td></tr></table><=
p>Delivery: <b>Monday 16 Feb 2026</b>, Alder Avenue.</p></body></html>
--=_p7_alt_divergent--
Specifications
- Wave
- p7
- Seed
- 20260807
- Structure
- multipart/alternative
- Parts
- text/plain + text/html
- Plain Total
- 18.90
- Html Total
- 21.90
- Plain Delivery
- Fri 13 Feb 2026
- Html Delivery
- Mon 16 Feb 2026
- Divergence Is Deliberate
- true
- Line Endings
- CRLF (RFC 5322)
Testing contract
Expected to pass- Scenario
- Extract order total and delivery date from a message whose text and HTML alternatives carry conflicting values.
- Expected result
- Selecting the last (richest) part yields 21.90 / Mon 16 Feb; selecting text/plain yields 18.90 / Fri 13 Feb — the divergence makes the choice observable.
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 — multipart/alternative Whose Parts Disagree” is a deterministic Novus Examples fixture for Email parsing, Conversion testing, Web scraping. 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) · multipart/alternative. 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("alt-divergent-parts.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 — Base64: Accented UTF-8 BodyA base64 text/plain message in utf-8 carrying the identical body to the quoted-printable twin beside it. Base64 is opaque to whitespace and line-start characters, so it is the reference side of the pair when a QP decoder is suspect.
- emlEML — Base64: From-Line and Lone DotA base64 text/plain message in utf-8 carrying the identical body to the quoted-printable twin beside it. Base64 is opaque to whitespace and line-start characters, so it is the reference side of the pair when a QP decoder is suspect.
- emlEML — Base64: ISO-8859-1 BodyA base64 text/plain message in iso-8859-1 carrying the identical body to the quoted-printable twin beside it. Base64 is opaque to whitespace and line-start characters, so it is the reference side of the pair when a QP decoder is suspect.
- emlEML — Base64: Soft Line BreaksA base64 text/plain message in utf-8 carrying the identical body to the quoted-printable twin beside it. Base64 is opaque to whitespace and line-start characters, so it is the reference side of the pair when a QP decoder is suspect.
- emlEML — Base64: Trailing WhitespaceA base64 text/plain message in utf-8 carrying the identical body to the quoted-printable twin beside it. Base64 is opaque to whitespace and line-start characters, so it is the reference side of the pair when a QP decoder is suspect.
Generated by generation/email_p7.py. Free for any use, no attribution required — license.