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 4 of 5; 24 results per page.
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.
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.
Nested MIME (mixed wrapping alternative plus a text attachment), for deep MIME tree walkers.
A References header that lists the same two Message-IDs twice, in a repeating order: what a client produces when it appends without checking. A threader that treats the chain as a literal path builds a cycle or reports a depth of four for a two-deep thread.
An eight-deep References chain folded so each Message-ID sits on its own line. There is no comma between msg-ids in this header, so a parser that splits on the line break rather than unfolding first ends up with ids that carry a leading space.
The immediate parent named by In-Reply-To was never delivered, but its grandparent is in the References chain. A threader has to fall back up the chain instead of orphaning the message: the everyday case after a deleted or filtered message.
A reply that declares its parent only through In-Reply-To. Threading code that builds ancestry from References alone files this message as a new thread root, splitting a conversation in the message list.
The same reply expressed the other way round: a References chain with no In-Reply-To. Together with its twin it isolates which of the two headers a threading implementation actually reads, since either alone is sufficient under RFC 5322.
A single Subject built from three encoded-words in three charsets and two encodings. RFC 2047 allows this, and it is what happens when a subject is quoted through several mail systems, so each word has to be decoded on its own terms.
The conformant answer to non-ASCII filenames: a filename split into three numbered RFC 2231 segments with a charset and a language tag, plus size and creation-date parameters. Parsers commonly handle filename*= but not the numbered continuation form.
S/MIME-shaped SAMPLE with a placeholder PKCS7 part (not a real signature) for MIME structure tests.
Two text/plain parts inside a mixed container, the second marked inline but carrying a filename. Clients split on this: some concatenate it into the body, some list it as an attachment because a filename is present, and the two behaviours look like different messages.
Threaded SAMPLE reply at depth 1 with a long References chain and bulky X-headers.
Threaded SAMPLE reply at depth 2 with a long References chain and bulky X-headers.
Threaded SAMPLE reply at depth 3 with a long References chain and bulky X-headers.
Threaded SAMPLE reply at depth 4 with a long References chain and bulky X-headers.
Threaded SAMPLE reply at depth 5 with a long References chain and bulky X-headers.
Threaded SAMPLE reply at depth 6 with a long References chain and bulky X-headers.
Threaded SAMPLE reply at depth 7 with a long References chain and bulky X-headers.
Threaded SAMPLE reply at depth 8 with a long References chain and bulky X-headers.
A reply carrying In-Reply-To and References headers, for email thread reconstructors.
A mailing-list post carrying three Authentication-Results headers stamped by three different hosts, where DKIM passed upstream and failed at the final hop after the list rewrote the message. Only the topmost header, from the receiving host, may be trusted.
The canonical rich-mail shape written out in full: a mixed container holding a related container holding an alternative pair, plus a CSV attachment at the outer level. A tree walker has to reach depth three to find the HTML body and still report exactly one attachment.
Two DKIM-Signature headers for the same message (the RSA/Ed25519 double-signing used during algorithm migrations) with an l= body-length tag on the first. l= means only the first 120 octets are covered, so anything appended afterwards still verifies; both values are SAMPLE placeholders.
