Search files, editable visual templates, and live browser targets from one registry-backed directory. Filtered query views stay crawlable for links but are deliberately noindex; the stable taxonomy pages below remain the canonical search surfaces.
Page 2 of 5; 24 results per page.
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.
The related container's root is the second part, named by the start= parameter, with an image sitting first. A reader that assumes the first part is always the root displays a PNG as the message body.
The HTML body references a Content-ID that no part in the message provides — the everyday result of a forward that dropped an attachment. A renderer should show the alt text and carry on, not emit a broken external request or fail the whole message.
Two inline image parts, only one of them referenced by the HTML. Attachment counters disagree loudly on this shape: some report one attachment, some two, some none, and the answer changes what a user sees in the message list.
An HTML body referencing two base64 PNG parts by Content-ID, both resolved. This is the baseline for the three related/cid fixtures beside it: everything a cid resolver needs is present and correctly spelled.
We use Google Analytics and show ads via Adsterra. Non-essential cookies and ad scripts run only after you allow the matching categories. See our cookie policy.
