On this page
Identify the mbox variant before splitting messages
Record a neutral file ID, digest, line ending style, declared media type and format parameter, first separator candidate, and the tool that produced the export. RFC 4155 says the mbox database format is not one authoritative historical format and recommends treating an unknown format parameter as opaque. Do not split every line beginning with From and call the result a message set.
The RFC 4155 and RFC 5322 source records carry verified publication months, September 2005 and October 2008. The RFC 2046 record keeps 22 October 2026 as its schema-compatible retrieval date, while the source ledger records its known November 1996 publication month separately. The checked day is retrieval evidence, not a publication claim.
| Boundary evidence | Record | Stop if |
|---|---|---|
| Format parameter | Declared value or unknown | An unknown variant is treated as default |
| Separator line | Full line, sender token, timestamp, offset | Only the prefix is matched |
| Message terminator | Empty line and line ending | End of file is assumed to terminate cleanly |
| Line ending | LF, CRLF, or mixed | Normalization hides source bytes |
| Body From line | Location and escaping state | Body text is mistaken for a separator |
| Mailbox nesting | Attachment or embedded mbox evidence | Two mbox streams are merged |
Preserve the raw separator line and its byte offset. RFC 4155 notes that it does not prescribe an escape syntax for body lines that begin with From space, so a parser must use the documented full separator form and a known variant policy rather than a guessed unescape rule.
Parse the Internet Message boundary independently
Within each candidate message, locate the RFC 5322 header section and the blank line that begins the body. Record header line folding, duplicate fields, malformed fields, and the parser’s recovery decision. A sender line in the mbox separator is not the same field as a From header inside the message. Keep envelope separator metadata and message headers in separate columns.
| Message layer | Record | Cannot infer |
|---|---|---|
| Envelope separator | Raw line and offset | That it is a message header |
| Header section | Field names, folding, and parse status | That a field is unique |
| Blank line | Exact delimiter and line ending | That no body exists |
| Body | Raw or encoded span | That text is safe to display |
| Transfer encoding | Declared encoding and decoder | That bytes are already Unicode |
| Message ID | Header value and source location | That it is a unique archive key |
Treat MIME boundaries and attachments as nested evidence
RFC 2046 defines multipart bodies with a boundary parameter and delimiter lines. Record the complete Content-Type header, boundary token, nesting path, delimiter offsets, part headers, Content-Disposition, filename parameter, media type, transfer encoding, and decoded byte span. A filename is metadata, not proof of file type, and a MIME part is not necessarily a standalone attachment.
| MIME observation | Supports | Open question |
|---|---|---|
| Multipart boundary | A candidate part delimiter | Does the closing delimiter exist? |
| Part headers | Declared media and disposition | Do bytes match the declaration? |
| Filename | Suggested display name | Is it encoded, duplicated, or unsafe? |
| Transfer encoding | A decode rule | Was decoded content retained separately? |
| Nested message | An embedded message part | Should it be parsed as a new message? |
| Attachment mbox | Potential nested mailbox payload | Could it intermix with the outer mailbox? |
Synthetic message ledger
{"mailbox":"fixture-mbox-01","message":{"separator_offset":"fixture-offset","header_body_split":"fixture-offset","content_type":"multipart/mixed","boundary":"fixture-boundary","parts":[{"path":"1","media_type":"text/plain","transfer_encoding":"fixture-encoding"},{"path":"2","media_type":"application/octet-stream","filename":"fixture.bin","decoded_span":"fixture-span"}]},"state":"metadata-only"}Reconcile counts and decoded parts without exposing mail
Use a synthetic mailbox to compare separator count, parsed message count, MIME part count, decoded attachment count, and re-encoded output. Capture parser version and recovery events. A successful attachment decode does not prove that the message boundary was correct, that a nested mbox was not intermingled, or that the decoded bytes are safe to open.
| Reconciliation | Record | Hold when |
|---|---|---|
| Separators to messages | Candidate and accepted counts | A separator is malformed or ambiguous |
| Headers to bodies | One split per message or recovery | Multiple blank lines change the result |
| MIME parts | Opening and closing delimiter counts | Nesting is incomplete |
| Decoded bytes | Encoded and decoded lengths | Decoder silently truncates |
| Re-encoded message | Changed headers and boundaries | Source bytes are replaced |
| Privacy boundary | Redacted field and payload policy | Real addresses or bodies enter the report |
Stop before message extraction is trustworthy
Stop conditions
- Stop if the mbox variant, separator policy, line endings, or format parameter is unknown.
- Stop if body lines beginning with From space could be confused with full separator lines.
- Stop if RFC 5322 headers and body cannot be separated without parser recovery.
- Stop if MIME opening or closing boundaries, nested parts, or transfer encoding are incomplete.
- Stop if an mbox attachment may have been intermingled with the receiving mailbox.
- Stop before opening decoded attachments when the source contains private or untrusted content.
Pair this worksheet with the data provenance log for export and decoder history and the data card template for collection context. A parsed attachment does not prove message completeness, ownership, privacy clearance, or permission.
For a supported non-health collection, after the owner has authority to describe the scope and a controlled metadata packet, the qualified appraisal request path may be a preparation step. It does not read mail, scan attachments, determine sender identity, create a quote, match a buyer, or grant a license.