基本的には、MTAによる再送処理が行なわれるように &fml8; が異常終了するか、 &fml8; 自身が頑張って配送処理を行なうか？のしょりしかありません。 &fml8; 自身が頑張る場合、 ログファイルやサマリファイルには欠落が出得るが、 投稿された記事の内容が失われることだけはないつもりです。 以下、記事の配送処理でファイルシステムのエラーで書き込みがうまくいかな い時、何が起こるかを説明しましょう。 &fml8; は STDIN から読みこんだメールを一度ディスクに書きます。 この書き込みが成功すれば、処理を進めます。失敗した場合、 MTA に再挑戦してもらうため、exit(EX_TEMPFAIL)でプロセスを異常終了させます。 くわしくは を参照してください。 きちんと新しい記事番号（＋１されたもの）がシークエンスファイル(seq)に 書き込めたか(ファイルに書いて、閉じて、再び開いて、再度読みこんでみる) を確認し、成功していれば、処理を進めます。 失敗していた場合、exit(EX_TEMPFAIL) で終了し、 MTA から &fml8; を再呼出してもらうようにします。 記事番号は更新してしまったので、この処理以降、exit(EX_TEMPFAIL) で終了してはいけません。 記事の書き込みはできませんが、オリジナルのメールは既にディスクに書き込 まれています。記事の方は、ヘッダ部分には色々と追加がありますが、本文は オリジナルメールのものと一緒です。そこで、キューディレクトリから 「spool/割り当てられた記事番号」ファイルへlink(2)することで、記事の内 容だけは保存するようにします。 さらに、記事ファイルにヘッダをつけてあげるコマンドが別途あるとよいでしょ うね。とりあえず、未実装ですが。 配送するべき記事をディスクに保存することができませんでしたが、 メモリ上に配送するべき記事はあるので、記事の配送処理をこころみます。 ただ、このときはメールキューに書き込めないため、もし配送過程でエラーが 生じた場合、配送は中途半端に終了となります。 配送するべき内容をキューに書き、書き込み成功後に配送処理が行なわれます。 キューに書き込めない場合、メモリ上のデータの配送を試みますが、 配送過程でエラーが生じた場合、配送は中途半端に終了となります。 トリッキーな拡張が必要ではありますが、ちゃんとキューイングをフェイクで きる仕組みが必要でしょう。たとえば、別の（のちに起動された）プロセスが、 この記事のメールキューを再生成して配送キューにいれるを試みるように拡張 するべきなのでしょう。この部分は未実装です。 outgoing キューについての詳細は、 を参照してください。