HDTenEightyP/NetNews huggingface dataset:
From: allens@yang.earlham.edu (Allen Smith)
Newsgroups: news.admin
Subject: Re: Sendsys police
Date: 12 Apr 92 07:13:44 GMT
Organization: Earlham College, Richmond, Indiana

In article <1992Apr7.194830.19599@Princeton.EDU>, vnend@phoenix.Princeton.EDU (D. W. James) writes:
> In article <FFgqiB1w164w@Bogus.COM> david@Bogus.COM (David Grant) writes:
> )dan@cubmol.bio.columbia.edu (Daniel Zabetakis) writes:
> )>     My idea is to form a Sendsys Police force. This would be a group
> )> of experienced news people who would take responsability to watch for
> )> sendsys bombs, and to forge cancels for them. Not only this, bu they 
> )> would also send e-mail to the other SP's, who would issue cancels from
> )> thier sites. This way, there would be a good chance of stopping the
> )> distribution of the control message.
>  
> )You have a good idea there.
>  
> )You could write a program that would automatically cancel the messages!
>  
> )Someone could be resposible for "allowing" a sendsys.  The person that
> )desired a sendsys would mail to an address like sendsys@the.sendsys.police
> )and would ask for a sendsys not to be canceled.
>  
> )The program would mail them back at their address, and ask for confirmation.
>  
> )Then the person could issue his sendsys without getting it canceled.
>  
> )That will solve the problem EASY!
> )->David Grant  (David@Bogus.COM) via CyberSpace Cafe (501) 525-1681 14.4k DS
> 
> Set up a robot mailer on uunet.
> 

> 	Writing the code: I don't think that this requires any great effort.
> 			I suspect that even I could do it, but if you want it
> 			soon you'd best find someone with more time.
> 
> 	Sendsys takes more time:	I don't think that this is an 
> 			unacceptable price to pay to stop this problem.
> 
> 	Impact on individual systems, other than UUNET, is not major.  And
> 	supporting USENET is what UUNET is for.

	However, it makes USENET even more dependent upon UUNET than it is 
already. UUNET is nice, but...
> 
	The idea is nice, but couldn't each individual "backbone" site do 
it alone? And send out an authorization message to other sites so, when 
they receive a sendsys from that address, it gets let through (whether 
first or second)? UUNET isn't really absolutely required, although it 
admittedly would be a very good one for a backbone site for this.
	-Allen
From: friedman@col.hp.com (John Friedman)
Subject: Starting alt groups?
Date: Tue, 7 Apr 1992 15:58:29 GMT
Organization: HP Colorado Springs Division

What is the proper way to start an alt group?

John Friedman
friedman@col.hp.com

Xref: sparky news.admin:3521 news.software.b:1947
From: henry@zoo.toronto.edu (Henry Spencer)
Newsgroups: news.admin,news.software.b
Subject: Re: A different approach to sendsys.
Date: 10 Apr 92 15:56:26 GMT
Organization: U of Toronto Zoology

In article <1992Apr9.145537.11708@julian.uwo.ca> reggers@julian.uwo.ca (Reg Quinton) writes:
>... who are these few people who need the data? If we knew who needed
>this ... then
>we could mail them our sys file...

How do they get data from sites whose sysadmins aren't alert and cooperative?
Network mapping, unlike arbitron and the like, is not primarily a statistical
exercise; you would really like 100% responses.
-- 
GCC 2.0 is to C as SVR4 is to Unix.     | Henry Spencer @ U of Toronto Zoology
                             -Dick Dunn |  henry@zoo.toronto.edu  utzoo!henry
From: david@Bogus.COM (David Grant)
Newsgroups: news.admin
Subject: Re: Sendsys police
Date: Sat, 04 Apr 92 18:55:38 CST
Organization: Bogus.COM -- Public Access Network Services

dan@cubmol.bio.columbia.edu (Daniel Zabetakis) writes:

>     My idea is to form a Sendsys Police force. This would be a group
> of experienced news people who would take responsability to watch for
> sendsys bombs, and to forge cancels for them. Not only this, bu they 
> would also send e-mail to the other SP's, who would issue cancels from
> thier sites. This way, there would be a good chance of stopping the
> distribution of the control message.

You have a good idea there.

You could write a program that would automatically cancel the messages!

Someone could be resposible for "allowing" a sendsys.  The person that
desired a sendsys would mail to an address like sendsys@the.sendsys.police
and would ask for a sendsys not to be canceled.

The program would mail them back at their address, and ask for confirmation.

Then the person could issue his sendsys without getting it canceled.

That will solve the problem EASY!

;-)


->David Grant  (David@Bogus.COM) via CyberSpace Cafe (501) 525-1681 14.4k DS
Newsgroups: news.admin
From: kevin@rotag.mi.org (Kevin Darcy)
Subject: Re: News requires redesign and re-implementation
Organization: Who, me???
Distribution: na
Date: Mon, 6 Apr 92 04:30:53 GMT

>Robert Withrow:
>>``news'' needs to be redesigned with security and authority as *primary*
>>objectives.

Maybe true, but if you're referring to the recent "wars", wasn't that a 
matter of IMPLEMENTATION (promiscuous NNTP ports, as I understand it), rather
than DESIGN? Due to ignorance/incompetence and/or simple human error, no 
large-scale system can be PERFECTLY secure at all times.

In the case of promiscuous NNTP ports, perhaps automated "rovers" could be
written which would ferret these out BEFORE the bad guys find them and use
them (?). I don't know. I'm not internet-connected. But it seems that this 
problem should be somewhat preventable/correctable.

In article <BM5qLo.HG8@world.std.com> geoff@world.std.com (Geoff Collyer) responds:
>I think you are overreacting, but if you can find us a fast, unpatented,
>unbroken, exportable, reversible, public-key cryptosystem, we'll be
>delighted to use it.

Are you being perhaps too picky, Geoff? Within limits, I personally wouldn't 
mind ditching the "fast" criterion, if I get rid of these "wars" and assorted 
foolishness. And "fast" is a very relative term, given the rate at which CPU 
technology is advancing these days anyway (I'm assuming of course that most of 
the performance problems with crypt routines relates to CPU-crunching (?)).
Besides, compared to B News, C News gives me all this extra performance I 
don't know what to do with; why not put it to a higher use? :-)

In any case, perhaps a distinction could be made, on an article level, between 
"trusted" transactions and non-trusted ones. Big bad machines with resources
to spare would generate only "trusted" articles, and try to verify everything 
they process. Joe Schmo's little '386 running a toy Whatevernix OS, on the 
other hand, might not have the resources to burn, so he only verifies control 
messages, if anything at all. And everything Joe _generates_ might be 
"untrusted", unless there was a way he could arrange for a more resourceful 
upstream site to authenticate his articles "by proxy". Newsreaders et alia 
would need to be tweaked to flag the "untrusted" articles visually, so that 
the user is at least alerted to the possibility of forgery as they are 
reading. Something to think about, at least...

"Unbroken" would be nice, of course, but I think ANYTHING would be an 
improvement right now over essentially NO transaction-level security at all.

As far as the rest of the criteria, I couldn't tell ya, not being a crypt 
expert...

								- Kevin
From: moconnor@ef2007.efhd.ford.com (Mike O'Connor)
Newsgroups: news.admin
Subject: Re: Automatic disclaimers on outbound postings from a corporation
Date: 16 Apr 92 15:16:44 GMT
Article-I.D.: ef2007.1992Apr16.151644.3590
Reply-To: Mike O'Connor <mjo@fmsrl7.srl.ford.com>
Organization: "Fordz"
X-Disclaimer: Not an official spokesperson for Ford Motor Co.

:>i'm looking for the best way to automatically incorporate a corporate
:>disclaimer into all news articles that are posted from within an
:>organization.
:>...
:>can anyone recommend a good procedure?
:
:  Yes.  I recommend you forget the whole idea.
:
:  Anybody reading usenet should already be assuming that postings are the
:individual poster's rantings and ravings.  Do you have to rub it in?

Unless, of course, someone *wants* to quote one out of context in a 
non-Usenet forum.  But I'm sure THAT never happens...  :)

Since various newsreaders have different means via which they post
news, your best bet probably would be to implement a "Disclaimer:" header
on a per-newsreader basis.  

						...Mike

 
-- 
 Mike O'Connor                     |  Ford Motor Company, USA
 Applications Systems Analyst      |  CPD P&MS ECC Core Software
 Phone #:  +1 (313) 390-4008       |  P.O. Box 2053, ECC MD-7
 Fax #:    +1 (313) 845-0576       |  Dearborn, MI  48121-2053
Newsgroups: news.admin
From: rjc@oghma.ocunix.on.ca (Robert J Carter)
Subject: Re: (yet another) sendsys alternative
Organization: Oghma Systems, Ottawa, Ontario, Canada
Date: Thu, 09 Apr 1992 05:38:17 GMT

In article <1992Apr7.133221.19856@unhtel.unh.edu> paul@unhtel.unh.edu (Paul S. Sawyer) writes:
>In article <9917095@tronix.SignalPath.on.ca> louis@tronix.SignalPath.on.ca (Louis Bertrand) writes:
>>
>>I propose that sendsys and senduuname be permanently disabled
>>and replaced it with a regular publishing of the sys files 
>>in a new newsgroup.  If the volume is too large, the sysfile 
>>newsgroup could be made regional (e.g. ont.sysfiles, tx.sysfiles).
>> ...
>
>That might be a good idea;  why not just put it into the maps as "#U"
>lines?  Many would be something like:
>
>...
>#U	ME:all
>#U	myfeed:all/all,!local:f:
>...

I'm not sure that thats a very good idea - I suspect that the maps are
difficult enough to maintain, and I that the sysfiles get fiddled with
fairly more often. I think the newsgroup (regional) may be a better
idea. My god, who in their right mind would WANT to look at uunet's
sysfile? :-)
-- 
|=================================================================| ttfn!
| Robert J Carter           Oghma Systems         Ottawa, Ontario | @     @
| Phone: (613) 565-2840                    rjc@oghma.ocunix.on.ca |   * *
|=================================================================|  \___/
Newsgroups: news.admin
From: schnoebe@convex.com (Eric Schnoebelen)
Subject: Re: A sys file standard (was: Any rational reason for sendsys?)
Followup-To: news.admin
Organization: USENET news support, CONVEX Computer Corp, Richardson, Tx. USA
Date: Mon, 6 Apr 1992 16:25:16 GMT
X-Disclaimer: This message was written by a user at CONVEX Computer
              Corp. The opinions expressed are those of the user and
              not necessarily those of CONVEX.

chip@chinacat.unicom.com (Chip Rosenthal) writes:
- In article <1992Apr5.184940.21845@news.eng.convex.com>
- 	schnoebe@convex.com (Eric Schnoebelen) writes:
- >	Thoughts?
- 
- Yes.  Please bring back the B news `Responding-System' header.

I was trying to not have to bring back the 'Responding-System:' header,
since the information about both ends of the link is in each entry.

I do agree that the 'Responding-System:' header is easier to parse and
less ambigous in determining who responded than any of the other
methods I have seen in my sendsys replies.  This includes C news'
(sometimes) 'Subject:' header.

In case anyone hadn't noticed, I am aiming for something that is
easily machine parsable.  That means I don't have to do nearly as much
work to analyze the results. I can let the computer do the repetitive
stuff (since they are good at that.)

-- 
Eric Schnoebelen		eric@cirr.com		schnoebe@convex.com
Watson's Law:
	The reliability of machinery is inversely proportional to the
	    number and significance of any persons watching it.
Newsgroups: news.admin
From: mem@mv.mv.com (Mark E. Mallett)
Subject: Re: (yet another) sendsys alternative
Organization: MV Communications, Inc.
Date: Tue, 07 Apr 1992 22:58:19 GMT

In article <1992Apr7.133221.19856@unhtel.unh.edu> paul@unhtel.unh.edu (Paul S. Sawyer) writes:
>That might be a good idea;  why not just put it into the maps as "#U"
>lines?  Many would be something like:
>
>...
>#U	ME:all
>#U	myfeed:all/all,!local:f:

Not only would this only catch sites that are included in the uucp
maps, but it would be prone to all of the problems that the uucp maps
already have, only probably more so.  Among these problems are that
the maps are perpetually out of date, and even when up-to-date reflect
only whatever the submitter chooses to represent.

-mm-

-- 
Mark E. Mallett  MV Communications, Inc./ PO Box 4963/ Manchester NH/ 03108
Bus. Phone: 603 429 2223    Home: 603 424 8129     BIX: mmallett
Internet: mem@mv.MV.COM  ( uucp: ...{decvax|harvard}!mv!mem )
Looking for news and mail in southern NH / northern MA?  Try MV!
From: reynhout@cs.uri.edu
Newsgroups: news.admin
Subject: Getting address from server name [Q]
Date: 7 Apr 92 08:04:04 GMT
Distribution: na
Organization: University of Rhode Island, Computer Science Dept.


   Is there a standard way to discern a machine's address, given its entry
in the path header of an article?

   My server is called "server.cs.uri.edu", making it very easy.  Others 
are not so simple, and some are incomprehensible.  I don't recall registering
my server name when I decided what to call it, so perhaps this is merely 
wishful thinking.

   I can, of course, work backwards -- contact my feed (or the furthest-back
which I can figure out the address for) and ask them to identify a given 
server name, then repeat this procedure until I get the address I'm looking
for.  Is this the ONLY way?

   Thanks,
   Andrew <reynhout@cs.uri.edu>
From: david@Bogus.COM (David Grant)
Newsgroups: news.admin
Subject: Re: sendsys bombers: you can run, but you can't hide
Date: Sun, 05 Apr 92 06:33:55 CDT
Organization: Bogus.COM -- Public Access Network Services

tinsel@uiuc.edu (Thomas Aaron Insel) writes:

> Moderation is useless.  If you can forge a sendsys, you can get past 
> moderation without thinking twice.

Have a program cancel unauthorized sendsys messages.  Can forge a Approval,
but you can't get into a daemon that is running.  I am sure that we can
make it plenty secure.



->David Grant  (David@Bogus.COM) via CyberSpace Cafe (501) 525-1681 14.4k DS
From: gritton@altar.caedm.byu.edu (Jamie Gritton)
Newsgroups: news.admin
Subject: UUNET speaks concerning usa.*
Date: 6 Apr 92 15:19:23 GMT
Article-I.D.: altar.GRITTON.92Apr6101923
Reply-To: gritton@byu.edu
Organization: Brigham Young University, Provo UT USA


   I got word from David Lawrence concerning the question of UUNET carrying
the usa.* hiearchy.
   He says UUNET will "inevitably" carry it.  I take this to mean that UUNET
will carry it, but only because they carry everything.  I certainly can't
construe that as a "go-ahead from UUNET."
   In fact, David tells me he isn't happy with the way usa.* has been
"created." To quote him: "_Please_ work within that framework toward
getting the hierarchy going."
   This suggestion does have merit. On the other hand, I don't want to
abandon my efforts. I've just sorted through my sendsys results, and sent
mail to those sites I felt would have the most trouble with usa being a
hiearchy. I am still in favor of a vote for this hiearchy, although I see
it more as a validation of an already existing fledgeling hiearchy.
--
James Gritton - gritton@byu.edu - I disclaim
Newsgroups: news.admin
From: fitz@wang.com (Tom Fitzgerald)
Subject: Re: sendsys bombers: you can run, but you can't hide
Organization: Wang Labs, Lowell MA, USA
Date: Mon, 06 Apr 92 07:26:01 GMT

> In article <bly8b9.5ji@wang.com> fitz@wang.com (Tom Fitzgerald) writes:

> >- Modifications to nntp and rnews to stamp incoming batches with the
> >  UUCP login name or IP address of the machine that the batch came from.

henry@zoo.toronto.edu (Henry Spencer) writes:

> Doable for NNTP, I would guess, although some work would be needed to
> define a transmission path for this information.  Rnews, unfortunately,
> is at the mercy of UUCP in this area, and many old UUCPs simply do not
> tell you which site the stuff came from.

Old UUCPs are indeed a problem - but it appears that most of the recent
sendsyses were injected at NNTP ports, so this really would help.  And it's
not like this scheme has to be working at all sites for it to help - as
long as there are enough points to be sure where the injection actually
occurred.

As far as defining a transmission path, storing the information in
$NEWSLIB/log is a good first step; there are lots of ways to get the
information back out of the logfile to interested parties, and they'd all
work fine, even the manual method.

---
Tom Fitzgerald   Wang Labs        fitz@wang.com
1-508-967-5278   Lowell MA, USA   ...!uunet!wang!fitz
Newsgroups: news.admin,news.software.b
From: henry@zoo.toronto.edu (Henry Spencer)
Subject: Re: A different approach to sendsys.
Date: Wed, 8 Apr 1992 22:53:29 GMT
Organization: U of Toronto Zoology

In article <1992Apr8.172944.2165@julian.uwo.ca> reggers@julian.uwo.ca (Reg Quinton) writes:
>I've been thinking about Felix's proposal and believe we can accomplish the
>same thing in an easier fashion:
>
>1. If you want to flood the net with sys files why not have everyone post
>   a monthly article in news.config that gives their sys file. This can
>   be at the system managers discretion...

The trouble is, most legitimate sendsyses do *not* flood the net with
sys files -- they send them only locally within some subregion.

>2. If someone wants to know the network topology why not just scan all
>   the Path: records that you have on your system and leave everyone else
>   alone? Surely all the information is already on your system.

No; this won't tell you about links that those articles didn't traverse.
Even if you assume that all machines post something regularly -- not true --
there is extensive redundancy in the feed topology and you cannot draw an
even vaguely complete map this way.
-- 
GCC 2.0 is to C as SVR4 is to Unix.     | Henry Spencer @ U of Toronto Zoology
                             -Dick Dunn |  henry@zoo.toronto.edu  utzoo!henry
From: sean@sdg.dra.com
Newsgroups: news.admin
Subject: Re: Automatic disclaimers on outbound postings from a corporation
Date: 17 Apr 92 11:10:25 CDT
Organization: Data Research Associates, St. Louis MO

In article <rdippold.703482860@cancun>, rdippold@cancun.qualcomm.com (Ron Dippold) writes:
> Right.  And most public access sites aren't very concerned, either,
> even when their name is on the message.  However, if I use Qualcomm
> letterheads, that's not the same thing as one with a "Hilton Hotels,
> call 1-800-xxx-xxxx for reservations".
> 
> The analogy is just fatally flawed.  The post office has no control
> whatsoever over what you send unless it's illegal.  They can't refuse
> to let you write letters.

The difference between using a public access site (how do you "know" the site
it was posted from was a public access site anyway?), or Hilton Hotel
letterhead versus Qualcomm letterhead isn't the choice of stationary. Rather it
comes from the agency relationship created by your employment.   Even if
Qualcomm had all of its employees use only plain paper with no corporate
letterhead, they could still be liable for their employees' actions.

Even if you only posted from public access sites, as an employee you could
still create a liability for your employer.  Just post something about the
next quarters' finacial results before their filing, and see what the SEC
thinks about that, even if you do it from some public access site.
-- 
Sean Donelan, Data Research Associates, Inc, St. Louis, MO
Domain: sean@sdg.dra.com, Voice: (Work) +1 314-432-1100
Xref: sparky news.admin:3446 news.groups:9657
From: allens@yang.earlham.edu (Allen Smith)
Newsgroups: news.admin,news.groups
Subject: Re: More sendsys and my new scripts
Date: 6 Apr 92 19:09:00 GMT
Article-I.D.: yang.1992Apr6.140900.16779
Organization: Earlham College, Richmond, Indiana

In article <1992Apr2.044322.4108@druid.uucp>, darcy@druid.uucp (D'Arcy J.M. Cain) writes:
>>from: darcy@druid.uucp (D'Arcy J.M. Cain)
> Xref: mips news.software.b:11314 news.admin:21658
> 
> Well I finished my control scripts as I mentioned (I'll post them in a
> separate message) and while testing them I happened to catch this one:
> 
>>From: gritton@alaska.caedm.byu.edu (Jamie Gritton)
>>Newsgroups: news.admin.ctl
>>Subject: sendsys
>>Message-ID: <GRITTON.92Mar31092916@alaska.caedm.byu.edu>
>>Date: 31 Mar 92 16:29:16 GMT
>>Control: sendsys
>>Sender: news@caedm.byu.edu
>>Reply-To: sendsys@shamu.caedm.byu.edu
>>Organization: Brigham Young University, Provo UT USA
>>Lines: 5
>>Approved: gritton@byu.edu
>>
>>This is for real.
>>I want to see just who's sending the usa.config posts to mailing lists.
>>I set up a program to handle this; I know what I'm doing.
>>--
>>James Gritton - gritton@byu.edu - I disclaim
> 
> So now I wonder if it is just a slightly more clever forgery.  Even if
> it isn't a forgery I have to question the last statement.  Even if
> somone issues a sendsys for themself on purpose does that mean that
> it's OK to start shunting megabytes around the net for their benefit?
> Perhaps but I don't think so, at least not in all cases.
> 
> Due to the recent sendsys bombings many sites are modifying the way
> they deal with sendsys control messages.  Personally I now look at
> every sendsys (actually almost every control message) and decide if
> it os OK to execute.  I plan to honour any reasonable looking sendsys
> if it originates locally but I don't think it is safe to blindly
> honour net wide ones like the above.
> 
> Perhaps if you have a legitimate need of a net wide sendsys you should
> post to news.admin announcing that you will be posting one in a day
> or two.  This gives others a chance to post objections if it is either
> inappropriate or a forgery.  Then sysadmins can deal with it in whatever
> manner they have elected to on their own system.  Comments?

	The control message in question is in order to trace who has 
mailing list gates set with the distribution usa admitted. Before a usa.* 
hierarchy could be properly done, this would need to be deleted. He did 
post about it- on news.groups, where the discussion is being done. Before 
concluding that such a message is a forgery/foolish/whatever, try mailing 
the person (you didn't mention doing so, so I'm (perhaps incorrectly) 
assuming that you haven't).
> 
	-Allen