Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!cs.utexas.edu!tut.cis.ohio-state.edu!mstar!mstar.morningstar.com!bob From: bob@MorningStar.Com (Bob Sutterfield) Newsgroups: comp.mail.misc Subject: Re: mail servers Message-ID: Date: 24 Aug 90 21:11:00 GMT References: <1990Aug17.021921.1863@chinet.chi.il.us> <1594@i2ack.sublink.org> <15781@bfmny0.BFM.COM> Sender: usenet@MorningStar.COM (USENET Administrator) Reply-To: bob@MorningStar.Com (Bob Sutterfield) Organization: Morning Star Technologies Lines: 60 In-Reply-To: tneff@bfmny0.BFM.COM's message of 22 Aug 90 08:02:39 GMT In article <15781@bfmny0.BFM.COM> tneff@bfmny0.BFM.COM (Tom Neff) writes: In article bob@MorningStar.Com (Bob Sutterfield) writes: A mail-based archive server is an impolite and destructive way to distribute large amounts of information, and should be discouraged in such applications. ...a MBAS is *potentially* destructive ... This gloomy potential need not be realized. Let's hope not! A lot of people find them very useful. Responsible archive servers will establish and enforce limits ... how much a given reply path can tolerate... How might the responsible archivist establish those limits? How is the archivist to know how much additional traffic a remote nonzero-incremental-cost mail connection might tolerate? Them's heavy heuristics, son, and requires a lot of communication between the archivist and all the administrators of all the nodes along the path. Perhaps a new Pathalias field, along with link cost, describing how benevolent the site can be to strangers? foobar(NIGHTLY,REAL_NICE) However, if each node must give explicit permission for the use of their piece of the path, I suspect that they won't. If the "public service" traffic isn't explicitly authorized, it passes by the beancounters without such a ripple. * In the most general sense of the term, a mail based archive server is any server that accepts requests via mail. The actions taken to satisfy those requests need not be limited to mailing file contents back along the reply path. Good point, I've played with shell scripts that invoked whois, finger, etc. in response to uux or mail requests. But my use of "mail based" meant that the response's transport mechanism is usually mail. - [A MBAS] might respond to a mailed request by placing the file in an anonymous UUCP download directory, and mailing back L.sys and filename information to the user. This is the best suggestion yet: Let the MBAS initiate the FTP in response to a mailed request, then prepare for the UUCP (or whatever) transfer. Presumably, after the file is copied via whatever other pay-per-use means, its storage would be reaped. But is the FTP traffic then really for an authorized Internet user? If the transfer was automatically initiated on behalf of someone who's not connected, what is the legal status of the resultant traffic? Who wants to ask? Since the MBAS genie is not going to go quietly back into its bottle, it would be more constructive to suggest responsible strategies for running them -- and provide software to implement those strategies -- than to inveigh against the entire phenomenon. Indeed so! And that's the sort of discussion I hoped to start. Let's find a way to help people be responsible with other people's resources. You've suggested a couple of good starters.