Editing Mbox

{{Short description|Family of email-related file formats}}
{{for|the Wikipedia template|Template:Mbox|selfref=y}}
{{Multiple issues|
{{More citations needed|date=March 2021}}
{{Technical|date=March 2021}}
{{Update|date=March 2021}}
}}

'''Mbox''' is a generic term for a family of related [[file format]]s used for holding collections of [[email]] messages. It was first implemented in [[Research Unix|Fifth Edition Unix]].

All messages in an mbox mailbox are [[Concatenation|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.<ref name="RFC4155">{{cite web |editor-last=Hall |editor-first=E. |title=Request for Comments: 4155 – The application/mbox Media Type |url=https://datatracker.ietf.org/doc/html/rfc4155 |date=September 2005 |website=[[Internet Engineering Task Force]] |access-date=17 May 2021 |archive-date=17 May 2021 |archive-url=https://web.archive.org/web/20210517200708/https://datatracker.ietf.org/doc/html/rfc4155 |url-status=live }}</ref>

A format similar to mbox is the [[MH Message Handling System]]. Other systems, such as [[Microsoft Exchange Server]] and the [[Cyrus (imapd)|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 ==
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 [[Request for Comments|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.<ref name="RFC4155" /><ref name="RFC2822">{{cite web |editor-last=Resnick |editor-first=P. |title=Request for Comments: 2822 – Internet Message Format |url=https://datatracker.ietf.org/doc/html/rfc2822 |date=April 2001 |website=[[Internet Engineering Task Force]] |access-date=17 May 2021 |archive-date=31 March 2023 |archive-url=https://web.archive.org/web/20230331010336/https://datatracker.ietf.org/doc/html/rfc2822 |url-status=live }}</ref>

== File locking ==
{{Multiple issues|section=yes|
{{Unreferenced section|date=March 2021}}
{{Technical|section|date=March 2021}}
}}

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 <code>fcntl()</code> and <code>lockf()</code>. This does not work well with network mounted file systems, such as the [[Network File System (protocol)|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 ==
In [[open source]] development, it is common to send [[patch (Unix)|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.<ref>{{cite web |title=Submitting patches: the essential guide to getting your code into the kernel — The Linux Kernel documentation |url=https://www.kernel.org/doc/html/v4.17/process/submitting-patches.html |website=www.kernel.org |access-date=2020-03-03 |archive-date=2019-10-27 |archive-url=https://web.archive.org/web/20191027200648/https://www.kernel.org/doc/html/v4.17/process/submitting-patches.html |url-status=live }}</ref><ref>{{cite book |last1=Randal |first1=Allison |last2=Sugalski |first2=Dan |last3=Tötsch |first3=Leopold |title=Perl 6 Essentials |date=2003 |publisher=O'Reilly Media, Inc. |isbn=978-0-596-00499-6 |url=https://archive.org/details/perl6essentials0000rand |url-access=registration |page=[https://archive.org/details/perl6essentials0000rand/page/14 14] |chapter=Patch submission |language=en}}</ref> [[Version control system]]s like [[git]] have support for generating mbox-formatted patches and for sending them to the list as emails in a thread.<ref>{{cite web |title=Git - git-format-patch Documentation |url=https://git-scm.com/docs/git-format-patch |website=git-scm.com |access-date=2020-03-03 |archive-date=2020-03-07 |archive-url=https://web.archive.org/web/20200307091330/https://git-scm.com/docs/git-format-patch |url-status=live }}</ref><ref>{{cite web |title=Git - git-send-email Documentation |url=https://git-scm.com/docs/git-send-email |website=git-scm.com |access-date=2020-03-03 |archive-date=2020-02-21 |archive-url=https://web.archive.org/web/20200221160736/https://git-scm.com/docs/git-send-email |url-status=live }}</ref>

==See also==
* [[Maildir]]
* [[MIX (email)]]
* [[MH Message Handling System]]

== References ==
{{reflist}}

== Further reading ==
* [http://qmail.org/qmail-manual-html/man5/mbox.html qmail mbox manual page]
* [https://web.archive.org/web/20120529014601/http://www.imc.org/ Internet Mail Consortium] – Standards body

[[Category:Email storage formats]]