/usr/local/libexec/fml/error は &fml4; の mead (libexec/mead) に相当するエラー解析プログラムです。 $use_error_mail_analyzer_function を yes にすると、 エラー解析機能が有効になります。 ちなみに、デフォルトで $use_error_mail_analyzer_function は yes つまりエラー解析機能は有効になっています。 このあたりは &fml4; と異なります。 つまるところ、 &fml8; では &fml4; でよく使う機能は初めから有効になっています。 ＭＬ作成時に $ml-admin アドレス宛のメールは /usr/local/libexec/fml/error を呼び出すように設定されます。 /usr/local/libexec/fml/distribute などと同様に /usr/local/libexec/fml/error は標準入力からメールを読みこみ、 それを解析し、Mail::Message オブジェクトの鎖を作ります。 そして Mail::Bounce クラスがエラー内容の解析をします。 Mail::Bounce は、エラーメールについて「どの MTA が生成したものか？」 「エラーを引き起こしたメールアドレス」「エラーの理由」を分析します。 解析結果は $error_mail_analyzer_cache_dir ディレクトリに格納されます。 一定時間以上経過すると、 $error_mail_analyzer_function がキャッシュのデータを解析し、 あるメールアドレスが存在しないように思えるか否か？を判定します。 その結果、消すべきだと判断されると、削除されます。 「一定時間」と「消すべきか？という判断」 の二つが主なチューニングパラメータになります。 $error_mail_analyzer_function_select_list にある関数名が利用し得るアルゴリズムです。 デフォルトでは simple_count と histgram という２つのアルゴリズムが用意されており、 histgram がデフォルトです。 単純にエラーが返ってきたメールの総数で「削除するか否か」の決断を判定します。 単純にエラー数なので、”たまたま”受信者が設定を少しの間だけ間違えていて、 ”たまたま”その日の流量が多い場合、 その受信者は「削除対象」とみなされることになります。 そういった場合にも、ようしゃなく削除してしまうのが、この方法の問題点です。 エラーが連続してＮ日続いた時に限り削除を行ないます。 デフォルトでは 14 日(つまり二週)のあいだ連続してエラーの場合に、 はじめてアドレスの削除が行なわれます。 デメリット: 少なくとも一日一通は流量がないと、このアルゴリズムは動作しません。 メリット: ちょっと間違えただけの受信者が削除されることはありません。 現在のデフォルトは、このアルゴリズムです。 注意: 当然のことながら、流量が一日一通に満たないような、 まったりとしたＭＬでは、このアルゴリズムは動作しません:-) 各エラーメール(らしきもの)の解析結果は $error_mail_analyzer_cache_dir ディレクトリに格納されます。 現在、キャッシュの入出力には Tie::JournaledDir クラスを使っていますが、 正確には FML::Error::Cache 経由で Tie::JournaledDir への IO を行なっています。 FML::Error::Cache が Tie::JournaledDir の直前に位置し、 アダプタ層となっています。 すべての IO は、FML::Error::Cache が提供する primitive なメソッドを通じてのみ行なわなければなりません。 $maintainer_recipient_maps を使うと、エラーメッセージの転送先を指定することができます。 デフォルトは「未定義」で、転送は行なわれません。 つまり &fml8; がエラーメールのログを残すだけです(安全ですので推奨)。 フォワードする設定をした場合は？というと、 単にエラーメールのフォワーディングが行なわれるだけです。 エラーメール( message/rfc822 )を一通だけ含む無味乾燥な mime/multipart がＭＬの管理者へ送信されます。 そのうち、ヘッダ情報 + そのエラーメールのアドレスの分析レポートとか なんか付けてやれや〜とかちょっと思っています。 リファレンス: fml-devel ML 451 あたりを参照。