EML Header — Dkim Signature Shape
SAMPLE .eml focusing on dkim signature shape header behaviour.
From: Alex SAMPLE <alex@brightside.example>
To: Sam Rivera <sam@meridiansupply.example>
Subject: DKIM shape SAMPLE
Date: Wed, 22 Jul 2026 09:25:00 -0400
Message-ID: <wi-dkim@brightside.example>
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brightside.example;
s=selector1; h=from:to:subject:date; bh=SAMPLEBASE64==; b=SAMPLEBASE64==
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
DKIM header shape SAMPLE (not a valid signature).
Specifications
- Role
- header-variant
- Wave
- I
Testing contract
Expected to pass- Scenario
- Exercise EML Header — Dkim Signature Shape in its headers workflow. SAMPLE .eml focusing on dkim signature shape header behaviour.
- Expected result
- subject='DKIM shape SAMPLE'; content type=text/plain; MIME leaf parts=1. Declared feature checks: role=header-variant.
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 Header — Dkim Signature Shape” is a deterministic Novus Examples fixture for Email parsing. 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: header-variant. 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("dkim-signature-shape.eml", "rb"))
print(msg["subject"], msg["from"])Related files
- emlEML — 1,024-Octet Header Line With No Fold PointA single header whose value is one 1,001-character token with no whitespace, making the line 1,024 octets — past the 998-octet limit RFC 5322 sets and impossible to fold. Fixed-size line buffers truncate here, and the truncation is silent.

- emlEML — Adjacent Encoded-Words (Separator Must Disappear)A Subject split mid-word across two adjacent encoded-words. RFC 2047 requires the linear whitespace between them to be discarded, so the correct result is one word; a decoder that keeps the space renders a split that reads as a typo.

- emlEML — Encoded-Word Longer Than the 75-Character LimitOne unbroken encoded-word of 148 characters, well past the 75-character ceiling RFC 2047 sets. Real senders emit these, and a decoder should still recover the whole word rather than truncating it at 75 or rejecting the header.

- emlEML — Encoded-Word Subject Folded Over Four LinesA Subject folded across four physical lines, one encoded-word per line, which is the shape RFC 2047 prescribes for long international headers. Because the fold whitespace is discarded on decode, each continuation word carries its own leading space inside the encoded-word — omit that and the subject decodes run-together.

- emlEML — Encoded-Word With an Unregistered CharsetAn encoded-word naming a charset no registry knows. The payload happens to be UTF-8, so a decoder has a choice: fall back and show readable text, or leave the raw encoded-word visible. What it must not do is raise and drop the whole header.

- emlEML — Encoded-Words in Display Names and a FilenameEncoded-words used everywhere they turn up in practice: both display names, the Subject, and — against the spec but very common — inside the quoted filename parameter, where RFC 2231 is the conformant mechanism. A tolerant parser decodes all four.

Generated by generation/pad_wave_i.py. Free for any use, no attribution required, license.