転送するメッセージ：
アダム・バックの投稿（1997年2月13日16:50 UTC）Date: Fri, 7 Feb 1997 20:11:15 GMT From: Adam Back aba@dcs.ex.ac.uk Subject: distributed mailing list architecture
Igor Chudov ichudov@algebra.com writes:
私はもっと簡単な解決を勧めたい。各サーバーを、ほかの二つか、三つのサーバーとつなぐ。このやり方はかなり堅牢で、CPUの時間や帯域をあまり食わず、実装も簡単だ。
あなたの提案している構成がどういうものかよく分からないが、私がいちばん設けやすいと考えるのは、こういうものだ。
私が思い描いているのは、漁網のような形だ。
アダム・バック主となるmajordomoを一つ置く。
この企てには、「中心の一つ」は何もあってはならない。
アダム・バック購読するときは、主となるmajordomoの申し込みのアドレスに送る。すると、そこからあなたの購読の申し込みが、無作為のメール分配器に転送される。
購読をやめるときは、主となるmajordomoの申し込みのアドレスに送る。すると、そこからあなたの申し込みが、すべてのメール分配器の申し込みのアドレスに転送される（購読の解除の流れはどのみち少ないし、主となるmajordomoで誰がどこに購読しているかを追う価値はなさそうだ）。
分配器を動かしたい人は、それぞれ（手作業で）主となるmajordomoに購読させる。
記事は主となるmajordomoに送る。するとそこから、購読者（メール分配器）に記事の写しが送られる。
メール分配器は、自分の購読者の一覧にあるアドレスにメールを送る。
（この構成は、より簡単な別案として、ジョン・ギルモアが提案した。）
簡単？ とんでもない。
リメーラーの連鎖の案なら、あと数日で動くリメーラーのネットワークを立ち上げられる。あなたの提案は、コードを書いてデバッグし、それを最後まで進めるのに何週間もかかる。
いや、このやり方は簡単でも効率的でもない。
私が漁網の形と呼ぶものは、ずっとすっきりしている。各拠点は、自分が発信元の連鎖に含まれていたメッセージを選り分けるだけでいい。procmailなら簡単で、manページの最初の例、たとえばdev/nullに捨てるやり方を見れば、procmailがしなければならないことの完璧な例が見つかる。ネットワークにほかに誰がいるかを知る必要はなく（星形の場合とは違う）、流れは、届くもの一つにつき写し一つで済む。星形のリメーラーのそれぞれからのn個の写しと、地元の購読者からの送信の分が要るのとは違う。下流のリメーラーが壊れたら、連鎖の次のリメーラーを購読するという簡単な手順を決められる。これも、ほんの数行のコードで簡単にできる……
If (bounce count of next site expires)
{
subscribe backup feed
}
If (next site returns)
{
unsubscribe backup feed
}実際の構成については：
A --> D
^ \ ^ \
/ v / v
C <-- B <-- E
^
|
v
N (mail-news gateway)繰り返すが、良い特徴がいくつかある。
-
ありふれたmajordomo／procmailの導入から、ごく簡単に立ち上げられる
-
拠点は、自分から出たメールを選り分けるだけでいい
-
ネットワークの多くの拠点ではなく、二つの拠点とだけやり取りすればいい（範囲を限ることと匿名性を支える）
-
各拠点は、大事な流れをほかの1拠点からしか受けないので、重複の流れが最小になる
-
網の端にある拠点を除き、どの拠点にも出力を送る先が二つあり、堅牢さが増す。端がつながるようにすれば（たとえばトーラス）、送り先がほかの2拠点より少ない拠点はなくなる。
-
つながりごとに、さまざまな段階の暗号や認証に対応でき、すべての参加者に一つの全体の構成への服従を強いない
-
簡単に規模を広げられる。星形はそうはいかない。中心のマシンは、連鎖の中のリメーラーの総数に応じて大きくならなければならず、ネットワークが広がれば、それは大金、それも山のような大金を意味する
-
ある連鎖の中の実際のマシンの数は柔軟だ。平面を敷き詰める図形、三角形（n=3）、正方形（n=4）、六角形（n=6）に合わせるのがいいと思う
-
この構成では、星形や中心のあるネットワークより、流れの分析や同期の洪水をしかけにくい
-
「小さな」マシンや、達人でもなく、資金も豊富でない運営者を支えられる
ジム・チョート CyberTects ravage@ssz.com