Mbox

Family of email-related file formats

For the Wikipedia template, see Template:Mbox.

This article has multiple issues. Please help improve it or discuss these issues on the talk page. (Learn how and when to remove these messages)

This article needs additional citations for verification. Please help improve this article by adding citations to reliable sources. Unsourced material may be challenged and removed.
Find sources: "Mbox" – news · newspapers · books · scholar · JSTOR (March 2021) (Learn how and when to remove this message)

|

This article may be too technical for most readers to understand. Please help improve it to make it understandable to non-experts, without removing the technical details. (March 2021) (Learn how and when to remove this message)

|

This article needs to be updated. Please help update this article to reflect recent events or newly available information. (March 2021)

|

(Learn how and when to remove this message)

Mbox is a generic term for a family of related file formats used for holding collections of email messages. It was first implemented in Fifth Edition Unix.

All messages in an mbox mailbox are concatenated and stored as plain text in a single file. Each message starts with the four characters "From" followed by a space (the so-called "From_ line") and the sender's email address. RFC 4155 defines that a UTC timestamp follows after another separating space character.[1]

A format similar to mbox is the MH Message Handling System. Other systems, such as Microsoft Exchange Server and the Cyrus IMAP server, store mailboxes in centralized databases managed by the mail system and not directly accessible by individual users. The maildir mailbox format is often cited as an alternative to the mbox format for networked email storage systems.

## Mail storage protocols

[edit]

Unlike the Internet protocols used for the exchange of email, the format used for the storage of email has never been formally defined through the RFC standardization mechanism and has been entirely left to the developer of an email client. However, the POSIX standard defined a loose framework in conjunction with the mailx program. In 2005, the application/mbox media type was standardized as RFC 4155, which hinted that mbox stores mailbox messages in their original Internet Message (RFC 2822) format, except for the used newline character, seven-bit clean data storage, and the requirement that each newly added message is terminated with a completely empty line within the mbox database.[1][2]

## File locking

[edit]

This section has multiple issues. Please help improve it or discuss these issues on the talk page. (Learn how and when to remove these messages)

This section does not cite any sources. Please help improve this section by adding citations to reliable sources. Unsourced material may be challenged and removed. (March 2021) (Learn how and when to remove this message)

|

This section may be too technical for most readers to understand. Please help improve it to make it understandable to non-experts, without removing the technical details. (March 2021) (Learn how and when to remove this message)

|

(Learn how and when to remove this message)

Because more than one messages are stored in a single file, some form of file locking is needed to avoid the corruption that can result from two or more processes modifying the mailbox simultaneously. This could happen if a network email delivery program delivers a new message at the same time as a mail reader is deleting an existing message.

Various mutually incompatible mechanisms have been used by different mbox formats to enable message file locking, including `fcntl()` and `lockf()`. This does not work well with network mounted file systems, such as the Network File System (NFS), which is why traditionally Unix used additional "dot lock" files, which could be created atomically even over NFS.

Mbox files should also be locked while they are being read. Otherwise, the reader may see corrupted message contents if another process is modifying the mbox at the same time, even though no actual file corruption occurs.

## As a patch format

[edit]

In open source development, it is common to send patches in the diff format to a mailing list for discussion. The diff format allows for irrelevant "headers", such as mbox data, to be added.[3][4] Version control systems like git have support for generating mbox-formatted patches and for sending them to the list as emails in a thread.[5][6]

## See also

[edit]

* Maildir
* MIX (email)
* MH Message Handling System

## References

[edit]

1. ^ a b Hall, E., ed. (September 2005). "Request for Comments: 4155 – The application/mbox Media Type". Internet Engineering Task Force. Archived from the original on 17 May 2021. Retrieved 17 May 2021.
2. ^ Resnick, P., ed. (April 2001). "Request for Comments: 2822 – Internet Message Format". Internet Engineering Task Force. Archived from the original on 31 March 2023. Retrieved 17 May 2021.
3. ^ "Submitting patches: the essential guide to getting your code into the kernel — The Linux Kernel documentation". www.kernel.org. Archived from the original on 2019-10-27. Retrieved 2020-03-03.
4. ^ Randal, Allison; Sugalski, Dan; Tötsch, Leopold (2003). "Patch submission". Perl 6 Essentials. O'Reilly Media, Inc. p. 14. ISBN 978-0-596-00499-6.
5. ^ "Git - git-format-patch Documentation". git-scm.com. Archived from the original on 2020-03-07. Retrieved 2020-03-03.
6. ^ "Git - git-send-email Documentation". git-scm.com. Archived from the original on 2020-02-21. Retrieved 2020-03-03.

## Further reading

[edit]

* qmail mbox manual page
* Internet Mail Consortium – Standards body