Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!mhuxr!mhuxt!houxm!ihnp4!jpusa1!stu
From: stu@jpusa1.UUCP (Stu Heiss)
Newsgroups: net.news
Subject: Alternative talk.* implementations and censorship
Message-ID: <131@jpusa1.UUCP>
Date: Sat, 14-Jun-86 13:12:36 EDT
Article-I.D.: jpusa1.131
Posted: Sat Jun 14 13:12:36 1986
Date-Received: Tue, 17-Jun-86 21:03:40 EDT
References: <322@spdcc.UUCP> <14395@ucla-cs.ARPA> <3822@gatech.CSNET> <14347@ucbvax.BERKELEY.EDU>
Reply-To: stu@jpusa1.UUCP (Stu Heiss)
Followup-To: net.news
Organization: JPUSA - Chicago, IL
Lines: 25

Summary:
Expires:

In article <14347@ucbvax.BERKELEY.EDU> weemba@brahms.UUCP (Matthew P. Wiener) writes:
>> I propose that giving sites KILL files ala rn should be available in the
>> software even if it is not actually used for censorship.  Thus, instead
>> (Of course, site A sending news to site B first gets B's KILL file, and
>> A junks before transmitting, not B after receiving.)

This is the most reasonable scheme I've heard yet.  It would really help
all the sites as the sa at each site can tune that site's kill file any time.

>> Presumably some appropriate netiquette would evolve (quickly!), involv-
>> ing warnings and probationary periods etc.
>> in the most obvious case, backbone site E, upon seeing fill_in_the_blank
>> flame come by would send a quick note to said flamer that the second such
>> gets the sender junked netwide at E.

Also reasonable.

>> Eventually USENET will grow too big again, and another cycle of cuts will

True, but it's growth is in proportion to it's value (more information
reaching more people) and we need to implement resonable solutions to
noise/cost/flame problems.  I think the kill file is a very workable
idea.  Maybe it could get in 2.10.3 yet (hint).
-- 
Stu Heiss {ihnp4!jpusa1!stu}