<!--
   $FML: errormail.sgml,v 1.8 2008/08/18 13:21:42 fukachan Exp $
-->


<chapter id="error.internal">
	<title>
	エラーメール解析プログラム (libexec/error)
	</title>

<para>
/usr/local/libexec/fml/error は &fml4; の 
mead (libexec/mead) に相当するエラー解析プログラムです。
</para>

<para>
$use_error_mail_analyzer_function を yes にすると、
エラー解析機能が有効になります。
ちなみに、デフォルトで $use_error_mail_analyzer_function は yes 
つまりエラー解析機能は有効になっています。
このあたりは &fml4; と異なります。
</para>

<para>
つまるところ、
&fml8; では &fml4; でよく使う機能は初めから有効になっています。
</para>


<sect1 id="error.internal.overview">
	<title>
	概要
	</title>

<para>
ＭＬ作成時に $ml-admin アドレス宛のメールは
/usr/local/libexec/fml/error を呼び出すように設定されます。
</para>

<para>
/usr/local/libexec/fml/distribute などと同様に 
/usr/local/libexec/fml/error 
は標準入力からメールを読みこみ、
それを解析し、Mail::Message オブジェクトの鎖を作ります。
そして Mail::Bounce クラスがエラー内容の解析をします。
</para>

<para>
Mail::Bounce は、エラーメールについて「どの MTA が生成したものか？」
「エラーを引き起こしたメールアドレス」「エラーの理由」を分析します。
</para>

<para>
解析結果は $error_mail_analyzer_cache_dir ディレクトリに格納されます。
</para>

<para>
一定時間以上経過すると、
$error_mail_analyzer_function がキャッシュのデータを解析し、
あるメールアドレスが存在しないように思えるか否か？を判定します。
その結果、消すべきだと判断されると、削除されます。
</para>

<para>
「一定時間」と「消すべきか？という判断」
の二つが主なチューニングパラメータになります。
</para>

</sect1>


<sect1 id="error.internal.algorithm">
	<title>
	エラー判定のアルゴリズム
	</title>

<para>
$error_mail_analyzer_function_select_list 
にある関数名が利用し得るアルゴリズムです。
デフォルトでは 
simple_count と histgram という２つのアルゴリズムが用意されており、
histgram がデフォルトです。
</para>


<sect2>
	<title>
	アルゴリズム: simple_count
	</title>

<para>
単純にエラーが返ってきたメールの総数で「削除するか否か」の決断を判定します。
</para>

<para>
単純にエラー数なので、”たまたま”受信者が設定を少しの間だけ間違えていて、
”たまたま”その日の流量が多い場合、
その受信者は「削除対象」とみなされることになります。
</para>

<para>
そういった場合にも、ようしゃなく削除してしまうのが、この方法の問題点です。
</para>

</sect2>


<sect2>
	<title>
	アルゴリズム: histgram
	</title>

<para>
エラーが連続してＮ日続いた時に限り削除を行ないます。
デフォルトでは 14 日(つまり二週)のあいだ連続してエラーの場合に、
はじめてアドレスの削除が行なわれます。
</para>

<para>
デメリット:
少なくとも一日一通は流量がないと、このアルゴリズムは動作しません。
</para>

<para>
メリット: ちょっと間違えただけの受信者が削除されることはありません。
</para>

<para>
現在のデフォルトは、このアルゴリズムです。
</para>

<para>
注意: 当然のことながら、流量が一日一通に満たないような、
まったりとしたＭＬでは、このアルゴリズムは動作しません:-)
</para>

</sect2>

</sect1>


<sect1 id="error.internal.cache">
	<title>
	データのキャッシュ
	</title>

<para>
各エラーメール(らしきもの)の解析結果は 
$error_mail_analyzer_cache_dir ディレクトリに格納されます。
</para>

<para>
現在、キャッシュの入出力には Tie::JournaledDir クラスを使っていますが、
正確には FML::Error::Cache 経由で Tie::JournaledDir 
への IO を行なっています。
</para>

<para>
FML::Error::Cache が Tie::JournaledDir の直前に位置し、
アダプタ層となっています。
すべての IO は、FML::Error::Cache が提供する 
primitive なメソッドを通じてのみ行なわなければなりません。
</para>

</sect1>


<sect1 id="error.internal.message.forward">
	<title>
	エラーメッセージをフォワードする	
	</title>

<para>
<screen>
$maintainer_recipient_maps
</screen>
を使うと、エラーメッセージの転送先を指定することができます。
デフォルトは「未定義」で、転送は行なわれません。
つまり &fml8; がエラーメールのログを残すだけです(安全ですので推奨)。
</para>

<para>
フォワードする設定をした場合は？というと、
単にエラーメールのフォワーディングが行なわれるだけです。
エラーメール( message/rfc822 )を一通だけ含む無味乾燥な 
mime/multipart がＭＬの管理者へ送信されます。
</para>

<!--
   XXX-TODO: ヘッダ情報 + そのエラーメールのアドレスの分析レポート
-->

<para>
そのうち、ヘッダ情報 + そのエラーメールのアドレスの分析レポートとか
なんか付けてやれや〜とかちょっと思っています。
</para>

<para>
リファレンス: fml-devel ML 451 あたりを参照。
</para>

</sect1>


</chapter>
