Find files, editable templates and browser test targets by what you need to make or test. Explore complete business kits for connected records, templates and expected results.
Page 66 of 221; 24 results per page.
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.
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.
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.
