What this RFC defines
RFC 4155 registers the application/mbox MIME media type for the traditional Unix mbox mailbox format. The mbox format stores multiple email messages in a single file, with each message separated by a From_ line. RFC 4155 formalises the media type so that mbox files can be correctly identified and handled when transferred as email attachments or via HTTP.
Where you see it in practice
When you export your email archive from a mail client and receive a .mbox file, the MIME type that identifies it as application/mbox comes from RFC 4155. Mail clients that can import mbox files check for this MIME type to identify the format. The mbox format itself predates the RFC and has several variants; RFC 4155 focuses on the MIME registration rather than defining a new format specification.
How it connects to other RFCs
RFC 4155 is a MIME media type registration that builds on RFC 2045 and RFC 2046 (MIME framework). It references the existing mbox format conventions without superseding any prior specification for mbox itself. It is an IANA registration document rather than a protocol standard defining new behaviour.
Current status
RFC 4155 is a current informational RFC, published September 2005. The application/mbox media type registration it defines is the canonical MIME type for mbox files. The mbox format itself remains widely used for email archiving and migration between mail clients despite being a legacy format.
The application/mbox media type
RFC 4155 registered the application/mbox media type for the traditional Unix mbox mailbox format. Mbox is a flat text file where multiple messages are concatenated, separated by lines starting with “From ” (with a space, no colon). This format dates to the earliest Unix mail systems in the 1970s and remains widely used for archives, mailing list distributions, and interchange between mail systems.
Mbox variants and gotchas
There are several mbox variants: mboxo (original, no escaping), mboxrd (escapes “From ” lines in body), mboxcl (adds Content-Length header), mboxcl2 (Content-Length only, no From escaping). Portable interchange should use mboxrd, but many tools produce mboxo, which corrupts bodies containing lines starting with “From “. If you export an archive from one mail client and import into another, differences in mbox flavor are the most common source of message loss or corruption.
Practical use in 2026
Mbox remains the primary archive format for many mailing list managers (Mailman archives are typically mbox), for local mail clients like Thunderbird (which uses mbox internally), and for backup tools. GDPR data export requests from mail services often produce mbox files. Web-based tools like mbox2eml or IMAP importers help convert mbox to individual messages for import into modern clients. Understanding application/mbox as a registered media type helps automated tools identify and process the format correctly.
RFC 4155 (September 2005) registers the application/mbox media type: the historical mbox format for storing multiple email messages in a single flat file. Format: messages concatenated with each starting with a From line (envelope-from sender + timestamp), delimited by blank lines. Foundation for Unix mail spools (/var/mail/user), mailbox archives, and mail import/export between clients. Widely supported by Unix MTAs, mail archives (mbox format Usenet archives), and mail clients (Thunderbird uses mbox internally). Superseded operationally by Maildir for concurrent access.
RFC 4155 at a glance
| Aspect | Detail |
|---|---|
| Purpose | Register application/mbox media type for the mbox format |
| Format | Concatenated messages; each starts with From line |
| Origin | Unix mail spool convention from the 1970s |
| Message delimiter | Blank line + next From line |
| Modern alternatives | Maildir (concurrent access), database-backed mailbox stores (Cyrus, Dovecot) |
| Published | September 2005 |
mbox format structure
mbox vs Maildir
| Aspect | mbox | Maildir |
|---|---|---|
| Storage | Single flat file per folder | One file per message in a directory |
| Concurrent access | Requires file locking; problematic under load | Native concurrent access (each message is atomic file) |
| Backup/atomicity | Whole file must be backed up as unit | Per-message backup possible |
| Corruption risk | Bad write can corrupt entire folder | Bad write affects only one message |
| Portability | Widely supported (Unix, Thunderbird, many tools) | Supported by modern MTAs and clients; less by legacy |
| Best for | Archives, import/export, single-user access | Live mail spools with concurrent access |
Common mbox handling mistakes
Related standards and further reading
- RFC 3501: IMAP4rev1 (some servers use mbox backend)
- RFC 1939: POP3 (mbox-style spool historically)
- RFC 3501 IMAP Guide: modern access protocol
Frequently asked questions
Is mbox still used in 2026?
Yes, in specific contexts. Mail archives (Usenet archives, mailing list archives at sites like MARC or Gmane) commonly use mbox. Thunderbird uses mbox internally for local storage. Unix mail spools historically used mbox; modern deployments have largely moved to Maildir or database backends. As an interchange format for exporting/importing mailboxes, mbox remains widely supported.
Should I use mbox or Maildir for a new mail server?
Maildir for anything with concurrent access requirements. mbox’s single-file structure requires locking that becomes a bottleneck under load. Maildir’s per-message files handle concurrent MDA writes natively. Modern MTAs (Postfix, Exim, Sendmail) all support Maildir; use it for production mail spools. Reserve mbox for archives, export/import, or single-user access patterns.
What is the difference between mbox variants?
mboxo (original): escapes “From ” to “>From ” in body unconditionally. mboxrd: escapes only when unambiguous (checks if the escaped version can be safely reversed). mboxcl and mboxcl2: use Content-Length header to know message boundaries without relying on delimiter escaping. mboxrd is the recommended modern variant; mboxcl2 is used by some Netscape-family archives.
How do I convert mbox to Maildir?
Various tools: mb2md, procmail with a to-maildir recipe, Dovecot’s doveadm import. Split the mbox file at message boundaries, write each message as an individual Maildir file with proper naming (timestamp.uniqid.hostname). Test with a small sample before large migrations.
Does mbox handle binary attachments correctly?
Yes when properly MIME-encoded. Binary attachments should be base64-encoded per MIME conventions before storing in mbox. Raw binary bytes in the file can create ambiguous delimiter detection (bytes may happen to look like “From ” lines). All modern mail clients that write to mbox files properly MIME-encode attachments.
About the Author
Alaa · LinkedIn
Email infrastructure specialist with 8+ years of hands-on experience in SMTP, deliverability, and email verification. I’ve configured and troubleshot mail systems across Postfix, Exchange, and cloud relays, managed IP reputation and warmup campaigns, and built verification pipelines processing millions of addresses. My work spans DNS authentication (SPF, DKIM, DMARC, BIMI), bounce handling, blocklist monitoring, and compliance frameworks including CAN-SPAM and GDPR. I write every article on SMTPedia to give email professionals, developers, and marketers the accurate, RFC-grounded reference they need.
About SMTPedia
SMTPedia is an independent email industry reference covering SMTP, IMAP, POP3, email deliverability, marketing platforms, DNS authentication, and email verification. Every article is researched from official provider documentation, IETF RFCs, and industry best practices. Settings and configurations are verified quarterly.
We are cited as a source by ChatGPT, Microsoft Copilot, and thousands of email professionals worldwide. Learn more about our editorial process.
