Appendix A.1	Introduction

クロスポストをした場合通常はＭＬすべてに流れてしまいます。ニュースシス
テムはニュースサーバがクロスポストを処理していますが、ＭＬサーバはそれ
ぞれ独立に動いているので、統一的にクロスポストを処理することができませ
ん。

これを解決する方法は２つです。

   1	サーバ間でプロトコルを決めてメールを渡しあい
	どれを配送したかしないか？を制御する。	

   2	サーバがのＭＬのサーバのメンバーリストを自前で持ち
	To: と Cc: を見て自分は誰の分を配送すればいいかを
	独立に定める。

1 は失敗した場合サイト間をまたいで無限ループする可能性があります。2 の
いいところはこれなら最悪でも全部のＭＬサーバが独立に流してしまうだけで、
今と同じです。そして間違いなくループ等は発生しないというところです。
基本方針として「最悪のケースを常に想定する」ので、実装として２を選択し
ます。

メンバーリストさえあれば fml そのものでなくてもクロスポストはサポート
できます。fml でないサーバは単に流してしまうだけですが。また、あらかじ
めお互いのメンバーリストを知らないといけないので未知のＭＬ間とのクロス
ポストは作動しません。そもそも”あるアドレス”を見た時にそれがＭＬなの
か個人なのか見わける手段はないわけですが:-)

Appendix A.2	クロスポスト判定アルゴリズム

a, b, c というＭＬがあるとしましょう。	

	To:	a, b
	Cc:	c

というヘッダを持つメールが来たとします。この場合ある人 aoi@chan.panic 
に送る時次のようにチェックをします。

	a の配送リストに aoi@chan.panic はいるか？
	b の配送リストに aoi@chan.panic はいるか？
	c の配送リストに aoi@chan.panic はいるか？	
	…これ以上あれば、以下同様のループ…

FMLは最初に見つかったＭＬへ配送します。例えば a にあれば a で、a には
いなくて b にいれば b です。

ポイントは、このプロセスを全部のＭＬサーバが独立に実行するところです。
そして

	○ あるアドレスが a にいる場合
	   a のＭＬが配送し、b と c のＭＬは配送しない

のように作動することで、複数のＭＬに入っていても一つのＭＬだけが配送さ
れます。

なお考えてみればわかりますが、ヘッダを配送先に合わせてそれぞれ変化させ
ることはできません(効率を無視すればできなくはないだろうが)。よって、
reply の仕方は

	1	各自の判断にまかせる
	2	Reply-To: を最初から出す人がつけてあげる

ということになります。（個人的には、クロスポストをする以上 ２ ぐらいま
で出す人が考えておくべきだとおもうのですが…）

Appendix A.3	Config.ph Configurations

クロスポストをサポートする場合は $USE_CROSSPOST をセットして下さい。

	$USE_CROSSPOST = 1;

こういうのは sitedef.ph あたりで定義するといいような気がしますね。その
マシンで動いてる全部のＭＬでクロスポストとかできないと嬉しくないでしょ
うから

Appendix A.4	クロスポスト情報設定ファイル @CROSSPOST_CF

設定ファイルには

	MailingListのAddress	Directory(config.phのある場所)
=
	ML Address		location of config.ph

を書いておきます。クロスポストするＭＬのうち fml でないプログラムの場
合仮想的に config.ph を書いておく必要があります。

Example: We determine judgment for elena ML by checking
/var/spool/ml/elena/config.ph and lists under /var/spool/ml/elena.

	elena@baycity.asia	/var/spool/ml/elena
	Freekick@baycity.asia	/var/spool/ml/Freekick

/var/spool/ml/elena/config.ph を見て elena@baycity.asia MLの配送リスト
はどのファイルか(e.g. actives ? members ?)を決定して、そのファイルを配
送リストのチェックに用います。そのためにこのデータベースが必要になるわ
けです。