Xref: utzoo news.groups:13824 news.admin:7398 news.misc:3761
Path: utzoo!attcan!utgpu!utstat!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!ulysses!smb
From: smb@ulysses.homer.nj.att.com (Steven M. Bellovin)
Newsgroups: news.groups,news.admin,news.misc
Subject: Re: Important announcement
Keywords: stuff
Message-ID: <12344@ulysses.homer.nj.att.com>
Date: 31 Oct 89 17:41:24 GMT
References: <21593@gryphon.COM> <6037@tank.uchicago.edu> <8122@asylum.SF.CA.US>
Organization: AT&T Bell Laboratories, Murray Hill
Lines: 24

I've said this before, and I may as well repeat it.  Back when we
created netnews, we knew there was no possibility of real security
short of usable, deployed, public-key cryptosystems or digital
signature schemes.  Our solution was simple:  we didn't put in any
control capabilities.  Later generations of netnews deities have
seen fit to reverse that decision, with consequences we can all see.
There is, and can be, no protection against forged articles in a
network based on UUCP and (standard) TCP/IP.

When RFC 111[345]-compliant mail systems become available,
it may be possible to change all that, if the legal minefied
can be navigated.  Until then, I suggest that you take any articles
with a grain of salt.

Btw, the optimization that the netnews software uses to avoid wasting
bandwidth -- not sending an article to a host in the Path: line --
was designed for environments where bandwidth was (a) limited
(we started with 300 bps modems...), and (b) expensive  (it was
a toll call from UNC to Duke.)  Folks who don't operate with those
restrictions may want to consider removing that code.


		--Steve Bellovin
	att!ulysses!smb, smb@ulysses.att.com