Email Delivery Status Report Inspector

How to use Email Delivery Status Report Inspector

Review an exported bounce or delivery notification without uploading private email or guessing from its human explanation. The machine report keeps one record per declared recipient block, original field spelling, exact byte positions and unassessed extensions. A support handoff can use the JSON evidence or a recipient CSV while keeping reported actions separate from status-code classes.

1. Choose one actual local report file, or load the original two-recipient example. It must explicitly identify the selected delivery-status MIME type.
2. Run the report inspection and review each recipient block, action, status class and original transport diagnostic. Repeated addresses remain separate records.
3. Download JSON for complete field evidence or CSV for a simpler recipient handoff. Independently verify any operational action; a supplied report can be incomplete or forged.

Good to know

• One nonempty actual local file of at most 1 MiB, with at most 20,000 transport lines and 998 bytes per physical line. CRLF is required; bare CR/LF, NUL and other controls apart from HTAB are refused. Headers and machine fields use strict 7-bit ASCII. Human and returned bodies may contain non-ASCII bytes, but their content is not decoded, rendered or exported. File names are report text, never output paths.
• Only an explicit top-level message/delivery-status entity without parameters, or multipart/report with exactly boundary and report-type=delivery-status parameters, is supported. The latter has two or three direct parts and a closing delimiter; the second part must be parameter-free message/delivery-status. The report and machine transfer encoding must be 7bit or absent. No nested-report search, ordinary email recovery, global-delivery-status/SMTPUTF8, encoded machine body or malformed-MIME repair.
• Machine content is at most 200,000 bytes, 1,000 fields and 100 recipient blocks. Each field block has at most 100 fields and 500 physical lines. Duplicate machine-field names are refused within a block, including extensions. Opaque MIME header repetitions such as Received are retained; repeated Content-Type, Content-Transfer-Encoding or MIME-Version are refused. Message Reporting-MTA and recipient Final-Recipient, Action and Status are required; known fields in the wrong block are refused. Unknown fields are retained as unassessed original evidence.
• Typed fields require an atom, semicolon and nonblank opaque payload. The tool preserves payload case and does not parse a mailbox, domain, date, diagnostic reply or embedded comment. The five action words are accepted without comments and compared without case. Status uses class 2, 4 or 5 and two canonical decimal components from 0 through 999, without leading zeros or comments; no status-registry lookup occurs. A failed action with a 4.x.x code remains valid selected evidence.
• Source ranges are zero-based original byte positions with end exclusive. Raw fields preserve line endings; unfolding removes CRLF while retaining continuation whitespace. Surrounding spaces/tabs are trimmed only in the selected summary values. Human/returned parts and preamble/epilogue are represented by lengths, never content. This is a declared inspection subset, not a full MIME or RFC-conformance validator.
• JSON is authoritative and capped at 1,000,000 readable characters. Recipient CSV omits extensions, raw fields and offsets; formula-like cells are apostrophe-prefixed for spreadsheet exposure reduction. The report can expose names, addresses and diagnostics; no anonymization or redaction is inferred. No network, storage, sending, mailbox probe, authenticity check, automatic subscriber deletion or proof of real delivery is provided.
• Processing is local. Output is limited to 1,000,000 text characters unless a stricter file limit is stated.