lyndon@cs.athabascau.ca (Lyndon Nerenberg) (05/16/91)
[ Sorry, but NN trashed the original group list. I didn't think ont.general was a very good place to post to from Alberta, so I faked it ... ] tower@buitc.bu.edu (Leonard (Len) H. Tower Jr.) writes: >You might talk to the folks who run the BITFTP gateway, and see if >they could slow down the rate at which they mail a large request. What we should really do is pressure the BITFTP sites to only honour requests from machines that are in the BITNET RSCS node tables. This would restrict the traffic to the NJE leased lines, which are usage insensitive as far as charging goes. This doesn't solve the problem of BITFTP requests plugging up the RSCS queues at the BITNET hub sites, but that's not what we're discussing :-) There are enough machines out there providing anonymous UUCP access to software archives that use of BITFTP from UUCP sites is no longer justifiable. If you want the software, you can bloody well pay your own phone line charges to pick it up. Maybe you didn't want that software so badly after all ... As an example of making the user pay, about a year ago I decided to stop carrying the comp.binaries groups here at AU. There were a number of reasons for doing this: potential viruses and cost in modem time and disk space being two of them. When we informed the user community of the change there was no end of howling and bitching from the PC users who were used to getting all this "free software" from the net. We pointed out that it was not "free," as the university was paying line charges (both leased lines and LD dialup) to transfer these files, most of which were of little or no use to the operation of the university. In essence, we said that if they *really* *wanted* the software, they could dial up any number of BBS's (from home on their dime) and pick it up that way. After a few weeks the complaints stopped coming in. From what I've heard (or not heard), not providing the binary groups has not resulted in the end of the world as these people know it, so I assume that they either don't need the code that badly, or they have made alternate arrangements. Yes, a few of them starting poking the various mail archive servers, however the traffic flow was not substantial (very few people even knew about them), and has trickled off to almost nothing. My conclusion is that they got tired of having to take a proactive stance to get the stuff and lost interest in it when we stopped handing it to them on a platter. What you describe is an unfortunate side effect of running a large mail relay site. I've run a few of them in my time and I've dealt with this problem before. I find the best way to deal with it is to make it very clear to the system administrators of any site you provide e-mail connectivity to just what sort of traffic you are willing to forward. Let them know that any violation of those guidelines could (and probably will) result in the termination of their feed. Place the responsibility upon them to police their own user community. In nearly every case, they will do so. If you see things happening that you don't like, contact the system administrator at the site that's responsible, and let them know what's happening right away! It is very important to keep the lines of communication open. If the person at the other end feels like they are being dumped on arbitrarily, they will be much less sympathetic towards *your* problem. (And it *is* your problem - you set yourself up in the business of providing e-mail service in the first place.) The bottom line is, be fair to others - they probably don't know they screwed up. Respect the other site administrators - they probably don't like these things any more than you do, and will do their best to deal with it as soon as they are made aware of the problem. Don't change the rules in the middle of the game - make it *very* *clear* at the *outset* what sorts of traffic and volumes you are willing to accept, and make the continued provision of the feed contingent on their following those guidelines. How you deal with abuses is up to you. I prefer a solution that doesn't penalize users who did not contribute to the problem. However you accomplish that is going to be very site dependent. I wish you luck ... [ BTW - most of our problems went away when we got onto the Internet. I now run all my non-local UUCP connections over TCP. Keep pushing for that ONET link :-) ] -- Lyndon Nerenberg VE6BBM / Computing Services / Athabasca University atha!cs.athabascau.ca!lyndon || lyndon@cs.athabascau.ca Packet: ve6bbm@ve6bbm.ab.can.noam The only thing open about OSF is their mouth. --Chuck Musciano
peter@ficc.ferranti.com (Peter da Silva) (05/16/91)
In article <1705@aupair.cs.athabascau.ca> lyndon@cs.athabascau.ca (Lyndon Nerenberg) writes: > There are enough machines out there providing anonymous UUCP access > to software archives that use of BITFTP from UUCP sites is no longer > justifiable. If you want the software, you can bloody well pay your own > phone line charges to pick it up. Maybe you didn't want that software so > badly after all ... A lot of the time it's not the phone line charges (which we're likely paying for to get to UUNET or UUPSI or whatever anyway) it's the prospect of debugging yet another chat script. That is to say, we bloody well already pay our own bleeding phone charges. The real solution would be for UUNET and other sites to provide their own remote FTP type facilities to their cusomers. I've brought this up before, and been poohpoohed, but so far as I can tell it would solve most of these sorts of problems. And sites could do their own choking. Why is it that Princeton in the strange world of BITNET is the only place that thinks to do this? Hell, for UUNET it'd be pure profit. -- Peter da Silva; Ferranti International Controls Corporation; +1 713 274 5180; Sugar Land, TX 77487-5012; `-_-' "Have you hugged your wolf, today?"
les@chinet.chi.il.us (Leslie Mikesell) (05/16/91)
In article <1705@aupair.cs.athabascau.ca> lyndon@cs.athabascau.ca (Lyndon Nerenberg) writes: >>You might talk to the folks who run the BITFTP gateway, and see if >>they could slow down the rate at which they mail a large request. Yes, it's a little awesome for us serial line folks to see the FTP transcripts showing a 500K file received within the same second it was requested, and dumped into mail in 5 or 6 seconds. >What we should really do is pressure the BITFTP sites to only honour >requests from machines that are in the BITNET RSCS node tables. But what about uunet customers? >There are enough machines out there providing anonymous UUCP access >to software archives that use of BITFTP from UUCP sites is no longer >justifiable. Enough??? Since when has software become a matter of quantity? If you can't get to the item you want, who cares how many others there are? For example, how else can you get the in-progress work on kermit5a other than ftp'ing from the kermit/sw directory on watsun.cc.columbia.edu? >If you want the software, you can bloody well pay your own >phone line charges to pick it up. Maybe you didn't want that software so >badly after all ... Isn't paying your own way supposed to be what uunet is all about? >[ BTW - most of our problems went away when we got onto the Internet. > I now run all my non-local UUCP connections over TCP. Keep pushing > for that ONET link :-) ] At what volume does this become practical? Les Mikesell
schoff@uu.psi.com (Martin Schoffstall) (05/16/91)
Peter, Most service providers are interesting in guaranteeing a level of service reliability every hour of every day of the year, across all of their customers. No one every succeeds, but that is the goal, if you get 95%+ you survive, if you get 99.9%+ you thrive. Mailing files is one of those things that doesn't work very reliably, due to many factors from error correction, to memory utilization, to installed base of mailer constraits, to resource constraints, etc. I've seen this debate for a decade, and I'm sure it continue forever. To transfer files we use a tried and true mechanism: FTP. Why does BITNET do this? Because it fits in their model, part of their model (from my biased perspective) is an acceptance of unreliability. Where else do you have dozens of huge organizations cut off for days, whole countries similiarly, nuked disk spools continually, and have to use non-standard MTU's to dump it (really tunnel it) through the Internet. [But it has those great applications! Or so they believe.....] Marty ---------------- In article <OCCB4F3@xds13.ferranti.com> peter@ficc.ferranti.com (Peter da Silva) writes: > >The real solution would be for UUNET and other sites to provide their own >remote FTP type facilities to their cusomers. I've brought this up before, >and been poohpoohed, but so far as I can tell it would solve most of these >sorts of problems. And sites could do their own choking. Why is it that >Princeton in the strange world of BITNET is the only place that thinks to >do this? >
jim@crom2.uucp (James P. H. Fuller) (05/16/91)
lyndon@cs.athabascau.ca (Lyndon Nerenberg) writes: > There are enough machines out there providing anonymous UUCP access > to software archives that use of BITFTP from UUCP sites is no longer > justifiable. If you want the software, you can bloody well pay your own > phone line charges to pick it up. Maybe you didn't want that software so > badly after all ... True for system-related software. There are tons of places to get EMACS and Perl and pathalias and so on. But emphatically *not* true for other kinds of software -- in particular scientific software, which is one of the principal justifications of the Internet, and BITNET, and BITFTP. Let's say your site gets a bionet.all feed and you want to keep your copy of the GenBank genetic sequence database current on a daily basis using bionet.molbio.genbank.updates. The New York University soft- ware to do this is available by anon-ftp from goober.phri.nyu.edu. Can you think of an anon-uucp source for this? (LONG pause while the man thinks....) The same is true for an IMMENSE amount of other scientific software written by researchers and put up for anon-ftp and only anon-ftp. If you shut down BITFTP you're screwing all the legitimate users along with the abusers, including every small college and small research enter- prise in the Known Universe which can't afford a leased-line Internet connection. There must be a more intelligent way! I say THANK YOU to the folks at Princeton through whose good offices outsiders are permit- ted to use BITFTP. (P.S. Thanks also to DEC for the same thing. BITFTP isn't the only ftp-to-mail gateway, as you may know. And thanks to the archive-server sites, though they're a drop in the bucket compared to what's available via ftp.) > As an example of making the user pay, about a year ago I decided to > stop carrying the comp.binaries groups here at AU. There were a number > of reasons for doing this: potential viruses and cost in modem time and > disk space being two of them. When we informed the user community of > the change there was no end of howling and bitching from the PC users > who were used to getting all this "free software" from the net. We > pointed out that it was not "free," as the university was paying > line charges (both leased lines and LD dialup) to transfer these > files, most of which were of little or no use to the operation of > the university. In essence, we said that if they *really* *wanted* > the software, they could dial up any number of BBS's (from home on > their dime) and pick it up that way. That's a very good example of cutting down nonessential use with- out at the same time stomping on the researchers you're there to support. There's a major difference between students who want games for their PCs and faculty members who want software for gene sequencing or amino acid analysis or Michaelis-Menten enzyme kinetics or numerical taxonomy or gas chromatography or carbon-14 dating of palaeolithic strata or photoelectric photometry of variable stars or.... I'll bet there are people at your own university who have used BITFTP to obtain software of the latter types. After all, you weren't always on the Internet. merce@iguana.uucp (Jim Mercer) writes: > how much of a net.lobby do we have to do to get pucc.princeton.edu to shut > down BITFTP? > > can we at least get them to limit responses to systems that can be verified > as being on BITNET (as i assume the system was intended)? I absolutely agree that there's no reason to try to get EMACS through the mail. But the list of things that are both big enough to cause trouble and easily available from uunet and other big anon-uucp sites is short enough (e.g. the GNU collection, TeX, X windows et al.) to write into a compact list. In fact, why not just *use* uunet's filelist? If you want to lobby Princeton for something, ask them to check all the GET commands against such a list, and bounce disallowed requests. Shutting down BITFTP would solve your mail prob- lems, but so would shutting down iguana. There are more thoughtful solutions than either of these! lyndon@cs.athabascau.ca (Lyndon Nerenberg) continues: > What you describe is an unfortunate side effect of running a large > mail relay site. I've run a few of them in my time and I've dealt > with this problem before. I find the best way to deal with it is > to make it very clear to the system administrators of any site you > provide e-mail connectivity to just what sort of traffic you are > willing to forward. Let them know that any violation of those guidelines > could (and probably will) result in the termination of their feed. Amen! This is a problem that site admins are qualified to solve (and paid to solve) on a site-by-site basis, by configuring mailers and by having explicit arrangements with the sites to which they connect, *before* the problem becomes a problem. Every single admin I have ever met has wanted to be considered clever; just saying "Nuke Princeton" is not the way to impress people with your skill in your job. > How you deal with abuses is up to you. I prefer a solution that > doesn't penalize users who did not contribute to the problem. Double amen! Those of us stuck out here in uucp-only-land thank you! ------------------------------------- ----------------------------------------- crom2 Athens GA Public Access Unix | i486 AT, 16mb RAM, 600mb online | AT&T Unix System V release 3.2 Molecular Biology | Tbit PEP 19200bps V.32 V.42/V.42bis Population Biology | Ecological Modeling | Admin: James P. H. Fuller Bionet/Usenet/cnews/nn | {jim,root}%crom2@nstar.rn.com ------------------------------------- -----------------------------------------
brian@ucsd.Edu (Brian Kantor) (05/16/91)
I believe we're doing it the right way; I have (under construction) a mail-based archive server which not only limits volume, but will audit the address requesting the data. The qualifications are that we will send a large file in response to a request from someone if their return address is 1 hop from us (i.e., a direct connection) 1 hop from uunet (i.e., requester picks up the tab) on the internet everyone else gets a 'sorry charlie' response for files over the limit, which I'm currently inclined to make around a few Kb, like three or four. When we have it running and debugged, the server code will be available for anonymous ftp. Don't hold your breath. - Brian
jim@crom2.uucp (James P. H. Fuller) (05/17/91)
schoff@uu.psi.com (Martin Schoffstall) writes: > Most service providers are interesting in guaranteeing a level of service > reliability every hour of every day of the year, across all of their > customers. No one every succeeds, but that is the goal, if you get > 95%+ you survive, if you get 99.9%+ you thrive. > > Mailing files is one of those things that doesn't work very reliably, > due to many factors from error correction, to memory utilization, to > installed base of mailer constraits, to resource constraints, etc. > I've seen this debate for a decade, and I'm sure it continue forever. > >To transfer files we use a tried and true mechanism: FTP. Can you say "0% reliability?" FTP to uucp-only sites doesn't work AT ALL. What's your advice for them? "Screw you, Jack, I've got mine?" Harrumph! Jim ------------------------------------- ----------------------------------------- crom2 Athens GA Public Access Unix | i486 AT, 16mb RAM, 600mb online | AT&T Unix System V release 3.2 Molecular Biology | Tbit PEP 19200bps V.32 V.42/V.42bis Population Biology | Ecological Modeling | Admin: James P. H. Fuller Bionet/Usenet/cnews/nn | {jim,root}%crom2@nstar.rn.com ------------------------------------- -----------------------------------------
lyndon@cs.athabascau.ca (Lyndon Nerenberg) (05/17/91)
les@chinet.chi.il.us (Leslie Mikesell) writes: >But what about uunet customers? They can send mail to ftp-requesdt@uunet.uu.net and request the files be transfered for them. Why uunet doesn't provide a service like BITFTP for DIRECTLY connected customers is beyond me. -- Lyndon Nerenberg VE6BBM / Computing Services / Athabasca University atha!cs.athabascau.ca!lyndon || lyndon@cs.athabascau.ca Packet: ve6bbm@ve6mc.ab.can.noam The only thing open about OSF is their mouth. --Chuck Musciano
lyndon@cs.athabascau.ca (Lyndon Nerenberg) (05/17/91)
jim@crom2.uucp (James P. H. Fuller) writes: >There's a major difference between students who want games for their PCs >and faculty members who want software for gene sequencing or amino acid >analysis or Michaelis-Menten enzyme kinetics or numerical taxonomy or gas >chromatography or carbon-14 dating of palaeolithic strata or photoelectric >photometry of variable stars or.... I'll bet there are people at your own >university who have used BITFTP to obtain software of the latter types. >After all, you weren't always on the Internet. Har dee har har har har har! It was the PhD's who wanted games for their Amigas :-) -- Lyndon Nerenberg VE6BBM / Computing Services / Athabasca University atha!cs.athabascau.ca!lyndon || lyndon@cs.athabascau.ca Packet: ve6bbm@ve6mc.ab.can.noam The only thing open about OSF is their mouth. --Chuck Musciano
emv@ox.com (Ed Vielmetti) (05/17/91)
In article <1991May16.154958.13266@crom2.uucp> jim@crom2.uucp (James P. H. Fuller) writes:
True for system-related software. There are tons of places to get
EMACS and Perl and pathalias and so on. But emphatically *not* true for
other kinds of software -- in particular scientific software, which is
one of the principal justifications of the Internet, and BITNET, and
BITFTP.
i'm working on a snappy interface to comp.archives so that you can
browse and search through software reviews, decide what it is that you
want, and have the latest and greatest version of it fetched back for
you. the target audience is people who do not have a dedicated leased
line to the internet but who could afford uunet-style rates to do part
time dialup IP. it'll have an interface to something like "archie" as
well.
details as they are worked out.
not free like BITFTP, but it should be much better.
--Edkarl.kleinpaste@osc.edu (05/17/91)
jim@crom2.uucp writes: >To transfer files we use a tried and true mechanism: FTP. Can you say "0% reliability?" FTP to uucp-only sites doesn't work AT ALL. What's your advice for them? "Screw you, Jack, I've got mine?" Harrumph! Oh, blow it out your ear. It was positively routine when I ran osu-cis' archives to get mail from people saying, "I've been told that there's a package called bletch.tar.Z living on foo.bar.baz:pub/extraneous and I really need to pick it up. Could you possibly make it available on osu-cis?" I only turned down requests like that about 5 times in 5 years. Most of the time was when we were in serious disc space trouble; once, someone wanted a 50Mbyte package. But there's currently ~200Mbytes on osu-cis mostly unused. My advice to UUCP-only sites: Go ask for help before screaming about the inability of any of the existing mechanisms to do the job for you. Harrumph, yourself. Tone down your attitude. [As for whether the current maintainers of osu-cis' archives still work that way, I don't know. Load on its seemingly ever-dwindling staff may have made it an untenable proposition.]
les@chinet.chi.il.us (Leslie Mikesell) (05/17/91)
In article <34032@ucsd.Edu> brian@ucsd.Edu (Brian Kantor) writes: >I believe we're doing it the right way; I have (under construction) a >mail-based archive server which not only limits volume, but will audit >the address requesting the data. >The qualifications are that we will send a large file in response to a request >from someone if their return address is > 1 hop from us (i.e., a direct connection) > 1 hop from uunet (i.e., requester picks up the tab) > on the internet Hmmm... Are you looking at the From: header or the envelope-from? Everything I send through uunet goes through three internal machines via uucp. One on my desktop, a local gateway, and a machine in our Washington DC office where it's a local call to uunet. The From: line will just have fb.com, which doesn't tell you much. Am I going to have to rip out the uucp From_ line on the from the DC machine to uunet? Les Mikesell les@chinet.chi.il.us
peter@ficc.ferranti.com (Peter da Silva) (05/18/91)
In article <1991May16.145758.6817@uu.psi.com> schoff@uu.psi.com (Martin Schoffstall) writes: > Mailing files is one of those things that doesn't work very reliably, Why does remote ftp have to have anything to do with mail? An interface like this would be great for those of us with no SLIP capability: "uux uupsi!rftp sprite.berkeley.edu:~ftp/mx.tar.Z (ficc!~/from-uupsi)" I realise this might hurt your flat rate pricing, so you could restrict rftp to people with DCS or LAN-DCS access, or impose a surcharge, or something. UUNET would be able to do this without pain. And it would strongly discourage people from using mail for file transfer. > To transfer files we use a tried and true mechanism: FTP. Which requires interactive access to the Internet. When one is using an intermittent transport mechanism (dial-ups and modems) a store-and-forward technique is much more useful. With a smart enough UUCP on your end, you could even avoid staging the file at all in most cases. -- Peter da Silva; Ferranti International Controls Corporation; +1 713 274 5180; Sugar Land, TX 77487-5012; `-_-' "Have you hugged your wolf, today?"
jbuck@janus.Berkeley.EDU (Joe Buck) (05/18/91)
In article <1991May16.224338.286@crom2.uucp> jim@crom2.uucp (James P. H. Fuller) writes: >>To transfer files we use a tried and true mechanism: FTP. > > Can you say "0% reliability?" FTP to uucp-only sites doesn't work >AT ALL. What's your advice for them? "Screw you, Jack, I've got mine?" >Harrumph! No, the answer for UUCP-only sites who can't anonymous FTP is to anonymous UUCP. There are a number of sites that provide this service; osu-cis, uunet (in addition to providing the service for regular customers, they have a 900 number so anyone can use the service). The answer to reducing the long distance charges is for UUCP-only folks to set up more archive sites and more anonymous UUCP sites. For those that wail, "but it costs money if I do that", it costs money whether you place the call yourself or pass the bill onto someone else. Sites on the Internet are paying for their access. Sites with long-distance UUCP connections are paying phone bills and (in some cases) access charges. No one's saying "Screw you, Jack"; you have alternatives. They are simply saying that they won't subsidize your large file transfers. -- -- Joe Buck jbuck@janus.berkeley.edu {uunet,ucbvax}!janus.berkeley.edu!jbuck
schoff@uu.psi.com (Martin Schoffstall) (05/18/91)
In article <1991May16.224338.286@crom2.uucp> jim@crom2.uucp (James P. H. Fuller) writes: > > Can you say "0% reliability?" FTP to uucp-only sites doesn't work >AT ALL. What's your advice for them? "Screw you, Jack, I've got mine?" >Harrumph! > Jim I'm REAL familiar with the fact that UUCP sites don't have FTP access, but you can't be critical if you have PORCHE tastes on a YUGO budget. Marty
schoff@uu.psi.com (Martin Schoffstall) (05/18/91)
In article <MDDB7-A@xds13.ferranti.com> peter@ficc.ferranti.com (Peter da Silva) writes: > >"uux uupsi!rftp sprite.berkeley.edu:~ftp/mx.tar.Z (ficc!~/from-uupsi)" > >I realise this might hurt your flat rate pricing, so you could restrict Pricing is not an issue at all, actually, the only problems have been (a) admin overhead of people oriented things, (b) breaking mailers. >rftp to people with DCS or LAN-DCS access, or impose a surcharge, or >something. HOST-DCS and LAN-DCS already support anon ftp and tcp/ip so this isn't an issue. >Which requires interactive access to the Internet. When one is using an >intermittent transport mechanism (dial-ups and modems) a store-and-forward >technique is much more useful. With a smart enough UUCP on your end, you >could even avoid staging the file at all in most cases. Obviously you can have dialup Internet access today. What your really looking for is "batched XFtp" with last hop polling control. Which is even more general than your rftp. But lets go back to your rftp, what you need to do is create the code and make it work across 2 dozen platforms and it will be as explosive as CNews use. So get the community to work the spec and write the code and we're off, minimum portability would be bsd4.x sunos sysv xenix ice's Uaccess uupc aix Your biggest and most controversial design decision will be to decide if this works one hop or multiple hops. Marty
jbuck@janus.Berkeley.EDU (Joe Buck) (05/18/91)
In article <1991May17.202220.9531@uu.psi.com> schoff@uu.psi.com (Martin Schoffstall) writes: >In article <MDDB7-A@xds13.ferranti.com> peter@ficc.ferranti.com (Peter da Silva) writes: >> >>"uux uupsi!rftp sprite.berkeley.edu:~ftp/mx.tar.Z (ficc!~/from-uupsi)" >> >... >But lets go back to your rftp, what you need to do is create the >code and make it work across 2 dozen platforms and it will be >as explosive as CNews use. So get the community to work the >spec and write the code and we're off, minimum portability would be Oh, rot. The proposed program would only need to work on host "uupsi" and would be simple to write. Your customers would only need to issue a uux command, and that could be bundled into a symbol shell script. If you wanted to implement it easily, you could grab the "expect" package, which has been posted on the net, and have it run the anonymous FTP session. You'd have to write almost no code. >Your biggest and most controversial design decision will be to >decide if this works one hop or multiple hops. No controversy at all. One hop only. Otherwise it would be another way for UUCP sites to get a free lunch. The "rftp" command would retrieve the first argument by anonymous FTP and then transfer the result by uucp to the second argument. By building on top of "expect", a competent programmer could get it working without much trouble. -- -- Joe Buck jbuck@janus.berkeley.edu {uunet,ucbvax}!janus.berkeley.edu!jbuck
merce@iguana.uucp (Jim Mercer) (05/18/91)
In article <1991May16.154958.13266@crom2.uucp> jim@crom2.uucp (James P. H. Fuller) writes: >If you shut down BITFTP you're screwing all the legitimate users along >with the abusers, including every small college and small research enter- >prise in the Known Universe which can't afford a leased-line Internet >connection. There must be a more intelligent way! I say THANK YOU to >the folks at Princeton through whose good offices outsiders are permit- >ted to use BITFTP. do i hear a thanks for those sites between Princeton and the small sites who store and forward your valuable data? maybe if these small sites can't afford the line charges, they are out of their league? (the is more meant for the non-academic sites) >merce@iguana.uucp (Jim Mercer) writes: >> how much of a net.lobby do we have to do to get pucc.princeton.edu to shut >> down BITFTP? >> >> can we at least get them to limit responses to systems that can be verified >> as being on BITNET (as i assume the system was intended)? > >...... Shutting down BITFTP would solve your mail prob- >lems, but so would shutting down iguana. There are more thoughtful solutions >than either of these! shutting down iguana would not cause any grief, but that's not the system i was talking about (see top of original article). shutting down lsuc.on.ca would affect ~75 systems directly and an unknown number of downstream sites. lsuc is a mail hub for Toronto, Ontario, Canada. also, lsuc.on.ca is not the only (or first) site to complain about MBAS abuse. MBAS's are a plague on the email network. email is not for file transfers. it wasn't designed for it (hence uuencode, 40-64K chunks, etc) and most systems budget disk space and modem time according to what they figure will be normal mail loads. i don't care if someone orders EMACS source or bionet info, if it is uuencoded and chunked, it is an abuse of the email network. >....... Every single admin I have ever >met has wanted to be considered clever; just saying "Nuke Princeton" is >not the way to impress people with your skill in your job. i'm not trying to be clever. i don't say nuke princeton either. my suggestion that they limit BITFTP to BITNET (as i assume it was intended) has been taken to heart, if i am to believe some of the posts and email i have received recently. -- [ Jim Mercer work: jim@lsuc.on.ca home: merce@iguana.uucp +1 519 570-3467 ] [ "Anarchists Unite!" - seen spray painted on a wall ]
merce@iguana.uucp (Jim Mercer) (05/18/91)
In article <1991May16.224338.286@crom2.uucp> jim@crom2.uucp (James P. H. Fuller) writes: >schoff@uu.psi.com (Martin Schoffstall) writes: >>To transfer files we use a tried and true mechanism: FTP. > > Can you say "0% reliability?" FTP to uucp-only sites doesn't work >AT ALL. What's your advice for them? "Screw you, Jack, I've got mine?" >Harrumph! agreed, FTP is an direct internet only facility. why not use the next best thing in your case? direct uucp connection. To which joe.user@site.uucp (Joe User) MIGHT SAY: > that costs money. too fucking bad, better your money/time/disk than mine. -- [ Jim Mercer work: jim@lsuc.on.ca home: merce@iguana.uucp +1 519 570-3467 ] [ "Anarchists Unite!" - seen spray painted on a wall ]
peter@ficc.ferranti.com (Peter da Silva) (05/18/91)
In article <1991May17.200736.8137@uu.psi.com> schoff@uu.psi.com (Martin Schoffstall) writes: > I'm REAL familiar with the fact that UUCP sites don't have FTP access, > but you can't be critical if you have PORCHE tastes on a YUGO budget. Marty. I'm willing to rent a Porsche. You have one, but you only rent to people that already have one. -- Peter da Silva; Ferranti International Controls Corporation; +1 713 274 5180; Sugar Land, TX 77487-5012; `-_-' "Have you hugged your wolf, today?"
peter@ficc.ferranti.com (Peter da Silva) (05/18/91)
In article <1991May17.202220.9531@uu.psi.com> schoff@uu.psi.com (Martin Schoffstall) writes: > In article <MDDB7-A@xds13.ferranti.com> peter@ficc.ferranti.com (Peter da Silva) writes: > >"uux uupsi!rftp sprite.berkeley.edu:~ftp/mx.tar.Z (ficc!~/from-uupsi)" > >I realise this might hurt your flat rate pricing, so you could restrict > Pricing is not an issue at all, actually, the only problems have been > (a) admin overhead of people oriented things, (b) breaking mailers. Neither of which are a problem with my hypothetical rftp program. > >rftp to people with DCS or LAN-DCS access, or impose a surcharge, or > >something. > HOST-DCS and LAN-DCS already support anon ftp and tcp/ip so this > isn't an issue. Sure it is. Anonymous FTP isn't available through UUCP. Some of us out here don't have hardware that easily supports SLIP. In fact most UNIX boxes out here are running V.3.2 and below (in fact, most are running Xenix) and while KA9Q is great it's not well integrated. Of course we could get KA9Q on a PC and do it, but either way it requires we have a human at this end monitoring the transfer in real-time. That's the basic problem with FTP, and why mailservers are so popular. > Obviously you can have dialup Internet access today. Obviously. Does DCS come with a V.4 license? Rhetorical question, of course. > But lets go back to your rftp, what you need to do is create the > code and make it work across 2 dozen platforms and it will be > as explosive as CNews use. Nah, it just needs 2 platforms: what you're running, and what UUNET's running. > Your biggest and most controversial design decision will be to > decide if this works one hop or multiple hops. Since it's to come back via UUCP, it's limited to one hop by the UUCP design unless you want to add spooling. Besides, multihop is a SMOP once the basic system works: echo 'site1\!site2\!site3' > /usr/spool/rftp/C.whatever uux uupsi!rftp site:file /usr/spool/rftp/D.whatever Then have a daemon that looks for a matched pair of C. and D. files (and the D. file will appear when the request gets back) and pass it on to the next site. It would build a new C. file and ship both that and the D. file to the next site. Voila! Reliable uucp forwarding for files. But that's peripheral. The real problem is the lack of a reasonbaly reliable batch FTP via UUCP. That's the thing that's making a niche for mailservers. Scratch that niche and the whole mailserver problem goes away. -- Peter da Silva; Ferranti International Controls Corporation; +1 713 274 5180; Sugar Land, TX 77487-5012; `-_-' "Have you hugged your wolf, today?"
peter@ficc.ferranti.com (Peter da Silva) (05/18/91)
In article <1991May17.183950.25550@agate.berkeley.edu> jbuck@janus.Berkeley.EDU (Joe Buck) writes: > The answer to reducing > the long distance charges is for UUCP-only folks to set up more archive > sites and more anonymous UUCP sites. For those that wail, "but it costs > money if I do that", it costs money whether you place the call yourself > or pass the bill onto someone else. It's not the money, it's the inconvenience. You have to: 1) find a site with the package that allows anon-uucp. a) Alternatively, ask some kind soul to ftp it to such a site. 2) Establish a chat script for that particular site. This is an interactive, often labor intensive, and tedious business. a) You have to be the system operator to do this. This adds to the load for system admins. 3) Poll the site. Instead you could do this: 1) send a message to a mailserver. 2) Unpack the file from a bunch of little messages into an archive. Ideally, you should be able to do this: 1) Queue a uux for that RFTP request. > No one's saying "Screw you, Jack"; you have alternatives. They are simply > saying that they won't subsidize your large file transfers. Fine. They gonna pay me the overtime for all the stuff that our developers want or need, that I have to set up and poll myself because of the problems establishing a reliable UUCP connection? -- Peter da Silva; Ferranti International Controls Corporation; +1 713 274 5180; Sugar Land, TX 77487-5012; `-_-' "Have you hugged your wolf, today?"
mpd@anomaly.sbs.com (Michael P. Deignan) (05/18/91)
<asbestos underwear on> jbuck@janus.Berkeley.EDU (Joe Buck) writes: >No, the answer for UUCP-only sites who can't anonymous FTP is to anonymous >UUCP. There are a number of sites that provide this service; osu-cis, >uunet (in addition to providing the service for regular customers, they >have a 900 number so anyone can use the service). The problem here is that many UUCP-only sites are looking for a free ride. <asbestos underwear off> MD -- -- Michael P. Deignan / Since I *OWN* SBS.COM, -- Domain: mpd@anomaly.sbs.com / These Opinions Generally -- UUCP: ...!uunet!rayssd!anomaly!mpd / Represent The Opinions Of -- Telebit: +1 401 455 0347 / My Company...
les@chinet.chi.il.us (Leslie Mikesell) (05/19/91)
In article <1991May17.183950.25550@agate.berkeley.edu> jbuck@janus.Berkeley.EDU (Joe Buck) writes: >No, the answer for UUCP-only sites who can't anonymous FTP is to anonymous >UUCP. There are a number of sites that provide this service; osu-cis, >uunet (in addition to providing the service for regular customers, they >have a 900 number so anyone can use the service). Not the same at all. Has anyone measured the average time between when a posting appears in comp.archives about some program's availability and the time it appears in an anon-uucp site? In most cases it's somewhere approaching infinity... And, when they do show up there, how do you find out about it? Are you supposed to uucp the huge ls-lR.Z file daily? Plus, there's the problem that the ftp'able version is always kept up-to-date on its home site but the uucp-able copies may have dozens of bugs that can cost the users months of work to fix. Don't take this as a flame towards the maintainers of the anon-uucp sites. I do use and appreciate their services, but it's an impossible job. >The answer to reducing >the long distance charges is for UUCP-only folks to set up more archive >sites and more anonymous UUCP sites. For those that wail, "but it costs >money if I do that", it costs money whether you place the call yourself >or pass the bill onto someone else. I don't have a problem with the phone charges or uunet-style access fees. $100/month will shovel a heck of a lot of source code through uunet. I'm not asking anyone but my organization to pay this, and I can point out to them that it's cheaper and faster than paying someone to write similar code at the typical 30 lines per day rate. The LD charges are the least of the problem anyway. Unless you have an archive site that is a local no-cost call (and around the Chicago area there is hardly any such thing as a local call) it probably won't cost any more to call a different state across the country. >No one's saying "Screw you, Jack"; you have alternatives. They are simply >saying that they won't subsidize your large file transfers. And what's the alternative that lets me get a current directory listing from an ftp site that has offered to make something available? Uunet has someone that handles ftp requests, but I would feel uncomfortable asking a person to check a remote directory on a weekly basis. It didn't bother me at all to make such requests through bitftp. Obviously, the answer is to automate the requests at the uucp <-> internet gateways like uunet and other sites that want to offer similar services but the existing software doesn't provide any real support for queuing files for anon-uucp, or mail to accounts that haven't been pre-arranged. Maybe uunet could put up a kermit server login on the 900 number and build in a little magic so a remote GET host:path would find anything in the world. For their subscribers, a mail server that only queued for direct connections would work, or a uux'able command. Les Mikesell les@chinet.chi.il.us
les@chinet.chi.il.us (Leslie Mikesell) (05/19/91)
In article <1991May17.200736.8137@uu.psi.com> schoff@uu.psi.com (Martin Schoffstall) writes: >I'm REAL familiar with the fact that UUCP sites don't have FTP access, >but you can't be critical if you have PORCHE tastes on a YUGO budget. I'd guess that most FTP users just want the files delivered and don't really care about the vehicle. In fact, given a choice, most people would probably prefer uucp's automatic queuing mechanism if the remote site can't be reached on the first attempt. Les Mikesell les@chinet.chi.il.us
les@chinet.chi.il.us (Leslie Mikesell) (05/19/91)
In article <1991May17.202220.9531@uu.psi.com> schoff@uu.psi.com (Martin Schoffstall) writes: >>"uux uupsi!rftp sprite.berkeley.edu:~ftp/mx.tar.Z (ficc!~/from-uupsi)" >But lets go back to your rftp, what you need to do is create the >code and make it work across 2 dozen platforms and it will be >as explosive as CNews use. So get the community to work the >spec and write the code and we're off, minimum portability would be Build it into a kermit server and it will work on many dozens of platforms that already exist and you can make it interactive for doing directories down mutliple levels, etc. Just make REMOTE DIR understand host:dir, and GET should understand host:file. >bsd4.x >sunos >sysv >xenix >ice's Uaccess >uupc >aix >Your biggest and most controversial design decision will be to >decide if this works one hop or multiple hops. Making a mail server that runs on your machines would handle all of this, since these users obviously already have mail access. Just make the server check a list of allowable paths before sending it down multiple hops. If they are your subscribers you should be able to get this information easily. No changes to anything else would be necessary. Les Mikesell les@chinet.chi.il.us
gsh7w@astsun.astro.Virginia.EDU (Greg Hennessy) (05/19/91)
Peter da Silva writes:
# 1) find a site with the package that allows anon-uucp.
UUnet is always there. And they have 1-900 numbers.
--
-Greg Hennessy, University of Virginia
USPS Mail: Astronomy Department, Charlottesville, VA 22903-2475 USA
Internet: gsh7w@virginia.edu
UUCP: ...!uunet!virginia!gsh7wmerce@iguana.uucp (Jim Mercer) (05/19/91)
In article <30EBM2G@xds13.ferranti.com> peter@ficc.ferranti.com (Peter da Silva) writes: >In article <1991May17.183950.25550@agate.berkeley.edu> jbuck@janus.Berkeley.EDU (Joe Buck) writes: >> No one's saying "Screw you, Jack"; you have alternatives. They are simply >> saying that they won't subsidize your large file transfers. > >Fine. They gonna pay me the overtime for all the stuff that our developers >want or need, that I have to set up and poll myself because of the problems >establishing a reliable UUCP connection? can you say "a cost of doing business" ? i thought you could. -- [ Jim Mercer work: jim@lsuc.on.ca home: merce@iguana.uucp +1 519 570-3467 ] [ "Anarchists Unite!" - seen spray painted on a wall ]
emv@ox.com (Ed Vielmetti) (05/19/91)
In article <1991May18.172953.3331@chinet.chi.il.us> les@chinet.chi.il.us (Leslie Mikesell) writes: >No, the answer for UUCP-only sites who can't anonymous FTP is to anonymous >UUCP. There are a number of sites that provide this service; osu-cis, >uunet (in addition to providing the service for regular customers, they >have a 900 number so anyone can use the service). Not the same at all. Has anyone measured the average time between when a posting appears in comp.archives about some program's availability and the time it appears in an anon-uucp site? In most cases it's somewhere approaching infinity... I am prepared to say that MSEN will be able to ensure that as soon as a posting appears on comp.archives, it will be available through the MSEN archive service. (How can I promise this? Easy. I run comp.archives.) Since no one has infinite disk storages, there may be time lags for huge packages or for things announced a long time ago; getting the details right of the caching and refreshing of these packages to make sure there's not stale old stuff on disk is this summer's work. The key information (5000+ descriptions and locations of software packages) have already been taken care of. Our prices should be competetive with other internet service providers, and I think we can do a good job. For more information contact info@msen.com. --Ed Edward Vielmetti, vice president for research, MSEN Inc. emv@msen.com
wgb@balkan.TNT.COM (William G. Bunton) (05/19/91)
In article <1991May18.190644.27513@murdoch.acc.Virginia.EDU> gsh7w@astsun.astro.Virginia.EDU (Greg Hennessy) writes: >Peter da Silva writes: ># 1) find a site with the package that allows anon-uucp. > >UUnet is always there. And they have 1-900 numbers. And some of us, due to children or other excuses, have to have 900 blocking in place. -- William G. Bunton | Since it's documented to be possible, I wgb@balkan.tnt.com | can't call it a bug. Tools & Techniques, Austin, TX | -- Bill Davidsen
peter@ficc.ferranti.com (Peter da Silva) (05/19/91)
In article <1991May18.190644.27513@murdoch.acc.Virginia.EDU> gsh7w@astsun.astro.Virginia.EDU (Greg Hennessy) writes: > Peter da Silva writes: > # 1) find a site with the package that allows anon-uucp. > UUnet is always there. And they have 1-900 numbers. And they have 1-800 numbers for subscribers, too. I've been there. They don't have everything. They don't have TCL. They don't have MX or TX. They only have STDWIN because Guido put it in the amiga-sources area while I was the moderator of amiga-sources. That's the problem. Partly because of FTP, nobody has everything. And because of FTP, they shouldn't have to. So you get back to 1) find a site with the package that allows anon-uucp. -- Peter da Silva; Ferranti International Controls Corporation; +1 713 274 5180; Sugar Land, TX 77487-5012; `-_-' "Have you hugged your wolf, today?"
peter@ficc.ferranti.com (Peter da Silva) (05/19/91)
In article <1991May18.203937.9443@iguana.uucp> merce@iguana.uucp (Jim Mercer) writes: > >Fine. They gonna pay me the overtime for all the stuff that our developers > >want or need, that I have to set up and poll myself because of the problems > >establishing a reliable UUCP connection? > can you say "a cost of doing business" ? Can you say "we're already paying for the mail service, why should we pay twice?"? Can you say "We're quite willing to pay for access to a reliable service for things like this... in fact we're already doing so."? I can. Because we are. Playing games with half a dozen archive servers, trying to talk one of them into copying software in, and so on... it's insane. I get better service from the public library system, and I'm not a paying customer (except in as much as I'm a taxpayer... but let's not get into tax subsidized networks). -- Peter da Silva; Ferranti International Controls Corporation; +1 713 274 5180; Sugar Land, TX 77487-5012; `-_-' "Have you hugged your wolf, today?"
6sigma2@polari.UUCP (Brian Matthews) (05/20/91)
In article <1991May18.190644.27513@murdoch.acc.Virginia.EDU> gsh7w@astsun.astro.Virginia.EDU (Greg Hennessy) writes: |UUnet is always there. And they have 1-900 numbers. In my experience, uunet has about half of the things I would like to ftp, and most of those are available at numerous other anon UUCP archives. It's that other half that aren't available at at any anon UUCP site that made bitftp useful. -- Brian L. Matthews blm@6sceng.UUCP
daniel@island.COM (Daniel Smith "innovation, not litigation...") (05/20/91)
In <lyndon.674434989@aupair.cs.athabascau.ca> lyndon@cs.athabascau.ca (Lyndon Nerenberg) writes: > les@chinet.chi.il.us (Leslie Mikesell) writes: > >But what about uunet customers? > They can send mail to ftp-requesdt@uunet.uu.net and request the files > be transfered for them. Why uunet doesn't provide a service like BITFTP > for DIRECTLY connected customers is beyond me. I wholeheartily second this! I've used ftp-request on occasion, but the turnaround time isn't as good as what would be possible if uunet were to run the type of software that Princeton is using. This would be a great service to uunet Customers[*], and would free up their staff (hi Lorelei!) a bit for other things. Daniel [*] heck, they'd be making money off of it, can't think of reason why they would not want to do this. -- daniel@island.com Daniel Smith, Island Graphics, (415) 491 0765 x 250(w) daniel@world.std.com 4000 CivicCenterDrive SanRafael MarinCounty CA 94903 dansmith@well.sf.ca.us Fax: 491 0402 Disclaimer: Hey, I wrote it, not IG! falling/yes I'm falling/and she keeps calling/me back again - IJSaF, Beatles
mrm@sceard.Sceard.COM (M.R.Murphy) (05/20/91)
In article <1991May18.043931.7094@iguana.uucp> merce@iguana.uucp (Jim Mercer) writes: [...] > >too fucking bad, better your money/time/disk than mine. > >-- >[ Jim Mercer work: jim@lsuc.on.ca home: merce@iguana.uucp +1 519 570-3467 ] >[ "Anarchists Unite!" - seen spray painted on a wall ] Clearly a forgery, since Jim would never write such a line, especially since he doesn't write the check for the bill for an Internet connection, and it isn't his money (or disk, for that matter). Might be his time, but he probably gets paid for it, as is implied by the "work:" in the .sig. Again, clearly a forgery. -- Mike Murphy mrm@Sceard.COM ucsd!sceard!mrm +1 619 598 5874
mcr@Sandelman.OCUnix.on.ca (Michael Richardson) (05/20/91)
In article <1991May17.202220.9531@uu.psi.com> schoff@uu.psi.com (Martin Schoffstall) writes: >But lets go back to your rftp, what you need to do is create the >code and make it work across 2 dozen platforms and it will be >as explosive as CNews use. So get the community to work the >spec and write the code and we're off, minimum portability would be >bsd4.x >sunos >sysv >xenix >ice's Uaccess >uupc >aix Why? All the meat is on the server (your box) not the customers. You simply 'uuto' it to them once it is there. Are you saying that you run such a wide spread of access machines? (UUPC??) You may want to chop large files into smaller (binary) files, and this may require some thought as to the correct format to pick (and how to verify integrity of each part), but would be an enhancement so that 2meg tar.Z files can still be sent over a line which only stays up for an hour at a time... >Your biggest and most controversial design decision will be to >decide if this works one hop or multiple hops. Does uucp/uuto? Does uux? -- :!mcr!: | The postmaster never | So much mail, Michael Richardson | resolves twice. | so little time. HOME: mcr@sandelman.ocunix.on.ca Bell: (613) 237-5629 Small Ottawa nodes contact me about joining ocunix.on.ca!
gsh7w@astsun9.astro.Virginia.EDU (Greg Hennessy) (05/20/91)
Me: #>UUnet is always there. And they have 1-900 numbers. William G. Bunton: #And some of us, due to children or other excuses, have to have 900 #blocking in place. That is your decision, hence your problem. UUnet also has 1-800 numbers. Don't tell me you have those blocked also. -- -Greg Hennessy, University of Virginia USPS Mail: Astronomy Department, Charlottesville, VA 22903-2475 USA Internet: gsh7w@virginia.edu UUCP: ...!uunet!virginia!gsh7w
brad@looking.on.ca (Brad Templeton) (05/20/91)
If the NSF would permit it, I am sure somebody could be convinced to set up a 1-900 number which connects you to a variant of FTP that lets you rout around in anonymous FTP directories (or any others you have permissions for) and download from them. I say a variant becuase you don't want to copy the file to the local host and then uucp it at 900 prices, you would rather the socket from the archive host be connected directly to a zmodem send program, for example. Or a very clever uucp that, assuming you know what you want, can uucp a file like sitename:file for you using anonymous FTP. -- Brad Templeton, ClariNet Communications Corp. -- Waterloo, Ontario 519/884-7473
randy@chinet.chi.il.us (Randy Suess) (05/20/91)
In article <1991May19.133104.11572@balkan.TNT.COM> wgb@balkan.TNT.COM (William G. Bunton) writes: >And some of us, due to children or other excuses, have to have 900 >blocking in place. On your uucp line? Common, be real. -- Randy Suess randy@chinet.chi.il.us
pjg@acsu.buffalo.edu (Paul Graham) (05/20/91)
peter@ficc.ferranti.com (Peter da Silva) writes: | |Can you say "we're already paying for the mail service, why should we pay |twice?"? Can you say "We're quite willing to pay for access to a reliable |service for things like this... in fact we're already doing so."? it would seem that you should join BITNET then. or contract with some other service that can provide you with what you need. -- pjg@acsu.buffalo.edu / rutgers!ub!pjg / pjg@ubvms (Bitnet) opinions found above are mine unless marked otherwise.
randy@m2xenix.psg.com (Randy Bush) (05/20/91)
wgb@balkan.TNT.COM (William G. Bunton) writes: >> UUnet is always there. And they have 1-900 numbers. > And some of us, due to children or other excuses, have to have 900 > blocking in place. And some of us, do to immaturity at downstream sites, have to have MBAS blocking in place. -- randy@psg.com ..!uunet!m2xenix!randy
lyndon@cs.athabascau.ca (Lyndon Nerenberg) (05/20/91)
6sigma2@polari.UUCP (Brian Matthews) writes: >In article <1991May18.190644.27513@murdoch.acc.Virginia.EDU> gsh7w@astsun.astro.Virginia.EDU (Greg Hennessy) writes: >In my experience, uunet has about half of the things I would like to >ftp, and most of those are available at numerous other anon UUCP archives. Which is why sending a request to ftp-request@uunet.uu.net asking for the package/software/whatever is a Good Thing To Do. -- Lyndon Nerenberg VE6BBM / Computing Services / Athabasca University atha!cs.athabascau.ca!lyndon || lyndon@cs.athabascau.ca Packet: ve6bbm@ve6mc.ab.can.noam The only thing open about OSF is their mouth. --Chuck Musciano
eah@xenitec.on.ca (Ed Hew happily using ksh) (05/20/91)
In article <1991May19.133104.11572@balkan.TNT.COM> wgb@balkan.TNT.COM (William G. Bunton) writes: >>UUnet is always there. And they have 1-900 numbers. > >And some of us, due to children or other excuses, have to have 900 >blocking in place. >-- >William G. Bunton | wgb@balkan.tnt.com Oh, I can't resist this.... You have 900 blocking in place on your _modem_ lines?? It'd be rather trivial to write a little filter to check for `logname` before allowing your "kids or other excuses" access to any of your modem utilities. -- Ed. A. Hew, <edhew@xenitec.on.ca> ..!{watmath|lsuc}!xenitec!eah XeniTec Consulting Services, Kitchener, ON, Canada (519) 570-9848 [biz.sco.{opendesktop,general,announce} newsgroup/mlists person.]
merce@iguana.uucp (Jim Mercer) (05/20/91)
In article <+.EB_VA@xds13.ferranti.com> peter@ficc.ferranti.com (Peter da Silva) writes: >In article <1991May18.203937.9443@iguana.uucp> merce@iguana.uucp (Jim Mercer) writes: >> >Fine. They gonna pay me the overtime for all the stuff that our developers >> >want or need, that I have to set up and poll myself because of the problems >> >establishing a reliable UUCP connection? > >> can you say "a cost of doing business" ? > >Can you say "we're already paying for the mail service, why should we pay >twice?"? if MBAS's were only a plague on hubs that sell their services, i wouldn't have a problem, but they do tend to clog those of us generous enough to provide those services for free. if you are paying for mail service, bitch to your service provider. if they aren't good enough, change providers. if no provider can do a good enough job, start your own. >Can you say "We're quite willing to pay for access to a reliable >service for things like this... in fact we're already doing so."? if you have reliable service, what's your beef? -- [ Jim Mercer work: jim@lsuc.on.ca home: merce@iguana.uucp +1 519 570-3467 ] [ "Anarchists Unite!" - seen spray painted on a wall ]
merce@iguana.uucp (Jim Mercer) (05/20/91)
In article <1991May19.183202.5575@sceard.Sceard.COM> mrm@Sceard.COM (M.R.Murphy) writes: >In article <1991May18.043931.7094@iguana.uucp> merce@iguana.uucp (Jim Mercer) writes: >[...] >> >>too fucking bad, better your money/time/disk than mine. >> >>-- >>[ Jim Mercer work: jim@lsuc.on.ca home: merce@iguana.uucp +1 519 570-3467 ] >>[ "Anarchists Unite!" - seen spray painted on a wall ] > >Clearly a forgery, since Jim would never write such a line, especially since he >doesn't write the check for the bill for an Internet connection, and it isn't >his money (or disk, for that matter). Might be his time, but he probably gets >paid for it, as is implied by the "work:" in the .sig. > >Again, clearly a forgery. not a forgery. (changed my .sig as it seems to conflict with my actions according to some of the email i've gotten.) the "mine" in the message, was an organizational "mine", as opposed to a personal "mine". the money/time/disk is paid for by my employer, but that does not imply that it is open to use by any person with an email account. also, my paid time is supposed to be directed at supporting the other employees. much of the news and mail administration is done on my own free time. we, like many other systems on USENET, store and forward news and mail out of a co-operative spirit. seems to me that the direction of the net is towards greed and ignorance. dare i say, immenent (sp?) death of the net(tm). -- [ Jim Mercer work: jim@lsuc.on.ca home: merce@iguana.uucp +1 519 570-3467 ] [ "Clickity-Click, Barba-Trick" - The Barbapapas ]
merce@iguana.uucp (Jim Mercer) (05/20/91)
>In article <1991May19.133104.11572@balkan.TNT.COM> wgb@balkan.TNT.COM (William G. Bunton) writes: >And some of us, due to children or other excuses, have to have 900 >blocking in place. Others have wriiten to the extent: >You have 900 blocking in place on your _modem_ lines?? yes, it is true. there are some people out there who do not have dedicated lines for their home machines. (maybe even work machines). -- [ Jim Mercer work: jim@lsuc.on.ca home: merce@iguana.uucp +1 519 570-3467 ] [ "Clickity-Click, Barba-Trick" - The Barbapapas ]
peter@ficc.ferranti.com (Peter da Silva) (05/20/91)
In article <77133@eerie.acsu.Buffalo.EDU> pjg@acsu.buffalo.edu (Paul Graham) writes: > it would seem that you should join BITNET then. > or contract with some other service that can provide you with what you > need. We did that already. That's the problem. -- Peter da Silva; Ferranti International Controls Corporation; +1 713 274 5180; Sugar Land, TX 77487-5012; `-_-' "Have you hugged your wolf, today?"
peter@ficc.ferranti.com (Peter da Silva) (05/20/91)
Speaking of communication problems: I'm not arguing for MBAS. Never have. In article <1991May20.062932.13623@iguana.uucp> merce@iguana.uucp (Jim Mercer) writes: > if MBAS's were only a plague on hubs that sell their services, i wouldn't > have a problem, but they do tend to clog those of us generous enough to > provide those services for free. That's why I'm arguing for a workable alternative to mail based archive servers. We have an evolutionary niche for them. If we scratch the niche we scratch the itch. -- Peter da Silva; Ferranti International Controls Corporation; +1 713 274 5180; Sugar Land, TX 77487-5012; `-_-' "Have you hugged your wolf, today?"
timk@wynnds.xenitec.on.ca (Tim Kuehn) (05/20/91)
In <1991May20.064047.13740@iguana.uucp> merce@iguana.uucp (Jim Mercer) writes: >seems to me that the direction of the net is towards greed and ignorance. > >dare i say, immenent (sp?) death of the net(tm). I'd think it's more likely "imminent change in the fundamental nature of the net from free co-operative sharing of resources in a reasonable manner" to a "you want it? You pay for it!" situation due to the net.abusers out there who can't seem to get it through their head that services provided out of the good will of others who are paying the bill for their services can pull the plug just like that if their good will is abused once too often. >[ Jim Mercer work: jim@lsuc.on.ca home: merce@iguana.uucp +1 519 570-3467 ] >[ "Clickity-Click, Barba-Trick" - The Barbapapas ] ------------------------------------------------------------------------ Tim Kuehn TDK Consulting Services (519)-888-0766 timk@wynnds.xenitec.on.ca -or- !{watmath|lsuc}!xenitec!wynnds!timk Valpo EE turned loose on unsuspecting world! News at 11! "You take it seriously when someone from a ballistics research lab calls you." Heard at a Unix user's meeting discussing connectivity issues.
david@twg.com (David S. Herron) (05/20/91)
In article <34032@ucsd.Edu> brian@ucsd.Edu (Brian Kantor) writes: .. >mail-based archive server which not only limits volume, but will audit >the address requesting the data. > >The qualifications are that we will send a large file in response to a request >from someone if their return address is > 1 hop from us (i.e., a direct connection) > 1 hop from uunet (i.e., requester picks up the tab) > on the internet Good idea, BUT. Meta-Question for you: Why put this authorization sort of thing in the program. That is ... You have some particular set of administrative concerns you want to address with your mail server. Suppose someone else also has administrative concerns, but not the same set. Say they have two routes, one over per-packet charging X.25 with X.400 and the other over non-per-packet charging Internet, and they want to reject most of the requests which will return over the X.25/X.400 link because it's expensive. To make it worse, suppose they have this person they do work with but s/he is only connected throuth the expensive X.25/X.400 link ... Taken from another angle.. my first thought about how to do this is to have the program do low-level rooting around in various files scattered about like /usr/lib/uucp/{L.sys,Systems}. That can be UGLI. Howzabout pushing the authorization stuff into the MTA. Then it could be used for more purposes than just an archive server. For instance I have seen requests for preventing certain people from posting to a mailing list, or conversely limiting posters to a mailing list to a select group. Or, as I implied above, you may want to limit people in general from using your expensive links but allow a select few to do so. (Hmm.. just had a thought that the more radical among you might not like this. Just remember the Golden Rule: Thems that gots the gold makes the rule. It is truer than you think!) At any rate there are two MTA's which already have generic authorization facilities in it. MMDF and PP -- <- David Herron, an MMDF & WIN/MHS guy, <david@twg.com> <- Formerly: David Herron -- NonResident E-Mail Hack <david@ms.uky.edu> <- <- "MS-DOS? Where we're going we don't need MS-DOS." --Back To The Future
chip@chinacat.unicom.com (Chip Rosenthal) (05/21/91)
In article <1991May19.194044.24840@murdoch.acc.Virginia.EDU> gsh7w@astsun9.astro.Virginia.EDU (Greg Hennessy) writes: >That is your decision, hence your problem. Calm down, Greg. It wasn't his decision - it was the Texas PUC which decided for him. The Texas PUC has mandated all carriers offer 900 blocking to customers. If the carrier can't offer this service, then 900 calls must be blocked through the entire exchange until the service is available. A good number of Texas exchanges are currently cutoff from 900 numbers. Therefore, there are folks out there willing to pay for a call to uunet to grab stuff who can't. But that's still all beside the point - I don't think that justifies BITFTP or mail servers. -- Chip Rosenthal <chip@chinacat.Unicom.COM> | Don't play so Unicom Systems Development 512-482-8260 | loud, Mr. Collins.
brendan@cs.widener.edu (Brendan Kehoe) (05/21/91)
eah@xenitec.on.ca wrote: >Oh, I can't resist this.... > >You have 900 blocking in place on your _modem_ lines?? What's to resist his kids from popping a phone into one of those jacks to call out? -- Brendan Kehoe - Widener Sun Network Manager - brendan@cs.widener.edu Widener University in Chester, PA A Bloody Sun-Dec War Zone
peter@ficc.ferranti.com (Peter da Silva) (05/21/91)
Here's another idea... how about having mail-based archive servers putting a line that says "Class: Junk". Then if you have an expensive link you dump junk mail going through it on the floor. -- Peter da Silva; Ferranti International Controls Corporation; +1 713 274 5180; Sugar Land, TX 77487-5012; `-_-' "Have you hugged your wolf, today?"
jim@crom2.uucp (James P. H. Fuller) (05/21/91)
eah@xenitec.on.ca (Ed Hew happily using ksh) writes: > > > UUnet is always there. And they have 1-900 numbers. > > > > And some of us, due to children or other excuses, have to have 900 > > blocking in place. >Oh, I can't resist this.... > >You have 900 blocking in place on your _modem_ lines?? Ahhh, he read _Newsweek_ and when they said "there's no such thing as home computers, they all bought C64s and put them in the closet" he *believed*! Aren't dimwits fun? The things they say! For you guys who have peu d'imagination (note Francais, courtesy for Canadian customers) it happens that there are VERY MANY systems active on the net that borrow the household VOICE LINE to pick up the news and mail. Hey, and some of us even manage to reproduce! SOME of us even know more about the VCR than the kids do and can lock out MTV and *keep* it locked out. But it still takes money to get in an extra modem-only line. ("I can't resist this": those who don't know the above obviously don't *have* a machine in their short-forehead Neanderthal caves, I mean homes....) Crom has its own line right now (whoopee) but n'etais pas always vrai. crom2 Athens GA Public Access Unix | i486 AT, 16mb RAM, 600mb online Molecular Biology | AT&T Unix System V release 3.2 Population Biology | Tbit PEP 19200bps V.32 V.42/V.42bis Ecological Modeling | admin: James P. H. Fuller Bionet/Usenet/cnews/nn | {jim,root}%crom2@nstar.rn.com
lyndon@cs.athabascau.ca (Lyndon Nerenberg) (05/21/91)
peter@ficc.ferranti.com (Peter da Silva) writes: >Here's another idea... how about having mail-based archive servers putting >a line that says "Class: Junk". Then if you have an expensive link you >dump junk mail going through it on the floor. Gack! A good idea! :-) It would be nice if they did this anyway. If this header is present in a message that bounces at an smail3 site, the error notification will not include the message body. This can save a lot of bandwidth. In our case, it *has* saved a lot of bandwidth - there are a surprising number of MBAS' that insist on replying to the envelope from address, rather than to the From: or Reply-To: headers. Despite the fact that we do the correct transformation in the envelope when gatewaying from uucp to smtp, downstream sites invariably mung this stuff up, with the result that the reply gets to the site one hop away from the destination, and then bounces dues to a !@ precedence disagreement. Ugh! It would also be possible to reroute mail around expensive links based on the Class: header. A bit less antisocial than just filing it :-) -- Lyndon Nerenberg VE6BBM / Computing Services / Athabasca University atha!cs.athabascau.ca!lyndon || lyndon@cs.athabascau.ca Packet: ve6bbm@ve6mc.ab.can.noam The only thing open about OSF is their mouth. --Chuck Musciano
les@chinet.chi.il.us (Leslie Mikesell) (05/21/91)
In article <1991May20.180914.26084@chinacat.unicom.com> chip@chinacat.unicom.com (Chip Rosenthal) writes: > [900 blocking] >Therefore, there are folks out there willing to pay for a call to uunet >to grab stuff who can't. Maybe not on the spur of the moment, but they can always get a subscription and the associated access through direct LD, 800 numbers, telenet, Compuserve's network, and whatever else they happen to use. >But that's still all beside the point - I don't >think that justifies BITFTP or mail servers. Why - do you think mail should only be delivered when it suits the carrier's whims? Les Mikesell les@chinet.chi.il.us
mrm@sceard.Sceard.COM (M.R.Murphy) (05/21/91)
In article <1991May20.064047.13740@iguana.uucp> merce@iguana.uucp (Jim Mercer) writes: >In article <1991May19.183202.5575@sceard.Sceard.COM> mrm@Sceard.COM (M.R.Murphy) writes: [...] >>Again, clearly a forgery. > >not a forgery. (changed my .sig as it seems to conflict with my actions >according to some of the email i've gotten.) I didn't know it wasn't a forgery:-) <-- smiley for Severly Humor-Impaired TwitS > >the "mine" in the message, was an organizational "mine", as opposed to a >personal "mine". New definition of the word "mine" :-) [...] >seems to me that the direction of the net is towards greed and ignorance. > Is it surprising that lsuc (Law Society...) would seek the administrative rather than the technical solution? :-) Much as I would like to see the facilities offered by MBAS's available, I, too, agree that the potential for abuse is such that it is not likely to find a feasable way to keep the concept in general. Too bad. If the non-Internet sites are lucky, then the major providers like uunet will react quickly to the need and come up with something reasonable. I would suggest something like the 1 hop criterion, or maybe a file at the provider similar to a paths file where an entry in the file indicates a legal path for a request. -- Mike Murphy mrm@Sceard.COM ucsd!sceard!mrm +1 619 598 5874
scott@skypod.guild.org (Scott Campbell) (05/21/91)
In article <1991May20.033655.5269@xenitec.on.ca> eah@xenitec.on.ca (Ed Hew happily using ksh) writes: >In article <1991May19.133104.11572@balkan.TNT.COM> wgb@balkan.TNT.COM (William G. Bunton) writes: >>>UUnet is always there. And they have 1-900 numbers. >> >>And some of us, due to children or other excuses, have to have 900 >>blocking in place. > >You have 900 blocking in place on your _modem_ lines?? It would be trivial for an ingenious "child or other excuse" to unplug the modem and plug in a phone... or do you hardwire your modem to the wall? -- Scott J.M. Campbell scott@skypod.guild.org Skypod Communications Inc. ..!gatech!dscatl!daysinns!skypod!scott 1001 Bay Street, Suite 1210 ..!uunet!utai!lsuc!becker!skypod!scott Toronto, Ont. (416) 924-4059 ..!epas.utoronto.ca!nyama!skypod!scott
randy@chinet.chi.il.us (Randy Suess) (05/21/91)
In article <HLW+T2L@cs.widener.edu> brendan@cs.widener.edu (Brendan Kehoe) writes: >>You have 900 blocking in place on your _modem_ lines?? > What's to resist his kids from popping a phone into one of those >jacks to call out? > Uh, proper upbringing? -- Randy Suess randy@chinet.chi.il.us
jim@lsuc.on.ca (Jim Mercer) (05/21/91)
In article <1991May21.025032.25282@chinet.chi.il.us> les@chinet.chi.il.us (Leslie Mikesell) writes: >In article <1991May20.180914.26084@chinacat.unicom.com> chip@chinacat.unicom.com (Chip Rosenthal) writes: >>But that's still all beside the point - I don't >>think that justifies BITFTP or mail servers. > >Why - do you think mail should only be delivered when it suits the >carrier's whims? why should USENET be any different than the internet. the internet is made up of a group of regional networks. each regional network sets policy as to what is acceptable use of their resources, and deals with the packets accordingly. USENET (uucpNET) is made up of a group of uucp hosts. each host should be able to set policy as to what is acceptable use of their resources. if that host's whims are that BITFTP or alt.sex.pictures is not acceptable use, they can deal with it accordingly. i think it is reasonable for the users of downstream sites to be at the mercy of upstream host policy. i think it is totally unreasnable for upstream hosts to be at the mercy of downstream user's whims. -- [ Jim Mercer jim@lsuc.On.Ca || ...!uunet!attcan!lsuc!jim +1 416 947-5258 ] [ Educational Systems Manager - Law Society of Upper Canada, Toronto, CANADA ] [ Standards are great. They give non-conformists something to not conform to. ] [ The opinions expressed here may or may not be those of my employer ]
randy@chinet.chi.il.us (Randy Suess) (05/22/91)
In article <1991May21.002214.5493@crom2.uucp> jim@crom2.uucp (James P. H. Fuller) writes:
]>You have 900 blocking in place on your _modem_ lines??
]
] For you guys who have peu d'imagination (note Francais, courtesy for
]Canadian customers) it happens that there are VERY MANY systems active on the
]net that borrow the household VOICE LINE to pick up the news and mail. Hey,
]and some of us even manage to reproduce! SOME of us even know more about
]the VCR than the kids do and can lock out MTV and *keep* it locked out. But
]it still takes money to get in an extra modem-only line. ("I can't resist
]this": those who don't know the above obviously don't *have* a machine in their
]short-forehead Neanderthal caves, I mean homes....)
]
Scuse me, you have a system at home capable of running UNIX,
at least one VCR, cable, and you can't afford $20 per month
for a dedicated uucp fone line? Also, your kids can't be trusted
not to call 900 numbers, but they are intelligent enough not to
pick up the fone while you are uploading this drivel?
Yeah. Right.
--
Randy Suess
randy@chinet.chi.il.uslan_csse@netrix.nac.dec.com (CSSE LAN Test Account) (05/22/91)
In article <1991May18.173513.3472@chinet.chi.il.us> les@chinet.chi.il.us (Leslie Mikesell) writes: > >I'd guess that most FTP users just want the files delivered and don't >really care about the vehicle. In fact, given a choice, most people >would probably prefer uucp's automatic queuing mechanism if the remote >site can't be reached on the first attempt. Ummm...UUCP over TCP has been in existence for years; quite a lot of vendors supply it. See if your library has uucpd in it; you might also check your /etc/services or /etc/inetd.conf files for its name. If it exists on your system, it is a whole lot nicer than ftp. It retries if the call doesn't go through; it does proper error checking and doesn't hand you garbaged files; it runs easily from a script; you don't have to do it twice because you forgot to say "binary" the first time, and all those good things. Plus, when I've done timing tests, it has often run 3-4 time faster than ftp for big files. If the BSD crowd didn't have such a bad case of NIHitis, we'd all have it by now...
lyndon@cs.athabascau.ca (Lyndon Nerenberg) (05/22/91)
lan_csse@netrix.nac.dec.com (CSSE LAN Test Account) writes: >it does proper error checking and doesn't >hand you garbaged files; If your FTP does this then I suggest you have a looong chat with your OS vendor. > it runs easily from a script; you don't have >to do it twice because you forgot to say "binary" the first time, But you do have to run it twice if you forgot to say "ascii". UUCP runs on more then just Unix these days. And I have yet to find a uucp that supports the -ascii option :-) >If the BSD crowd didn't have such a bad case of NIHitis, we'd all have >it by now... Huh? Where do you think (working) uucp over tcp was first implemented? -- Lyndon Nerenberg VE6BBM / Computing Services / Athabasca University atha!cs.athabascau.ca!lyndon || lyndon@cs.athabascau.ca Packet: ve6bbm@ve6mc.ab.can.noam As a math athiest, I should be excused from this. --Calvin
gamiddle@watmath.waterloo.edu (Guy Middleton) (05/22/91)
In article <22813@shlump.lkg.dec.com> lan_csse@netrix.nac.dec.com (CSSE LAN Test Account) writes: > Ummm...UUCP over TCP has been in existence for years; quite a lot of > vendors supply it. [ ... ] > If the BSD crowd didn't have such a bad case of NIHitis, we'd all have > it by now... I can't see the relevance of this. TCP/uucp has been in BSD since 4.2. Or was there some other point I had missed?
pjg@acsu.buffalo.edu (Paul Graham) (05/22/91)
[is this a real person?] lan_csse@netrix.nac.dec.com (CSSE LAN Test Account) writes: |Ummm...UUCP over TCP has been in existence for years; quite a lot of |vendors supply it. |. . . it is a whole lot nicer than ftp. It retries if |the call doesn't go through; it does proper error checking and doesn't |hand you garbaged files; eh? |If the BSD crowd didn't have such a bad case of NIHitis, we'd all have |it by now... eh? -- pjg@acsu.buffalo.edu / rutgers!ub!pjg / pjg@ubvms (Bitnet) opinions found above are mine unless marked otherwise.
berk@techsys.UUCP (techsys consulting) (05/22/91)
....(text deleted....)
Peter, it seems that some demand a free ride because it's the human
way.
I'm sure that you have, somewhere, the cost of storage per hour,
and connect per hour, and can rational a cost of queing/routing.
Just tell these guys what the REAL cost to operate, on a professional
scale is. They don't care that somebody is doing NOT FAST on a boat-
load of curiosity seeked trivia. (God help the forwarder of EMACS
18.57!) I supply newsfeeds, and I'm not thrilled when stuff like
all of the BITFTP goes through ME.
Set a standard.. what MUST we po' folk do? Suggest a most painless
(on a generalized scale) viable method for equalization of the cost.
usc!celia!techsys!berk extant map entries void
Does henry@ut.zoo ever answer?thomas@mvac23.UUCP (Thomas Lapp) (05/22/91)
gsh7w@astsun9.astro.Virginia.EDU (Greg Hennessy) writes: > Me: > #>UUnet is always there. And they have 1-900 numbers. > > William G. Bunton: > #And some of us, due to children or other excuses, have to have 900 > #blocking in place. > > That is your decision, hence your problem. And some of us have telcos who have removed 976-xxxx numbers and are thinking about doing the same for 1-900-xxx-xxxx. > UUnet also has 1-800 numbers. Don't tell me you have those blocked > also. However you have to be a member/have an account already. More inconvenient than 900 number. - tom -- internet : mvac23!thomas@udel.edu or thomas%mvac23@udel.edu (home) : 4398613@mcimail.com (work) uucp : {ucbvax,mcvax,uunet}!udel!mvac23!thomas Location : Newark, DE, USA -- The UUCP Mailer
merce@iguana.uucp (Jim Mercer) (05/22/91)
In article <1991May21.031016.9269@sceard.Sceard.COM> mrm@Sceard.COM (M.R.Murphy) writes: >Is it surprising that lsuc (Law Society...) would seek the administrative >rather than the technical solution? :-) sometimes the administrative solution is better than the technical solution. Goal: reduce MBAS impact on USENET Technical: install filters at many major mail hubs Administrative: get MBAS's to straighten up their act. which is easier, faster and more effective in the long run? .... I'm not a lawyer, but i'd like to play one on TV. 8^) -- [ Jim Mercer work: jim@lsuc.on.ca home: merce@iguana.uucp +1 519 570-3467 ] [ "AIDS. Stick it in your head instead!" - Billboard seen in Toronto ] [ (it lost (gained?) something in the translation from french) ]
asp@uunet.uu.net (Andrew Partan) (05/22/91)
In article <4068@island.COM>, daniel@island.COM (Daniel Smith "innovation, not litigation...") writes: > > They can send mail to ftp-requesdt@uunet.uu.net and request the files > > be transfered for them. Why uunet doesn't provide a service like BITFTP > > for DIRECTLY connected customers is beyond me. > I wholeheartily second this! I've used ftp-request on occasion, > but the turnaround time isn't as good as what would be possible if uunet > were to run the type of software that Princeton is using. If someone can write some software that can distinguish between customer!customer-node!user and customer!non-customer-node!user for all customers w/o us having to keep a database of interior customer nodes, then we will consider running it. Until that point, we would rather use one of our operators to do the ftping of files. --asp@uunet.uu.net (Andrew Partan)
randy@chinet.chi.il.us (Randy Suess) (05/22/91)
In article <1991May21.113455.23876@skypod.guild.org> scott@skypod.guild.org (Scott Campbell) writes: >It would be trivial for an ingenious "child or other excuse" to unplug the modem >and plug in a phone... or do you hardwire your modem to the wall? > Then you have more problems other than file transfer. Try being a parent. -- Randy Suess randy@chinet.chi.il.us
mrm@sceard.Sceard.COM (M.R.Murphy) (05/22/91)
In article <1991May22.040039.21721@iguana.uucp> merce@iguana.uucp (Jim Mercer) writes: >In article <1991May21.031016.9269@sceard.Sceard.COM> mrm@Sceard.COM (M.R.Murphy) writes: >>Is it surprising that lsuc (Law Society...) would seek the administrative >>rather than the technical solution? :-) > >sometimes the administrative solution is better than the technical solution. Sometimes the administrative solution is better than the poorly thought out technical solution. > >Goal: reduce MBAS impact on USENET Agreed. A noble endeavour. Really agreed. No smiley. > >Technical: install filters at many major mail hubs A technical solution. Part of an overall solution. Not the whole solution. Not the most important part of the solution. A kludge. > >Administrative: get MBAS's to straighten up their act. Close. Real close. How to straighten up the act is another question. How about having the MBAS not abuse its downstream sites unless they are masochistic enough to accept the abuse willingly. That is, have the MBAS check if the entire path for a transfer is cooperative. If it doesn't know that an element of the path is cooperative, then that element should be deemed non-cooperative, and the whole path is ng. Politely notifiy the requestor to that effect. By "check the path", I mean "check the path." As in "an address isn't good enough, you gotta check the path, and every element in the path must be explicitly cooperative." Not hard to do in software. > >which is easier, faster and more effective in the long run? > It is easier, faster, and more effective in the long run to fix a few friendly, large, well-managed MBASes than it is to try to educate, coerce, or constrain the vast morass of USENET, THISNET, THATNET, and THEOTHERNET. The administrative solution of pulling the plug is a first level solution. It is not a real good solution, but it is better than nothing. WRT MBAS abuse, can you say attractive nuisance? I knew that someone who wanted to play a lawyer on TV could :-) WRT MBAS in general, I'm pretty sure that others thought the same as I did, "What a Neat Idea (smile, smile). It can't last (smile, smile). Wow! What a mess it'll be if ever more than just a few people use it. Oops. It'll be interesting to see what happens." 50MB of VMS stuff in a 10MB spool is just another denial of service attack. In this case it is an attack by the MBAS. Inadvertant, just trying to be of service, genuinely trying to be useful and helpful, but still a denial of service attack. The administration of the MBAS might be expected to know better. To expect the user to know better is also a noble endeavour, but probably will be disappointing. Sort of like connecting two very large user communities with a 9600 baud line, telling 'em they can communicate including sending data files of humongous proportion, and then empirically observing the phenomenon of bottleneck. :-) -- Mike Murphy mrm@Sceard.COM ucsd!sceard!mrm +1 619 598 5874
randy@m2xenix.psg.com (Randy Bush) (05/22/91)
mrm@sceard.Sceard.COM (M.R.Murphy) writes: > Much as I would like to see the facilities offered by MBAS's available, I, > too, agree that the potential for abuse is such that it is not likely to > find a feasable way to keep the concept in general. Too bad. There was a time in the net's life where 'potential for abuse' was not a major problem as it remained but a potential. Folk were almost proud to have dangerous tools lying around unabused (e.g. magic on WAITS). The recent abuse of MBASs makes it clear that the net has 'matured' (i.e. accumulated the immature) to the point where one can no longer leave dangerous tools available, at least not at countertop level. Recent traffic here, where the abusers claim a *right* to their lack of consideration/citizenship, makes it clear that net tool builders now must design against abuse as much as (if not more than) for use. This results in (at least) twice the effort/resource to achieve the same result. Great. In a sense, I guess, this is a sign of 'growth' and 'maturity' of the net. In another, it is sad sign of the modern human condition in self-righteous, 'you owe me', rip-off America (and the fools who follow us). <sigh> -- randy@psg.com ..!uunet!m2xenix!randy
lan_csse@netrix.nac.dec.com (CSSE LAN Test Account) (05/22/91)
In article <77373@eerie.acsu.Buffalo.EDU> pjg@acsu.buffalo.edu (Paul Graham) writes: >[is this a real person?] >lan_csse@netrix.nac.dec.com (CSSE LAN Test Account) writes: No; they won't give us individual accounts here, so a bunch of us use this one, with subdirectories set up for each of us, and a .$USER file for each to do his/her/its own personal login tailoring. It's lots of fun to try to sort out news and mail to a shared account; you should try it sometime. We do have fun reading each others' mail and all that, especially flames that come in from questions on various newsgroups. But then, we keep finding useful morsels among the flames, and we don't mind if they are well-done, so we keep using rn in one window, notes in another, and complaining that they can't get together... >|Ummm...UUCP over TCP has been in existence for years; quite a lot of >|vendors supply it. >|. . . it is a whole lot nicer than ftp. It retries if >|the call doesn't go through; it does proper error checking and doesn't >|hand you garbaged files; > >eh? Well, just a week or so ago, I tried ftping over to lcs.mit.edu to fetch a copy of something useful, and it took three tries before ftp could get the tar.Z file across intact, and then zcat|tar couldn't unpack it. When I ran a hexdump of it, there were big chunks (whose sizes were a multiple of 512) that were filled with nulls. This isn't new. I have a little program that merges files that contain null chunks, and complains if the non-null parts don't agree. If I give it 3 or more files, it uses the obvious voting algorithm for each byte, and only complains if there are chunks on which no two files agree. It sure comes in handy at times. (All the grumbling about the turkeys who think their file-transfer package works; they have a very strange definition of the term. ;-) Sure, ftp works fine across a single Ethernet. It usually works if you have one or two bridges or gateways to cross. But everywhere I've worked, it has problems on some links, and its way of failing is to tell you that it has copied the data, when large chunks are null or garbage. I'm tired of complaining to vendors about it; I've never once seen the problems get fixed (and it's been nearly 10 years now). They just run tests on their in-house network, there aren't any problems there, so they dismiss me as an idiot who obviously must be misusing this wonderful tool. In my experience, you should always install as many file-transfer packages as you can get your hands on, to increase the probability that maybe one of them will work in a particular situation. UUCP is generally the best (in the sense that if it tells you it succeeds, then the data is always there and intact), but between an arbitrary pair of machines, there is a very small chance that you can make UUCP work, because you can't get a physical connection that is compatible with any of the drivers that the two ends' UUCPs have in common. Kermit also works well (when you can get it to work at all) but is slow and requires constant handholding, and isn't in the libraries supplied by very many vendors. Rcp usually just says "Permission denied" and you can't figure out what the security rules are this time. Tftp works in some cases where ftp fails, but it but tftpd isn't installed nearly as widely as ftpd. The dcp command works if you are luck enough to have DECnet on both ends, but these days you can't get a DECnet address, and in any case, dcp only succeeds if you are the receiver; it invariably fails its security checks if you try downloading to another machine. And so on. Another constant problem is that ftp is inherently interactive; if you run it from a script, it has totally bizarre and baffling behavior; it certainly doesn't copy the files. Making this work seems to require renaming /dev/tty (which means being super-user), and this breaks any other application that tries using /dev/tty during the copy. Again, when you ask questions, you get treated like an idiot. (Why would you want to write a script in one of those user-unfriendly shell languages when you can do the job so easily by hand every time? ;-) Of course, there is also the approach of uuencode+uusplit+mail, with the inverse transformation at the other end... Sigh.
lan_csse@netrix.nac.dec.com (CSSE LAN Test Account) (05/23/91)
In article <1991May22.081251.1026@uunet.uu.net> asp@uunet.uu.net (Andrew Partan) writes: | If someone can write some software that can distinguish between | customer!customer-node!user | and | customer!non-customer-node!user | for all customers w/o us having to keep a database of interior customer | nodes, then we will consider running it. Wasn't this sort of distinction the reason for the domainizing of the mail system? It seems that the way to do it would be to define a domain for your customers (perhaps "uu.net" ;-), and only send things to machines in that domain. Am I missing something? Of course, enforcing the domain's boundaries might be an interesting research problem. Then again, maybe it'd just be an interesting legal problem.
les@chinet.chi.il.us (Leslie Mikesell) (05/23/91)
In article <1991May22.081251.1026@uunet.uu.net> asp@uunet.uu.net (Andrew Partan) writes: >If someone can write some software that can distinguish between > customer!customer-node!user >and > customer!non-customer-node!user >for all customers w/o us having to keep a database of interior customer >nodes, then we will consider running it. >Until that point, we would rather use one of our operators to do the >ftping of files. > --asp@uunet.uu.net (Andrew Partan) If you tell us how your operators can distinguish this without a database, perhaps someone will suggest how to do it in software. I'd settle for a requirement that the return address either be only one hop away in uucp format or in domain format where uunet is the forwarder for the domain. The operator request could still be used in situations where this check fails. How do you feel about requests like checking the directory of the test versions of kermit on watsun.cc.columbia.edu on a weekly basis? Les Mikesell les@chinet.chi.il.us
lyndon@cs.athabascau.ca (Lyndon Nerenberg) (05/23/91)
asp@uunet.uu.net (Andrew Partan) writes: >If someone can write some software that can distinguish between > customer!customer-node!user >and > customer!non-customer-node!user >for all customers w/o us having to keep a database of interior customer >nodes, then we will consider running it. You don't have to. All that's required is that you provide a tool to get the files from uunet to the customers uucp gateway, via uucp. Let the customer site develop their own interface to the facility on their gateway machine if they require that functionality in house. uucp(1) is for transferring files - use *it*, not mail... >Until that point, we would rather use one of our operators to do the >ftping of files. I would be interested in knowing just how much "business" the ftp-request alias gets. And, do you have any idea how many of the requests are satified by replies to the effect "it's already here, in pub/... " ? -- Lyndon Nerenberg VE6BBM / Computing Services / Athabasca University atha!cs.athabascau.ca!lyndon || lyndon@cs.athabascau.ca Packet: ve6bbm@ve6mc.ab.can.noam As a math athiest, I should be excused from this. --Calvin
gaynor@agvax2.ag.ohio-state.edu (05/23/91)
>The recent abuse of MBASs makes it clear that the net has 'matured' (i.e. >accumulated the immature) to the point where one can no longer leave dangerous >tools available, at least not at countertop level. > >Recent traffic here, where the abusers claim a *right* to their lack of >consideration/citizenship, makes it clear that net tool builders now must >design against abuse as much as (if not more than) for use. Lamentably, this is true. I've started seeing users who seem to believe that the law of computer usage is "if you can do it, you're allowed." Or, more accurately, if there is no rule stating explicitly that they cannot do such-and-such a thing, then they must be allowed to do it. If they can get at a command that will shut down the system, then they are allowed to do it. If they can fake mail from other users, then they must be allowed to do so. A sad state... --- Jim Gaynor - AgVAX System Manager - Academic Computing - Ohio State University VMS:<gaynor@agvax2.ag.ohio-state.edu> UNIX:<gaynor@magnus.acs.ohio-state.edu> Disclaimer : All opinions expressed here are mine and only mine. So there! Witty Quote: "Think, think, think, think..." - Winnie-the-Pooh, Taoist Bear.
peter@ficc.ferranti.com (Peter da Silva) (05/23/91)
In article <1991May22.040039.21721@iguana.uucp> merce@iguana.uucp (Jim Mercer) writes: > Goal: reduce MBAS impact on USENET Goal: reduce the traffic of sources through electronic mail routes. > Technical: install filters at many major mail hubs Alternatively, provide an alternative to mailing of sources. > Administrative: get MBAS's to straighten up their act. How does this help with the "could you mail me a copy of..." people? > which is easier, faster and more effective in the long run? UUCP access to FTP. -- Peter da Silva; Ferranti International Controls Corporation; +1 713 274 5180; Sugar Land, TX 77487-5012; `-_-' "Have you hugged your wolf, today?"
peter@ficc.ferranti.com (Peter da Silva) (05/23/91)
In article <1991May22.081251.1026@uunet.uu.net> asp@uunet.uu.net (Andrew Partan) writes: > If someone can write some software that can distinguish between > customer!customer-node!user > and > customer!non-customer-node!user > for all customers w/o us having to keep a database of interior customer > nodes, then we will consider running it. Simple. Non-customer nodes can't execute: uux - rftp ~/from-uunet OPEN archive.biguni.edu CD alt/sex GET bigknockers.gif ^D -- Peter da Silva; Ferranti International Controls Corporation; +1 713 274 5180; Sugar Land, TX 77487-5012; `-_-' "Have you hugged your wolf, today?"
emv@msen.com (Ed Vielmetti) (05/23/91)
In article <1991May22.174325.6230@chinet.chi.il.us> les@chinet.chi.il.us (Leslie Mikesell) writes:
How do you feel about requests like checking the directory of the
test versions of kermit on watsun.cc.columbia.edu on a weekly basis?
Les,
If you can specify exactly where the files you are interested in are,
it is straightforward to maintain a reasonably up to date shadow
directory of the remote FTP site and make that directory available for
UUCP. Updates can be handled in a number of ways
- triggered by references of new versions in comp.archives
- refreshed on demand by users who make a request like
rftp -dir watsun.cc.columbia.edu:/kermit/test/ ./kermit-test-dir.out
to see what's out there
- kept up by hand by humans if there's something amiss
- automatically shadowed weekly or every n days according to need
- changes noticed whenever "archie" updates are done
Naturally you'd like to keep whatever mechanisms there are for making
sure that the file you fetch is the same as the latest version on the
server somewhat hidden from the general "rftp" user, so that your
caching will have a reasonable chance to work. No sense in going off
to bother Columbia if you have a copy handy that's the same as what
they have.
UUNET has the "kept up by hand" part down pat, and I believe they have
some automatic shadows running. There's a site in Australia that's
caching based on comp.archives. Other schemes have been proposed as
well.
--Edhenry@zoo.toronto.edu (Henry Spencer) (05/23/91)
In article <DJuB31w164w@techsys.UUCP> berk@techsys.UUCP (techsys consulting) writes: >usc!celia!techsys!berk extant map entries void > Does henry@ut.zoo ever answer? Yeah, he does... but he gets, and replies to, a lot of mail, so when his answer bounces from some difficult mailer en route, he tends to just say "oh, to hell with it" and go on to something else, unless there's some reason why it's important to *him* that the mail get through. -- And the bean-counter replied, | Henry Spencer @ U of Toronto Zoology "beans are more important". | henry@zoo.toronto.edu utzoo!henry
lmb@sat.com (Larry Blair) (05/23/91)
In article <1991May22.081251.1026@uunet.uu.net> asp@uunet.uu.net (Andrew Partan) writes: =In article <4068@island.COM>, daniel@island.COM (Daniel Smith "innovation, not litigation...") writes: => > They can send mail to ftp-requesdt@uunet.uu.net and request the files => > be transfered for them. Why uunet doesn't provide a service like BITFTP => > for DIRECTLY connected customers is beyond me. => I wholeheartily second this! I've used ftp-request on occasion, => but the turnaround time isn't as good as what would be possible if uunet => were to run the type of software that Princeton is using. = =If someone can write some software that can distinguish between = customer!customer-node!user =and = customer!non-customer-node!user =for all customers w/o us having to keep a database of interior customer =nodes, then we will consider running it. This is obviously not going to be possible, since you have no idea what constitutes a `customer-node'. Why not just restrict the service to `customer!user' or `user@*customer'? Anyone wanting to use this service would have to figure out how to set up a /usr/lib/alias file, but so what? A service like this would make me want to retain my uunet account (which we are about to drop). Even better, uucp the file rather than mail it. That would be much more efficient and would avoid having to worry about whether the requester was a customer or not. =Until that point, we would rather use one of our operators to do the =ftping of files. Does this imply that I can request uunet to ftp something for me? -- Larry Blair lmb@sat.com {apple,decwrl}!sat!lmb
dean@coplex.uucp (Dean Brooks) (05/23/91)
asp@uunet.uu.net (Andrew Partan) writes: >If someone can write some software that can distinguish between > customer!customer-node!user >and > customer!non-customer-node!user >for all customers w/o us having to keep a database of interior customer >nodes, then we will consider running it. Solve the problem not by determining reply paths and all that garbage. Instead, arrange for direct uucp to the receiving node. Perhaps not as convenient for a secondhand customer node, but any site connected to uunet (as a customer) will be able to direct uucp of responses. By theory, this is the correct solution. UUCP was devised for file transfers. Email was designed for textual data. This would also open up the possibility of a 1-900 service for non-customers. Basically, they would mail the request, and anon uucp the source via anon login (on the 1-900 number). When the FTP'd software is available for download, send mail in response notifying so. If after 48 hours the software is not received, trash it. This may be a little harder to do, but certainly profitable... (-8 -- dean@coplex.uucp (Dean Brooks) Copper Electronics, Inc. Louisville, Kentucky
chip@tct.com (Chip Salzenberg) (05/23/91)
According to jim@lsuc.on.ca (Jim Mercer):
>USENET (uucpNET) is made up of a group of uucp hosts.
Sorry, but that's incorrect. To quote from "What Is Usenet?"...
7. Usenet is not the Internet.
The Internet is a wide-ranging network, parts of which are
subsidized by various governments. The Internet carries many
kinds of traffic; Usenet is only one of them. And the Internet is
only one of the various networks carrying Usenet traffic.
8. Usenet is not a UUCP network.
UUCP is a protocol (some might say "protocol suite," but that's a
technical point) for sending data over point-to-point connections,
typically using dialup modems. Usenet is only one of the various
kinds of traffic carried via UUCP, and UUCP is only one of the
various transports carrying Usenet traffic.
9. Usenet is not a UNIX network, nor even an ASCII network.
Don't assume that everyone is using "rn" on a UNIX machine. There
are Vaxen running VMS, IBM mainframes, Amigas, and MS-DOS PCs
reading and posting to Usenet. And, yes, some of them use
(shudder) EBCDIC. Ignore them if you like, but they're out there.
If you want to be understood, get your terminology straight.
--
Brand X Industries Custodial, Refurbishing and Containment Service:
When You Never, Ever Want To See It Again [tm]
Chip Salzenberg <chip@tct.com>, <uunet!pdn!tct!chip>root@mjbtn.JOBSOFT.COM (Mark J. Bailey [ADMIN]) (05/23/91)
In <1991May22.081251.1026@uunet.uu.net> asp@uunet.uu.net (Andrew Partan) writes: >[stuff deleted] >If someone can write some software that can distinguish between > customer!customer-node!user >and > customer!non-customer-node!user >for all customers w/o us having to keep a database of interior customer >nodes, then we will consider running it. >Until that point, we would rather use one of our operators to do the >ftping of files. Simple. Require that all uunet customers enlist in the domain process. Or, to enforce that, allow the service to be available only to customers that have enrolled in the domain system. UUNET should know about domain names of its customers, and customers should operate all nodes under their domain (ie, no organization "is supposed" to have more than one domain name). Now, if a customer had a neighboring site for which it wished to allow anon-ftp requests from the neighbor site to uunet (ie, customer agrees to let neighbor send requests "via" customer's account (ieie, customer will pass teh request and subsequently pay for return responses)), then customer could notify uunet of the domain of customer's neighbor as being legal for requesting via customer's uunet channel. This is very much the case with me as I have a telebit and 900+ megs of online space here at Jobsoft. I share the uunet service (ie, split costs) with a public access node here (that I co-admin), RaiderNet Public Access, which has its own domain, RAIDERNET.COM. My domain is JOBSOFT.COM. UUNET should immediately (from my account info) know I am a uunet customer. Now, I would like for the RaiderNet system to be able to use the uunet ftp service without having to reside under my domain. I would send a letter to uunet!postmaster from my 'root' account giving authorization for requests from the RaiderNet.COM domain to be honored as I have agreed to pay for them. This is not at all out of the question as when any node that is not a uunet customer wants to setup a domain name using uunet as their forwarder, they must obviously have their traffic routed through some site that is a uunet customer. UUNET's policy requires permission granted from the uunet customer's root account giving authorization for the non-uunet site to route traffic via the uunet customer's site. This is good as the uunet's customer is acknowledging he will pay for that traffic, both ways. The non-uunet site might then start pumping up mail volumes, at the uunet customer's expense. But, as in my case, that has been arranged for. So, when dealing with a uunet anon-ftp service, the senerio is essentially the same (to a certain degree). Also, maintaining a database of domain names would be a lot more logical than individual site names! Also, is an organization (such as JobSoft) that were a uunet customer added several new unix stations, if uunet's authorization were based on domain names, no new arrangements would have to be made, provided the organization kept the policy of all mail nodes being setup under that organization's domain name. On the contrary, it would be quite a bit of work on both sides if individual nodes had to be registered. You might could use an organization map entry, but since when are they really accurate? Besides, the domain system has been preached to us for years, why not put it to some additional use? Just some thoughts. Mark. -- Mark J. Bailey, N4XHX _______/====X11====\_______ USMAIL: 511 Memorial Blvd., Murfreesboro, TN 37129 | JobSoft | VOICE: +1 615 893 0098 | Design & Development Co.| UUCP: ...!uunet!mjbtn!mjb, ...!raider!mjbtn!mjb | Murfreesboro, TN USA | DOMAIN: mjb@mjbtn.JOBSOFT.COM CIS: 76314,160 --------------------------- <KA9Q-UNIX-USERS Mailing List-Subscribe: ka9q-unix-requests@mjbtn.jobsoft.com>
peter@ficc.ferranti.com (peter da silva) (05/24/91)
In article <1991May22.180529.21358@zardoz.eng.ohio-state.edu>, gaynor@agvax2.ag.ohio-state.edu writes: > I've started seeing users who seem to believe that ... if there is no rule > stating explicitly that they cannot do such-and-such a thing, then they must > be allowed to do it. Users, hell! It's a general ethical problem in modern society... many people see no limits other than the law. They believe that if something is legal, there is no reason why anyone should be upset if they do it. Common sense, enlightened self interest, and so on don't mean anything to these people. It's not necessarily a new problem... what is new is the acceptance of this viewpoint. The idea that (for example) unless it can be shown that a member of the legislature actually broke a law there is no reason he should suffer for his action. The corresponding problem is that if something is illegal, people assume it must therefore be wrong. They forget that laws are made by people, and usually made after the fact. > A sad state... indeed. -- Peter da Silva; Ferranti International Controls Corporation; +1 713 274 5180; Sugar Land, TX 77487-5012; `-_-' "Have you hugged your wolf, today?"
dennisg@kgw1.xetron.COM (Dennis Glatting) (05/24/91)
In article <1705@aupair.cs.athabascau.ca>, lyndon@cs.athabascau.ca (Lyndon Nerenberg) writes: |> [ stuff deleted ] |> There are enough machines out there providing anonymous UUCP access |> to software archives that use of BITFTP from UUCP sites is no longer |> justifiable. If you want the software, you can bloody well pay your own |> phone line charges to pick it up. Maybe you didn't want that software so |> badly after all ... i used bitftp a fair amount. one such example is retrieving OO papers from geneva. i do pay for my phone line charges. i have a uunet account. (i assume there aren't any other charges involved). i want bitftp! |> As an example of making the user pay, about a year ago I decided to |> stop carrying the comp.binaries groups here at AU. There were a number |> of reasons for doing this: potential viruses and cost in modem time and |> disk space being two of them. When we informed the user community of |> the change there was no end of howling and bitching from the PC users |> who were used to getting all this "free software" from the net. we pitched binaries because of virus threats. |> [ remainder deleted ] -- ..!uunet!kgw2!dennisg | Dennis P. Glatting dennisg@Xetron.COM | so?
lyndon@cs.athabascau.ca (Lyndon Nerenberg) (05/24/91)
dennisg@kgw1.xetron.COM (Dennis Glatting) writes: >i used bitftp a fair amount. one such example is retrieving >OO papers from geneva. i do pay for my phone line charges. i have a >uunet account. (i assume there aren't any other charges involved). >i want bitftp! No, what you *want* is access to those files. What you are complaining about is the removal of your current user interface to getting those files. Since you are a uunet subscriber, you can still have the files ftp'd by sending an email request to ftp-request@uunet.uu.net, rather than to bitftp@whatever. All that's changed is the syntax of your request, something that is hardly worth bitching about. -- Lyndon Nerenberg VE6BBM / Computing Services / Athabasca University atha!cs.athabascau.ca!lyndon || lyndon@cs.athabascau.ca Packet: ve6bbm@ve6mc.ab.can.noam As a math athiest, I should be excused from this. --Calvin
dan@gacvx2.gac.edu (05/24/91)
In article <1991May22.180529.21358@zardoz.eng.ohio-state.edu>, gaynor@agvax2.ag.ohio-state.edu writes: > Lamentably, this is true. > > I've started seeing users who seem to believe that the law of computer usage is > "if you can do it, you're allowed." Or, more accurately, if there is no rule > stating explicitly that they cannot do such-and-such a thing, then they must be > allowed to do it. If they can get at a command that will shut down the system, > then they are allowed to do it. If they can fake mail from other users, then > they must be allowed to do so. > > A sad state... I have found that one or two of the "lets strech the rules until they break" types seem like they are more people, sometimes it seems like the abusive behavior is being done by "all the users." They get into so much trouble and take up so much of an administrators time that they just can't be one person. The most painfull one here finally was suspended for failure to maintain a satisfactory GPA. I was allowed to remove his account. I now have time to answer the questions of real users. He never caused a big problem, just near constant irritation. The other users were glad to get the 50mb he was using up filled with GIF files back too. Its not just student, I have had faculty that are worse. Ever have to share the administration of a UNIX machine with someone who pops into "su" every time he uses the machine, just because? Nough complaining. I wouldn't give any of it up, but I am happy to take it away from the ones who can't handle it. -- Dan Boehlke Internet: dan@gac.edu Campus Network Manager BITNET: dan@gacvax1.bitnet Gustavus Adolphus College St. Peter, MN 56082 USA Phone: (507)933-7596
merce@iguana.uucp (Jim Mercer) (05/24/91)
In article <1991May22.141737.26521@sceard.Sceard.COM> mrm@Sceard.COM (M.R.Murphy) writes: >50MB of VMS stuff in a 10MB spool is just another denial of service attack. >In this case it is an attack by the MBAS. Inadvertant, just trying to be >of service, genuinely trying to be useful and helpful, but still a denial of >service attack. The administration of the MBAS might be expected to know >better. To expect the user to know better is also a noble endeavour, but >probably will be disappointing. when we got hit with the VMS stuff, we investigated and found that it was user ignorance. "i didn't know it was going to be that big." MBAS was explained to him, and when we finished, i feel he had more that enough information so that he would not do it again. 6 weeks later, same user, getting some VMS uucp suite. he tells me that if our system can't handle the load, we should get out of the hub business. now, was this attack from the MBAS or the user? -- [ Jim Mercer work: jim@lsuc.on.ca home: merce@iguana.uucp +1 519 570-3467 ] [ "AIDS. Stick it in your head instead!" - Billboard seen in Toronto ] [ (it lost (gained?) something in the translation from french) ]
jeh@cmkrnl.uucp (05/24/91)
In article <1991May23.053628.17360@coplex.uucp>, dean@coplex.uucp (Dean Brooks) writes: > This would also open up the possibility of a 1-900 service for non-customers. > Basically, they would mail the request, and anon uucp the source via > anon login (on the 1-900 number). When the FTP'd software is available > for download, send mail in response notifying so. If after 48 hours > the software is not received, trash it. I, for one, would make use of such a service. --- Jamie Hanrahan, Kernel Mode Consulting, San Diego CA Chair, VMS Internals Working Group, U.S. DECUS VAX Systems SIG Internet: jeh@dcs.simpact.com, hanrahan@eisner.decus.org, or jeh@crash.cts.com Uucp: ...{crash,scubed,decwrl}!simpact!cmkrnl!jeh
blarson@blars (05/24/91)
In article <1991May18.172953.3331@chinet.chi.il.us> les@chinet.chi.il.us (Leslie Mikesell) writes: >And what's the alternative that lets me get a current directory listing >from an ftp site that has offered to make something available? Uunet >has someone that handles ftp requests, but I would feel uncomfortable >asking a person to check a remote directory on a weekly basis. It didn't >bother me at all to make such requests through bitftp. You are bothered to use a service you pay for? (If uunet loses money doing this, they can always add a surcharge.) Getting a remote directory on a weekly basis sounds like a job for cron, not a human. Tell uunet that you want it every week, and let them worry about if they prefer to do in manually or automaticly. -- blarson@usc.edu C news and rn for os9/68k! -- Bob Larson (blars) blarson@usc.edu usc!blarson Hiding differences does not make them go away. Accepting differences makes them unimportant.
peter@ficc.ferranti.com (Peter da Silva) (05/24/91)
In article <204@blars> blarson@usc.edu writes: > You are bothered to use a service you pay for? Yes. Some of us prefer to threat the people we deal with as people, rather than as machines, even if we *are* paying for that service. -- Peter da Silva; Ferranti International Controls Corporation; +1 713 274 5180; Sugar Land, TX 77487-5012; `-_-' "Have you hugged your wolf, today?"
les@chinet.chi.il.us (Leslie Mikesell) (05/25/91)
In article <EMV.91May22165647@poe.aa.ox.com> emv@msen.com (Ed Vielmetti) writes: >If you can specify exactly where the files you are interested in are, >it is straightforward to maintain a reasonably up to date shadow >directory of the remote FTP site and make that directory available for >UUCP. Updates can be handled in a number of ways [...] >Naturally you'd like to keep whatever mechanisms there are for making >sure that the file you fetch is the same as the latest version on the >server somewhat hidden from the general "rftp" user, so that your >caching will have a reasonable chance to work. No sense in going off >to bother Columbia if you have a copy handy that's the same as what >they have. If the file changes frequently and is not requested often, caching would just be a waste. Besides, bitftp at Princeton was able to scarf a 500K file from Columbia within a second of asking, according to the FTP log they send back - is it really worth storing a copy to save that second? On the other hand, it is pretty inconvenient for me to determine when that file has been changed. What you really need is a new transfer protocol that tells you up front the date and length of a file and a CRC value for the contents. If you have a matching copy, then you don't need to do the transfer at all. If your copy is shorter, you would send a CRC and the length of the piece you have and the other end would check it against the corresponding length of its copy. If the CRC matched, you could just pick up the new portion of the file, otherwise the old copy would be completely overwritten. Ideally, this protocol would work through one or more "relay" sites that would be allowed to cache locally, passing on only the initial check to the remote end point. Les Mikesell les@chinet.chi.il.us
scott@skypod.guild.org (Scott Campbell) (05/25/91)
In article <1991May22.141737.26521@sceard.Sceard.COM> mrm@Sceard.COM (M.R.Murphy) writes: >In article <1991May22.040039.21721@iguana.uucp> merce@iguana.uucp (Jim Mercer) writes: >>Goal: reduce MBAS impact on USENET >>Administrative: get MBAS's to straighten up their act. >Close. Real close. How to straighten up the act is another question. >How about having the MBAS not abuse its downstream sites unless they are >masochistic enough to accept the abuse willingly. That is, have the MBAS >check if the entire path for a transfer is cooperative. If it doesn't >know that an element of the path is cooperative, then that element should >be deemed non-cooperative, and the whole path is ng. Politely notifiy the >requestor to that effect. By "check the path", I mean "check the path." >As in "an address isn't good enough, you gotta check the path, and >every element in the path must be explicitly cooperative." Not hard to >do in software. What about a new line in everyone's map entry stating whether they will forward MBAS mail? Or perhaps a line which states the maximum number of Megs that a particular site is willing to accept? (0 would mean don't send MBAS stuff through me at all). Then MBAS's could go through the path to a user and if all the sites along the path explicitly allowed MBAS files, then it would be ok to send, otherwise - NIX. This would mean that MBAS's would have to start getting the map files (which they probably don't have, being on the internet). Anyone that REALLY wants to get MBAS mail can update their map entry and convince sites upstream to do so also. Anyone who doesn't want MBAS traffic can simply do nothing. scott -- Scott J.M. Campbell scott@skypod.guild.org Skypod Communications Inc. ..!gatech!dscatl!daysinns!skypod!scott 1001 Bay Street, Suite 1210 ..!uunet!utai!lsuc!becker!skypod!scott Toronto, Ont. (416) 924-4059 ..!epas.utoronto.ca!nyama!skypod!scott
rick@uunet.uu.net (Rick Adams) (05/25/91)
In article <22813@shlump.lkg.dec.com>, lan_csse@netrix.nac.dec.com (CSSE LAN Test Account) writes: > Ummm...UUCP over TCP has been in existence for years; quite a lot of > vendors supply it. See if your library has uucpd in it; you might also > check your /etc/services or /etc/inetd.conf files for its name. If it > exists on your system, it is a whole lot nicer than ftp. It retries if > the call doesn't go through; it does proper error checking and doesn't > hand you garbaged files; it runs easily from a script; you don't have > to do it twice because you forgot to say "binary" the first time, and > all those good things. Plus, when I've done timing tests, it has often > run 3-4 time faster than ftp for big files. > > If the BSD crowd didn't have such a bad case of NIHitis, we'd all have > it by now... Huh. UUCP over TCP was popularized by ME. (I also "invented" it. It was also "invented" inside of Bell Labs at about the same time.) I wrote the code. I integrated it into 4.2BSD. I gave it away to hundreds (of properly licensed) sites. UUCP over TCP was what kept usenet alive until nntp came along. Now, given that I freely admit to being one of the BSD crowd, exactly what is my NIHitis and how did giving code away to all comers keep "you all" from having it? ---rick
fitz@wang.com (Tom Fitzgerald) (05/25/91)
I'm running an MBAS here (flame away, I'm distributing stuff that too many people have no other way to get, and I've got load-limiters in place to keep the total volume reasonable). peter@ficc.ferranti.com (Peter da Silva) writes: > Here's another idea... how about having mail-based archive servers putting > a line that says "Class: Junk". Then if you have an expensive link you > dump junk mail going through it on the floor. You mean "Precedence:"? My pride won't let me put in "Precedence: Junk", but I'm perfectly willing to put in "Precedence: Bulk". On the other hand, if I find out that mail is being dropped as a result with no message to either me or the requester, I'll take it out again. If anyone (even a daemon) writes to me saying the load from the MBAS is too high, I'll choke it back or find another route. That's doable, once I know which system to route around. If mail mysteriously disappears somewhere, I'll force it through by disguising all the keywords that might give away the fact that it's an archive server. Actually, "Precedence: Bulk" is a pretty good thought. --- Tom Fitzgerald Wang Labs fitz@wang.com 1-508-967-5278 Lowell MA, USA ...!uunet!wang!fitz
glenn@gla-aux.uucp (Glenn Austin) (05/25/91)
In article <1991May19.214916.27412@chinet.chi.il.us>, randy@chinet.chi.il.us (Randy Suess) writes: > In article <1991May19.133104.11572@balkan.TNT.COM> wgb@balkan.TNT.COM (William G. Bunton) writes: > >And some of us, due to children or other excuses, have to have 900 > >blocking in place. > > On your uucp line? Common, be real. Yes. On our uucp line. Some of us live in locations where multiple phone lines can be prohibitively expensive (a friend would have had to pay $400 for installation PLUS $125 PER MONTH PLUS any long distance charges), or there are simply not enough lines available in the neighborhood (because everybody else has multiple lines). I'm lucky now, I have a second line, but I STILL don't permit dialup access -- my mail & news server also acts as a development machine, and I have too much time and money invested in it to have every cracker in a 50 mile radius attempting to break into my machine. =============================================================================== | Glenn L. Austin | "Turn too soon, run out of room. | | Macintosh Wizard and | Turn too late, much better fate." | | Auto Racing Driver | -- Jim Russell Racing School Instructors | |-----------------------------------------------------------------------------| | Usenet: glenn@gla-aux.uucp | CI$: 76354,1434 | | GENie: G.AUSTIN3 | AOnline: GAustin | ===============================================================================
peter@ficc.ferranti.com (Peter da Silva) (05/25/91)
In article <b5yj8p.n0l@wang.com> fitz@wang.com (Tom Fitzgerald) writes: > You mean "Precedence:"? Yeh. > My pride won't let me put in "Precedence: Junk", but I'm perfectly willing > to put in "Precedence: Bulk". On the other hand, if I find out that mail > is being dropped as a result with no message to either me or the requester, > I'll take it out again. OK, so folks who want to use the precedence field to filter traffic, make sure you send a short message to one end or the other indicating the mail was dropped so they can reroute around you. OK? I think GIFS should have Junk precedence, though. -- Peter da Silva; Ferranti International Controls Corporation; +1 713 274 5180; Sugar Land, TX 77487-5012; `-_-' "Have you hugged your wolf, today?"
merce@iguana.uucp (Jim Mercer) (05/26/91)
In article <2173@kgw2.XETRON.COM> dennisg@Xetron.COM writes: >i used bitftp a fair amount. one such example is retrieving >OO papers from geneva. i do pay for my phone line charges. i have a >uunet account. (i assume there aren't any other charges involved). just because you have an account on uunet or PSI or some other commercial connection, does not guarantee you access to any facilities on the internet. it buys you the right to demand service from your connection. but not beyond. BITFTP@pucc.princeton.edu is run by Princeton, not uunet, not PSI. other services like the NIC and the listservers are run by other organizations. if you want BITFTP style service, demand it from the people you pay money to. you cannot demand service from people that are not responsible to you. >i want bitftp! sounds a little like that Dire Straits song, "I want my, I want my, I want my BIT F T P." -- [ Jim Mercer work: jim@lsuc.on.ca home: merce@iguana.uucp +1 519 570-3467 ] [ "AIDS. Stick it in your head instead!" - Billboard seen in Toronto ] [ (it lost (gained?) something in the translation from french) ]
les@chinet.chi.il.us (Leslie Mikesell) (05/27/91)
In article <1991May26.031911.3454@iguana.uucp> merce@iguana.uucp (Jim Mercer) writes: >if you want BITFTP style service, demand it from the people you pay money to. >you cannot demand service from people that are not responsible to you. Hmmm, wasn't it *your* demand or ummm "request" that bitftp be stopped that started this thread in the first place. In what way are they responsible to you? Les Mikesell les@chinet.chi.il.us
merce@iguana.uucp (Jim Mercer) (05/27/91)
In article <1991May26.170852.10508@chinet.chi.il.us> les@chinet.chi.il.us (Leslie Mikesell) writes: >In article <1991May26.031911.3454@iguana.uucp> merce@iguana.uucp (Jim Mercer) writes: > >>if you want BITFTP style service, demand it from the people you pay money to. >>you cannot demand service from people that are not responsible to you. > >Hmmm, wasn't it *your* demand or ummm "request" that bitftp be stopped >that started this thread in the first place. neither, all i asked was how much of a net.lobby would it take to shut it down. i did not demand or request directly that they shut it down. silly me, i didn't think that i could tackle the issue alone. 8^) >In what way are they responsible to you? it was their traffic that clogged my arteries once too often. -- [ Jim Mercer work: jim@lsuc.on.ca home: merce@iguana.uucp +1 519 570-3467 ] [ "AIDS. Stick it in your head instead!" - Billboard seen in Toronto ] [ (it lost (gained?) something in the translation from french) ]
tneff@bfmny0.BFM.COM (Tom Neff) (05/28/91)
In article <1991May22.040039.21721@iguana.uucp> merce@iguana.uucp (Jim Mercer) writes: >Goal: reduce MBAS impact on USENET While we're at it, let's reduce the impact of 'sendsys' messages on mailing lists! What's that you say? News is different from mail? Indeed.
fitz@wang.com (Tom Fitzgerald) (05/29/91)
>>> Why uunet doesn't provide a service like BITFTP >>> for DIRECTLY connected customers is beyond me. asp@uunet.uu.net (Andrew Partan) writes: > If someone can write some software that can distinguish between > customer!customer-node!user > and > customer!non-customer-node!user > for all customers w/o us having to keep a database of interior customer > nodes, then we will consider running it. As a customer, I'd be delighted to have "me!user" work, and "me!anything!user" fail. Especially since I'd prefer it UUCP'd into my UUCP spool area, rather than uuencoded and mailed. Anyone inside Wang who wants it can pick it up via ftp from wang:/usr/spool/uucppublic. --- Tom Fitzgerald Wang Labs fitz@wang.com 1-508-967-5278 Lowell MA, USA ...!uunet!wang!fitz
saj@chinet.chi.il.us (Stephen Jacobs) (05/30/91)
The way to make all of this academic would be for a fair geographic distribution
of internet sites to make some kind of logins publicly available (I think Peter
daSilva suggested this already). I have no idea about workability, and
absolutely no hope that it will happen, but I'd gladly pay $50 a year for
access to a system with a couple of lines, nothing but the ftp suite enabled
(well, enough more so I could send stuff on to my machine) and all files
deleted 10 minutes after logoff (the delay to allow for logoffs by line hits).
The advantage over uucp archives is the ability to browse. It would probably
take at least 4 such sites to make it remotely practical. The whole idea is
generally along the lines of uunet's 900 number, but more focussed in purpose,
and in more locations.
I'm not shy about paying my own phone bills. But many of the packages I'd like
to check out are archived in places that don't give me that option.
Steve saj@chinet.chi.il.usvixie@decwrl.dec.com (Paul A Vixie) (05/31/91)
>> Actually, "Precedence: Bulk" is a pretty good thought.
Indeed. I'll add that to decwrl!ftpmail next time I'm hacking it.
--
Paul Vixie
DEC Western Research Lab <vixie@pa.dec.com> <paul@vixie.sf.ca.us>
Palo Alto, California, USA ...!decwrl!vixie ...!vixie!paulherrickd@iccgcc.decnet.ab.com (06/02/91)
In article <1991May22.114409.28815@chinet.chi.il.us>, randy@chinet.chi.il.us (Randy Suess) writes: > In article <1991May21.113455.23876@skypod.guild.org> scott@skypod.guild.org (Scott Campbell) writes: >>It would be trivial for an ingenious "child or other excuse" to unplug the modem >>and plug in a phone... or do you hardwire your modem to the wall? >> > > Then you have more problems other than file transfer. Try being > a parent. That is what the author of "child or other excuse" was saying when he said he had 900 blocking. dan herrick herrickd@iccgcc.decnet.ab.com
tim@qed.tcc.com (Tim Capps) (06/02/91)
jim@crom2.uucp (James P. H. Fuller) writes: > Can you say "0% reliability?" FTP to uucp-only sites doesn't work > AT ALL. What's your advice for them? "Screw you, Jack, I've got mine?" > Harrumph! > Jim > Hear, hear! I for one am really tired of seeing "oh, you can just get this via anonymous FTP". Pah. There is nothing more annoying than finding all about what you CAN'T get. ---------------------------------------------------------------------------- Tim Capps | tim@qed.tcc.com | Give The QED BBS a call! New QED Software | The QED BBS (213)420-9327 | phone number - V.32 & PEP etc. ----------------------------------------------------------------------------
randy@m2xenix.psg.com (Randy Bush) (06/03/91)
tim@qed.tcc.com (Tim Capps) writes: > Hear, hear! I for one am really tired of seeing "oh, you can just get > this via anonymous FTP". Pah. There is nothing more annoying than > finding all about what you CAN'T get. There's nothing more annoying than all those ads that show beautiful beaches ..., and say how lovely it is vacationing in Hawaii. Since I would have to pay to go there, such ads should be forbidden. qed indeed. -- randy@psg.com ..!uunet!m2xenix!randy
jeh@cmkrnl.uucp (06/03/91)
In article <VJmw32w164w@qed.tcc.com>, tim@qed.tcc.com (Tim Capps) writes: > jim@crom2.uucp (James P. H. Fuller) writes: > >> Can you say "0% reliability?" FTP to uucp-only sites doesn't work >> AT ALL. What's your advice for them? "Screw you, Jack, I've got mine?" >> Harrumph! >> Jim >> > Hear, hear! I for one am really tired of seeing "oh, you can just get > this via anonymous FTP". Pah. There is nothing more annoying than > finding all about what you CAN'T get. Of course you can get it. All you need to do is to do exactly what all the existing Internet sites have done: Pay for some form of tcp/ip link to the Internet. It may be that your budget does not allow for this. (Mine doesn't.) Fine, you can sign up with uunet, but use them ONLY for uucp'ing stuff that you ask them to grab for you via ftp. The cost for this is not all that high. Oh, you wanted to get at that stuff for free! Well... perhaps you wil feel better if you realize that THE PEOPLE WITH REAL INTERNET LINKS ARE NOT GETTING IT FOR FREE EITHER. They pay big bucks for their leased lines, 56K or T1 modems, router boxes, etc., etc., not to mention competent technical people to keep the stuff running. And when they got on the Internet they never signed anything that said "we agree to free and unlimited use of these facilities by uucp sites who want access to worldwide anon ftp archives for the cost of a local phone call". You get what you pay for. There are mechanisms by which a uucp-only site can access anon ftp archives, for a fair price that covers their hosts' costs of Internet access. All that has happened with the demise of bitftp, is that there are now fewer mechanisms by which a uucp-only site can access such archives while others (sometimes unknowingly) foot the bill for their fun. I don't see this as a major tragedy. --- Jamie Hanrahan, Kernel Mode Consulting, San Diego CA Chair, VMS Internals Working Group, U.S. DECUS VAX Systems SIG Internet: jeh@dcs.simpact.com, hanrahan@eisner.decus.org, or jeh@crash.cts.com Uucp: ...{crash,scubed,decwrl}!simpact!cmkrnl!jeh
lyndon@cs.athabascau.ca (Lyndon Nerenberg) (06/04/91)
tim@qed.tcc.com (Tim Capps) writes: >Hear, hear! I for one am really tired of seeing "oh, you can just get >this via anonymous FTP". Pah. There is nothing more annoying than >finding all about what you CAN'T get. Well then, stop pissing and moaning and get yourself an Internet connection. -- Lyndon Nerenberg VE6BBM / Computing Services / Athabasca University atha!cs.athabascau.ca!lyndon || lyndon@cs.athabascau.ca Packet: ve6bbm@ve6mc.ab.can.noam As a math atheist, I should be excused from this. --Calvin
kcoady@cup.portal.com (Kathleen Ellen Coady) (06/04/91)
I don't see why any other network should accept a file transfer request from BITNET if BITNET isn't going to accept any of theirs. When my system goes online, I'm going to bounce all such traffic from any BITNET node that doesn't provide a public login and phone number where the files they ftp to other BITNET sites can be had by everyone else for the price of the phone call.
stevef@bony1.bony.com (Steve Faiwiszewski) (06/04/91)
In article <1991Jun2.151614.65@cmkrnl.uucp> jeh@cmkrnl.uucp writes: > >Of course you can get it. All you need to do is to do exactly what all the >existing Internet sites have done: Pay for some form of tcp/ip link to the >Internet. > >It may be that your budget does not allow for this. (Mine doesn't.) Fine, >you can sign up with uunet, but use them ONLY for uucp'ing stuff that you ask >them to grab for you via ftp. The cost for this is not all that high. > > --- Jamie Hanrahan, Kernel Mode Consulting, San Diego CA >Chair, VMS Internals Working Group, U.S. DECUS VAX Systems SIG >Internet: jeh@dcs.simpact.com, hanrahan@eisner.decus.org, or jeh@crash.cts.com >Uucp: ...{crash,scubed,decwrl}!simpact!cmkrnl!jeh There is another aspect to the issue. The bank I work for can certainly afford to pay for a tcp/ip link. However, for security (read paranoid) reasons, management will never go for it. Hell, it took us months to convince management to allow us to have a uucp based mail/news feed from Uunet. Now, since we *PAY* for connection to uunet, and we *DONT* go thru anyone else's system, there would be no harm for us calling upon the services of an MBAS. Without one, we are restricted to what we can get directly from uunet, which is (naturally) far from having a complete archive. Would be nice if uunet implemented an MBAS like thing for its customers... - Steve - -- ======================================================================= Internet: stevef@bony1.bony.COM | The Bank Of New York | ~~~~~~~~~~~~~~~~~~~~ bang : uunet!bony1!stevef | Reality is Nobody's Dream
lyndon@cs.athabascau.ca (Lyndon Nerenberg) (06/05/91)
kcoady@cup.portal.com (Kathleen Ellen Coady) writes: >I don't see why any other network should accept a file transfer request from >BITNET if BITNET isn't going to accept any of theirs. When my system goes >online, I'm going to bounce all such traffic from any BITNET node that >doesn't provide a public login and phone number where the files they ftp >to other BITNET sites can be had by everyone else for the price of the >phone call. I see. How do you plan to coerce the majority of BITNET sites that are large IBM mainframes using EBCDIC character sets and NJE to support your UUCP protocol? Or even xmodem for that matter? (Does anyone out there know of a port of UUCP to MVS/CMS/??? Just the thought makes me shudder.) The BITFTP server runs on a machine that is connected to BOTH the Internet and BITNET. They pay membership dues to both networks, and are therefore entitled to make any use they desire (within the constraints of their respective network contracts) of those network connections. Since they have decided to stop forwarding to the UUCP network, you need not fear that their traffic will traverse one of your connections. I'm also curious as to how you plan on determining if the originating site is on BITNET. The only accurate way to do this is to get regular updates of the BITNET NODES tables and use that to look up each and every domain address that goes through your system to see if it is in fact a BITNET host. The trouble is, you can only get copies of that table from a BITNET host that would be willing to forward the file to you from BITNET. Since you explicitly disallow that, getting the node table will be a bit tricky, n'est ce pas? -- Lyndon Nerenberg VE6BBM / Computing Services / Athabasca University atha!cs.athabascau.ca!lyndon || lyndon@cs.athabascau.ca Packet: ve6bbm@ve6mc.ab.can.noam As a math atheist, I should be excused from this. --Calvin
les@chinet.chi.il.us (Leslie Mikesell) (06/05/91)
In article <lyndon.676060395@aupair.cs.athabascau.ca> lyndon@cs.athabascau.ca (Lyndon Nerenberg) writes: >I see. How do you plan to coerce the majority of BITNET sites that >are large IBM mainframes using EBCDIC character sets and NJE to support >your UUCP protocol? Or even xmodem for that matter? (Does anyone out >there know of a port of UUCP to MVS/CMS/??? Just the thought makes >me shudder.) Not that it has anything to do with the rest of the discussion, but kermit actually works quite well under CMS if you have dial-up access. It is pretty bizarre what it has to do to make the ASCII CRC's come out right even though it's working in EBCDIC... The recent ones even have server mode and long packet support. Les Mikesell les@chinet.chi.il.us
merce@iguana.uucp (Jim Mercer) (06/05/91)
In article <1991Jun4.151838.7885@bony1.bony.com> stevef@bony1.bony.com (Steve Faiwiszewski) writes: >Now, since we *PAY* for connection to uunet, and we *DONT* go thru >anyone else's system, there would be no harm for us calling upon the >services of an MBAS. Without one, we are restricted to what we can >get directly from uunet, which is (naturally) far from having a >complete archive. unless the MBAS is located on uunet AND uunet has direct links to all the systems it will auto-snarf files from, you can not say that you "*DONT* go thru anyone else's system". the internet is made up of many autonomous hosts and regional segments which have different priorities and policies. since you pay uunet, and not the internet as a whole, you are limited to uunet and anything beyond that is a gift. MBAS providers and members of the internet are under no contract to supply you with anything. they can extend and withdraw their services as they wish. >Would be nice if uunet implemented an MBAS like >thing for its customers... yes, it would. -- [ Jim Mercer work: jim@lsuc.on.ca home: merce@iguana.uucp +1 519 570-3467 ] [ "AIDS. Stick it in your head instead!" - Billboard seen in Toronto ] [ (it lost (gained?) something in the translation from french) ]
kcoady@cup.portal.com (Kathleen Ellen Coady) (06/05/91)
lyndon@cs.athabascau.ca writes: >How do you plan to coerce the majority of BITNET sites...to use async proto- >col, uucp, ASCII, etc...and how do you plan to identify BITNET sites? >Summary, not verbatim. I find that your question contains incorrect assumptions, starting with the use of the word 'coerce', and continuing through to the assumption that the viable way to identify a BITNET site is through a list forwarded from BITNET. As for access, implement it--or don't--any way you like; it is self- evident from the continued existence of internetwork mail and previous file transfer that neither data nor protocol is untranslatable. I am unable to discern precisely why there is no chance that I'd be handling your traffic, as I do not think it beyond the bound of reason to suppose that I might be archiving something of interest to some user on BITNET. You are of course at liberty to use your connections any way you wish; so am I, and I do not wish to forward information to someone who refuses to return the courtesy. I suggested dialup as a possible method of bypassing an uncooperative network in the event that a BITNET site chose not to isolate itself from the rest of the user community; conceivably there are better ways, and if so, I would certainly withdraw my suggestion in their favor. I am extremely sorry, but I do not intend to take further part in this discussion because I am not sure that the intent of your question was actually to elicit information. If I have misjudged your intention, I beg your pardon.
dc@dcs.qmw.ac.uk (Daniel Cohen;E303) (06/05/91)
In <1991Jun4.151838.7885@bony1.bony.com> stevef@bony1.bony.com (Steve Faiwiszewski) writes: >Now, since we *PAY* for connection to uunet, and we *DONT* go thru >anyone else's system, there would be no harm for us calling upon the >services of an MBAS. Without one, we are restricted to what we can >get directly from uunet, which is (naturally) far from having a >complete archive. Would be nice if uunet implemented an MBAS like >thing for its customers... When I was a customer of uunet, they were prepared to fetch files by anonymous ftp for me, and then mail it to me for collection with the regular delivery. I know it's not as convenient as being able to ftp things yourself but it does mean you're not limited to what you can get directly from uunet. I imagine they still provide this service to customers; ask them. -- Daniel Cohen Department of Computer Science Email: dc@dcs.qmw.ac.uk Queen Mary and Westfield College Tel: +44 71 975 5249/4/5 Mile End Road, London E1 4NS, UK Fax: +44 81 980 6533 *** Glory, Glory, Hallelujah ***
witr@rwwa.COM (Robert Withrow) (06/06/91)
In article <1991Jun5.021549.28810@iguana.uucp>, merce@iguana.uucp (Jim Mercer) writes: |In article <1991Jun4.151838.7885@bony1.bony.com> stevef@bony1.bony.com (Steve Faiwiszewski) writes: |>Now, since we *PAY* for connection to uunet...there would be no harm for |>us calling upon the services of an MBAS. |unless the MBAS is located on uunet AND uunet has direct links to all the |systems it will auto-snarf files from, you can not say that you "*DONT* go |thru anyone else's system".... since you pay uunet, and not the internet as |a whole, you are limited to uunet and anything beyond that is a gift. MBAS |providers and members of the internet are under no contract to supply you |with anything. This strikes me as a pointless (albeit true) remark, because the same can be said about any kind of direct internet access. And no one in this thread has complained about the costs ``to-the-net'' of anonymous FTP. I do not believe that a MBAS (when used as described above) increases the costs to any arbitrary internet node beyond that which results from direct internet access. It may in fact *lower* the costs; it can enforce copying-time restrictions thus decrease the load on the net. Stated another way, using a MBAS that mails the FTPd stuff *only* to directly connected sites is no more costly to the net than using anonymous FTP. Since the ``net-at-large'' seems willing to support the costs of anonymous FTP, I don't see how the ``net-at-large'' can object to such a MBAS service. BTW, UUNET *does* have a MBAS: You send them mail and ask them to FTP something. It works, but, from my experience, slowly and unreliably. -- --- Robert Withrow, R.W. Withrow Associates, Swampscott MA 01907 USA Tel: +1 617 598 4480, Fax: +1 617 598 4430, Net: witr@rwwa.COM
tim@qed.tcc.com (Tim Capps) (06/06/91)
jeh@cmkrnl.uucp writes: > In article <VJmw32w164w@qed.tcc.com>, tim@qed.tcc.com (Tim Capps) writes: > > Hear, hear! I for one am really tired of seeing "oh, you can just get > > this via anonymous FTP". Pah. There is nothing more annoying than > > finding all about what you CAN'T get. > > Of course you can get it. All you need to do is to do exactly what all the > existing Internet sites have done: Pay for some form of tcp/ip link to the > Internet. > > It may be that your budget does not allow for this. (Mine doesn't.) Fine, > you can sign up with uunet, but use them ONLY for uucp'ing stuff that you ask > them to grab for you via ftp. The cost for this is not all that high. Hey, a constructive response! Now, that's a novel thing these days! Now, that's a good idea. I hadn't thought of that. Maybe I'll do that. The only alternative I had come up with is PSI. They charge $120/mo flat fee, which is far too much, considering the amount of FTP I'd actually do (once in a blue moon). Besides, (and I know this is probably flame bait, but what the heck) based on what I have heard about the facsist contracts PSI wants you to sign, you can count me out with that company. > Oh, you wanted to get at that stuff for free! Well... perhaps you wil feel > better if you realize that THE PEOPLE WITH REAL INTERNET LINKS ARE NOT GETTIN > IT FOR FREE EITHER. They pay big bucks for their leased lines, 56K or T1 > modems, router boxes, etc., etc., not to mention competent technical people t > keep the stuff running. No, I didn't ever say that. > And when they got on the Internet they never signed anything that said "we > agree to free and unlimited use of these facilities by uucp sites who want > access to worldwide anon ftp archives for the cost of a local phone call". > > You get what you pay for. There are mechanisms by which a uucp-only site can > access anon ftp archives, for a fair price that covers their hosts' costs of > Internet access. Like I said, I never said that. Take a few deep breaths please, I got the point already. > All that has happened with the demise of bitftp, is that there are now fewer > mechanisms by which a uucp-only site can access such archives while others > (sometimes unknowingly) foot the bill for their fun. > > I don't see this as a major tragedy. Me neither. ---------------------------------------------------------------------------- Tim Capps | tim@qed.tcc.com | Give The QED BBS a call! New QED Software | The QED BBS (213)420-9327 | phone number - V.32 & PEP etc. ----------------------------------------------------------------------------
daniel@island.COM (Daniel Smith - part of the caffeine generation) (06/07/91)
In <42955@cup.portal.com> kcoady@cup.portal.com (Kathleen Ellen Coady) writes: > I don't see why any other network should accept a file transfer request from > BITNET if BITNET isn't going to accept any of theirs. When my system goes > online, I'm going to bounce all such traffic from any BITNET node that > doesn't provide a public login and phone number where the files they ftp > to other BITNET sites can be had by everyone else for the price of the > phone call. You're confused. emailing to bitftp to have that program grab a file for you is different than using ftp yourself. The whole issue is that people all over the world (including me) were taking advantage of bitftp (which was at just one site) to obtain files via email. That program's access, so to speak, is now restricted to bitnet sites. Bitnet sites accept file transfer requests if you're using ftp. Your suggestion of bouncing traffic is amusing. Are you saying that you would send a 100k back to where it came from (generating 200k total of transfers), thus further loading down any given connection? If you want to get files for the price of a phone call (and a little more), call uunet. They have a 900 number. I seconded a suggestion a while back that uunet obtain the BITFTP software, and offer it as a service to their customers. They would make a little money off of it, save some of their staff time (less time spent looking at ftp-request mail), and in turn, some of the sites that get software from uunet may make their archives available. Daniel -- daniel@island.com Daniel Smith, Island Graphics, (415) 491 0765 x 250(w) daniel@world.std.com 4000 CivicCenterDrive SanRafael MarinCounty CA 94903 dansmith@well.sf.ca.us Fax: 491 0402 Disclaimer: Hey, I wrote it, not IG! falling/yes I'm falling/and she keeps calling/me back again - IJSaF, Beatles
tim@qed.tcc.com (Tim Capps) (06/08/91)
mpd@anomaly.sbs.com (Michael P. Deignan) writes: > > <asbestos underwear on> > > jbuck@janus.Berkeley.EDU (Joe Buck) writes: > > >No, the answer for UUCP-only sites who can't anonymous FTP is to anonymous > >UUCP. There are a number of sites that provide this service; osu-cis, > >uunet (in addition to providing the service for regular customers, they > >have a 900 number so anyone can use the service). > > The problem here is that many UUCP-only sites are looking for a free ride. > > <asbestos underwear off> Uh-Huh. I'll bet you don't PERSONALLY pay for your access, now do you? I'll bet the company pays for it. If that's the case, then who is getting the free ride? ---------------------------------------------------------------------------- Tim Capps | tim@qed.tcc.com | Give The QED BBS a call! New QED Software | The QED BBS (213)420-9327 | phone number - V.32 & PEP etc. ----------------------------------------------------------------------------
jeh@cmkrnl.uucp (06/08/91)
In article <qwm435w164w@qed.tcc.com>, tim@qed.tcc.com (Tim Capps) writes: >jeh@cmkrnl.uucp writes: >> [...] >> Oh, you wanted to get at that stuff for free! [...] > >No, I didn't ever say that. Sorry, though I happened to be doing a followup to your post, that was a generic "you", referring to whoever is out there who DOES want to get it for free, or for a local phone call only. --- Jamie Hanrahan, Kernel Mode Consulting, San Diego CA Chair, VMS Internals Working Group, U.S. DECUS VAX Systems SIG Internet: jeh@dcs.simpact.com, hanrahan@eisner.decus.org, or jeh@crash.cts.com Uucp: ...{crash,scubed,decwrl}!simpact!cmkrnl!jeh
merce@iguana.uucp (Jim Mercer) (06/09/91)
In article <aX6732w164w@qed.tcc.com> tim@qed.tcc.com (Tim Capps) writes: >mpd@anomaly.sbs.com (Michael P. Deignan) writes: >> >No, the answer for UUCP-only sites who can't anonymous FTP is to anonymous >> >UUCP. There are a number of sites that provide this service; osu-cis, >> >uunet (in addition to providing the service for regular customers, they >> >have a 900 number so anyone can use the service). >> >> The problem here is that many UUCP-only sites are looking for a free ride. > >Uh-Huh. I'll bet you don't PERSONALLY pay for your access, now do you? >I'll bet the company pays for it. If that's the case, then who is getting >the free ride? he's not getting a free ride, if his company is paying for it. at least it is being paid for by someone directly related to him. if your company won't pay for your file transfers, don't expect mine to. -- [ Jim Mercer work: jim@lsuc.on.ca home: merce@iguana.uucp +1 519 570-3467 ] [ "AIDS. Stick it in your head instead!" - Billboard seen in Toronto ] [ (it lost (gained?) something in the translation from french) ]