4 .\" Copyright (C) 2000 Thomas Roessler <roessler@does-not-exist.org>
6 .\" This document is in the public domain and may be distributed and
7 .\" changed arbitrarily.
9 .TH mbox 5 "February 19th, 2002" Unix "User Manuals"
12 mbox \- Format for mail message storage.
15 This document describes the format traditionally used by Unix hosts
16 to store mail messages locally.
18 files typically reside in the system's mail spool, under various
19 names in users' Mail directories, and under the name
21 in users' home directories.
25 is a text file containing an arbitrary number of e-mail messages.
26 Each message consists of a postmark, followed by an e-mail message
27 formatted according to \fBRFC822\fP, \fBRFC2822\fP. The file format
28 is line-oriented. Lines are separated by line feed characters (ASCII 10).
30 A postmark line consists of the four characters "From", followed by
31 a space character, followed by the message's envelope sender
32 address, followed by whitespace, and followed by a time stamp. This
33 line is often called From_ line.
35 The sender address is expected to be
37 as defined in \fBRFC2822\fP 3.4.1. The date is expected to be
41 For compatibility reasons with legacy software, two-digit years
42 greater than or equal to 70 should be interpreted as the years
43 1970+, while two-digit years less than 70 should be interpreted as
44 the years 2000-2069. Software reading files in this format should
45 also be prepared to accept non-numeric timezone information such as
46 "CET DST" for Central European Time, daylight saving time.
50 >From example@example.com Fri Jun 23 02:56:55 2000
52 In order to avoid misinterpretation of lines in message bodies
53 which begin with the four characters "From", followed by a space
54 character, the mail delivery agent must quote any occurrence
55 of "From " at the start of a body line.
57 There are two different quoting schemes, the first (\fBMBOXO\fP) only
58 quotes plain "From " lines in the body by prepending a '>' to the
59 line; the second (\fBMBOXRD\fP) also quotes already quoted "From "
60 lines by prepending a '>' (i.e. ">From ", ">>From ", ...). The later
61 has the advantage that lines like
63 >From the command line you can use the '-p' option
65 aren't dequoted wrongly as a \fBMBOXRD\fP-MDA would turn the line
68 >>From the command line you can use the '-p' option
70 before storing it. Besides \fBMBOXO\fP and \fBMBOXRD\fP there is also
71 \fBMBOXCL\fP which is \fBMBOXO\fP with a "Content-Length:"-field with the
72 number of bytes in the message body; some MUAs (like
74 do automatically transform \fBMBOXO\fP mailboxes into \fBMBOXCL\fP ones when
75 ever they write them back as \fBMBOXCL\fP can be read by any \fBMBOXO\fP-MUA
78 If the modification-time (usually determined via
82 file is greater than the access-time the file has new mail. Many MUAs
83 place a Status: header in each message to indicate which messages have
89 files are frequently accessed by multiple programs in parallel,
91 files should generally not be accessed without locking.
93 Three different locking mechanisms (and combinations thereof) are in
97 locking is mostly used on recent, POSIX-compliant systems. Use of
98 this locking method is, in particular, advisable if
100 files are accessed through the Network File System (NFS), since it
101 seems the only way to reliably invalidate NFS clients' caches.
104 locking is mostly used on BSD-based systems.
106 Dotlocking is used on all kinds of systems. In order to lock an
108 file named \fIfolder\fR, an application first creates a temporary file
109 with a unique name in the directory in which the
110 \fIfolder\fR resides. The application then tries to use the
112 system call to create a hard link named \fIfolder.lock\fR
113 to the temporary file. The success of the
115 system call should be additionally verified using
117 calls. If the link has succeeded, the mail folder is considered
118 dotlocked. The temporary file can then safely be unlinked.
120 In order to release the lock, an application just unlinks the
121 \fIfolder.lock\fR file.
123 If multiple methods are combined, implementors should make sure to
124 use the non-blocking variants of the
128 system calls in order to avoid deadlocks.
130 If multiple methods are combined, an
132 file must not be considered to have been successfully locked before
133 all individual locks were obtained. When one of the individual
134 locking methods fails, an application should release all locks it
135 acquired successfully, and restart the entire locking procedure from
136 the beginning, after a suitable delay.
138 The locking mechanism used on a particular system is a matter of
139 local policy, and should be consistently used by all applications
140 installed on the system which access
142 files. Failure to do so may result in loss of e-mail data, and in
148 .IR /var/spool/mail/$LOGNAME
150 \fB$LOGNAME\fP's incoming mail folder.
155 user's archived mail messages, in his \fB$HOME\fP directory.
160 A directory in user's \fB$HOME\fP directory which is commonly used to hold
180 Thomas Roessler <roessler@does-not-exist.org>, Urs Janssen <urs@tin.org>
185 format occurred in Version 6 AT&T Unix.
187 A variant of this format was documented in \fBRFC976\fP.
projects / software / mutt-debian.git / blob