3 maildir \- directory for incoming mail messages
7 directories of incoming mail messages.
8 It solves the reliability problems that plague
13 .SH "RELIABILITY ISSUES"
14 A machine may crash while it is delivering a message.
19 folders this means that the message will be silently truncated.
22 format, if the message is truncated in the middle of a line,
23 it will be silently joined to the next message.
24 The mail transport agent will try again later to deliver the message,
25 but it is unacceptable that a corrupted message should show up at all.
28 every message is guaranteed complete upon delivery.
30 A machine may have two programs simultaneously delivering mail
36 formats require the programs to update a single central file.
37 If the programs do not use some locking mechanism,
38 the central file will be corrupted.
44 none of which work portably and reliably.
47 no locks are ever necessary.
48 Different delivery processes never touch the same file.
50 A user may try to delete messages from his mailbox at the same
51 moment that the machine delivers a new message.
56 formats, the user's mail-reading program must know
57 what locking mechanism the mail-delivery programs use.
61 can be safely updated or deleted by a mail-reading program.
64 .B Network F\fPa\fBil\fPur\fBe System
66 presumably because the operating system vendor does not offer
68 NFS exacerbates all of the above problems.
69 Some NFS implementations don't provide
71 reliable locking mechanism.
77 if two machines deliver mail to the same user,
78 or if a user reads mail anywhere except the delivery machine,
79 the user's mail is at risk.
81 works without trouble over NFS.
82 .SH "THE MAILDIR STRUCTURE"
85 format has three subdirectories,
86 all on the same filesystem:
94 is a newly delivered mail message.
95 The modification time of the file is the delivery date of the message.
96 The message is delivered
107 an extra blank line at the end.
108 The message is normally in RFC 822 format,
114 but it could contain arbitrary binary data.
115 It might not even end with a newline.
119 are just like files in
121 The big difference is that files in
123 are no longer new mail:
124 they have been seen by the user's mail-reading program.
125 .SH "HOW A MESSAGE IS DELIVERED"
128 directory is used to ensure reliable delivery,
131 A program delivers a mail message in six steps.
140 .BR tmp/\fItime.pid.host ,
143 is the number of seconds since the beginning of 1970 GMT,
145 is the program's process ID,
151 returned anything other than ENOENT,
152 the program sleeps for two seconds, updates
156 again, a limited number of times.
159 .BR tmp/\fItime.pid.host .
162 the message to the file.
166 .BR new/\fItime.pid.host .
167 At that instant the message has been successfully delivered.
169 The delivery program is required to start a 24-hour timer before
171 .BR tmp/\fItime.pid.host ,
172 and to abort the delivery
173 if the timer expires.
174 Upon error, timeout, or normal completion,
175 the delivery program may attempt to
177 .BR tmp/\fItime.pid.host .
181 (1) as usual, checking the number of bytes returned from each
186 and checking its return value;
189 and checking its return value.
190 (Standard NFS implementations handle
193 but make up for it by abusing
195 .SH "HOW A MESSAGE IS READ"
196 A mail reader operates as follows.
200 directory for new messages.
201 Say there is a new message,
203 The reader may freely display the contents of
210 .BR cur/\fIunique:info .
212 .B http://pobox.com/~djb/proto/maildir.html
216 The reader is also expected to look through the
218 directory and to clean up any old files found there.
221 may be safely removed if it
222 has not been accessed in 36 hours.
224 It is a good idea for readers to skip all filenames in
229 Other than this, readers should not attempt to parse filenames.
230 .SH "ENVIRONMENT VARIABLES"
231 Mail readers supporting
236 as the name of the user's primary mail directory.