Find files, editable templates and browser test targets by what you need to make or test. The directory below is cut by format; the two collections under it cut the same library by subject and by workflow.
Page 3 of 5; 24 results per page.
A multipart/report that advertises report-type=delivery-status but is deliberately incomplete: the required message/delivery-status part is missing, leaving only human prose and the returned headers. Real MTAs emit this, and a parser must not assume the part exists.
multipart/report delivery-status SAMPLE with action=relayed for DSN parsers.
One multipart/report carrying two per-recipient blocks: a permanent 5.1.1 failure and a temporary 4.4.7 delay for the same original message. Bounce processors that read only the first block suppress a good address, or keep retrying a dead one.
The same bounce as its twin, except the returned content is text/rfc822-headers: the privacy-preserving form most large providers send. A processor keyed on message/rfc822 finds nothing here and reports an un-attributable bounce.
A bounce whose third part is the complete original message (headers and body) as message/rfc822. Paired with the headers-only twin beside it, it shows whether a bounce processor can recover the original Message-ID from either shape.
A permanent bounce whose extended status is 5.7.1 (rejected by policy) with Remote-MTA, Original-Recipient and Last-Attempt-Date all present. Suppression lists that key on the 5.x class alone blacklist a perfectly valid address over a sender-side problem.
One 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.
A 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.
An 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.
Encoded-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.
A reply carrying the Exchange threading headers (Thread-Topic and a SAMPLE Thread-Index) next to the standard References chain, plus an X-MS header with an empty value. Empty header values are legal and are a common cause of parser exceptions.
Simple follow-up SAMPLE message #1 for mailbox threading pads.
Simple follow-up SAMPLE message #2 for mailbox threading pads.
Simple follow-up SAMPLE message #3 for mailbox threading pads.
A header line and a body line sitting exactly on the RFC 5322 maximum of 998 octets excluding CRLF. Both are legal, so anything that rejects, wraps, or truncates them is off by one against the spec: this is the reference case for that boundary.
Two headers folded with horizontal tabs instead of spaces, which RFC 5322 permits exactly as it permits spaces. Parsers that test only for a leading space treat the continuation as a brand-new header and lose the second half of the Subject.
A single-part text/html email with no text/plain alternative: edge case for clients that require multipart/alternative.
The 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.
A 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.
The 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.
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.
A zero-length text/plain alternative next to a real HTML part: the shape produced by senders that add a plain part only to satisfy spam filters. Anything preferring plain text renders a blank message unless it falls back when the chosen part is empty.
The same release notes as plain text, Markdown (RFC 7763) and HTML, ordered least-faithful first. Most selectors only know the plain/HTML pair, so this is the fixture that shows whether an unfamiliar middle part is skipped or mistaken for the body.
Two complete messages carried in a multipart/digest, neither part declaring a Content-Type. RFC 2046 makes the default message/rfc822 inside a digest instead of the usual text/plain, so a parser that hardcodes the text default renders raw headers as body text.
