{ "content": [ { "type": "text", "text": "# mbox (man)\n\n## NAME\n\nmbox - Format for mail message storage.\n\n## DESCRIPTION\n\nThis document describes the format traditionally used by Unix hosts to store mail messages\nlocally. mbox files typically reside in the system's mail spool, under various names in\nusers' Mail directories, and under the name mbox in users' home directories.\n\n## Sections\n\n- **NAME**\n- **DESCRIPTION**\n- **LOCKING**\n- **FILES**\n- **SEE ALSO**\n- **AUTHOR**\n- **HISTORY**\n\nUse structuredContent.sections for detailed options, examples, and full documentation.\n" } ], "structuredContent": { "command": "mbox", "section": "", "mode": "man", "summary": "mbox - Format for mail message storage.", "synopsis": null, "tldr_summary": null, "tldr_examples": [], "tldr_source": null, "flags": [], "examples": [], "see_also": [ { "name": "mutt", "section": "1", "url": "https://www.chedong.com/phpMan.php/man/mutt/1/json" }, { "name": "fcntl", "section": "2", "url": "https://www.chedong.com/phpMan.php/man/fcntl/2/json" }, { "name": "flock", "section": "2", "url": "https://www.chedong.com/phpMan.php/man/flock/2/json" }, { "name": "link", "section": "2", "url": "https://www.chedong.com/phpMan.php/man/link/2/json" }, { "name": "stat", "section": "2", "url": "https://www.chedong.com/phpMan.php/man/stat/2/json" }, { "name": "asctime", "section": "3", "url": "https://www.chedong.com/phpMan.php/man/asctime/3/json" }, { "name": "maildir", "section": "5", "url": "https://www.chedong.com/phpMan.php/man/maildir/5/json" }, { "name": "mmdf", "section": "5", "url": "https://www.chedong.com/phpMan.php/man/mmdf/5/json" } ], "section_outline": [ { "name": "NAME", "lines": 2, "subsections": [] }, { "name": "DESCRIPTION", "lines": 47, "subsections": [] }, { "name": "LOCKING", "lines": 34, "subsections": [] }, { "name": "FILES", "lines": 10, "subsections": [] }, { "name": "SEE ALSO", "lines": 3, "subsections": [] }, { "name": "AUTHOR", "lines": 2, "subsections": [] }, { "name": "HISTORY", "lines": 6, "subsections": [] } ], "sections": { "NAME": { "content": "mbox - Format for mail message storage.\n", "subsections": [] }, "DESCRIPTION": { "content": "This document describes the format traditionally used by Unix hosts to store mail messages\nlocally. mbox files typically reside in the system's mail spool, under various names in\nusers' Mail directories, and under the name mbox in users' home directories.\n\nAn mbox is a text file containing an arbitrary number of e-mail messages. Each message con‐\nsists of a postmark, followed by an e-mail message formatted according to RFC822, RFC2822.\nThe file format is line-oriented. Lines are separated by line feed characters (ASCII 10).\n\nA postmark line consists of the four characters \"From\", followed by a space character, fol‐\nlowed by the message's envelope sender address, followed by whitespace, and followed by a\ntime stamp. This line is often called From line.\n\nThe sender address is expected to be addr-spec as defined in RFC2822 3.4.1. The date is ex‐\npected to be date-time as output by asctime(3). For compatibility reasons with legacy soft‐\nware, two-digit years greater than or equal to 70 should be interpreted as the years 1970+,\nwhile two-digit years less than 70 should be interpreted as the years 2000-2069. Software\nreading files in this format should also be prepared to accept non-numeric timezone informa‐\ntion such as \"CET DST\" for Central European Time, daylight saving time.\n\nExample:\n\n>From example@example.com Fri Jun 23 02:56:55 2000\n\nIn order to avoid misinterpretation of lines in message bodies which begin with the four\ncharacters \"From\", followed by a space character, the mail delivery agent must quote any oc‐\ncurrence of \"From \" at the start of a body line.\n\nThere are two different quoting schemes, the first (MBOXO) only quotes plain \"From \" lines in\nthe body by prepending a '>' to the line; the second (MBOXRD) also quotes already quoted\n\"From \" lines by prepending a '>' (i.e. \">From \", \">>From \", ...). The later has the advan‐\ntage that lines like\n\n>From the command line you can use the '-p' option\n\naren't dequoted wrongly as a MBOXRD-MDA would turn the line into\n\n>>From the command line you can use the '-p' option\n\nbefore storing it. Besides MBOXO and MBOXRD there is also MBOXCL which is MBOXO with a \"Con‐\ntent-Length:\"-field with the number of bytes in the message body; some MUAs (like mutt(1)) do\nautomatically transform MBOXO mailboxes into MBOXCL ones when ever they write them back as\nMBOXCL can be read by any MBOXO-MUA without any problems.\n\nIf the modification-time (usually determined via stat(2)) of a nonempty mbox file is greater\nthan the access-time the file has new mail. Many MUAs place a Status: header in each message\nto indicate which messages have already been read.\n", "subsections": [] }, "LOCKING": { "content": "Since mbox files are frequently accessed by multiple programs in parallel, mbox files should\ngenerally not be accessed without locking.\n\nThree different locking mechanisms (and combinations thereof) are in general use:\n\n• fcntl(2) locking is mostly used on recent, POSIX-compliant systems. Use of this lock‐\ning method is, in particular, advisable if mbox files are accessed through the Network\nFile System (NFS), since it seems the only way to reliably invalidate NFS clients'\ncaches.\n\n• flock(2) locking is mostly used on BSD-based systems.\n\n• Dotlocking is used on all kinds of systems. In order to lock an mbox file named\nfolder, an application first creates a temporary file with a unique name in the direc‐\ntory in which the folder resides. The application then tries to use the link(2) system\ncall to create a hard link named folder.lock to the temporary file. The success of the\nlink(2) system call should be additionally verified using stat(2) calls. If the link\nhas succeeded, the mail folder is considered dotlocked. The temporary file can then\nsafely be unlinked.\n\nIn order to release the lock, an application just unlinks the folder.lock file.\n\nIf multiple methods are combined, implementors should make sure to use the non-blocking vari‐\nants of the fcntl(2) and flock(2) system calls in order to avoid deadlocks.\n\nIf multiple methods are combined, an mbox file must not be considered to have been success‐\nfully locked before all individual locks were obtained. When one of the individual locking\nmethods fails, an application should release all locks it acquired successfully, and restart\nthe entire locking procedure from the beginning, after a suitable delay.\n\nThe locking mechanism used on a particular system is a matter of local policy, and should be\nconsistently used by all applications installed on the system which access mbox files. Fail‐\nure to do so may result in loss of e-mail data, and in corrupted mbox files.\n", "subsections": [] }, "FILES": { "content": "/var/spool/mail/$LOGNAME\n$LOGNAME's incoming mail folder.\n\n$HOME/mbox\nuser's archived mail messages, in his $HOME directory.\n\n$HOME/Mail/\nA directory in user's $HOME directory which is commonly used to hold mbox format fold‐\ners.\n", "subsections": [] }, "SEE ALSO": { "content": "mutt(1), fcntl(2), flock(2), link(2), stat(2), asctime(3), maildir(5), mmdf(5), RFC822,\nRFC976, RFC2822\n", "subsections": [] }, "AUTHOR": { "content": "Thomas Roessler , Urs Janssen \n", "subsections": [] }, "HISTORY": { "content": "The mbox format occurred in Version 6 AT&T Unix.\nA variant of this format was documented in RFC976.\n\n\n\nUnix February 19th, 2002 mbox(5)", "subsections": [] } } } }