version 4, including all changes.
.
| Rev |
Author |
# |
Line |
| 1 |
perry |
1 |
mbox |
| |
|
2 |
!!!mbox |
| |
|
3 |
NAME |
| |
|
4 |
DESCRIPTION |
| |
|
5 |
LOCKING |
| |
|
6 |
FILES |
| |
|
7 |
SEE ALSO |
| |
|
8 |
AUTHOR |
| |
|
9 |
HISTORY |
| |
|
10 |
---- |
| |
|
11 |
!!NAME |
| |
|
12 |
|
| |
|
13 |
|
| |
|
14 |
mbox - Format for mail message storage. |
| |
|
15 |
!!DESCRIPTION |
| |
|
16 |
|
| |
|
17 |
|
| |
|
18 |
This document describes the format traditionally used by |
| |
|
19 |
Unix hosts to store mail messages locally. __mbox__ files |
| |
|
20 |
typically reside in the system's mail spool, under various |
| |
|
21 |
names in users' __Mail__ directories, and under the name |
| |
|
22 |
__mbox__ in users' home directories. |
| |
|
23 |
|
| |
|
24 |
|
| |
|
25 |
An __mbox__ is a text file containing an arbitrary number |
| |
|
26 |
of e-mail messages. Each message consists of a postmark, |
| |
|
27 |
followed by an e-mail message formatted according to RFC |
| |
|
28 |
822. The file format is line-oriented. Lines are separated |
| |
|
29 |
by line feed characters (ASCII 10). |
| |
|
30 |
|
| |
|
31 |
|
| |
|
32 |
A postmark line consists of the four characters |
| |
|
33 |
addrspec__ as defined in appendix |
| |
|
34 |
D of RFC 822. |
| |
|
35 |
|
| |
|
36 |
|
| |
|
37 |
The date is expected to be formatted according to the |
| |
|
38 |
following syntax (represented in the augmented Backus-Naur |
| |
|
39 |
formalism used by RFC 822): |
| |
|
40 |
|
| |
|
41 |
|
| |
|
42 |
For compatibility reasons with legacy software, two-digit years greater than or equal to 70 should be interpreted as the years 1970+, while two-digit years less than 70 should be interpreted as the years 2000-2069. |
| |
|
43 |
|
| |
|
44 |
|
| |
|
45 |
Software reading files in this format should also be |
| |
|
46 |
prepared to accept non-numeric timezone information such as |
| |
|
47 |
|
| |
|
48 |
|
| |
|
49 |
Example: |
| |
|
50 |
|
| |
|
51 |
|
| |
|
52 |
From roessler@does-not-exist.org Fri Jun 23 02:56:55 |
| |
|
53 |
2000 |
| |
|
54 |
|
| |
|
55 |
|
| |
|
56 |
In order to avoid mis-interpretation of lines in message |
| |
|
57 |
bodies which begin with the four characters |
| |
|
58 |
!!LOCKING |
| |
|
59 |
|
| |
|
60 |
|
| |
|
61 |
Since __mbox__ files are frequently accessed by multiple |
| |
|
62 |
programs in parallel, __mbox__ files should generally not |
| |
|
63 |
be accessed without locking. |
| |
|
64 |
|
| |
|
65 |
|
| |
|
66 |
Three different locking mechanisms (and combinations |
| |
|
67 |
thereof) are in general use: |
| |
|
68 |
|
| |
|
69 |
|
| |
|
70 |
fcntl(2) locking is mostly used on recent, |
| |
|
71 |
POSIX-compliant systems. Use of this locking method is, in |
| |
|
72 |
particular, advisable if __mbox__ files are accessed |
| |
|
73 |
through the Network File System (NFS), since it seems the |
| |
|
74 |
only way to reliably invalidate NFS clients' |
| |
|
75 |
caches. |
| |
|
76 |
|
| |
|
77 |
|
| |
|
78 |
flock(2) locking is mostly used on BSD-based |
| |
|
79 |
systems. |
| |
|
80 |
|
| |
|
81 |
|
| |
|
82 |
Dotlocking is used on all kinds of systems. In order to lock |
| |
|
83 |
an __mbox__ file named ''folder'', an application |
| |
|
84 |
first creates a temporary file with a unique name in the |
| |
|
85 |
directory in which the ''folder'' resides. The |
| |
|
86 |
application then tries to use the link(2) system call |
| |
|
87 |
to create a hard link named ''folder''__.lock__ to the |
| |
|
88 |
temporary file. The success of the link(2) system |
| |
|
89 |
call should be additionally verified using stat(2) |
| |
|
90 |
calls. If the link has succeeded, the mail folder is |
| |
|
91 |
considered dotlocked. The temporary file can then safely be |
| |
|
92 |
unlinked. |
| |
|
93 |
|
| |
|
94 |
|
| |
|
95 |
In order to release the lock, an application just unlinks |
| |
|
96 |
the ''folder''__.lock__ file. |
| |
|
97 |
|
| |
|
98 |
|
| |
|
99 |
If multiple methods are combined, implementors should make |
| |
|
100 |
sure to use the non-blocking variants of the fcntl(2) |
| |
|
101 |
and flock(2) sytem calls in order to avoid |
| |
|
102 |
deadlocks. |
| |
|
103 |
|
| |
|
104 |
|
| |
|
105 |
If multiple methods are combined, an __mbox__ file must |
| |
|
106 |
not be considered to have been successfully locked before |
| |
|
107 |
all individual locks were obtained. When one of the |
| |
|
108 |
individual locking methods fails, an application should |
| |
|
109 |
release all locks it acquired successfully, and restart the |
| |
|
110 |
entire locking procedure from the beginning, after a |
| |
|
111 |
suitable delay. |
| |
|
112 |
|
| |
|
113 |
|
| |
|
114 |
The locking mechanism used on a particular system is a |
| |
|
115 |
matter of local policy, and should be consistently used by |
| |
|
116 |
all applications installed on the system which access |
| |
|
117 |
__mbox__ files. Failure to do so may result in loss of |
| |
|
118 |
e-mail data, and in corrupted __mbox__ |
| |
|
119 |
files. |
| |
|
120 |
!!FILES |
| |
|
121 |
|
| |
|
122 |
|
| |
|
123 |
/var/spool/mail/''user'' |
| |
|
124 |
|
| |
|
125 |
|
| |
|
126 |
''user'''s incoming mail folder. |
| |
|
127 |
|
| |
|
128 |
|
| |
|
129 |
~''user''/mbox |
| |
|
130 |
|
| |
|
131 |
|
| |
|
132 |
''user'''s archived mail messages, in his home |
| |
|
133 |
directory. |
| |
|
134 |
|
| |
|
135 |
|
| |
|
136 |
~''user''/Mail/ |
| |
|
137 |
|
| |
|
138 |
|
| |
|
139 |
A directory in ''user'''s home directory which is |
| |
|
140 |
commonly used to hold __mbox__ format |
| |
|
141 |
folders. |
| |
|
142 |
!!SEE ALSO |
| |
|
143 |
|
| |
|
144 |
|
| |
|
145 |
elm(1), fcntl(2), flock(2), |
| |
|
146 |
link(2), local(8), mail(1), |
| 4 |
perry |
147 |
maildir(5), mail.local(8), mutt(1), |
| |
|
148 |
mutt_dotlock(1), pine(1), procmail(1), |
| 1 |
perry |
149 |
sendmail(8) |
| |
|
150 |
|
| |
|
151 |
|
| |
|
152 |
D. Crocker, Standard for the format of ARPA Internet text |
| |
|
153 |
messages, RFC 822 |
| |
|
154 |
|
| |
|
155 |
|
| |
|
156 |
M. R. Horton, UUCP mail interchange format standard, RFC |
| |
|
157 |
976 |
| |
|
158 |
!!AUTHOR |
| |
|
159 |
|
| |
|
160 |
|
| |
|
161 |
The present document was written by Thomas Roessler |
| |
|
162 |
!!HISTORY |
| |
|
163 |
|
| |
|
164 |
|
| |
|
165 |
The __mbox__ format occured in Version 6 AT |
| |
|
166 |
__ |
| |
|
167 |
|
| |
|
168 |
|
| |
|
169 |
A variant of this format was documented in RFC |
| |
|
170 |
976. |
| |
|
171 |
---- |