[PREVIOUS CHAPTER]
[______TOC_______]
Appendix A クロスポスト
Appendix A.1 Introduction
クロスポストをした場合通常はMLすべてに流れてしまいます。ニュースシス
テムはニュースサーバがクロスポストを処理していますが、MLサーバはそれ
ぞれ独立に動いているので、統一的にクロスポストを処理することができませ
ん。
これを解決する方法は2つです。
1 サーバ間でプロトコルを決めてメールを渡しあい
どれを配送したかしないか?を制御する。
2 サーバがのMLのサーバのメンバーリストを自前で持ち
To: と Cc: を見て自分は誰の分を配送すればいいかを
独立に定める。
1 は失敗した場合サイト間をまたいで無限ループする可能性があります。2 の
いいところはこれなら最悪でも全部のMLサーバが独立に流してしまうだけで、
今と同じです。そして間違いなくループ等は発生しないというところです。
基本方針として「最悪のケースを常に想定する」ので、実装として2を選択し
ます。
メンバーリストさえあれば fml そのものでなくてもクロスポストはサポート
できます。fml でないサーバは単に流してしまうだけですが。また、あらかじ
めお互いのメンバーリストを知らないといけないので未知のML間とのクロス
ポストは作動しません。そもそも”あるアドレス”を見た時にそれがMLなの
か個人なのか見わける手段はないわけですが:-)
Appendix A.2 クロスポスト判定アルゴリズム
a, b, c というMLがあるとしましょう。
To: a, b
Cc: c
というヘッダを持つメールが来たとします。この場合ある人 aoi@chan.panic
に送る時次のようにチェックをします。
a の配送リストに aoi@chan.panic はいるか?
b の配送リストに aoi@chan.panic はいるか?
c の配送リストに aoi@chan.panic はいるか?
…これ以上あれば、以下同様のループ…
FMLは最初に見つかったMLへ配送します。例えば a にあれば a で、a には
いなくて b にいれば b です。
ポイントは、このプロセスを全部のMLサーバが独立に実行するところです。
そして
○ あるアドレスが a にいる場合
a のMLが配送し、b と c のMLは配送しない
のように作動することで、複数のMLに入っていても一つのMLだけが配送さ
れます。
なお考えてみればわかりますが、ヘッダを配送先に合わせてそれぞれ変化させ
ることはできません(効率を無視すればできなくはないだろうが)。よって、
reply の仕方は
1 各自の判断にまかせる
2 Reply-To: を最初から出す人がつけてあげる
ということになります。(個人的には、クロスポストをする以上 2 ぐらいま
で出す人が考えておくべきだとおもうのですが…)
Appendix A.3 Config.ph Configurations
クロスポストをサポートする場合は $USE_CROSSPOST をセットして下さい。
$USE_CROSSPOST = 1;
こういうのは sitedef.ph あたりで定義するといいような気がしますね。その
マシンで動いてる全部のMLでクロスポストとかできないと嬉しくないでしょ
うから
Appendix A.4 クロスポスト情報設定ファイル @CROSSPOST_CF
設定ファイルには
MailingListのAddress Directory(config.phのある場所)
=
ML Address location of config.ph
を書いておきます。クロスポストするMLのうち 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 ?)を決定して、そのファイルを配
送リストのチェックに用います。そのためにこのデータベースが必要になるわ
けです。