Novus Examples, Real, documented example files for testing

EML: DSN Delayed SAMPLE

multipart/report delivery-status SAMPLE with action=delayed for DSN parsers.

File: EML · Dsn
Use case: Email parsingConversion testing· Conversion set

EML: DSN Delivered SAMPLE

multipart/report delivery-status SAMPLE with action=delivered for DSN parsers.

File: EML · Dsn
Use case: Email parsingConversion testing· Conversion set

EML: DSN Failed SAMPLE

multipart/report delivery-status SAMPLE with action=failed for DSN parsers.

File: EML · Dsn
Use case: Email parsingConversion testing· Conversion set

EML: DSN Missing Its message/delivery-status Part (Deliberately Incomplete)

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.

File: EML · Dsn
Use case: Email parsingError handling+1· Conversion set

EML: DSN Relayed SAMPLE

multipart/report delivery-status SAMPLE with action=relayed for DSN parsers.

File: EML · Dsn
Use case: Email parsingConversion testing· Conversion set

EML: DSN Reporting Two Recipients With Different Outcomes

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.

File: EML · Dsn
Use case: Email parsingConversion testing· Conversion set

EML: DSN Returning Only the Original Headers

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.

File: EML · Dsn
Use case: Email parsingConversion testing· Paired fixture

EML: DSN Returning the Original Message in Full

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.

File: EML · Dsn
Use case: Email parsingConversion testing· Paired fixture

EML: DSN With a 5.7.1 Policy Rejection

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.

File: EML · Dsn
Use case: Email parsingConversion testing· Conversion set

EML: Encoded-Word Longer Than the 75-Character Limit

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.

File: EML · Headers · B (base64)
Use case: Email parsingEncoding detection+1· Conversion set

EML: Encoded-Word Subject Folded Over Four Lines

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.

File: EML · Headers
Use case: Email parsingEncoding detection+1· Conversion set

EML: Encoded-Word With an Unregistered Charset

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.

File: EML · Headers · B (base64)
Use case: Email parsingError handling+1· Conversion set

EML: Encoded-Words in Display Names and a Filename

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.

File: EML · Headers
Use case: Email parsingEncoding detection+1· Conversion set

EML: Exchange-Style Thread-Index Alongside References

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.

File: EML · Threading
Use case: Email parsingConversion testing· Conversion set

EML: Follow-up SAMPLE 1

Simple follow-up SAMPLE message #1 for mailbox threading pads.

File: EML · Threading
Use case: Email parsing· Conversion set

EML: Follow-up SAMPLE 2

Simple follow-up SAMPLE message #2 for mailbox threading pads.

File: EML · Threading
Use case: Email parsing· Conversion set

EML: Follow-up SAMPLE 3

Simple follow-up SAMPLE message #3 for mailbox threading pads.

File: EML · Threading
Use case: Email parsing· Conversion set

EML: Header and Body Lines at Exactly 998 Octets

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.

File: EML · Headers
Use case: Email parsingConversion testing· Conversion set

EML: Headers Folded With HTAB Continuations

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.

File: EML · Headers
Use case: Email parsingConversion testing· Conversion set

EML: HTML Only (No Plain Alternative)

A single-part text/html email with no text/plain alternative: edge case for clients that require multipart/alternative.

File: EML · Mime
Use case: Email parsingConversion testing

EML: Identical Image, Inline and Attached

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.

File: EML · Mime
Use case: Email parsingConversion testing· Conversion set

EML: message/rfc822 Forward of a Multipart Message

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.

File: EML · Mime
Use case: Email parsingConversion testing· Conversion set

EML: multipart/alternative in Reverse Preference Order

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.

File: EML · Mime
Use case: Email parsingConversion testing· Conversion set

EML: multipart/alternative Whose Parts Disagree

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.

File: EML · Mime
Use case: Email parsingConversion testing+1· Conversion set

Explore the test library

Filter the library

5297 results