merce@iguana.uucp (Jim Mercer) (05/15/91)
[ please note that i am under the buzz of a couple beers (a lot for me) and i really probably shouldn't be posting right now, but what the heck. ] [ see end of article for pleas for help ] [ speaking as jim@lsuc.on.ca, for reasons illustrated below ] [ lsuc.on.ca is a "central" mail hub in toronto, all connections are via dial-up, no TCP, no SLIP, just uucp ] it seems that every 6 weeks or so, some bonehead on one of our ~75 mail connections, decides to BITFTP something huge. first it was a 60 Meg VMS utility (attributed to ignorance). next it was a 12 Meg VMS uucp suite (same bonehead, attributed to lack of respect of the 'net) [ BTW: the bonehead in this case, when contacted via voice, told me "if you can handle the volume, get out of the gateway business", to which i (wished) i said "fuck you and the mutant OS you live in" ] last night it was another bonehead ordering gcc source and gas source (16 Meg) (attributed to ignorance). [ the mail processing on this bopped the load average up to 17.00+, as well as "discovering" some bad blocks on the drive which the system want's to use for inode tables. do i need this? ] i've about had my fill of this. effective now, we will be developing scanners to trash BITFTP and listserve type requests flowing via lsuc. that is requests and responses. (any hints on keywords would be appreciated) lsuc's mail/uucp system over flowed last night, resulting in unknown quantities of news and mail being dropped on the floor. coincidentally, our news partition ran out of inodes at the same time and the entire disk seems trashed. i spent an hour and a half (11:30pm - 1:00am) last night, doing damage control from at home (in kitchener). i still managed to get up and catch my bus into toronto. today (Tuesday), i spent no less than 3 hours trying to put the disk back together so we could get news and mail back up. i had to leave before the job was done (pre-natal class at 7:00pm in kitchener) and i had to leave instructions on how to shut down news before i left. when i got home, i called in and news was shut down (newsrunning off). i'm not sure what kind of news loss we'll have (major for sure) and i don't know if mail is totally functional. (the file systems were messed up) i am really peaved. [ ok jim, calm down (previous 6 lines of expletives deleted) ] Education! Education! Education! Education! Education! Education! Education! Education! we can put in place all the filters we want, but the only way to resolve this issue of file transfer by email is Education. Henry Spencer defined email at a user group meeting as (paraphrase from (currently fuzzy) memory) "text entered by hand, ie. not machine generated". file transfer by email would be fine if all of the hubs had infinite disk space for spooling stuff up to dial-up sites, but we don't. i might also note that in all 3 cases of abuse, the requested items were more than likely available locally. and if not, were of interest to the local community (ie. someone at UofToronto could have ftp'd it). please tell your users to post to the local *.general groups to see if it is local. .... 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)? or maybe, get them to limit responses to "official" internet sites? grrrrrrrrrr!!!!!!!!! this really pisses me off. HELP: i am looking for the following "tools": - Cnews spacefor that checks remaining inodes as well as free blocks - efficient rmail frontend which will "act" on key phrases in the To: and From_ headers - how to mark bad blocks on a 3B2/500 (SysV 3.2.1) please reply to jim@lsuc.on.ca (as i have tried to set the Reply-To: header) thanx -- [ Jim Mercer work: jim@lsuc.on.ca home: merce@iguana.uucp +1 519 570-3467 ] [ "Anarchists Unite!" - seen spray painted on a wall ]
carlo@electro.com (Carlo Sgro) (05/15/91)
In article <1991May15.042146.29800@iguana.uucp> jim@lsuc.on.ca (Jim Mercer) writes: >it seems that every 6 weeks or so, some bonehead on one of our ~75 mail >connections, decides to BITFTP something huge. My sympathies. We are a smaller site with a few connections and plenty of disk space but no modem power (2400 baud max. speed). We have had so many problems with people using BITFTP (and other large file transfer) tying up our lines (and our main feeds' lines) that we have had to drastically restrict mail through our site. Luckily, we have had cooperation from those connected to us (and those downstream from them). >effective now, we will be developing scanners to trash BITFTP and listserve >type requests flowing via lsuc. I'm sure that I and many others would be interested in this, but ... >we can put in place all the filters we want, but the only way to resolve this >issue of file transfer by email is Education. > ... >i might also note that in all 3 cases of abuse, the requested items were more >than likely available locally. and if not, were of interest to the local >community (ie. someone at UofToronto could have ftp'd it). Damn right! There are people out there who believe that having a modem and a UUCP connection means that they have god-given rights to do whatever they want. There are many, many more that don't believe anything much but just fail to think before they act. We at Electrohome might seem like a large company with money to spend on Telebits and disks and the such. However, there are private systems who have better setups than we do. The bean-counters don't know anything about UUCP connectivity. We're probably lucky for that. However, it also means that a Telebit is something that I've tried to get for almost 3 years. We depend on the good grace of the large sites to which we connect. We simply don't have the resources and can't risk losing the good grace of our neighbours by transferring large reams of BITFTP stuff that could be more easily obtained by using a bit of resourcefulness. >please tell your users to post to the local *.general groups to see if >it is local. Would it be a desirable thing to set up local groups specifically for this sort of thing? I would think that it would be easier for a neophyte leaf admin to find out about kw.software (as an example) than to find out about BITFTP. -- Carlo Sgro Not a card-carrying member of the watmath!watcgl!electro!carlo Laurie Bower Singers Fan Club. carlo@electro.com System Administrator, Electrohome, Ltd., Kitchener, ON, (519)744-7111x7210
karl.kleinpaste@osc.edu (05/15/91)
merce@iguana.uucp writes:
[ please note that i am under the buzz of a couple beers
I dunno, I kinda think that such a buzz might be just the thing after
fighting BITFTP-assaulted systems for a day or three.
I wrote a similar flame regarding MBASes last December; I got a lot of
support, but I also got a lot of abuse for, e.g., "not helping the
users put the system to use properly." I would like to know from
where such a definition of "properly" derives.
first it was a 60 Meg VMS utility
next it was a 12 Meg VMS uucp suite
last night it was...gcc source and gas source
The local offenders from my neck of the woods tend to want
GNU Emacs
_All_ the RFCs
Every service document the NIC has.
A horde of Amiga and Mac things
"ls -lR" listings of every ftp site known to humankind.
and of course a wide selection of less common things.
Education!
Educating email users in the etiquette of "intermediate link non-abuse"
is like educating new Usenet users: You can't explain it to them until
they've screwed up, usually pretty badly. Until then, they think
they're somehow immune from any social side effects of what they do.
please tell your users to post to the local *.general groups to see if
it is local.
What if the community in question hasn't access to a Usenet system?
(Mine doesn't. It's CompuServe. No news. Not like this, anyway.)
how much of a net.lobby do we have to do to get pucc.princeton.edu to shut
down BITFTP?
I don't want it shut down; I want it made load-sensitive. A variety
of schemes can be used for that, which were discussed last December.
- efficient rmail frontend which will "act" on key phrases in the To: and
From_ headers
Either hack the rmail from the Berkeley sendmail distribution, or use
something like smail 2.5 and hack its operation when invoked as rmail
to do what you want. Most of what you need to do can be done without
peeking at the header at all; just operate on the envelope.
--karlstanley@phoenix.com (John Stanley) (05/15/91)
merce@iguana.uucp (Jim Mercer) writes: > [ lsuc.on.ca is a "central" mail hub in toronto, all connections are via > dial-up, no TCP, no SLIP, just uucp ] > > lsuc's mail/uucp system over flowed last night, resulting in unknown quantiti > of news and mail being dropped on the floor. > > coincidentally, our news partition ran out of inodes at the same time and > the entire disk seems trashed. > > we can put in place all the filters we want, but the only way to resolve this > issue of file transfer by email is Education. The only way to solve the problem is to teach uucico to keep track of free space and inodes, and to stop accepting anything until there is space. "Can't tango - no space". And to notify the admin about the problem. This would solve the problem since uucico would happily pass the mail on, news would unbatch and expire, and then there would be space for more. This would even be a beneficial thing all around. It would provide a load averaging mechanism. The size of the transfer is known to the sender, and could easily be passed to the reciever. The receiver could easily check for space. It could even be set up to leave X amount. This is probably in some of the more advanced protocols. The fact that it is not in 'g' is depressing, and is the real source of your trouble. BTW, if anyone knows where I can get a uucico for MS-DOS that DOES use a protocol that fixes this, please let me know. What will you do when someone posts a request for something and dozens of people mail it to him? > how much of a net.lobby do we have to do to get pucc.princeton.edu to shut > down BITFTP? No! This is a valuable service to the entire UUCP community. Well, at least it is here. Your problem (which is the same problem here, BTW) is that a UUCP connection will happily accept that which it cannot store. The BITFTP connection is just a symptom.
tower@buitc.bu.edu (Leonard (Len) H. Tower Jr.) (05/16/91)
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. 50k an hour? That requires them to have a lot of spooling space, but would limit the harm done small systems who forward mail themselves. Brian Reid's mail-based server (in use at a lot of Unix sites) does something like this on a per-address basis. You might also see if you can configure your mailer to bounch (or bit-bucket (if you want to be rude)) messages larger then a certain size (64k is traditional between UUCP hosts, though I've seen limits as small as 25k from some of the oversea gateway machines). I personally think any mail-based server that distributes any large packages (source, data, et al) is doing a dis-service to the Matrix (the world wide net as defined by John Quarterman). It causes sites who are willing to enlarge the community by passing small quantities of human generated mail along to stop cooperating due to resource use much larger then they can handle. This makes the net a smaller and less useful community for all of us. thanx -len
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?"
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? >
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 ------------------------------------- -----------------------------------------
merce@iguana.uucp (Jim Mercer) (05/17/91)
In article <ZN9Z22w163w@phoenix.com> stanley@phoenix.com (John Stanley) writes: >merce@iguana.uucp (Jim Mercer) writes: >> we can put in place all the filters we want, but the only way to resolve this >> issue of file transfer by email is Education. > > The only way to solve the problem is to teach uucico to keep track of >free space and inodes, and to stop accepting anything until there is >space. "Can't tango - no space". And to notify the admin about the >problem. This would solve the problem since uucico would happily pass >the mail on, news would unbatch and expire, and then there would be >space for more. changing uucico is not solving the problem of MBAS abuse. it solves the problem of low spool space. this can also be solved by throwing hardware at it. the point is that we are providing email forwarding services as a benefit to the local uucp community, who by and large use it in a reasonable manner. it's assholes and ignoramuses who absolutely positively have to have THAT file, but are not willing to pay their own way. email is for messaging, not file transfers. > What will you do when someone posts a request for something and >dozens of people mail it to him? again, email is for messaging, not file transfers. >> how much of a net.lobby do we have to do to get pucc.princeton.edu to shut >> down BITFTP? > > No! This is a valuable service to the entire UUCP community. Well, at >least it is here. No! BITFTP is a terrible DIS-service to the entire UUCP community. talk to the sites in Ontario, Canada, who are possibly going to lose all internet connectivity partially due to increased mail volume (ie. BITFTP). > Your problem (which is the same problem here, BTW) is that a UUCP >connection will happily accept that which it cannot store. The BITFTP >connection is just a symptom. excuse me? -- [ Jim Mercer work: jim@lsuc.on.ca home: merce@iguana.uucp +1 519 570-3467 ] [ "Anarchists Unite!" - seen spray painted on a wall ]
karl.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.]
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
stanley@phoenix.com (John Stanley) (05/18/91)
merce@iguana.uucp (Jim Mercer) writes: > In article <ZN9Z22w163w@phoenix.com> stanley@phoenix.com (John Stanley) write > > changing uucico is not solving the problem of MBAS abuse. it solves the > problem of low spool space. > > this can also be solved by throwing hardware at it. Throwing hardware at it solves nothing. As long as uucico accepts more data that can be stored on disk, you are vulnerable to uucico filling your spool area. You are BETTING that when you have more hardware it won't happen, but until you fix uucico, it can. You are not the only one in this situation. I learned the hard way at this site that uucico is untrustworthy. When it happened to me, I didn't blame USENET and tell everyone to stop posting. I "fixed" the uucico I have by running it only under supervision. Since that time, I have NEVER suffered a filled spool. There are two kinds of admins on the net: those who have had uucico hose them, and those that will have it happen. Here is a question for all admins. I am writing a software package that will run unattended. Output from this package is saved to disk, and is based on automatic external input. (E.g. data logger that logs significant events at a nuke plant.) I have written this software with the knowledge (i.e. it's a fact!) that normal nuke operations will never generate too much data to be loggable to disk, and so I have not written in any tests to make sure that there is enough disk space for logging. How many admins think this is a failure waiting to happen? How many admins would be on the phone to me, or their lawyers, about it? Now, everyone who has their hands up on the last one, why is uucico different? > the point is that we are providing email forwarding services as a benefit > to the local uucp community, So do many others. > it's assholes and ignoramuses who absolutely positively have to have THAT > file, but are not willing to pay their own way. If you have a problem with the users of your system, take it up with them. Don't come out into the world and demand that everyone else give up what they have just because you can't afford to give it to your users. If you want THEM to pay their way, well, then, CHARGE THEM. With all the lawyers you must have floating around there, the legal issues certainly wouldn't be a problem. > email is for messaging, not file transfers. Email is for what the users email. When someone asks me, in mail, for the frequencies for cable channels, am I supposed to type it in or am I allowed to send him the FILE I have already typed in? Is he now prohibited from saving this information in a FILE, because "email is for messaging, not file transfers."? Email is an analog to paper mail, and sometimes people mail books. > > What will you do when someone posts a request for something and > >dozens of people mail it to him? > > again, email is for messaging, not file transfers. Respond to the question. People are already posting requests for files to be mailed to them as a direct result of you getting BITFTP shut off. What will you do when your spool fills up from people mailing files to each other? You are going to cut off mail. Then people will be asking for stuff to be posted. Blam! No more news. That's the only real solution to your problem, you know. Don't. > >> how much of a net.lobby do we have to do to get pucc.princeton.edu to shut > >> down BITFTP? > > > > No! This is a valuable service to the entire UUCP community. Well, at > >least it is here. > > No! BITFTP is a terrible DIS-service to the entire UUCP community. Your uucico hosed you while transferring BITFTP mail, so BITFTP is bad for everyone. That is a grand-daddy of over-generalizations. BITFTP makes available a huge amount of information, much of which is not available in any other way. Alot of the traffic on USENET (one of those UUCP things, you know) is eliminated by the single posting "X is available via anonymous ftp at A.B.C.D." The fact that YOU might have to pass the same thing twice or thrice is more than compensated for by all the things you won't have to carry AT ALL because they weren't posted. When EVERY anonymous ftp site is also available via a mailserver, THEN you can argue that BITFTP is of NO service to UUCP. It will be a long time before that happens. Those who set up anon-ftp sites tend to think in terms of Internet and forget about anyone who can't ftp. You will NEVER be able to make that 'DIS-service' claim stick. > talk to the sites in Ontario, Canada, who are possibly going to lose all > internet connectivity partially due to increased mail volume (ie. BITFTP). And just how is BITFTP going to increase your mail volume when it no longer accepts mail requests? Or is this your threat for when human generated mail fills your spool? If I were one of these sites I would start looking for another feed right now, because you have already indicated that you aren't happy carrying their mail and are looking for the next available excuse to cut it totally. > > Your problem (which is the same problem here, BTW) is that a UUCP > >connection will happily accept that which it cannot store. The BITFTP > >connection is just a symptom. > > excuse me? There is none. You bitched about your spool area filling up, mail and news being lost, and your disk being trashed. You blamed users downstream from you, and BITFTP. If YOUR uucico didn't accept more stuff from your feed than there was room on your disk, your disk wouldn't have been trashed, mail and news would not have been lost, and your spool area wouldn't have filled. Your system would have processed what it could, and then, when there was space, would accept more. If you have a problem with supplying mail service to people that causes your disks to fill, then fix your uucico so it doesn't fill your disks. If you have a problem because you think your users should pay their own way, charge them. Don't supply mail services to your users and then tell them that they can't use them, and worse, don't tell the rest of the world not to do something just because you can't handle it.
stanley@phoenix.com (John Stanley) (05/18/91)
karl.kleinpaste@osc.edu writes: > 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?" Based on past experience with PSI, and on the posting from them on this matter, I can predict with certainty what their response will be were I to ask them to do something like that. "Pay us more money and you can ftp it yourself." (Past experience: when PSI was hyping their telnet-able white pages, I asked if there was a way that UUCP sites could access it. The answer was "Pay us more money for a higher level account." )
moraes@cs.toronto.edu (Mark Moraes) (05/18/91)
stanley@phoenix.com (John Stanley) writes: > No! This is a valuable service to the entire UUCP community. Well, at >least it is here. Ironic. It was intended for the Bitnet community (who play by different rules and have size grading on files, er, virtual card decks). I agree that it would be a valuable service for uunet/uupsi/your-favourite-internet-uucp-service-provider to make a mail based archive service available for their directly connected customers. (I thought uunet already did this) Take that up with them. (I just hope they implement it to cope with several hundred people simultaneously requesting the X.V11R5 distribution :-) Most complaints about mail based archive servers (MBAS) come from the people who provide free uucp connections to their neighbours to improve mail connectivity or because they're nice folk who think a global network is A Good Thing. Usually these people two or three hops upstream from the eventual destination of the MBAS mail. The difficulty is both disk space and modem time tied up by large file xfers. UUCP isn't packet switched, alas. Not much flow control either. Picture all those files from the MBAS piling up behind a Telebit which is the 100Kbps -> 10Kbps chokepoint! At present, we keep logs on MBAS traffic and send "please don't route this mail through us" messages to people who are recipients of a lot of such traffic. It seems to be working fairly well, except for the occasional glitch (the mail Jim was complaining about passed through us too!) and the human cost in monitoring the logs. An option we're considering is to modify our mailer to downgrade messages greater than M Kbytes and remove downgraded messages if they're older than N hours. (may as well learn from Bitnet :-) More human cost, but then, one of utai's postmasters is interested in exploring the frontiers of mailer science! Mark. -- "Coping with Mail Based Archive Servers" -- coming soon to a thesis near you.
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 ]
andy@mks.com (Andy Toy) (05/18/91)
In article <1991May15.135732.9749@electro.com> carlo@electro.UUCP (Carlo Sgro) writes: >Would it be a desirable thing to set up local groups specifically for this >sort of thing? I would think that it would be easier for a neophyte leaf >admin to find out about kw.software (as an example) than to find out about >BITFTP. There have been occasional postings in ont.archives, can.usrgroup, and {kw,ont,can}.uucp newsgroups asking for software locally. It may be desirable to have local newsgroups with more descriptive and consistent names. Otherwise, use the existing local *.uucp and *.archives newgroups. -- Andy Toy, Department of Computing Services, Extension 31, second floor annex
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?"
peter@ficc.ferranti.com (Peter da Silva) (05/18/91)
In article <qqD524w163w@phoenix.com> stanley@phoenix.com (John Stanley) writes: > Now, everyone who has their hands up on the last one, why is uucico > different? 'tisn't. That's why it's apparently fixed in the more recent HDB uucps. At least that's the behaviour I've observed. -- 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!gsh7wgws@xenitec.on.ca (Geoff Scully) (05/19/91)
In article <qqD524w163w@phoenix.com> stanley@phoenix.com (John Stanley) writes: >merce@iguana.uucp (Jim Mercer) writes: > >> In article <ZN9Z22w163w@phoenix.com> stanley@phoenix.com (John Stanley) write >> >> changing uucico is not solving the problem of MBAS abuse. it solves the >> problem of low spool space. >> >> this can also be solved by throwing hardware at it. > > Throwing hardware at it solves nothing. As long as uucico accepts >more data that can be stored on disk, you are vulnerable to uucico >filling your spool area. You are BETTING that when you have more >hardware it won't happen, but until you fix uucico, it can. > Can and will are different things. Fixing uucico (umpteen different versions from umpteen different vendors) and ensuring that the new uucico is widely distributed to the installed base of UUCP connected Usenet sites is not by any stretch of the imagination, a possibility. At least in the short term. Not that it is a bad idea, just that it does not solve the immediate problem. > You are not the only one in this situation. I learned the hard way at >this site that uucico is untrustworthy. When it happened to me, I didn't >blame USENET and tell everyone to stop posting. I "fixed" the uucico I >have by running it only under supervision. Since that time, I have NEVER >suffered a filled spool. There are two kinds of admins on the net: those >who have had uucico hose them, and those that will have it happen. > Hahahaha. John, I don't know how much of a downstream you have, but for sites like xenitec (with ~25 downstream) and lsuc (with ~75 downstream) the idea of only running uucico under supervised conditions is absurd. >> the point is that we are providing email forwarding services as a benefit >> to the local uucp community, > > So do many others. > >> it's assholes and ignoramuses who absolutely positively have to have THAT >> file, but are not willing to pay their own way. > > If you have a problem with the users of your system, take it up with >them. Don't come out into the world and demand that everyone else give >up what they have just because you can't afford to give it to your >users. If you want THEM to pay their way, well, then, CHARGE THEM. With >all the lawyers you must have floating around there, the legal issues >certainly wouldn't be a problem. > The point is not that we want to CHARGE them, but rather that we want them to be respectful of the fact that we provide them with a service WITHOUT CHARGING them. No one needs the headaches of administering the accounting for this in addition to administering a mail hub. >> email is for messaging, not file transfers. > > Email is for what the users email. When someone asks me, in mail, for >the frequencies for cable channels, am I supposed to type it in or am I >allowed to send him the FILE I have already typed in? Is he now >prohibited from saving this information in a FILE, because "email is for >messaging, not file transfers."? Email is an analog to paper mail, and >sometimes people mail books. > There is a big difference between a list of cable freqs and ~60 MEG of sources. Oh, and BTW, when you send a book to somebody, do you send it to somebody 1/3 of the way and then ask them to pay the price in time and stamps to have it continue its journey? Not likely. You send it directly to the destination, paying the postage yourself. Again, email is not and was not ever intended as a way to send huge files over a store and forward network. >> > What will you do when someone posts a request for something and >> >dozens of people mail it to him? >> >> again, email is for messaging, not file transfers. > > Respond to the question. People are already posting requests for >files to be mailed to them as a direct result of you getting BITFTP shut >off. What will you do when your spool fills up from people mailing files >to each other? You are going to cut off mail. Then people will be asking >for stuff to be posted. Blam! No more news. > What a totally stupid and reactionist view this is. You still operate under the assumption that the user making such a request has any business doing so. Jim did respond to the question. Sending large file transfers over a store and forward email network is evil. Period. If I got such a request (or found one from my downstream in the news), I would either advise him that I had these files for him, or advise him as to where it is available and tell him to establish a direct connect to the site that has it. He has no business expecting me or my upstream to pay for his wants and needs. Oh, and before somebody mentions that news is a store and forward method of large file transfer, I know this. I have allocated 200Mb of news spool for this purpose. I have only allocated ~70 Mb for mail. If my news spool overflows and drops some news on the floor, this is a hassle, but if my mail spool overflows and drops mail on the floor, I and probably many of my downstream users would be rightly pissed off. >> >> how much of a net.lobby do we have to do to get pucc.princeton.edu to shut >> >> down BITFTP? >> > >> > No! This is a valuable service to the entire UUCP community. Well, at >> >least it is here. >> >> No! BITFTP is a terrible DIS-service to the entire UUCP community. > > Your uucico hosed you while transferring BITFTP mail, so BITFTP is >bad for everyone. That is a grand-daddy of over-generalizations. > As Jim mentions below, BITFTP has hosed many more than just lsuc's spool, and as a result, (admittedly only partially due to this), all of Ontario is facing termination of our access to (free) Internet mail forwarding. It is not an over-generalization. All of our downstream will suffer when this happens. Oh, and this access will still be cut off even though the BITFTP server at princeton now does The Right Thing. It was abused and now we will all pay for it reagardless. The volume brought it to the attention of the bean counters at the organization that runs the IP service in this province that alot of people were getting alot of stuff for free, so now we will get *NOTHING* for free. > BITFTP makes available a huge amount of information, much of which is >not available in any other way. Alot of the traffic on USENET (one of >those UUCP things, you know) is eliminated by the single posting "X is >available via anonymous ftp at A.B.C.D." The fact that YOU might have to >pass the same thing twice or thrice is more than compensated for by all >the things you won't have to carry AT ALL because they weren't posted. > Bullshit. At some point in time, most everything that is available *immediately* by FTP will be available *eventually* via the normal UseNet distribution method. The point is, if you want it *now*, you pay for it, not me. If you are willing to wait, I am willing to dedicate resources on my machine to bring it in (and in many cases archive it for anon-uucp) via UseNet. For those things that don't make it to UseNet and are not available any other way (anon-uucp, tapes, etc) all I can say is "Too Bad." You are deprived of the *priviledge* of using that free software because you can't get it. You do not have a *right* to have that software, and you certainly don't have a right to have it at my expense. Oh, and for those people (like Peter) who complain about how much of a hassle it is to set up direct connects to anon-uucp sites to do these transfers, all I can say is, tuff luck. Compare the cost of you doing this to the cost of buying a router and leased line to an AlterNet (or equiv) Point Of Presence and doing the FTP yourself. All I will say is that I will not save you the time and money by spending my time and money. > When EVERY anonymous ftp site is also available via a mailserver, >THEN you can argue that BITFTP is of NO service to UUCP. It will be a >long time before that happens. Those who set up anon-ftp sites tend to >think in terms of Internet and forget about anyone who can't ftp. > There is a reason for this. Get it straight once and for all. FTP IS AN INTERNET SERVICE!!! IT WAS DESIGNED TO TRANSFER FILES BETWEEN DIRECTLY CONNECTED HOSTS COMMUNICATING AT HIGH SPEED. IT WAS NOT DESIGNED TO BE USED BY STORE AND FORWARD NETWORKS! PERIOD. At the point in time where even a sizable minority of anon-ftp sites provide mail-servers, I will go out of my way to scan pass-through mail traffic, perhaps even partially manually, and ensure that any such requests passing through me promptly hit the floor. I doubt that I will have to do much of this, because my upstream will catch most of them before I do and drop them on the floor for me. >> talk to the sites in Ontario, Canada, who are possibly going to lose all >> internet connectivity partially due to increased mail volume (ie. BITFTP). > > And just how is BITFTP going to increase your mail volume when it no >longer accepts mail requests? Or is this your threat for when human >generated mail fills your spool? If I were one of these sites I would >start looking for another feed right now, because you have already >indicated that you aren't happy carrying their mail and are looking for >the next available excuse to cut it totally. > He never said he didn't want to carry their mail, he said he is unwilling to have their 60Mb file transfers trashing his file systems and wasting 3 days of his time. Human generated *MAIL* will NEVER fill my spool, short of some idiot mailbombing a user here or downstream of me. That problem can be quickly solved with a phone call to the offending site's upstream admin. Those few who have tried this in the past have rapidly found out that they made a big mistake. If you were on my downstream you would not have to worry about making the decision to look for another site to connect to, as I would have already dropped you with this attitude. 'Nuff said. --g --- Geoff Scully Support Services -- XeniTec Consulting Services Internet: gws@xenitec.on.ca UUCP: ..!{uunet!}watmath!xenitec!gws "We need to look at what we owe each other, rather than what we can make off each other." Bob Rae, National Disaster Party, Ontario Premier elect. 09/06/90
merce@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
les@chinet.chi.il.us (Leslie Mikesell) (05/19/91)
In article <ZN9Z22w163w@phoenix.com> stanley@phoenix.com (John Stanley) writes: > The only way to solve the problem is to teach uucico to keep track of >free space and inodes, and to stop accepting anything until there is >space. "Can't tango - no space". The SysVr3 HDB uucp uucico will refuse to accept files if there isn't enough space. But if the last file that came in more than half filled the remaining spool space, uuxqt will still happily try to pipe it to rmail (or whatever) and delete it after the receiving program chokes. At least in this scenario there is a chance of the program being able to queue up an error message about it in the mail. Les Mikesell les@chinet.chi.il.us
stanley@phoenix.com (John Stanley) (05/19/91)
merce@iguana.uucp (Jim Mercer) writes: > too fucking bad, better your money/time/disk than mine. If you don't want to be a mail server, then stop doing it. If you don't want to carry mail to or from bitftp, don't do it. If you can't handle the traffic, then get out of the kitchen. Don't demand that the world stop just because you want off.
stanley@phoenix.com (John Stanley) (05/19/91)
merce@iguana.uucp (Jim Mercer) writes: > In article <30EBM2G@xds13.ferranti.com> peter@ficc.ferranti.com (Peter da Sil > can you say "a cost of doing business" ? > > i thought you could. Why do you expect HIM to say 'cost of doing business' when you refuse to?
smd@lsuc.on.ca (Sean Doran) (05/19/91)
In an article (Message-Id: <1991May17.041635.4503@iguana.uucp>), merce@iguana.uucp (Jim Mercer) wrote: | In article <ZN9Z22w163w@phoenix.com> stanley@phoenix.com (John Stanley) writes: [...] | it's assholes and ignoramuses who absolutely positively have to have THAT | file, but are not willing to pay their own way. More to the point, it's people who have to have THAT file, and who do not consider that intermediate sites ought to be consulted before it is ordered that cause the most problems. If people who have to have big files took the trouble to ask around locally, they'd probably find it somewhere much closer than BITFTP@PUCC.PRINCETON.EDU. If the people who had ordered huge VMS files or gcc/gas had asked us first, we would have pointed them at the University of Toronto or taken steps to uucp the files directly to them. Instead, they (like many proponents of BITFTP) argue that BITFTP is an essential service, and that intermediate sites for some reason ought to be able to handle 16 Mbytes worth of extra data, just go ahead and grab files willy-nilly. The only time that intermediate sites generally ever learn of MBAS activity is when it is drawing attention to itself (i.e., causing problems). It's mostly people who lack courtesy and respect for intermediate sites and their sysadmins/postmasters who are really irritating. | email is for messaging, not file transfers. Unless _everyone_ along the way gives a direct OK to a file transfer. | > What will you do when someone posts a request for something and | >dozens of people mail it to him? If the somebody had been thinking, she or he would have asked for tips on where to find the material in question, rather than posting a "please send XYZ to me" message. This sort of courtesy is something that does not always manifest itself in many users. "Education", Jim's watchword, is the key here. | >> how much of a net.lobby do we have to do to get pucc.princeton.edu to shut | >> down BITFTP? | > | > No! This is a valuable service to the entire UUCP community. Well, at | >least it is here. | | No! BITFTP is a terrible DIS-service to the entire UUCP community. That's true given that it is (was?) a well advertised way to grab files so easily that inexperienced users could quickly become inconsiderate users. All MBASes which don't follow the rules that Brian Kantor recently posted for his MBAS (i. Send to neighbouring sites; ii. Send to sites directly on the Internet; iii. Send to sites directly connected to uunet) firstly make it very difficult to predict the path that the MBAS will choose, and secondly makes it impossible for the MBAS to know whether any intermediate sites might get crunched. | talk to the sites in Ontario, Canada, who are possibly going to lose all | internet connectivity partially due to increased mail volume (ie. BITFTP). Alternatively, talk to the sites in Ontario face the prospect of paying $500/a to our Regional Internet (ONet) if they want to send or receive mail across it. The policy is justified by pointing out that the unconnected UUCP sites in Ontario are getting service from ONet that they aren't paying for, to the detriment of the ONet co-operative and its member-organizations. | > Your problem (which is the same problem here, BTW) is that a UUCP | >connection will happily accept that which it cannot store. The BITFTP | >connection is just a symptom. No, John Stanley, the problem here is that people do not think of the consequences of ordering huge files across a store-and-forward network of UUCP sites (and an often costly one, too) and even if they do, they don't bother to even advise sites along the way that they'd like to order something big that will be travelling through them. A simple note to the postmaster of every mail-handling site between you and BITFTP saying: ``I would like to order file xyz from BITFTP. It will probably travel back through you. Is that OK?'' is a good idea. It's an especially good idea, given that one of those postmasters might have a copy that doesn't have to be chopped up and mailed to you, but can be uucped directly. | [ Jim Mercer work: jim@lsuc.on.ca home: merce@iguana.uucp +1 519 570-3467 ] | [ "Anarchists Unite!" - seen spray painted on a wall ] -- Sean Doran <smd@lsuc.ON.CA> la Commission des Jeunes liberaux du Canada
merce@iguana.uucp (Jim Mercer) (05/19/91)
In article <qqD524w163w@phoenix.com> stanley@phoenix.com (John Stanley) writes: >merce@iguana.uucp (Jim Mercer) writes: >> it's assholes and ignoramuses who absolutely positively have to have THAT >> file, but are not willing to pay their own way. > > If you have a problem with the users of your system, take it up with >them. Don't come out into the world and demand that everyone else give >up what they have just because you can't afford to give it to your >users. If you want THEM to pay their way, well, then, CHARGE THEM. With >all the lawyers you must have floating around there, the legal issues >certainly wouldn't be a problem. oh, for the days of old, when money wasn't the root of all things on the net. i don't want to charge anyone anything. i just want them to be reasonable. >> >> how much of a net.lobby do we have to do to get pucc.princeton.edu to shut >> >> down BITFTP? >> > >> > No! This is a valuable service to the entire UUCP community. Well, at >> >least it is here. >> >> No! BITFTP is a terrible DIS-service to the entire UUCP community. > > Your uucico hosed you while transferring BITFTP mail, so BITFTP is >bad for everyone. That is a grand-daddy of over-generalizations. ok, i should have used the term MBAS. my uucico works perfectly fine for normal loads, as it does on literally thousands of other systems. (it just so happens that the only 3 times our uucp spool overflowed, they were all caused by BITFTP transfers.) > BITFTP makes available a huge amount of information, much of which is >not available in any other way. Alot of the traffic on USENET (one of >those UUCP things, you know) is eliminated by the single posting "X is >available via anonymous ftp at A.B.C.D." The fact that YOU might have to >pass the same thing twice or thrice is more than compensated for by all >the things you won't have to carry AT ALL because they weren't posted. news and mail are two different systems. news is better able to handle large transfers. > When EVERY anonymous ftp site is also available via a mailserver, >THEN you can argue that BITFTP is of NO service to UUCP. It will be a >long time before that happens. Those who set up anon-ftp sites tend to >think in terms of Internet and forget about anyone who can't ftp. you seem to be stuck on another point here. i would prepare that all mailservers (for files) be dropped. they are a plague on the email portion of the network. > You will NEVER be able to make that 'DIS-service' claim stick. the users will probably not like it, but i'm getting a lot of support from admins out there. >> talk to the sites in Ontario, Canada, who are possibly going to lose all >> internet connectivity partially due to increased mail volume (ie. BITFTP). > > And just how is BITFTP going to increase your mail volume when it no >longer accepts mail requests? the problems started way before BITFTP was shut down to user outside of BITNET and EARN. >Or is this your threat for when human >generated mail fills your spool? If I were one of these sites I would >start looking for another feed right now, because you have already >indicated that you aren't happy carrying their mail and are looking for >the next available excuse to cut it totally. i have not dropped any of the sites related to the BITFTP abuse through our system. i have no problem with regular mail volume, or even mailinglist explosion. >> > Your problem (which is the same problem here, BTW) is that a UUCP >> >connection will happily accept that which it cannot store. The BITFTP >> >connection is just a symptom. >> >> excuse me? > > There is none. You bitched about your spool area filling up, mail and >news being lost, and your disk being trashed. You blamed users >downstream from you, and BITFTP. If YOUR uucico didn't accept more stuff >from your feed than there was room on your disk, your disk wouldn't have >been trashed, mail and news would not have been lost, and your spool >area wouldn't have filled. Your system would have processed what it could, >and then, when there was space, would accept more. the problem is not a lack of disk space, but an abundance of traffic. why should i fix my software, if it handles what it was designed for. if you want to redesign the uucp systems, you have a lot of work ahead of you. BTW: my file systems overflowed because of the way news and mail are piped around. if this had been straight file copies, the system would have shut down the modem sooner. >Don't supply mail services to your users and >then tell them that they can't use them, and worse, don't tell the rest >of the world not to do something just because you can't handle it. they can use them, just not abuse them. i read this on the net a long time ago, read it and think about it. abuse of email causes bad karma. -- [ 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/19/91)
In article <1991May18.192000.6202@xenitec.on.ca> gws@xenitec.on.ca (Geoff Scully) writes: >In article <qqD524w163w@phoenix.com> stanley@phoenix.com (John Stanley) writes: >>merce@iguana.uucp (Jim Mercer) writes: >>> email is for messaging, not file transfers. >> >> Email is for what the users email. When someone asks me, in mail, for >>the frequencies for cable channels, am I supposed to type it in or am I >>allowed to send him the FILE I have already typed in? Is he now >>prohibited from saving this information in a FILE, because "email is for >>messaging, not file transfers."? Email is an analog to paper mail, and >>sometimes people mail books. >> > >There is a big difference between a list of cable freqs and ~60 MEG of >sources. Oh, and BTW, when you send a book to somebody, do you send it to >somebody 1/3 of the way and then ask them to pay the price in time and >stamps to have it continue its journey? Not likely. You send it directly >to the destination, paying the postage yourself. Again, email is not and >was not ever intended as a way to send huge files over a store and forward >network. i would like to also comment that books, when shipped via mail, are tariffed differently then letters, and are handled using totally different equipment. -- [ 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/19/91)
In article <1991May19.052610.10658@iguana.uucp> merce@iguana.uucp (Jim Mercer) writes: >i would prepare that all mailservers (for files) be dropped. prefer oops 8^) -- [ Jim Mercer work: jim@lsuc.on.ca home: merce@iguana.uucp +1 519 570-3467 ] [ "Anarchists Unite!" - seen spray painted on a wall ]
gcs@polari.UUCP (Greg Sheppard) (05/19/91)
In article <1991May17.041635.4503@iguana.uucp> merce@iguana.uucp (Jim Mercer) writes: > >No! BITFTP is a terrible DIS-service to the entire UUCP community. > It appears all this moaning & groaning about uucp and bitftp has shutdown the internet/bitftp service also (at least temporarily). From my perspective on an mmdf subhost connected via short haul to an internet site, the real convenience of bitftp was I could fire off a request for a needed file, then go about my business confident bitftp would eventually deliver. Interactive ftp, on the other hand, requires more attention. Hopefully, princeton will one day drop the uucp (if that is the problem) and reinstate the internet portion of the service. I know this sounds selfish, but the main gripe seems to be coming from uucp-land. Why should the internet service suffer as well? -- Greg Sheppard Internet: imop@wa-ngnet.army.mil WAARNG, Tacoma, WA, USA UUCP: ...!polari!gcs Voice: +1 206 581 8924 --
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
gcs@polari.UUCP (Greg Sheppard) (05/19/91)
In article <01a722w163w@phoenix.com> stanley@phoenix.com (John Stanley) writes: >merce@iguana.uucp (Jim Mercer) writes: > > If you don't want to be a mail server, then stop doing it. If you don't >want to carry mail to or from bitftp, don't do it. If you can't handle the >traffic, then get out of the kitchen. Don't demand that the world stop >just because you want off. This seems like a pretty reasonable response. Maybe some constructive solution for the uucp camp might be proposed. It's kinda sad princeton is down for the internet folks too, when I'm not sure it was an internet problem. When the smoke clears,hopefully the server will remain, but with more safeguards. Let's not get too radical and destroy a service which does have it's uses. If it's a uucp problem, point that out when groaning to the powers that be. -- Greg Sheppard Internet: imop@wa-ngnet.army.mil WAARNG, Tacoma, WA, USA UUCP: ...!polari!gcs Voice: +1 206 581 8924 --
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
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
lyndon@cs.athabascau.ca (Lyndon Nerenberg) (05/20/91)
gcs@polari.UUCP (Greg Sheppard) writes: > Hopefully, princeton will one day drop the uucp (if that is the problem) >and reinstate the internet portion of the service. I know this >sounds selfish, but the main gripe seems to be coming from uucp-land. >Why should the internet service suffer as well? Interfacing to the ftp *protocol* doesn't mean you have to use the ftp *command* ! You can perform background ftp's from inside of emacs (M-x ftp-find-file). You can also use the bftp command (batched FTP). There are probably others ... Everybody says mail is a great way to transfer files. Does anybody remember when FTP (well, it's predecessor) was used to transfer mail? Ever wonder why that's not the case these days? [ DANGER WILL ROBINSON!! THAT WAS A RHETORICAL PARAGRAPH!! Save your stupid flames and comments for something else ... ] -- 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
todd@Gwinnett.COM (Todd Reese) (05/20/91)
In article <1991May19.053734.10830@iguana.uucp> merce@iguana.uucp (Jim Mercer) writes: ^^^^^^ >In article <1991May19.052610.10658@iguana.uucp> merce@iguana.uucp (Jim Mercer) writes: >>i would prepare that all mailservers (for files) be dropped. > prefer > >oops 8^) > >-- >[ Jim Mercer work: jim@lsuc.on.ca home: merce@iguana.uucp +1 519 570-3467 ] >[ "Anarchists Unite!" - seen spray painted on a wall ] In other words, these messages come straight from a LIZARD. -- Todd Reese | todd@Gwinnett.COM Gwinnett Computer Services | {rutgers,ogicse,gatech}!emory!gwinnett!todd Atlanta(Duluth), GA | (404) 623 - 6374 |
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.]
stanley@phoenix.com (John Stanley) (05/20/91)
smd@lsuc.on.ca (Sean Doran) writes: > If the people who had ordered huge VMS files or gcc/gas had asked us first, > we would have pointed them at the University of Toronto or taken steps to > uucp the files directly to them. > > Instead, they (like many proponents of BITFTP) argue that BITFTP is an > essential service, and that intermediate sites for some reason ought to be > able to handle 16 Mbytes worth of extra data, just go ahead and grab files > willy-nilly. I have the ls-lR from my feed. If it is there, I ask for it from there. None of the stuff I have asked for has been. If you have a problem with sites downstream from you, deal with the sites downstream from you. Don't kill a service that IS being used responsibly by many sites just because you can't handle your downstream sites. > | email is for messaging, not file transfers. > > Unless _everyone_ along the way gives a direct OK to a file transfer. Agreeing to route mail is approval to route mail. > | > What will you do when someone posts a request for something and > | >dozens of people mail it to him? > > If the somebody had been thinking, she or he would have asked for tips on > where to find the material in question, rather than posting a "please send > XYZ to me" message. Nobody wants to handle this question. They keep saying that the user who did this shouldn't have. It is too late. He already did. How do you handle what he already did? Do you cut off all mail because users can't handle it? As for asking how to get things, I can't count the number of times I have gotten the response 'anonymous ftp' when I ask that. > | talk to the sites in Ontario, Canada, who are possibly going to lose all > | internet connectivity partially due to increased mail volume (ie. BITFTP). > > Alternatively, talk to the sites in Ontario face the prospect of paying > $500/a to our Regional Internet (ONet) if they want to send or receive mail > across it. The policy is justified by pointing out that the unconnected And I will be paying $900 this year. Cry for Ontario. And $US are bigger than $CAN. > No, John Stanley, the problem here is that people do not think of the > consequences of ordering huge files across a store-and-forward network of > UUCP sites (and an often costly one, too) and even if they do, they don't No, Sean Doran, the problem was that Mr. Mercer's disks filled up and he lost mail and news. If the store-and-forward network did not hose disks and drop news and mail, the consequences would be much less severe, and would fall under 'cost of doing business'. The other problem here is that nobody wants the hassle of managing their users, they want to take the easy way out by stopping EVERYONE from doing what they won't tell their users to stop. > A simple note to the postmaster of every mail-handling site between you and > BITFTP saying: ``I would like to order file xyz from BITFTP. It will > probably travel back through you. Is that OK?'' is a good idea. And just who are the mail handling sites between me and bitftp? The only one I know for sure is uupsi, and I have a contract with them that says unlimited news and mail. I cannot predict who will handle the mail once PSI puts it on the Internet. How am I supposed to contact them? Second, if a site agrees to route mail, they have agreed to route mail. If they have problems with mail I send, I expect that they will contact me about it and we can go from there. Since I cannot at any time predict all possible permutations of mail routing, I cannot send these simple notes. > It's an > especially good idea, given that one of those postmasters might have a copy > that doesn't have to be chopped up and mailed to you, but can be uucped > directly. UUCPing anything from anywhere but uupsi is tieing up slower UUCP resources to the benefit of faster Internet ones. This is not a good tradeoff.
bdb@becker.UUCP (Bruce D. Becker) (05/20/91)
In article <1991May17.041635.4503@iguana.uucp> merce@iguana.uucp (Jim Mercer) writes: |In article <ZN9Z22w163w@phoenix.com> stanley@phoenix.com (John Stanley) writes: |>merce@iguana.uucp (Jim Mercer) writes: |>> we can put in place all the filters we want, but the only way to resolve this |>> issue of file transfer by email is Education. |> |> The only way to solve the problem is to teach uucico to keep track of |>free space and inodes, and to stop accepting anything until there is |>space. "Can't tango - no space". And to notify the admin about the |>problem. This would solve the problem since uucico would happily pass |>the mail on, news would unbatch and expire, and then there would be |>space for more. | |changing uucico is not solving the problem of MBAS abuse. it solves the |problem of low spool space. | |this can also be solved by throwing hardware at it. | |the point is that we are providing email forwarding services as a benefit |to the local uucp community, who by and large use it in a reasonable manner. | |it's assholes and ignoramuses who absolutely positively have to have THAT |file, but are not willing to pay their own way. | |email is for messaging, not file transfers. *BZZZZZZZT* I'm sorry, contestant - that's the Wrong Answer! There's no use trying to pass off your personal opinion as Proven Fact. You may well wish to have such policies in effect at *your* site, but you've got no call to try to restrict other sites from using uucp/email in some way in which you don't approve. That's a kind of techno-censorship which has pretty bad implications. Perhaps it would be better if uucp/email services had better tools for re-routing so that you/others could automatically route email away from your site by some category method (or perhaps not, that's just an off-the-cuff suggestion). The real point is that whatever policies you implement for traffic thru your system, they should not interfere with the policies of your neighbors or downstream connections where such policies differ. That point is in a way quite idealistic without some qualification. In order to make this work, there needs to be some agreed notions between sites as to what is acceptable use. In addition, some kind of "culture" overall needs to prevail, so that new users can expect relatively similar services at any entry point on the net, and can expect to have to fulfill relatively similar obligations. Currently the propogation of such understandings (vague as they are at this time) seems to be lagging far behind the propogation of email/uucp connectivity. Not surprisingly the base uucp/email technology has implications which cannot always be met in practice due to capacity problems, etc. A naive but intelligent user might well try to put things into practice which negatively impact other systems, without being aware of the possibilities. Consequently some kind of system of education needs to be available in a form which is integral to the installation/implementation of uucp/email services on each system where it is provided. That itself is dependent on what is agreed are the "facts" of such education, which at the present time are still incompletely defined. Your "reasonable manner" may not be at all the same as another site's, due to your requirement, whims, bureaucracy, etc. Better if you were somehow able to encode what services your site was able/willing to provide, and somehow globally advertise them. Such "capability-based" connectivity would solve a number of these kinds of issues, and create a context for fresh new contentious problems to replace the current tiresome old ones we have now 8^). |>> how much of a net.lobby do we have to do to get pucc.princeton.edu to shut |>> down BITFTP? |> |> No! This is a valuable service to the entire UUCP community. Well, at |>least it is here. | |No! BITFTP is a terrible DIS-service to the entire UUCP community. | |talk to the sites in Ontario, Canada, who are possibly going to lose all |internet connectivity partially due to increased mail volume (ie. BITFTP). Bull. There are real problems with Internet connectivity here, but your assertion hardly describes them. Increased mail volume is not in and of itself an issue. -- ,u, Bruce Becker Toronto, Ontario a /i/ Internet: bdb@becker.UUCP, bruce@gpu.utcs.toronto.edu `\o\-e UUCP: ...!utai!mnetor!becker!bdb _< /_ "It's the death of the net as we know it (and I feel fine)" - R.A.M.
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 ]
merce@iguana.uucp (Jim Mercer) (05/20/91)
In article <01a722w163w@phoenix.com> stanley@phoenix.com (John Stanley) writes: >merce@iguana.uucp (Jim Mercer) writes: > >> too fucking bad, better your money/time/disk than mine. > > If you don't want to be a mail server, then stop doing it. If you don't >want to carry mail to or from bitftp, don't do it. If you can't handle the >traffic, then get out of the kitchen. Don't demand that the world stop >just because you want off. this sounds all too familiar. about 2 months ago, some bonehead decided he HAD TO HAVE some VMS utility package. so, off he goes and BITFTP's it. 60Meg before uuencoding and mail chunking plus headers. it starts trickling through the internet at 56K or whatever, hit the University of Toronto, then slowly weasels it's way onto lsuc. quite a bit got queued up on lsuc before we established a link to bonehead's site. then we had a bi-directional connection going. worked fine, until bonehead's disk filled up. then lsuc's disk filled up. by that time, the rest had ended up in UofT's queues. we gutted it and cleaned up, it didn't do too much damage. i figure, this is a bit of a problem, better voice the sysadmin. sysadmin says sorry, and i don't feel like cutting a large company's connection for one bonehead user's mistake. so i get the bonehead's number and give him a personal talking to. he had almost the exact same thing to say. if you can't deal with the heat, get out of the kitchen. > If you don't want to be a mail server, then stop doing it. we want to maintain connectivity, and will continue to do it. >If you don't want to carry mail to or from bitftp, don't do it. problem solved. 8^) please remember, i did not DEMAND that bitftp shut down, all i did was ask how much of a lobby it would take to shut it down. turns out it didn't take much. if a single sysadmin from a backwater town like Toronto can force a life-giving service of USENET to shut down, you might think that there were other complaints as well. when did i achieve net.god status? >If you can't handle the traffic, then get out of the kitchen. >Don't demand that the world stop just because you want off. i did not demand anything of the world. end users seem to be really pissed off now that their free ride is over. it's funny, you know, i get thank you letters from sysadmins and hate mail from end users. also, your previous posts in comp.mail.uucp are starting to blame the entire province of Ontario for the timely death of BITFTP. why do you insist on escalating the blame for this from one individual who posted an article explaining his grief and asking for some helpful hints, to blaming an entire region? the uucp community of Ontario is about to suffer a very large hit on their connectivity. this will mean that they will come to depend on sites like lsuc, who will store and forward their messages. lsuc has been a part of the USENET community for some 8 years (more? i've only been here for 2 years). they are well respected in the Toronto uucp community. i hope your connections are well aware of your total lack of respect for their resources. -- [ 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 <P4e721w163w@phoenix.com> stanley@phoenix.com (John Stanley) writes: >merce@iguana.uucp (Jim Mercer) writes: > >> In article <30EBM2G@xds13.ferranti.com> peter@ficc.ferranti.com (Peter da Sil > >> can you say "a cost of doing business" ? >> >> i thought you could. > > Why do you expect HIM to say 'cost of doing business' when you refuse to? since when did participation in USENET become a business? i beleive peter was referring to the costs of overtime in order to haggle with chat scripts so that he could get stuff from anon-uucp for his business. ... stanley, you are making a personal vendetta out of this. if you don't go away, i'll make you, using the same techniques i used on BITFTP. a net.god has spoken. 8^) -- [ Jim Mercer work: jim@lsuc.on.ca home: merce@iguana.uucp +1 519 570-3467 ] [ "Clickity-Click, Barba-Trick" - The Barbapapas ]
schoff@uu.psi.com (Martin Schoffstall) (05/20/91)
I kind of doubt if anyone said that a telnet'able resource could be available through ftp. I think we know the difference between telnet and ftp. Marty ----------- In article <B9D525w163w@phoenix.com> stanley@phoenix.com (John Stanley) writes: > > Based on past experience with PSI, and on the posting from them >on this matter, I can predict with certainty what their response will >be were I to ask them to do something like that. > > "Pay us more money and you can ftp it yourself." > >(Past experience: when PSI was hyping their telnet-able white pages, >I asked if there was a way that UUCP sites could access it. The answer >was "Pay us more money for a higher level account." ) >
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.
peter@ficc.ferranti.com (Peter da Silva) (05/21/91)
In article <yi0821w163w@phoenix.com> stanley@phoenix.com (John Stanley) writes: > Agreeing to route mail is approval to route mail. This is the sort of logic that leads to UUPSI changing their contracts, to EUNET and JANET blocking outside mail, to sites dropping off the net. The net is a co-operative venture. This means that to make it work you have to co-operate. Co-operate means more then just running the right software, it means co-ordination, it means compromise, it means consideration. Cooperation. Coordination. Compromise. Consideration. > Nobody wants to handle this question. Why don't you pay attention. Ed and I have independently proposed a solution. Ed is implementing it. Think of it as pest control. You're saying that we should just put up with the mosquitos. Other people are advocating massive use of DDT. A better solution is to introduce a competing species that doesn't bite. UUCP accessible remote FTP servers... everyone wins. -- 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/21/91)
In article <yi0821w163w@phoenix.com> stanley@phoenix.com (John Stanley) writes: >smd@lsuc.on.ca (Sean Doran) writes: >> If the people who had ordered huge VMS files or gcc/gas had asked us first, >> we would have pointed them at the University of Toronto or taken steps to >> uucp the files directly to them. >> >> Instead, they (like many proponents of BITFTP) argue that BITFTP is an >> essential service, and that intermediate sites for some reason ought to be >> able to handle 16 Mbytes worth of extra data, just go ahead and grab files >> willy-nilly. > > I have the ls-lR from my feed. If it is there, I ask for it from >there. None of the stuff I have asked for has been. If you have a >problem with sites downstream from you, deal with the sites downstream >from you. Don't kill a service that IS being used responsibly by many >sites just because you can't handle your downstream sites. this is all very well and good if you really don't care who you connect to, but we tend to like connectivity, and wish to continue it. you speak like someone who has a leaf node and has no concept of what makes a hub in uucpNET. most hubs do this as a public service, of their own free will. there are only a miniscule number of sites out there who look at being a mail hub as a business. what you keep saying is that we should get out of the way. you have no idea what USENET is and how it operates. if you want reliable mail transport, which will service your every whim, i suggest you kick out the appropriate cash to get a direct link to the internet. otherwise, you are relying on the goodness of the USENET collective spirit. abuse it, and it's gone. that's what happened to BITFTP. they did not cut it back because I said so. they cut it back because they have had enough complaints. mine was just the last one. if it wasn't mine, it would have been someone else's. >> | email is for messaging, not file transfers. >> >> Unless _everyone_ along the way gives a direct OK to a file transfer. > > Agreeing to route mail is approval to route mail. participating in a cooperative network does not give the end users the right to do ANYTHING they want. i will not route alt.sex.pictures. (i know, that's news, same concept) downstream sites can not demand that i feed it. it is our right to say what can and can not pass through our system. >> | talk to the sites in Ontario, Canada, who are possibly going to lose all >> | internet connectivity partially due to increased mail volume (ie. BITFTP). >> >> Alternatively, talk to the sites in Ontario face the prospect of paying >> $500/a to our Regional Internet (ONet) if they want to send or receive mail >> across it. The policy is justified by pointing out that the unconnected > > And I will be paying $900 this year. Cry for Ontario. And $US are bigger >than $CAN. bummer for you, obviously the sites in your area could not work out a decent co-operative local network, so now you have to go long distance. or was it that no one in your area would give a feed to you? >> No, John Stanley, the problem here is that people do not think of the >> consequences of ordering huge files across a store-and-forward network of >> UUCP sites (and an often costly one, too) and even if they do, they don't > > No, Sean Doran, the problem was that Mr. Mercer's disks filled up and >he lost mail and news. If the store-and-forward network did not hose >disks and drop news and mail, the consequences would be much less severe, >and would fall under 'cost of doing business'. > > The other problem here is that nobody wants the hassle of managing >their users, they want to take the easy way out by stopping EVERYONE >from doing what they won't tell their users to stop. you are not EVERYONE. if you were, we would be in sorry shape for sure. i have gotten support from many hub sysadmins. i cannot control the users on my nieghbor's systems or on their nieghbor's systems. i could cut them off, but that would be like killing off a service because of a few bad apples. sound familiar? >> A simple note to the postmaster of every mail-handling site between you and >> BITFTP saying: ``I would like to order file xyz from BITFTP. It will >> probably travel back through you. Is that OK?'' is a good idea. > > And just who are the mail handling sites between me and bitftp? The >only one I know for sure is uupsi, and I have a contract with them that >says unlimited news and mail. I cannot predict who will handle the mail >once PSI puts it on the Internet. How am I supposed to contact them? this is exactly my point. you have no idea whose systems your traffic is going to pass through. you say you pay $900 a month for a connection. that $900 does not get split amongst all of the systems world wide who store and forward your traffic. > Second, if a site agrees to route mail, they have agreed to route >mail. If they have problems with mail I send, I expect that they will >contact me about it and we can go from there. Since I cannot at any >time predict all possible permutations of mail routing, I cannot send >these simple notes. but you can request multi-megabyte messages which may traverse unwilling systems. as you say, you cannot predict the routing of mail. i cannot post a public notice that lsuc does not do MBAS traffic and expect the rest of the net to adhere to that. (neither can the other sysadmins who cast the evil eye on MBAS) >> It's an >> especially good idea, given that one of those postmasters might have a copy >> that doesn't have to be chopped up and mailed to you, but can be uucped >> directly. > > UUCPing anything from anywhere but uupsi is tieing up slower UUCP >resources to the benefit of faster Internet ones. This is not a good >tradeoff. assuming you have a direct connection to PSI (or uunet or other commercial USENET vendors). some people are a little radical. they tend to think that co-operation is a good thing. they like the idea that they can get free access to the net so long as they are reasonable about it. are you saying that we should only connect to commercial vendors who are equipped to deal with any amount of mail traffic? i would think that thousands of sites would disagree with you. -- [ Jim Mercer work: jim@lsuc.on.ca home: merce@iguana.uucp +1 519 570-3467 ] [ "Clickity-Click, Barba-Trick" - The Barbapapas ]
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.
stanley@phoenix.com (John Stanley) (05/21/91)
merce@iguana.uucp (Jim Mercer) writes: > > If you don't want to be a mail server, then stop doing it. > > we want to maintain connectivity, and will continue to do it. Then expect that, sometimes, the resources you have allocated based on 'normal' levels of traffic will be insufficient. Don't turn your limits into limits on the net as a whole. > >If you don't want to carry mail to or from bitftp, don't do it. > > problem solved. 8^) To everyone else's detriment. It is not as funny as you think. > end users seem to be really pissed off now that their free ride is over. Free ride? Are you now paying my bills? Hahahahaha. > it's funny, you know, i get thank you letters from sysadmins and hate mail > from end users. And hate mail from admins, too. > also, your previous posts in comp.mail.uucp are starting to blame the entire > province of Ontario for the timely death of BITFTP. I am not the one who began to post the opinions of Ontario as a whole. That is the responsibility of one of your feeds. > why do you insist on escalating the blame for this from one individual who > posted an article explaining his grief and asking for some helpful hints, > to blaming an entire region? You admitted you were buzzed when you wrote what you did. Asking about shutting BITFTP off is not asking for helpful hints. > the uucp community of Ontario is about to suffer a very large hit on their > connectivity. The entire UUCP community just has, too. > this will mean that they will come to depend on sites like lsuc, who will > store and forward their messages. Then they will be in for a shock when you offer to handle their mail for them and then start telling them that they can't use mail. > i hope your connections are well aware of your total lack of respect for thei > resources. I made sure that my connection was not going to be bothered by it. (I.e. I asked what the limits were. Response: none) How this has become a lack of respect for their resources is beyond me.
stanley@phoenix.com (John Stanley) (05/21/91)
peter@ficc.ferranti.com (Peter da Silva) writes: > In article <yi0821w163w@phoenix.com> stanley@phoenix.com (John Stanley) write > > Agreeing to route mail is approval to route mail. > > This is the sort of logic that leads to UUPSI changing their contracts, to > EUNET and JANET blocking outside mail, to sites dropping off the net. The > net is a co-operative venture. This means that to make it work you have to > co-operate. Co-operate means more then just running the right software, it > means co-ordination, it means compromise, it means consideration. Ok. Now tell me how asking uupsi, BEFORE I signed the contract, what their limitations were on mail and news, is being inconsiderate. Tell me what compromise I need to make when they tell me 'unlimited'. > Cooperation. Coordination. Compromise. Consideration. Tell me why I need to coordinate, compromise, or consider lsuc re: the mail volume from this site when absolutely NONE of it passes anywhere near lsuc. > > Nobody wants to handle this question. > > Why don't you pay attention. Ed and I have independently proposed a solution. > Ed is implementing it. If you had paid attention, you would also note that I have suggested a solution that allows individual sites to make individual decisions concerning how much and what traffic they will carry. It allows the currently operating MBAS to keep operating, while allowing lsuc to kill whatever mail it wants. > Think of it as pest control. You're saying that we should just put up with > the mosquitos. I am saying that the MBAS are not the problem. If the requests from users at a site are inappropriate, deal with the users and not the MBAS. > Other people are advocating massive use of DDT. A better > solution is to introduce a competing species that doesn't bite. UUCP accessib > remote FTP servers... everyone wins. That's right. I agree. BITFTP was one such beast. Asking that it close down because a site doesn't want to handle the traffic it can generate (when ASKED to generate that traffic) is spanking the wrong end of the baby.
merce@iguana.uucp (Jim Mercer) (05/21/91)
In article <1991May20.131422.29601@uu.psi.com> schoff@uu.psi.com (Martin Schoffstall) writes: >In article <B9D525w163w@phoenix.com> stanley@phoenix.com (John Stanley) writes: >> >> Based on past experience with PSI, and on the posting from them >>on this matter, I can predict with certainty what their response will >>be were I to ask them to do something like that. >> >> "Pay us more money and you can ftp it yourself." >> >>(Past experience: when PSI was hyping their telnet-able white pages, >>I asked if there was a way that UUCP sites could access it. The answer >>was "Pay us more money for a higher level account." ) >> > >I kind of doubt if anyone said that a telnet'able resource could >be available through ftp. I think we know the difference between >telnet and ftp. > >Marty >----------- another example of Mr. Stanley's lack of knowledge. -- [ Jim Mercer work: jim@lsuc.on.ca home: merce@iguana.uucp +1 519 570-3467 ] [ "Clickity-Click, Barba-Trick" - The Barbapapas ]
emv@msen.com (Ed Vielmetti) (05/21/91)
In article <1991May20.131422.29601@uu.psi.com> schoff@uu.psi.com (Martin Schoffstall) writes: >(Past experience: when PSI was hyping their telnet-able white pages, >I asked if there was a way that UUCP sites could access it. The answer >was "Pay us more money for a higher level account." ) I kind of doubt if anyone said that a telnet'able resource could be available through ftp. I think we know the difference between telnet and ftp. But you could have sold your dial-up customers access to a restricted telnet shell that only connected to that one white pages service, no? They're already dialing up some kind of terminal server, this would have been one more service. Ditto access to other services available through telnet-style connections, e.g. access to archie, "knowbot" stuff, full-text search through interesting databases, etc etc. It could be done without going to all of the expense of connecting them for a full TCP/IP connection. Naturally these services are hard to provide if you're selling flat-rate access to your dialups; don't want those people sitting on the modem all day and not getting billed for it. --Ed
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
schoff@uu.psi.com (Martin Schoffstall) (05/21/91)
In article <EMV.91May20162808@crane.aa.ox.com> emv@msen.com (Ed Vielmetti) writes: > >But you could have sold your dial-up customers access to a restricted >telnet shell that only connected to that one white pages service, no? >They're already dialing up some kind of terminal server, this would >have been one more service. Ditto access to other services available >through telnet-style connections, e.g. access to archie, "knowbot" >stuff, full-text search through interesting databases, etc etc. It >could be done without going to all of the expense of connecting them >for a full TCP/IP connection. > >Naturally these services are hard to provide if you're selling >flat-rate access to your dialups; don't want those people sitting on >the modem all day and not getting billed for it. > Actually we are just one feature away in our terminal servers from offering free WP services. What we needed was a way to bind a user account name (without a password) called "wp" directly to a Service Access Point (SAP), call it a socket. We think this will be delivered in the Summer, it was discussed in some detail in our user group in February. I don't necessarily agree with you that is hard, based on flat rate, it depends more on the scale, you know, # of queue servers, size of the queue, inter-arrival rate, etc.... Marty
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
merce@iguana.uucp (Jim Mercer) (05/21/91)
In article <1991May20.014546.3585@Gwinnett.COM> todd@Gwinnett.COM (Todd Reese) writes: >In an article merce@iguana.uucp (Jim Mercer) writes: > ^^^^^^ >>In another article merce@iguana.uucp (Jim Mercer) writes: >>>i would prepare that all mailservers (for files) be dropped. >> prefer >> >>oops 8^) >> >>-- >>[ Jim Mercer work: jim@lsuc.on.ca home: merce@iguana.uucp +1 519 570-3467 ] >>[ "Anarchists Unite!" - seen spray painted on a wall ] > >In other words, these messages come straight from a LIZARD. better a lizard, than a bloodsucking leech (sp?) on USENET. -- [ Jim Mercer work: jim@lsuc.on.ca home: merce@iguana.uucp +1 519 570-3467 ] [ why iguana? send mail to why@iguana.uucp to get details ] [ put SEND_DETAILS_TO: user@system in the body. ]
lyndon@cs.athabascau.ca (Lyndon Nerenberg) (05/21/91)
stanley@phoenix.com (John Stanley) writes: >merce@iguana.uucp (Jim Mercer) writes: >> > If you don't want to be a mail server, then stop doing it. >> we want to maintain connectivity, and will continue to do it. > Then expect that, sometimes, the resources you have allocated based >on 'normal' levels of traffic will be insufficient. Don't turn your >limits into limits on the net as a whole. What's "normal?" Well, aunro takes in about 9 MB of news every 24 hours. We feed that out to two full feeds, plus a couple of partial feeds. 30 MB total per day is average for that one machine. On top of that we push about 100 K of mail through. Call it 30 MB/day total. You're telling me that I should configure my system to handle an additional 60 MB burst, for a total daily throughput of 150 MB "just in case" ??? John, you are rapidly becoming an ass. >> >If you don't want to carry mail to or from bitftp, don't do it. >> problem solved. 8^) > To everyone else's detriment. It is not as funny as you think. No, not to everyones detriment. I, for one, will not miss the traffic. There are others who feel the same. Don't be so naive as to think you can speak in absolutes. This also makes you look like an ass. >> end users seem to be really pissed off now that their free ride is over. > Free ride? Are you now paying my bills? Hahahahaha. Your news articles traverse through links that are payed for by the organization I work for. They also travel through links payed for by the Law Society of Upper Canada (aka lsuc). Yes, you dumb ass, I (and others) are paying to ship your postings around the world. Since you don't have a direct connection to every site on usenet, we are paying your bills by saving you a hell of a lot of money EVERY TIME you post something to the net. >> the uucp community of Ontario is about to suffer a very large hit on their >> connectivity. > The entire UUCP community just has, too. More absolutes. Can you back that statement up with any verifiable facts? > Then they will be in for a shock when you offer to handle their mail for >them and then start telling them that they can't use mail. You left off the last part of that sentence. It should have read "can't use mail for large data transfers." -- 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
lyndon@cs.athabascau.ca (Lyndon Nerenberg) (05/21/91)
stanley@phoenix.com (John Stanley) mistakenly asserts that: > Tell me why I need to coordinate, compromise, or consider lsuc re: >the mail volume from this site when absolutely NONE of it passes >anywhere near lsuc. Pathalias tends to disagree with you. Do you understand how mail routing works? Anyway, a pathalias run against the current maps show the following routes through lsuc when originated from fozzie. These will be valid unless uupsi does its own internal rerouting. We can be sure that 'fozzie' does not maintain its own routing tables, since it's a PC running Waffle. lsuc uupsi!njin!rutgers!utai!lsuc!%s bac uupsi!njin!rutgers!utai!lsuc!bac!%s combeta uupsi!njin!rutgers!utai!lsuc!combeta!%s cle uupsi!njin!rutgers!utai!lsuc!cle!%s ziebmef uupsi!njin!rutgers!utai!lsuc!ziebmef!%s ziebmef.mef.org uupsi!njin!rutgers!utai!lsuc!ziebmef!%s xenicon uupsi!njin!rutgers!utai!lsuc!xenicon!%s brennan uupsi!njin!rutgers!utai!lsuc!xenicon!brennan!%s v1hdof uupsi!njin!rutgers!utai!lsuc!xenicon!v1hdof!%s emertec uupsi!njin!rutgers!utai!lsuc!xenicon!emertec!%s accnt uupsi!njin!rutgers!utai!lsuc!xenicon!accnt!%s ajaxpre uupsi!njin!rutgers!utai!lsuc!xenicon!ajaxpre!%s tndb uupsi!njin!rutgers!utai!lsuc!tndb!%s teecs uupsi!njin!rutgers!utai!lsuc!teecs!%s sp90 uupsi!njin!rutgers!utai!lsuc!sp90!%s sizone uupsi!njin!rutgers!utai!lsuc!sizone!%s senecam uupsi!njin!rutgers!utai!lsuc!senecam!%s ryelect uupsi!njin!rutgers!utai!lsuc!ryelect!%s peoples uupsi!njin!rutgers!utai!lsuc!peoples!%s parkridge uupsi!njin!rutgers!utai!lsuc!parkridge!%s ontmoh uupsi!njin!rutgers!utai!lsuc!ontmoh!%s scilink uupsi!njin!rutgers!utai!lsuc!ontmoh!scilink!%s ontmcu uupsi!njin!rutgers!utai!lsuc!ontmoh!ontmcu!%s qcmdt1 uupsi!njin!rutgers!utai!lsuc!ontmoh!qcmdt1!%s tbitcan uupsi!njin!rutgers!utai!lsuc!ontmoh!tbitcan!%s pi19 uupsi!njin!rutgers!utai!lsuc!ontmoh!pi19!%s pi19.pnfi.forestry.ca uupsi!njin!rutgers!utai!lsuc!ontmoh!pi19!%s .pnfi.forestry.ca uupsi!njin!rutgers!utai!lsuc!ontmoh!pi19!%s ontenv uupsi!njin!rutgers!utai!lsuc!ontmoh!ontenv!%s siemtor uupsi!njin!rutgers!utai!lsuc!ontmoh!siemtor!%s scinet uupsi!njin!rutgers!utai!lsuc!ontmoh!scinet!%s web uupsi!njin!rutgers!utai!lsuc!ontmoh!web!%s now uupsi!njin!rutgers!utai!lsuc!ontmoh!web!now!%s espinc uupsi!njin!rutgers!utai!lsuc!ontmoh!espinc!%s osccsg uupsi!njin!rutgers!utai!lsuc!ontmoh!osccsg!%s ontmto uupsi!njin!rutgers!utai!lsuc!ontmoh!ontmto!%s forgen uupsi!njin!rutgers!utai!lsuc!ontmoh!forgen!%s rom uupsi!njin!rutgers!utai!lsuc!ontmoh!rom!%s romwa uupsi!njin!rutgers!utai!lsuc!ontmoh!rom!romwa!%s rommin uupsi!njin!rutgers!utai!lsuc!ontmoh!rom!rommin!%s romeds uupsi!njin!rutgers!utai!lsuc!ontmoh!rom!romeds!%s moegate uupsi!njin!rutgers!utai!lsuc!ontmoh!moegate!%s nixtdc uupsi!njin!rutgers!utai!lsuc!nixtdc!%s snitor uupsi!njin!rutgers!utai!lsuc!nixtdc!snitor!%s modtor uupsi!njin!rutgers!utai!lsuc!nixtdc!snitor!modtor!%s sni.ca uupsi!njin!rutgers!utai!lsuc!nixtdc!snitor!sni.ca!%s .sni.ca uupsi!njin!rutgers!utai!lsuc!nixtdc!snitor!%s nixtor uupsi!njin!rutgers!utai!lsuc!nixtdc!nixtor!%s ncrcan uupsi!njin!rutgers!utai!lsuc!ncrcan!%s canada.ncr.com uupsi!njin!rutgers!utai!lsuc!ncrcan!%s .canada.ncr.com uupsi!njin!rutgers!utai!lsuc!ncrcan!%s toronto.ncr.com uupsi!njin!rutgers!utai!lsuc!ncrcan!%s .toronto.ncr.com uupsi!njin!rutgers!utai!lsuc!ncrcan!%s ncr.ca uupsi!njin!rutgers!utai!lsuc!ncrcan!ncr.ca!%s .ncr.ca uupsi!njin!rutgers!utai!lsuc!ncrcan!%s isgtec uupsi!njin!rutgers!utai!lsuc!isgtec!%s camtwh uupsi!njin!rutgers!utai!lsuc!isgtec!camtwh!%s orama uupsi!njin!rutgers!utai!lsuc!isgtec!camtwh!orama!%s graham uupsi!njin!rutgers!utai!lsuc!graham!%s beamish uupsi!njin!rutgers!utai!lsuc!graham!beamish!%s wcntr uupsi!njin!rutgers!utai!lsuc!graham!wcntr!%s gpapone uupsi!njin!rutgers!utai!lsuc!gpapone!%s golem uupsi!njin!rutgers!utai!lsuc!golem!%s tse uupsi!njin!rutgers!utai!lsuc!geac!tse!%s simcoe uupsi!njin!rutgers!utai!lsuc!geac!simcoe!%s pyrtor uupsi!njin!rutgers!utai!lsuc!geac!pyrtor!%s pix uupsi!njin!rutgers!utai!lsuc!geac!pix!%s gem uupsi!njin!rutgers!utai!lsuc!geac!gem!%s aeshq uupsi!njin!rutgers!utai!lsuc!geac!aeshq!%s .geac.com uupsi!njin!rutgers!utai!lsuc!geac!%s emgee uupsi!njin!rutgers!utai!lsuc!emgee!%s eastern uupsi!njin!rutgers!utai!lsuc!eastern!%s argentic uupsi!njin!rutgers!utai!lsuc!eastern!argentic!%s ve3sbk uupsi!njin!rutgers!utai!lsuc!eastern!ve3sbk!%s lasco uupsi!njin!rutgers!utai!lsuc!eastern!lasco!%s nts uupsi!njin!rutgers!utai!lsuc!eastern!nts!%s egsgate uupsi!njin!rutgers!utai!lsuc!eastern!egsgate!%s f98.n250.z1.fidonet.org uupsi!njin!rutgers!utai!lsuc!eastern!egsgate!%s egsgate.fidonet.org uupsi!njin!rutgers!utai!lsuc!eastern!egsgate!%s .n250.z1.fidonet.org uupsi!njin!rutgers!utai!lsuc!eastern!egsgate!%s eastern.com uupsi!njin!rutgers!utai!lsuc!eastern!%s .eastern.com uupsi!njin!rutgers!utai!lsuc!eastern!%s dvlmarv uupsi!njin!rutgers!utai!lsuc!dvlmarv!%s telesat uupsi!njin!rutgers!utai!lsuc!dvlmarv!telesat!%s cnseq1 uupsi!njin!rutgers!utai!lsuc!cnseq1!%s cherni uupsi!njin!rutgers!utai!lsuc!cherni!%s normar uupsi!njin!rutgers!utai!lsuc!cherni!normar!%s lrt uupsi!njin!rutgers!utai!lsuc!cherni!lrt!%s cherniak uupsi!njin!rutgers!utai!lsuc!cherni!%s cherniak.on.ca uupsi!njin!rutgers!utai!lsuc!cherni!cherniak.on.ca!%s .cherniak.on.ca uupsi!njin!rutgers!utai!lsuc!cherni!%s canrem uupsi!njin!rutgers!utai!lsuc!canrem!%s canremote uupsi!njin!rutgers!utai!lsuc!canrem!%s becker uupsi!njin!rutgers!utai!lsuc!becker!%s moeieb uupsi!njin!rutgers!utai!lsuc!becker!moeieb!%s arcana uupsi!njin!rutgers!utai!lsuc!becker!arcana!%s courier uupsi!njin!rutgers!utai!lsuc!becker!courier!%s snowdrop uupsi!njin!rutgers!utai!lsuc!becker!snowdrop!%s grunt uupsi!njin!rutgers!utai!lsuc!becker!grunt!%s dance uupsi!njin!rutgers!utai!lsuc!becker!dance!%s fricker uupsi!njin!rutgers!utai!lsuc!becker!fricker!%s panchax uupsi!njin!rutgers!utai!lsuc!becker!panchax!%s panchax.gryphon.com uupsi!njin!rutgers!utai!lsuc!becker!panchax!%s douglee uupsi!njin!rutgers!utai!lsuc!becker!douglee!%s icanerco uupsi!njin!rutgers!utai!lsuc!becker!icanerco!%s juliao uupsi!njin!rutgers!utai!lsuc!becker!juliao!%s kneller uupsi!njin!rutgers!utai!lsuc!becker!kneller!%s knelle uupsi!njin!rutgers!utai!lsuc!becker!kneller!%s hodgins uupsi!njin!rutgers!utai!lsuc!becker!hodgins!%s wcsd uupsi!njin!rutgers!utai!lsuc!becker!wcsd!%s qnd uupsi!njin!rutgers!utai!lsuc!becker!qnd!%s berner uupsi!njin!rutgers!utai!lsuc!becker!berner!%s haberfellner uupsi!njin!rutgers!utai!lsuc!becker!haberfellner!%s cccan uupsi!njin!rutgers!utai!lsuc!becker!cccan!%s dybbuk uupsi!njin!rutgers!utai!lsuc!becker!dybbuk!%s meadow uupsi!njin!rutgers!utai!lsuc!becker!meadow!%s thpsy uupsi!njin!rutgers!utai!lsuc!becker!thpsy!%s ctmsd2 uupsi!njin!rutgers!utai!lsuc!becker!ctmsd2!%s ctor uupsi!njin!rutgers!utai!lsuc!becker!ctmsd2!%s ctmsd2.ctor uupsi!njin!rutgers!utai!lsuc!becker!ctmsd2!%s nsq uupsi!njin!rutgers!utai!lsuc!becker!nsq!%s cbmtor uupsi!njin!rutgers!utai!lsuc!becker!cbmtor!%s cbmtor.commodore.com uupsi!njin!rutgers!utai!lsuc!becker!cbmtor!%s hoohah uupsi!njin!rutgers!utai!lsuc!becker!hoohah!%s avcocan uupsi!njin!rutgers!utai!lsuc!avcocan!%s sparks uupsi!njin!rutgers!utai!lsuc!avcocan!sparks!%s shaboom uupsi!njin!rutgers!utai!lsuc!avcocan!shaboom!%s krcc uupsi!njin!rutgers!utai!lsuc!avcocan!krcc!%s array uupsi!njin!rutgers!utai!lsuc!array!%s ascdoc uupsi!njin!rutgers!utai!lsuc!array!ascdoc!%s aimed uupsi!njin!rutgers!utai!lsuc!aimed!%s kasotf uupsi!njin!rutgers!utai!lsuc!aimed!kasotf!%s blunile uupsi!njin!rutgers!utai!lsuc!aimed!blunile!%s scgrp uupsi!njin!rutgers!utai!lsuc!aimed!scgrp!%s eversoft uupsi!njin!rutgers!utai!lsuc!aimed!eversoft!%s kasoft uupsi!njin!rutgers!utai!lsuc!aimed!kasoft!%s async uupsi!njin!rutgers!utai!lsuc!aimed!async!%s caduceus uupsi!njin!rutgers!utai!lsuc!aimed!caduceus!%s lamis uupsi!njin!rutgers!utai!lsuc!aimed!lamis!%s mnemosyne uupsi!njin!rutgers!utai!lsuc!aimed!mnemosyne!%s fmlult uupsi!njin!rutgers!utai!lsuc!aimed!mnemosyne!fmlult!%s lsuc.on.ca uupsi!njin!rutgers!utai!lsuc.on.ca!%s .lsuc.on.ca uupsi!njin!rutgers!utai!%s -- 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@msen.com (Ed Vielmetti) (05/21/91)
In article <1991May20.224849.19700@uu.psi.com> schoff@uu.psi.com (Martin Schoffstall) writes:
Actually we are just one feature away in our terminal servers from
offering free WP services.
Yup, beat up on the router/terminal server vendors to get this one right.
I don't necessarily agree with you that is hard, based on flat rate,
it depends more on the scale, you know, # of queue servers, size
of the queue, inter-arrival rate, etc....
Hard to disagree with you on queueing theory in an abstract sense; if
users could be modelled as having predictable arrival times, you could
figure out just where you'd run out of steam with your existing
equipment and know pretty much when to buy more. It gets slightly
complicated when the next queue server is in another state; busy
signals then mean a long distance call which can be harder to deal
with. If the local dialup is always busy, then your service is going
to be more costly than the identically priced service in a town with
open modems. Users are fickle creatures, and in any network the
size of the ones we are contemplating external events can goof up flat
rate schemes. Are you ready to handle X11R5, when all of your flat
rate customers start sitting on modems for hours on end, or will you
bump them into a higher service bracket to get it?
I guess the biggest complaint I can see with flat-rate prices is that
they are bound to be out of the price range of the light-duty user who
only wants to consume 1/2 hour a day of network time. The other
complaint is that the consumer is at the mercy of the service provider
to change the quality of service they are getting out of that
"unlimited" link by putting further limits on it. Without mentioning
any names, a flat-rate service provider has the danger of saturating
a market if their services can be effectively resold or given away to
third parties. It's inevitable that flat rates will have other
strings attached in order to keep individual user consumption of the
service down; that's a key to effective price discrimination.
--
Edward Vielmetti, MSEN Inc. emv@msen.com
BA (Economics), U of Michigan -- you never know when a course on
industrial organization will come in handy. 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 ]
jim@lsuc.on.ca (Jim Mercer) (05/21/91)
In article <HsN021w163w@phoenix.com> stanley@phoenix.com (John Stanley) writes: >merce@iguana.uucp (Jim Mercer) writes: >> it's funny, you know, i get thank you letters from sysadmins and hate mail >> from end users. > > And hate mail from admins, too. i take it that you mean yourself. you are not an admin, you are a single user node. >> the uucp community of Ontario is about to suffer a very large hit on their >> connectivity. > > The entire UUCP community just has, too. they have not had a hit on their connectivity. they have just had their greed checked. -- [ 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 ]
stanley@phoenix.com (John Stanley) (05/21/91)
lyndon@cs.athabascau.ca (Lyndon Nerenberg) writes: > stanley@phoenix.com (John Stanley) writes: > > Then expect that, sometimes, the resources you have allocated based > >on 'normal' levels of traffic will be insufficient. Don't turn your > >limits into limits on the net as a whole. > > What's "normal?" Are you asking me to define an absolute level of normal for the net? No, I have no intention of doing that. You might have noted the '' around my use of the word normal, and taken that as a hint that it wasn't being defined or used in a standard way. > Well, aunro takes in about 9 MB of news every 24 hours. > We feed that out to two full feeds, plus a couple of partial feeds. 30 MB > total per day is average for that one machine. On top of that we push about > 100 K of mail through. Call it 30 MB/day total. Well, you have just defined 'normal' for aunro. > You're telling me that I > should configure my system to handle an additional 60 MB burst, for a total > daily throughput of 150 MB "just in case" ??? John, you are rapidly becoming > an ass. Lyndon, you can't read a simple english sentence. I did not say that you should configure anything for any level at all. I said that when you have configured your system for 'normal', that you must expect that the traffic will exceed the 'normal' level at times. If you choose to configure your system for the level you feel is normal, don't tell the rest of the net that that is the level that is allowable for the rest of the net. > No, not to everyones detriment. I, for one, will not miss the traffic. > There are others who feel the same. Don't be so naive as to think you > can speak in absolutes. This also makes you look like an ass. When everyone else here is speaking in absolutes, it is only normal to do the same. If you don't want anyone else to speak that way, don't do it yourself. > >> end users seem to be really pissed off now that their free ride is over. > > Free ride? Are you now paying my bills? Hahahahaha. > > Your news articles traverse through links that are payed for by the News? Are we talking about news or about mail? > >> the uucp community of Ontario is about to suffer a very large hit on their > >> connectivity. > > The entire UUCP community just has, too. > > More absolutes. Can you back that statement up with any verifiable facts? UUCP was connected to anonymous ftp sites via BITFTP. UUCP is no longer connected to anonymous ftp via BITFTP. Both are facts, both verified. > You left off the last part of that sentence. It should have read "can't use > mail for large data transfers." When there is a standard definition of what 'large' is, and a clear guideline to determine what falls into 'large' and 'not large', I will accept a blanket statement like that. Since there is no such definition, and since any definition would of necessity be site dependent, it is the height of 'absolutism' to make YOUR definition of 'large' the one that everyone must use.
peter@ficc.ferranti.com (Peter da Silva) (05/21/91)
In article <w9o021w163w@phoenix.com> stanley@phoenix.com (John Stanley) writes: > Ok. Now tell me how asking uupsi, BEFORE I signed the contract, what > their limitations were on mail and news, is being inconsiderate. Tell > me what compromise I need to make when they tell me 'unlimited'. YOU use UUPSI, so have no limits. I use UUPSI, too. A lot of people don't. I don't, at home. If you want to use a MBAS through your link to UUPSI, that's fine. Nobody is saying you can't do that. But for that to work that MBAS *must* restrict itself to UUPSI, or other end-user paid links. That was the problem with BITFTP... it didn't. The most reasonable solution would be for UUPSI to provide a MBAS for UUPSI customers only. Have you asked them? -- Peter da Silva; Ferranti International Controls Corporation; +1 713 274 5180; Sugar Land, TX 77487-5012; `-_-' "Have you hugged your wolf, today?"
stanley@phoenix.com (John Stanley) (05/21/91)
lyndon@cs.athabascau.ca (Lyndon Nerenberg) writes: > stanley@phoenix.com (John Stanley) mistakenly asserts that: > > > Tell me why I need to coordinate, compromise, or consider lsuc re: > >the mail volume from this site when absolutely NONE of it passes > >anywhere near lsuc. > > Pathalias tends to disagree with you. Do you understand how mail routing > works? Yes, Mr. Lyndon, I know how mail routing works. Do you treat your users in such a condescending manner? > Anyway, a pathalias run against the current maps show the following routes > through lsuc when originated from fozzie. These will be valid unless uupsi > does its own internal rerouting. We can be sure that 'fozzie' does not > maintain its own routing tables, since it's a PC running Waffle. You cannot be sure of anything, Mr. Lyndon. You don't have all the facts. [[ many many useless lines of pathalias output deleted ]] Since the topic here is abuse of MBAS, the question now becomes, are any of those sites you listed paths to an MBAS? Is MY site an MBAS? If not, then why are you concerned about MBAS traffic passing through lsuc from or to me when that, according to your own pathalias list, is not possible? You have just proven for us all that my use of MBAS has no effect on lsuc.
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)
stanley@phoenix.com (John Stanley) writes: >lyndon@cs.athabascau.ca (Lyndon Nerenberg) writes: >> >> end users seem to be really pissed off now that their free ride is over. >> > Free ride? Are you now paying my bills? Hahahahaha. >> Your news articles traverse through links that are payed for by the > News? Are we talking about news or about mail? We are talking about the question "are you now paying my bills" that you made. The answer is: yes. Every site that forwards one of your postings is subsidizing your connectivity. That also applies to mail - not only do the UUCP sites help pay to get your mail delivered, but the regional and backbone networks that comprise the internet *also* subsidize your traffic. Leased lines are not free. Routers are not free. Network operations staff do not work for free. We are talking about moving data around. Whether the content is mail, news, file transfers, whatever, is not relevent. What is relevent is that your mail gets to its destination because there are other people and organizations who are willing to donate some of their resources to achieving large scale connectivity. You have no *right* to use those resources. And you have no right to tell us how to allocate those resources. Finally, you have no right to complain when we withdraw those resources, for *whatever* reason. > UUCP was connected to anonymous ftp sites via BITFTP. UUCP is no longer >connected to anonymous ftp via BITFTP. Both are facts, both verified. This does not mean that uucp sites can not get access to ftpable files. There are many many many other alternative transports available. -- 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
andyw@aspen32.cray.com (Andy Warner) (05/22/91)
I can't be the only one who wants to see the end of this bickering .. -- andyw. (W0/G1XRL) andyw@aspen.cray.com Andy Warner, Cray Research, Inc. (612) 683-5835
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) ]
) (05/22/91)
stanley@phoenix.com (John Stanley) writes: > lyndon@cs.athabascau.ca (Lyndon Nerenberg) writes: > > We can be sure that 'fozzie' does not > > maintain its own routing tables, since it's a PC running Waffle. > > You cannot be sure of anything, Mr. Lyndon. You don't have all the > facts. Being at a site running Waffle, I'd just like to point out that Waffle systems are entirely capable of maintaining their own routeing tables. They're not as nifty as pathalias or whatever, but they allow you to route all mail to a particular site via some explicit path rather than the usual smarthost-generated path. mathew
) (05/22/91)
jim@lsuc.on.ca (Jim Mercer) writes: > In article <HsN021w163w@phoenix.com> stanley@phoenix.com (John Stanley) write > >merce@iguana.uucp (Jim Mercer) writes: > >> it's funny, you know, i get thank you letters from sysadmins and hate mail > >> from end users. > > And hate mail from admins, too. > > you are not an admin, you are a single user node. Well, I think I qualify as an admin, and I think that sites should be able to request files by mail so long as the intervening sites do not complain about the traffic. mathew
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
stanley@phoenix.com (John Stanley) (05/22/91)
jim@lsuc.on.ca (Jim Mercer) writes: > you are not an admin, you are a single user node. Oh, this is good. You have, of course, gotten a copy of my password file, ignored the other entries in it, and have decided that this is a single user node. This is really rich. Either that, or you have been so blinded by your tremendous responsibility of running a hub that you no longer think that any other activity can be considered 'admin'. > >> the uucp community of Ontario is about to suffer a very large hit on their > >> connectivity. > > > > The entire UUCP community just has, too. > > they have not had a hit on their connectivity. > > they have just had their greed checked. Well, then, the same thing applies to the UUCP community of Ontario. By the way, I find it quite interesting that you, who is the strongest voice claiming that transfer of files via email, even to a user who has asked for those files, is WRONG and is an abuse of the net, would start transferring files to this site, by mail, without request. That you, who has the central hub for Ontario, with multiple links and multimegabyte spool space, and who wants nobody to transfer files through HIS system, would start trying to send them to a small site with one link and limited space. Does this fall under your definition of cooperation, Mr. Mercer? Mail bombing a site you don't like is your idea of consideration? Your actions speak louder than your words. You are abusing the mail system at this site, Mr. Mercer. This is not some generic claim that all file transfers are an abuse, it is a specific one based on your direct actions and this site in particular.
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
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?"
henry@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
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>jim@lsuc.on.ca (Jim Mercer) (05/23/91)
In article <w91c32w163w@phoenix.com> stanley@phoenix.com (John Stanley) writes: > By the way, I find it quite interesting that you, who is the >strongest voice claiming that transfer of files via email, even to a >user who has asked for those files, is WRONG and is an abuse of the net, >would start transferring files to this site, by mail, without request. >That you, who has the central hub for Ontario, with multiple links and >multimegabyte spool space, and who wants nobody to transfer files >through HIS system, would start trying to send them to a small site with >one link and limited space. > > Does this fall under your definition of cooperation, Mr. Mercer? Mail >bombing a site you don't like is your idea of consideration? Your actions >speak louder than your words. Mr. Stanley forgets to mention, that the "mail bombs" were 3 of the USENET informational postings from news.announce.newusers. i just figured he might read them and gain some perspective on the network(s) he is using (directly or indirectly). -- [ 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 ]
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?"
fenner@jazz.psu.edu (Bill Fenner) (05/24/91)
In article <4144@polari.UUCP> gcs@polari.UUCP (Greg Sheppard) writes: |This seems like a pretty reasonable response. Maybe some constructive |solution for the uucp camp might be proposed. It's kinda sad |princeton is down for the internet folks too, when I'm not sure |it was an internet problem. Why in the world would someone who's on the Internet want to use an MBAS to get something that's directly ftp'able? Bill -- Bill Fenner fenner@jazz.psu.edu ..psuvax1!hogbbs!wcfpc!wcf wcf@hogbbs.scol.pa.us (+1 814 238-9633 2400MNP5)
fenner@jazz.psu.edu (Bill Fenner) (05/24/91)
In article <7V9a31w163w@phoenix.com> stanley@phoenix.com (John Stanley) writes: | UUCP was connected to anonymous ftp sites via BITFTP. UUCP is no longer |connected to anonymous ftp via BITFTP. Both are facts, both verified. Maybe John would do well to look at the name of the service. It's called "BITftp". The reason it's called BITftp is because it was originally meant to be used by BITnet sites. The fact that it later became usable by UUCP and Internet sites is a coincidence. The people who run it finally got around to limiting it back to its original usage. Just because you _can_ use something, doesn't mean you are allowed, or are supposed to. BITFTP was never meant for use by UUCP sites, and the current restrictions on it reflect that fact. Just because there were no restrictions before doesn't mean that it's a change of policy to implement restrictions now. From the help file from BITFTP: BITFTP provides a mail interface to the FTP portion of the IBM TCP/IP product ("FAL") running on the Princeton VM system, to allow BITNET/NetNorth/EARN users to ftp files from sites on the Internet. I see no mention there of "to allow UUCP users to ftp files from sites on the Internet." It's for BITNET/NetNorth/EARN. If you were using BITFTP from a UUCP site, you were using it for other than its intended purpose, and shouldn't be surprised that it's gone. Bill -- Bill Fenner fenner@jazz.psu.edu ..psuvax1!hogbbs!wcfpc!wcf wcf@hogbbs.scol.pa.us (+1 814 238-9633 2400MNP5)
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) ]
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.
glenn@gla-aux.uucp (Glenn Austin) (05/24/91)
In article <91May18.002523edt.1028@smoke.cs.toronto.edu>, moraes@cs.toronto.edu (Mark Moraes) writes: > stanley@phoenix.com (John Stanley) writes: > At present, we keep logs on MBAS traffic and send "please don't route > this mail through us" messages to people who are recipients of a lot of > such traffic. It seems to be working fairly well, except for the > occasional glitch (the mail Jim was complaining about passed through us > too!) and the human cost in monitoring the logs. > > An option we're considering is to modify our mailer to downgrade messages > greater than M Kbytes and remove downgraded messages if they're older > than N hours. (may as well learn from Bitnet :-) More human cost, but > then, one of utai's postmasters is interested in exploring the frontiers > of mailer science! I seem to recall limitations of number of files and/or size as well over Bitnet. I really don't care WHEN I get the file, I just would like to GET the thing! =============================================================================== | 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 | ===============================================================================
jeffb@world.std.com (Jeffrey T Berntsen) (05/24/91)
fenner@jazz.psu.edu (Bill Fenner) writes: >Why in the world would someone who's on the Internet want to use an MBAS to >get something that's directly ftp'able? Because, depending on where you are on the Internet, FTP doesn't always reach all sites. I'm not talking about the inability to reach another Internet site because of network load or a busy remote machine. I'm talking about the inability to reach some other sites at all. > Bill >-- >Bill Fenner fenner@jazz.psu.edu ..psuvax1!hogbbs!wcfpc!wcf > wcf@hogbbs.scol.pa.us (+1 814 238-9633 2400MNP5) ----------------------------------------------------------------------------- Jeffrey T. Berntsen | looking for a good .sig jeffb@world.std.com | -----------------------------------------------------------------------------
pjh@mccc.edu (Pete Holsberg) (05/25/91)
OK - enough, already! Haven't you people heard of email for this kind of exchange? Thanks, Pete -- Prof. Peter J. Holsberg Mercer County Community College Voice: 609-586-4800 Engineering Technology, Computers and Math UUCP:...!princeton!mccc!pjh 1200 Old Trenton Road, Trenton, NJ 08690 Internet: pjh@mccc.edu TCF 92 TENTATIVELY on April 18-19, 1992
stanley@phoenix.com (John Stanley) (05/25/91)
jim@lsuc.on.ca (Jim Mercer) writes: > > Does this fall under your definition of cooperation, Mr. Mercer? Mail > >bombing a site you don't like is your idea of consideration? Your actions > >speak louder than your words. > > Mr. Stanley forgets to mention, that the "mail bombs" were 3 of the USENET > informational postings from news.announce.newusers. Thank you for admitting that you did, indeed transfer files via mail, and that those files did not pertain to the discussion of mail. I hate to tell you, but those files had already arrived via the proper medium, and have been archived for new users here to read ever since this site opened. Your transferring them to me via mail was an abuse of this site's resources. Period. > i just figured he might read them and gain some perspective on the network(s) > he is using (directly or indirectly). And thank you for admitting that file transfer via mail is appropriate when YOU think it is appropriate but not when YOU don't think it is.
gcs@polari.UUCP (Greg Sheppard) (05/25/91)
In article <1991May23.155151.1242@ecl.psu.edu> fenner@jazz.psu.edu (Bill Fenner) writes: > >Why in the world would someone who's on the Internet want to use an MBAS to >get something that's directly ftp'able? > Good question. When I first discovered it, I was struck by the convenience of firing off a request and going about my business, then "voila" small uuencoded file in my mailbox...it beat firing up ftp manually, starting up the download and sipping coffee for 15 minutes while the download chugged away. Then I discovered how to run an ftp session in background (with the help of .netrc) and it wasn't so bad. After a week or so without bitftp my operation is still functioning... and (like you implied) if I really need a file I can ftp it directly. A nice convenience has been lost, but we carry on. -- Greg Sheppard Internet: imop@wa-ngnet.army.mil WAARNG, Tacoma, WA, USA UUCP: ...!polari!gcs Voice: +1 206 581 8924 --
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
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 | ===============================================================================
cliff@demon.co.uk (Cliff Stanford) (05/26/91)
lyndon@cs.athabascau.ca (Lyndon Nerenberg) writes: >stanley@phoenix.com (John Stanley) writes: > >> UUCP was connected to anonymous ftp sites via BITFTP. UUCP is no longer >>connected to anonymous ftp via BITFTP. Both are facts, both verified. > >This does not mean that uucp sites can not get access to ftpable files. >There are many many many other alternative transports available. Such as? -- Cliff Stanford Email: cliff@demon.co.uk (Work) Demon Systems Limited cms@demon.co.uk (Home) 42 Hendon Lane Phone: 081-349 0063 (Office) London N3 1TT England 0860 375870 (Mobile)
rhealey@digibd.com (Rob Healey) (05/27/91)
In article <ZaJc36w164w@mantis.co.uk> mathew@mantis.co.uk (CNEWS MUST DIE!) writes: >Well, I think I qualify as an admin, and I think that sites should be able to >request files by mail so long as the intervening sites do not complain about >the traffic. > OK, how's 'bout the obvious answer: 1) Multi-hop UUCP. I believe uusend was the name of the critter. This would allow sites to UUCP files and none of this e-mail used as a file transport crap. If intermediate sites couldn't/wouldn't support the feature then their UUCP automatically sends info back and you could try an alternate path. e-mail is for notes and memos, you don't chop up mag tapes into x meter long chunck and bulk mail the mess in white envelopes! Use the RIGHT tool for the job: UUCP itself and not e-mail. Using uusend, or whatever it's called, would also allow for easy administration: if you don't want the traffic, remove the command. Maybe this util could be distributed with all new copys of news?? Just a technical thought, -Rob -- Rob Healey rhealey@digibd.com Digi International (DigiBoard) Eden Prairie, MN (612) 943-9020
tau-ceti (05/27/91)
pjh@mccc.edu (Pete Holsberg) writes: > > OK - enough, already! Haven't you people heard of email for this kind > of exchange? > > Thanks, > Pete > -- > Prof. Peter J. Holsberg Mercer County Community College > Voice: 609-586-4800 Engineering Technology, Computers and Math > UUCP:...!princeton!mccc!pjh 1200 Old Trenton Road, Trenton, NJ 08690 > Internet: pjh@mccc.edu TCF 92 TENTATIVELY on April 18-19, 1992 Yeah! I'm still new to this but if the newsgroups are going to all be clogged with bickering and posturing I'll go back to Compuserve and give up on what I imagined to be very worthwhile. Do these folks just post here instead of e=mailing in hopes people everywhere will read their gems of wisdom and say "wow, he must be a network genius"? Not likely from here. -- ..!dogear!kharma!cjbrown \ go ahead and flame me, I've been shot before..
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.
chip@chinacat.unicom.com (Chip Rosenthal) (05/28/91)
In article <J1kk33w164w@kharma.UUCP> dogear!kharma!cjbrown@isc-br!tau-ceti writes: ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >Do these folks just post here instead of >e=mailing in hopes people everywhere will read their gems of wisdom Sometimes, it's because people provide unusable addresses in the headers of their original message. -- Chip Rosenthal <chip@chinacat.Unicom.COM> | Don't play that Unicom Systems Development 512-482-8260 | loud, Mr. Collins.
daniel@island.COM (Daniel Smith - part of the caffeine generation) (05/29/91)
In <1991May24.180113.23739@mccc.edu> pjh@mccc.edu (Pete Holsberg) writes: > OK - enough, already! Haven't you people heard of email for this kind > of exchange? Sure they have. Haven't you heard of kill files (to filter out Subjects)? 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
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.usherrickd@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
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
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) ]
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. ----------------------------------------------------------------------------
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) ]