1つのマシンで、 メールを同じユーザーに配送する2つのプログラムが、 同時に動作しているかもしれません。 mbox や mh 形式は、 1つの中央のファイルを更新することを、 プログラムに要求します。 プログラムが何らかのロック機構を使用しない場合、 中央のファイルは、壊されてしまいます。 幾つかのの mbox や mh のロック機構がありますが、 可搬性と信頼性が高いものはありません。 対照的に、maildir では、 ロック機構は必要ありません。 異なる配送プロセスは、同じファイルを触りません。
ユーザーは、 マシンが新しいメッセージを配送するのと同じ瞬間に、 ユーザーのメール･ボックスから、 メッセージを削除しようとするかもしれません。 mbox や mh 形式では、 ユーザーのメール読み取りプログラムは、 メール配送プログラムが使用するロック機構を知っていなければなりません。 対照的に、maildir では、 どんな配送メッセージでも、 メール･読み取りプログラムによって、 安全に、更新または削除を行うことができます。
多くのサイトでは、 おそらくオペレーティング･システムのベンダーが何も提供しないために、 Sun 社の NFS (Network Failure System) を使用します。 NFS は、上記の問題のすべてを悪化させます。 幾つかの NFS の実装では、 何のロック機構も提供されません。 mbox や mh 形式では、 2つのマシンがメールを同じユーザーに配送したり、 ユーザーが配送マシンがどこであるかを省くようなメールを読み込む場合、 ユーザーのメールは、危険に遭遇しています。 maildir は、NFS 上でも、問題なく動作します。
new ディレクトリの各ファイルは、 新しく配送されたメール･メッセージです。 ファイルの変更時間は、メッセージの配送日付です。 メッセージは、 余分な UUCP 形式の From_ 行や、 >From クオーティング、 最後の余分な空行などを持たずに配送されます。 メッセージは、通常、 Return-Path 行や Delivered-To 行で始まるRFC 822 形式ですが、 任意のバイナリ･データを含むことができます。 これは、改行で終わっていないかもしれません。
cur ディレクトリのファイルは、 ちょうど new ディレクトリのファイルのようです。 大きな違いは、 cur ディレクトリのファイルは、もはや、新しいメールではありません。 これらは、 ユーザーのメール読み取りプログラムによって、 読まれています。
プログラムは、 メール･メッセージを次の6つの段階で配送します。
配送プログラムは、 tmp/time.pid.host を生成する前に24時間タイマーを始動することや、 タイマーが満了した場合に配送を中止することなどを要求されます。 エラー、タイムアウト、正常完了(normal completion) などの場合でも、 配送プログラムは、 tmp/time.pid.host を unlink() しようとするかもしれません。
NFS 書き込み(NFS-writing) とは、
メール読み取りプログラムは、 新しいメッセージに関して、 新しいディレクトリを通して吟味します。 仮に、新しいメッセージ new/unique があったとします。 読み取りプログラムは、 次のようなことを自由に行うことができます。
読み取りプログラムも、 tmp ディレクトリを通して吟味することや、 そこで発見された古いファイルをきれいにすることなどを期待されています。 36 時間以内にアクセスされていない場合、 tmp ディレクトリのファイルは、安全に取り除くことができます。
ドットで始まる new と cur ディレクトリ中のすべてのファイル名をスキップすることは、 読み取りプログラムにとって良いことです。 これとは異なり、 メールの読み取りプログラムは、 ファイル名を構文解析しようとしえはいけません。