MBOX File Documentation

Summary

An Mbox Mailbox file is a single plain-text file that stores many email messages one after another, the classic Unix, Thunderbird and Apple Mail mailbox format. Each message is separated by a line starting with From  (the word From plus a space). Specified in IETF RFC 4155 with the MIME type application/mbox, it is how Gmail arrives from Google Takeout. Import a .mbox into Thunderbird to read it; the common goal is converting it to PST for Outlook.

Technical details

FeatureValue
Full nameMbox Mailbox (email container)
File extension.mbox (Thunderbird stores folders with no extension)
MIME typeapplication/mbox
Format typePlain-text container concatenating many RFC 822 messages
DeveloperOriginated in Fifth Edition Unix mail (1970s); no single owner
Introduced1970s; informally documented as RFC 4155 (September 2005)
StandardIETF RFC 4155 (media type); messages follow RFC 5322 / MIME
Open standardYes — open, plain-text, widely implemented
Message separatorLine beginning From  (the “From_” line): sender + timestamp
Variantsmboxo, mboxrd, mboxcl, mboxcl2 (differ in From escaping)
Common variantmboxrd — used by Thunderbird and Google Takeout
Byte orderN/A — plain text (US-ASCII with MIME-encoded bodies)
Magic numberNone; a valid file starts with a From  line
Per-message contentRFC 822 headers + body + base64 attachments
Single-message siblingEML (one message per file)
Related extensions.eml, .emlx, .pst, .ost, .olm
Specificationrfc-editor.org/rfc/rfc4155
Structure at a glance

An mbox is plain text with no binary signature. Every message begins with a “From_” line: the literal word From, one space, the envelope sender, and a timestamp, for example From sender@example.com Mon Jan 1 00:00:00 2024. That line at the start of a line is the only delimiter between messages. Immediately below it come the message’s own From:, To:, Subject: and Date: headers, a blank line, then the body. Messages run back-to-back to the end of the file. Any body line that literally starts with From  is escaped to >From  so it is not mistaken for a new message.

What is an MBOX file?

MBOX is the traditional format for storing a whole mailbox — an entire folder of email — in one file. It dates back to early Unix mail (the concept appears in Fifth Edition Unix in the 1970s) and was finally written down in IETF RFC 4155, “The application/mbox Media Type”, in September 2005. The mechanism is deliberately minimal: each message is kept as its raw RFC 822/MIME text, and the messages are concatenated one after another in a single file, each introduced by a line that begins with the four characters From followed by a space.

Because it is plain text, an mbox is human-readable and extremely portable. You can open it in any editor and see the messages in order. The trade-off is that a large mailbox becomes one enormous file with no index, and there is not one mbox but several subtly incompatible variants that disagree about how to keep message bodies from being mistaken for message boundaries. This article covers how the file is laid out, what the “From_” separator really is, and why those variants exist.

The “From_” separator line

The single structural rule of mbox is the “From_” line (the underscore is a convention for “the space after From”). A new message starts wherever a line begins with:

From sender@example.com Mon Jan  1 00:00:00 2024

The token is the literal word From, then a single space, then the envelope sender address, then a UTC-style timestamp. This line is not one of the message’s own headers. It is a delivery-time marker prepended by the mail system, which is why the message’s real originator appears again just below it in a proper From: header (note the colon). A parser walks the file looking only for lines that start with From  at column zero; each one it finds begins a new message, and everything up to the next such line is the previous message’s headers and body.

That simplicity is also the format’s weakness. Nothing about the text From  is inherently special, so if the body of an email contains a line that happens to start with “From ” — a perfectly ordinary English sentence — a naive reader would split one message into two. Every mbox variant is essentially a different answer to that one problem.

An mbox message, header block to body

Below the separator, each message is exactly what a standalone EML file would contain: a block of headers, a blank line, then the body. A short example:

From alice@example.com Mon Jan  1 09:15:02 2024
Return-Path: <alice@example.com>
From: Alice <alice@example.com>
To: Bob <bob@example.net>
Subject: Lunch
Date: Mon, 1 Jan 2024 09:15:00 +0000
Message-ID: <abc123@example.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8

Are we still on for noon?
>From the office I can leave by 11:45.

From bob@example.net Mon Jan  1 09:20:41 2024
...next message...

Two details matter here. First, the message is self-contained RFC 5322 mail, so an mbox is really a single-file archive of many EML messages; splitting an mbox on its “From_” lines yields a folder of .eml files, and that is exactly how conversion tools work. Second, note the body line >From the office: the writer’s original text was “From the office”, and the mailbox software prefixed a > so the line would not be read as a new message. That escaping is the crux of the variant problem.

The four variants: mboxo, mboxrd, mboxcl, mboxcl2

All four store messages the same way; they differ only in how a body line beginning with “From ” is protected, and how message length is determined.

VariantFrom escapingLength by
mboxoEscapes From  to >From , but not reversiblyScanning for the next From_ line
mboxrdEscapes From  and existing >From  (piles up >), fully reversibleScanning for the next From_ line
mboxclEscapes like mboxoA Content-Length header
mboxcl2No escaping at allA Content-Length header

mboxo is the original and the trap. It turns a body’s From  into >From , but it does not escape a line that already started with >From . On the way back out the reader strips one >, so a line the author genuinely wrote as “>From” is silently corrupted. mboxrd, devised by Rahul Dhesi, fixes this by escaping every line matching >*From , piling on one more > each time, which makes the transformation reversible: strip exactly one > on read and the original text returns intact. mboxrd is what Mozilla Thunderbird and Google Takeout produce, so it is the variant most users actually hold. mboxcl and mboxcl2 add a Content-Length header to each message giving the body’s exact byte count, so a reader jumps forward by that many bytes instead of scanning for the next separator; mboxcl2 then needs no From escaping at all, because it never scans. The cost is fragility: if a Content-Length is wrong or missing, message boundaries collapse.

Where mbox files come from, and its single-message sibling

mbox is the standard export and storage format across the free-software mail world. Mozilla Thunderbird stores every folder as an mbox file (usually with no extension, in the profile’s Mail and ImapMail directories) and exports to .mbox through the ImportExportTools NG add-on. Apple Mail exports mailboxes as .mbox bundles. Above all, Google Takeout exports an entire Gmail account as one .mbox file, which is how most people first encounter the format — and why a single file can hold years of mail as readable text.

Keep the family straight. An .mbox holds many messages in one file (a mailbox). An EML or .emlx file holds a single message. Microsoft’s .pst and .ost are Outlook’s proprietary binary mailbox stores; Outlook cannot read mbox at all, which is why “mbox to PST” is the dominant conversion task. The usual free route is to import the mbox into Thunderbird and migrate from there, since Thunderbird speaks both worlds.

Reading an mbox and keeping messages intact

To read an mbox with rendered HTML and decoded attachments, import it into a mail client: Thunderbird with ImportExportTools NG on any OS, or Apple Mail on macOS through Mailbox > Import Mailboxes > “Files in mbox format”. On Linux the classic terminal reader is mutt -f mailbox.mbox, and Evolution or KMail import it through their File > Import dialogs. For a quick look you need nothing at all: a text editor shows every message, each beginning with its From  line, though you will see raw base64 where attachments live rather than the files themselves.

The one real hazard with mbox is not security but integrity. The file itself is inert text and cannot execute, though it carries genuine email, so the usual caution about phishing links and attachments applies once you open a message in a client. The subtler risk is the variant mismatch described above: hand an mboxrd file to a tool expecting mboxo, or feed a body containing an unescaped “From ” line to a strict scanner, and messages can split or merge at the wrong place. When converting or migrating a large mailbox, use a tool that understands the same variant your file was written in — for Gmail and Thunderbird exports, that means mboxrd.

Frequently asked questions

Can I read an MBOX without an email client?

Yes. It is plain text, so a text editor displays every message in order, each starting with a From  line. What you will not get is rendered HTML or decoded attachments — those appear as raw quoted-printable or base64 blocks. For a readable inbox with working attachments, import the file into Thunderbird or Apple Mail.

What is the difference between MBOX and EML?

An .mbox is a container holding many messages concatenated into one mailbox file; an EML file is a single message. Because each message inside an mbox is itself RFC 5322 mail, splitting an mbox on its “From_” separators produces a set of .eml files, and combining .eml files with separator lines rebuilds an mbox.

Why did my MBOX split one email into two?

A body line began with the text “From ” and the tool that wrote or read the file used a variant that did not escape it (or a reader expecting a different variant). mboxrd, used by Thunderbird and Gmail exports, escapes such lines reversibly to prevent exactly this; a mismatch between the writer’s and reader’s variants is the usual cause of split or merged messages.

References