Re: subscribe

[Sean Roach <roach_s@alph.swosu.edu>]

At 08:48 PM 2/12/97 -0600, Igor Chudov wrote:
>Jim Choate wrote:
>> 
>> 
>> Hi Igor,
>> 
>> > I will not impact me negatively. I do, however, suggest very strongly
>> > that hosts should be subscribed to each other thgrough another mechanism
>> > and not majordomo, in order to prevent mail loops, header rewriting and
such.
>> 
>> Suggestions? What I had in mind was that any messages that get sent on
>> cpunks@ssz.com get sent over to algebra. One mechanism I would like to play
>> with is a 'linked list' of remailers. Remailer A sends only to B and
>> receives only from C...
>> 
>> 
>>                                A
>>                              ^   v
>>                              C < B
>
>> Then to stop loops B deletes all outgoing mail from B. Since email can be
>> forwarded from many sites the search must traverse the entire forward chain
>> killing the message if B appears as a source. I suspect a simple procmail
sort
>> can accomplish this. My next step is to brush up on my procmail. I hope to
>> have something in a couple of days that will allow you to subscribe
>> cpunks@algebra to cpunks@ssz and both ends will be filtering.
>
>Here's how I do it (it is pretty close to your proposal): 
>
>1) I delete duplicate messages (by looking up the database of
>message-IDs) right away
>2) I bounce all incoming messages to several other list servers
>3) I pipe the article to majordomo for distribution.
>
>Note that majordomo changes headers and I wuold like to feed
>other servers with UNCHANGED articles.
...
>> Another nice advantage of this architecture is that 'rings' of remailers can
>> be interconnected by simply sending output to more than one site. Might even
>> be a good stability rule, "Never have a remailer send to more than 1 machine
>> in its 'own' ring". I see no limit other than resources that would limit the
>> number of rings an individual remailer might be in.
>
>A very good point.
>
...
Something to consider.  If anyone of the distributed remailers is removed
from a ring, the messages that need to travel across that ring can no longer
do that.  This makes the loop only as strong as its most at risk remailer.
The star approach has already been seen in action, the trouble here is a
single choke point.
Full interconnectability is only feasible in a small net, but I would advise
this at first.  Check for the x-loop to see if another one got it first.  If
none, add one and send it on down the line.
A disjointed mess, if the remailers are given first access to the list,
could work quite well as long as that x-loop remained to point to who sent
the message, and the x-loop contained an unalterable message number, and the
remailers could eliminate duplications, probably based on message number.
This should work as the net grows and would only be as weak as the strongest
two connected remailers.
Sounds like the internet.