FAILURE MAP
← Case archive

FA-76698 / Email MIME structure / Member archive

Classify recipients of a delivery status report: status class · case 03

Temporary failures are treated as permanent bounces and unsubscribe the recipient.

Member previewVariant 3 · 3 implementations · 7 checks per implementation

Case contract

A report is valid only when its type is multipart/report, its report-type parameter (name and value case-insensitive) is delivery-status, and its second part is message/delivery-status or message/global-delivery-status. Each recipient {final, action, status} gets: failed -> hard for status class 5, soft for 4, unknown otherwise; delayed -> delayed; delivered, relayed or expanded -> ok; anything else unknown (actions are case-insensitive and trimmed). has_original is true when a third part is message/rfc822 or text/rfc822-headers. Invalid reports give {valid False, recipients [], has_original False}.

Why this case matters

Bounce processing drives list hygiene and retry decisions; misclassification unsubscribes healthy addresses.

One recorded failure

Sample boundary fixture

This sample comes from the broken implementation of a controlled reproducer.

Boundary fixtureActualExpectedOutcome
status class decides{"has_original": false, "recipients": [["c@x", "hard"], ["d3@x", "hard"]], "valid": true}{"has_original": false, "recipients": [["c@x", "soft"], ["d3@x", "unknown"]], "valid": true}Failed

MEMBER ARCHIVE

The complete case is available to members.

This record includes three runnable implementations, regression fixtures, execution results, and source hashes.

Member access is invitation-based. Sign in with your invited account to inspect the sources.

Sign in to the archive ↗