fml をインストールしたホスト上から投稿できない (1) &fml8; のフィルタで弾かれている可能性があります。 &fml8; のログを見て下さい。 通常 Mail コマンドは MIME ヘッダを生成しませんので、 &fml8; では不正なメールとみなされます (注: デフォルトの &fml4; では、 そこまで見てないのでエラーにならなかったはずです)。 (2) いまでは珍しいかもしれませんが、 そのＭＬサーバのホストの上からメールを送信するとエラーになることがあります。 [コマンドの例] % echo test |Mail -s test elena@example.org こういった場合には不完全な情報しか与えられていませんから、 メール全体を生成するのは Mail コマンド (もしくは Mail コマンドからメールを渡された MTA )の役目です。 ただし、こういった場合には、 From: の部分が「ユーザ」だけとか 「ユーザ＠ FQDN 」だったりします。 きちんと「ユーザ＠正しいドメイン」の形に生成されるようになっていないと &fml8; としては正当なユーザに見えません(そしてフィルタで弾かれます)。 正しいドメインがつくように MTA の設定を直して下さい。 CGI でＭＬを作成したがメールサーバに反映されていない ログを見てみて下さい。 まず WWW サーバ側に出力されているログを確認して下さい。 fml からのエラーメッセージが記録されている可能性があります。 例: /usr/local/apache/logs/error_log /usr/local/apache/logs/suexec_log /var/spool/ml 以下も確認してみましょう。 ＭＬのホームディレクトリすら出来ていないなら (そのＭＬのログファイルがありませんから) WWW サーバの処理の段階で何かがおかしいです。 まずは WWW サーバのログファイルを解析する必要があります。 中途半端にＭＬがセットアップされている (たとえばホームディレクトリはあるが、aliases に反映されていない) 場合には、fml のログファイル(例: /var/spool/ml/elena/log)を見てみて下さい。 配送に失敗した記事を自動で再送したい MTA 間での再送エラーは MTA が再配送を試みます。 Sendmail の歴史的なパラメータが五日間でしたので、 「五日間は再配送を試みる」 MTA が多いと思います。 &fml8; と MTA 間でエラーが生じた場合は &fml8; のメールキューに入り、 &fml8; が MTA への再送を試みます。 この部分の動作において &fml8; は MTA です。 再送のタイミングは次に &fml8; の何らかのプログラムが起動された時です。 そのため５分後などと確約は出来ません。 ５分ごとに再送を試みたい場合には、 cron で makefml ML flush を実行するようにしてみてください。 参考: も参照してください。 何度も同じメールが来る を参照してください。 特定の人に配送されてない気がする を参照してください。 ＭＬのメンバーでないアドレスからエラーメールがくる (1) ＭＬの受信者の中にメールを転送している人がいると、 その転送先からエラーメールが管理者へ返ってくる可能性があります。 (2) SPAM メールです。 aliases から fml に変更したら 2 通来るようになった。 バグではなく MTA の仕様上、そうなる可能性があります。 たとえば aliases が次のようになっていたとします。 elena: rudo, kenken, hitomi この aliases のＭＬに From: rudo To: elena Cc: rudo test というメールを投稿したとすると rudo には一通届くだけです。 MTA が elena ＭＬの受信者を調べ rudo 宛の重複分を取りのぞいています。 elena ＭＬを fml に変更すると、 この MTA による重複削除の効果がなくなります。 そのため、 elena ＭＬ経由 rudo 宛にとどく分と rudo 宛に直接配送されてくる分の２つになるというわけです。 flock が動かない OS なのですが？ fml8 は flock(2) 必須ですので、fml8 は動きません (たぶん動くけど動作が変になります)。 ただ、flock(2) といっても、 実際には Perl の Fnctl モジュールを使っていて、 このモジュールが OS ごとの差異を吸収しています。 また、fcntl(2) は POSIX.1 ですので、 これが動かない OS は、よほど変な OS です。 記事番号が１にもどってしまった &fml4; と異なり &fml8; では、そういうことは起こらないように作ってあります。 記事番号がアップデートできないなら、 そもそも &fml8; の処理が途中で止まるようになっています。 このロジックに抜けがあって起きる可能性があるかもしれませんが、 実際にそういう現象がおきてみないとよくわかりません。 &fml8; の耐久シミュレーションでは発生しませんでした。 きちんとロジックは動作しています。 いまのところ、大丈夫と信じています。 間違えて消してしまった！ 「間違えて makefml rmml を実行してしまった！」ということなら、 reviveml コマンドで復活できます。 「間違えて rm -fr してしまった！」ということなら、 &fml8; では自動でバックアップなどしてないので打つ手はありません。 そういったミスオペレーションの可能性を考えて、つねに バックアップ をとっておくべきです。 それが「運用」ということであります。 ディスクが足りない時に消してよいファイルは？ 安全に消せる領域は、ほとんどありません。 あえていえば、 ねんのため記録している受信メールおよび送信メールのキャッシュくらいです。 これは、各ＭＬのホームにある var/mail/incoming と var/mail/outgoing です。 また過去のログが不要であれば log を消すという案もありますが、 あまりおすすめできません。 いずれもデバッグに必要なので、あまりおすすめできません。 消す場合にも、他のマシンにバックアップをとったあと消してください。