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 |
---- |