stanley@phoenix.com (John Stanley) (05/18/91)
gregory@csri.toronto.edu (Kate Gregory) writes: > I've deleted attributions here on purpose. Someone somewhere writes: > > > I don't have access to ftp, and I can only get mail. I just tried to use > >bitftp, but the reply said something to the effect of my site being a > >'mail only site' and bitftp could no longer provide services to it. Could > >somebody please e-mail me the uuencoded PC binaries and documentation? > >Just send me a message saying you have it first... that way, I won't end > >up getting several megs worth of mail that is the same thing several > >times over. Amazing how quickly the requests for human generated multi-megabyte mail start to show up when the machine generated stuff is stopped. But this mail is ok because it is human generated, right? When this fellow gets multiple copies of the same thing, and he will, won't this take more resources to pass than one response from BITFTP? Like I said. The problem was not BITFTP. The problem is software that happily attempts to scribble across a disk on which there is no space. We would not accept this in any other application, especially an unattended one, but we will accept this from uucico. Well, BITFTP has shut itself off. Disks will now be filled with human generated mail. Fixing uucico would stop the problem at its root, but no, the next thing to be dropped will be mail itself. Then newsgroups will become too large, and those will be dropped. Unless you fix the uucico problem, you will never be rid of the problem of filled disks.
bob@MorningStar.Com (Bob Sutterfield) (05/18/91)
In article <kyV422w163w@phoenix.com> stanley@phoenix.com (John Stanley) writes:
Unless you fix the uucico problem, you will never be rid of the
problem of filled disks.
You may have encountered a problem with downstream sites filling your
spools with sources in transit, and you may consider that to be "the
uucico problem". Many others have encountered a problem with
downstream sites filling their long-distance phone lines with sources
in transit. This is what their beancounters consider to be "the
uucico problem" when they get the phone bill at the end of the month.
Both are impolite, and both threaten the neighborliness of our
networks.
The polite thing to do is to pay for the shipment of the data you
cause to be shipped.paul@frcs.UUCP (Paul Nash) (05/19/91)
Thus spake bob@MorningStar.Com (Bob Sutterfield): > > ... Many others have encountered a problem with > downstream sites filling their long-distance phone lines with sources > in transit. As one of those with a long-distance (trans-Atlantic) telephone, and attendant bill (that comes out of my private and personal pocket :-(), I can only agree. This problem has caused me to turn off mail forwarding to other sites, so that they can't get _any_ mail via my link, because of a few megabytes (and $1000's) of FTP stuff that was spewed over my phone. I, for one, welcome the demise of the BITFTP server, even though I used it a fair amount myself. It _did_ have its merits though -- I was busy setting up a filter that would look for `BITFTP' in any of the mail headers and trash the offending item. The problem (and solution) is one of politeness. If the individuals had approached me and offered to pay, I would have been only to happy to leave my link as a mail path. As it is, a few bad-mannered people have spoiled it for everyone. This makes _me_ feel guilty, but it's the only way to cope with a bad-mannered bank-manager. ---=---=---=---=---=---=---=---=---=---=---=---=---=---=---=---=---=--- Paul Nash Free Range Computer Systems cc paul@frcs.UUCP ...!uunet!m2xenix!frcs!paul
merce@iguana.uucp (Jim Mercer) (05/19/91)
In article <kyV422w163w@phoenix.com> stanley@phoenix.com (John Stanley) writes: > Like I said. The problem was not BITFTP. The problem is software >that happily attempts to scribble across a disk on which there is no >space. We would not accept this in any other application, especially an >unattended one, but we will accept this from uucico. > > Well, BITFTP has shut itself off. Disks will now be filled with human >generated mail. Fixing uucico would stop the problem at its root, but >no, the next thing to be dropped will be mail itself. Then newsgroups >will become too large, and those will be dropped. > > Unless you fix the uucico problem, you will never be rid of the >problem of filled disks. isn't this like saying "cars produce so much pollution, we neet to improve peoples lungs" ? -- [ Jim Mercer work: jim@lsuc.on.ca home: merce@iguana.uucp +1 519 570-3467 ] [ "Anarchists Unite!" - seen spray painted on a wall ]
stanley@phoenix.com (John Stanley) (05/19/91)
merce@iguana.uucp (Jim Mercer) writes: > In article <kyV422w163w@phoenix.com> stanley@phoenix.com (John Stanley) write > > Unless you fix the uucico problem, you will never be rid of the > >problem of filled disks. > > isn't this like saying "cars produce so much pollution, we neet to improve > peoples lungs" ? No. It is like saying that if you choose to suck on an exhaust pipe, don't bitch about the pollution you are breating.
stanley@phoenix.com (John Stanley) (05/19/91)
gws@xenitec.on.ca (Geoff Scully) writes: > Can and will are different things. Fixing uucico (umpteen different > versions from umpteen different vendors) Lsuc runs umpteen different versions? > Not that it is a bad idea, just that it does not solve > the immediate problem. Fixing YOUR copy of uucico WILL fix your problem. Adding a disk will NOT fix the problem, it just puts it off for a while. > 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. If you choose to run software that has the proven ability to hose your disks, and you run it without supervision, they YOU have made the choice to accept the occasional hosing of your disks. YOU made that choice of your own free will. If YOU now decide that you don't like the decision you made, don't blame or punish the rest of us because YOU made the wrong decision. If you choose to point a gun to your head and pull the trigger, don't bitch about the person who loaded it. > > 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. Fine. Don't charge them. That is YOUR choice. But if your users are a problem for you, YOU deal with THEM. Don't expect us to quietly suffer your failings. > >> email is for messaging, not file transfers. > > > > Email is for what the users email. When someone asks me, in mail, for > > There is a big difference between a list of cable freqs and ~60 MEG of > sources. The only difference is size. Don't claim that email isn't for file transfers and then say email is ok for file transfers. Be consistent. > 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. If you don't want to handle mail without charging for it, don't do it. If you want to drop replies from bitftp on the floor, do it. > >> > 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. No, the stupid and reactionist view is to get BITFTP to stop providing a service just because you can't handle it. > You still operate > under the assumption that the user making such a request has any business > doing so. I made no such assumption. People ARE doing it. They will continue to do it. People will respond to those requests. It makes no difference whether they SHOULD be doing it, it will happen. What will YOU do when it causes YOU problems? We already know how you handle problems with your users asking for things from BITFTP -- you get BITFTP to stop accepting requests from anyone. > Jim did respond to the question. Sending large file transfers > over a store and forward email network is evil. Period. That is not an answer. The question is not if it is evil, it is how you will handle it when it DOES happen. Automobile accidents are evil things. Do you refuse to wear a seat belt or carry auto insurance because accidents are evil? > 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. That's nice. That's what I would do, too. That is not what everyone would do. That is a fact. When I posted such a message telling someone where the software was, I got 100+k of mail from someone who decided that it was being nice to mail it to me without asking if I had already received it, much less if I wanted it. > > 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. Cry for Ontario. So now Ontario will have to pay for mail forwarding just like many other sites do. Why should I worry about what Ontario gets for free? You seem to be speaking for Ontario, and Ontario's opinion is that I should have to convince NASA to set up anonymous UUCP and that I should have to call them long distance to get the material I want from them. Well, tough titties for Ontario. When they change their opinion, maybe I will change mine. > It is not an over-generalization. All of our downstream will suffer when > this happens. When all UUCP sites are downstream from you, then it will not be an over-generalization. > 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. Don't forget, the reason the rest of us are paying is because Ontario couldn't handle it. > >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. Bullshit. > The point is, if you want it *now*, you pay for it, > not me. When my mail from BITFTP starts to pass through your site, which is the only way you would be paying for my mail, then you have a complaint. Until then, don't complain about paying for carrying my mail when you don't. > 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. God no. If everything available via anon-ftp were to show up in USENET, EVERYONE would be suffering. > 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." Ontario has what it wants, the rest of the world can take a hike. Great opinion. Makes Ontario look real friendly. > 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. Since none of my mail of carried at your expense, you have no right to tell me I can't send it. > 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. Yeah, you have already told us how little you care about anything outside your site. > 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. Unless you can provide proof that my mail is costing you anything, shut the hell up about how much money and time my mail is costing you. Or Peter da Silva's mail. Or anyone else's. If you have a problem with YOUR user's mail costing you time and money, then YOU deal with YOUR user's. > > 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. Those who set up anon-ftp sites generally don't think about setting up anon-uucp connections, and that is probably because they are thinking of Internet and not UUCP or BITNET or anything else. It is also because some of them have rules about dialup lines. It is NOT because ftp is an internet only protocol, it is because they are on the internet and don't realize that there are other networks. > 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. Get this straight once and for all. FTP IS NOT BEING USED IN ANY STORE AND FORWARD NETWORKS. THAT IS THE PROBLEM THAT, UNTIL RECENTLY, BITFTP SOLVED. > 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, You can't afford the time to watch your uucico to keep it from hosing your disks, but you can afford the time to read all the mail passing through to make sure it doesn't violate your sense of propriety. Go figure. > and ensure that any such > requests passing through me promptly hit the floor. That is your right. Do it now. That is the proper solution to the problem that you are having. The proper solution is not to screw up a service for everyone just because YOU can't handle it. > >> 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. He chose to run software that is a known disk hoser. > Human generated *MAIL* will NEVER fill my spool, Never? > short > of some idiot mailbombing a user here or downstream of me. A useful statement. Mail will never fill my spool unless mail fills my spool. If you had a uucico that would stop accepting things when the spool got close to full, you could THEN say that human generated mail will NEVER fill your spool, without any qualifications. > That problem > can be quickly solved with a phone call to the offending site's upstream > admin. Your spool will be cleaned up by calling another site's admin? What is he going to do, dial into your system and clean it up for you?
peter@ficc.ferranti.com (Peter da Silva) (05/19/91)
gws@xenitec.on.ca (Geoff Scully) writes: > 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. I'm not complaining. I'm explaining. I mail floppies and stamps and wait for the post office as often as not, simply because it's most convenient. People *will* do the convenient thing. I'm trying to show how the convenient thing can be made the right thing to do. Think of it as the moral equivalent of pushing for more recycling centers. If people have to drive 20 miles to recycle their milk jugs, they'll toss them in the trash. If people have to go through hassles to get files from anonymous-uucp, they'll use mail servers. If they can set up *one* script for *one* site, either with a 900 number or a service agreement, and type: uux - uunet!rftp ~/from-uunet OPEN sprite.berekeley.edu CD ~ftp GET mx.tar.Z QUIT ^D whenever they want a file, they'll do that instead of mail BITFTP@PRINCETON.EDU PATH yoursite!yourname OPEN sprite.berekeley.edu CD ~ftp GET mx.tar.Z QUIT ^D It's just as easy to set up and way more convenient to unpack. -- Peter da Silva; Ferranti International Controls Corporation; +1 713 274 5180; Sugar Land, TX 77487-5012; `-_-' "Have you hugged your wolf, today?"
gws@xenitec.on.ca (Geoff Scully) (05/20/91)
In article <TaF723w163w@phoenix.com> stanley@phoenix.com (John Stanley) writes: >gws@xenitec.on.ca (Geoff Scully) writes: > >> Can and will are different things. Fixing uucico (umpteen different >> versions from umpteen different vendors) > > Lsuc runs umpteen different versions? > No, but as has been pointed out many times now, the problem is net-wide and not unique to lsuc. >> Not that it is a bad idea, just that it does not solve >> the immediate problem. > > Fixing YOUR copy of uucico WILL fix your problem. Adding a disk will >NOT fix the problem, it just puts it off for a while. > Perhpas you don't realize this (running a PC and WAFFLE, for which you likely have source), but most sites do not have sources to uucico. Trying to convince a vendor that this needs fixing should be but is not always an easy thing to do. My immediate problem is not uucico. Mine works. My immediate problem is email abuse and the network wide problem it is causing. You continue to miss the distinction after it has been pointed out to you my multiple posters. >> 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. > > If you choose to run software that has the proven ability to hose your >disks, and you run it without supervision, they YOU have made the choice >to accept the occasional hosing of your disks. YOU made that choice >of your own free will. If YOU now decide that you don't like the decision >you made, don't blame or punish the rest of us because YOU made the wrong >decision. > > If you choose to point a gun to your head and pull the trigger, don't >bitch about the person who loaded it. > You show a serious lack of understanding about what it means to run a site with *ANY* downstream, which is not surprising since your map entry shows you to have none (or maybe 1, I can't find an entry for syrgrp in the maps; Nice map entry too, incorrectly formatted, and of course, protecting your anonimity should anyone grow tired of your inane attitude). The problem has nothing to do with uucico writing on a full disk, but rather with what fills that disk. Since you seem to like analogy so much, how about if you know your car is built to protect your life in all cases except when hit by another car moving more than 55MPH, would you try to educate people not to speed or would you bitch at your auto manufacturer for not making your car safer? >> 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. > > Fine. Don't charge them. That is YOUR choice. But if your users are >a problem for you, YOU deal with THEM. Don't expect us to quietly suffer >your failings. > I don't have any failing here. I don't have a problem with my users. Many other admins I speak to regularly do, and they do take care of them. I have not inflicted any suffering on you or anybody else. >> >> email is for messaging, not file transfers. >> > >> > Email is for what the users email. When someone asks me, in mail, for >> >> There is a big difference between a list of cable freqs and ~60 MEG of >> sources. > > The only difference is size. Don't claim that email isn't for file >transfers and then say email is ok for file transfers. Be consistent. > The question at hand is one of respect for the time and resources of upstream admins. Sending a small list of cable freqs that happened to originate in a file is not going to bother any admin. The reason that people are starting to ignore the distinction is because of idiots like you who claim that if it is ok to send a small file, then all files are ok. I am being consistent. I am consistently amazed at your lack of respect for other peoples resources. >> 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. > > If you don't want to handle mail without charging for it, don't >do it. If you want to drop replies from bitftp on the floor, do it. > Nice evasion of the question. It has nothing to do with me. I ask the question again. If I were to agree to handle your mail (read: MAIL) for free, would you be so discourteous as to send me a book? >> >> > 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. > > No, the stupid and reactionist view is to get BITFTP to stop providing >a service just because you can't handle it. > BITFTP still provides service, it just doesn't provide it to YOU, someone who had no business using it in the first place. Jim did not single handedly get BITFTP shut down. Nobody "got" BITFTP shut down. From what I know, Princeton took action on their own inititive, coincidently the day after Jim's initial posting. This problem has been building for years, growing in magnitude with every occurrence. The people at Princeton evidently got tired of hearing about the problem and decided to put the BIT back into BITFTP. >> You still operate >> under the assumption that the user making such a request has any business >> doing so. > > I made no such assumption. People ARE doing it. They will continue >to do it. People will respond to those requests. It makes no difference >whether they SHOULD be doing it, it will happen. What will YOU do when >it causes YOU problems? We already know how you handle problems with >your users asking for things from BITFTP -- you get BITFTP to stop >accepting requests from anyone. > As I said above, niether I or anyone else I am aware of was responible for you losing your free lunch. People are out there raping women all the time. Does this mean that because none of my female loved ones have been raped that I should not speak out against it? >> Jim did respond to the question. Sending large file transfers >> over a store and forward email network is evil. Period. > > That is not an answer. The question is not if it is evil, it is how >you will handle it when it DOES happen. Automobile accidents are evil >things. Do you refuse to wear a seat belt or carry auto insurance because >accidents are evil? > No, I do these things, but I also operate under the assumption that no one is going to intentionally ram me head on. Yes, it may happen, but I certainly don't take it as a given. >> 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. > > That's nice. That's what I would do, too. That is not what everyone >would do. That is a fact. When I posted such a message telling someone >where the software was, I got 100+k of mail from someone who decided >that it was being nice to mail it to me without asking if I had already >received it, much less if I wanted it. > As you seem to be fond of pointing out, that's your problem. But it would seem to give you an interest in educating users not to send files by email. Somehow I doubt you will agree with that. :-) >> > 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. > > Cry for Ontario. So now Ontario will have to pay for mail forwarding >just like many other sites do. Why should I worry about what Ontario >gets for free? You seem to be speaking for Ontario, and Ontario's >opinion is that I should have to convince NASA to set up anonymous UUCP >and that I should have to call them long distance to get the material I >want from them. Well, tough titties for Ontario. When they change their >opinion, maybe I will change mine. > They will not change their opinion because they are not in business to service your every whim and desire. If they choose to not provide anon-uucp that is their choice and your tuff luck. If you are not on the internet and can't find alternative methods, you lose. What do I care about that? Do you really think that the rest of the world computer community at large owes you whatever you may desire, regardless of how much of their time and money is involved? >> 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. > > Don't forget, the reason the rest of us are paying is because Ontario >couldn't handle it. > Wake up. It is not because of Ontario's or anybody elses problems that you (and everybody else) have lost their free ftp lunch. It is a constant pattern of abuse, which you seem to advocate, which caused the service to be restriced back to the people who are paying for it and for whom it was originally intended to serve. >> >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. > > Bullshit. > >> The point is, if you want it *now*, you pay for it, >> not me. > > When my mail from BITFTP starts to pass through your site, which is >the only way you would be paying for my mail, then you have a complaint. >Until then, don't complain about paying for carrying my mail when you >don't. > That was the generic "me" I was using. Obviously I was not clear enough for your blinkered field of vision. Let me rephrase. If x user on a machine not directly connected to the internet wants to get some source *now*, x user can pay for it (not pay *ME*, or his upstream admins, for it but pay for it himself, with his machine, his modem, his phone bill and his time). >> 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." > > Ontario has what it wants, the rest of the world can take a hike. Great >opinion. Makes Ontario look real friendly. > You are looking for nice safe easy scapegoat to crap on about losing your free access to ftp, and so you choose to dump on Ontario. As has been pointed out many times now, Ontario is not responsible for your loss, and yet you choose to make snide comments. Makes you look real friendly. >> 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. > > Since none of my mail of carried at your expense, you have no right >to tell me I can't send it. > The generic "my" again. Even after seeing it used this way multiple times you still don't figure it out. >> 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. > > Yeah, you have already told us how little you care about anything >outside your site. > What I have told you is how little I care about assholes who think that mail hubs like mine and Jim's are in business to service the every whim and desire of sites downstream of them. In fact I care a great deal about the net as a whole, and consider people with attitudes like yours to be a threat to that. >> 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. > > Unless you can provide proof that my mail is costing you anything, >shut the hell up about how much money and time my mail is costing you. >Or Peter da Silva's mail. Or anyone else's. If you have a problem with >YOUR user's mail costing you time and money, then YOU deal with YOUR >user's. > I won't even comment on this again. That was a generic "my" and a generic "you" again. My user's mail costs me next to nothing in terms of time and money, and as I said above, I don't have a problem with users doing huge file transfers. I was refering to a general, recurring net-wide problem, not to my specific site. >> > 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. > > Those who set up anon-ftp sites generally don't think about setting >up anon-uucp connections, and that is probably because they are thinking >of Internet and not UUCP or BITNET or anything else. It is also because >some of them have rules about dialup lines. It is NOT because ftp is an >internet only protocol, it is because they are on the internet and don't >realize that there are other networks. > I can't possibly believe that you really expect anybody to buy this load of bullshit. The reason that they are thinking internet when they set up ftp is because ftp is an internet protocol. The reason they *don't* think of other networks and protocols are many and varied, and you point out some of them. Another would be to avoid having to deal with idiots like you. Send me a note sometime telling me how it is that you manage to know so much about what Internet admins think about when setting up ftp, when you clearly have no experience in this relm. I don't either, BTW, but I don't presume to second guess their motivations or reasoning, or demand that they set up services to serve me when they may have neither the resources or desire to do so. >> 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. > > Get this straight once and for all. FTP IS NOT BEING USED IN ANY STORE >AND FORWARD NETWORKS. THAT IS THE PROBLEM THAT, UNTIL RECENTLY, BITFTP >SOLVED. > That was my point. BITFTP provided a way to use FTP on a store and forward network, without regard to the costs incurred by the storing sites. FTP on the internet does not have this problem as it goes directly from source to destination. In solving the the problem of not being able to use FTP from a site not on the internet, it created a whole new set of problems, and hence was not a viable solution. Other solutions have been proposed here which would solve these problems while respecting the wishes of the admins of resources used along the way. >> Human generated *MAIL* will NEVER fill my spool, > > Never? > >> short >> of some idiot mailbombing a user here or downstream of me. > > A useful statement. Mail will never fill my spool unless mail fills >my spool. If you had a uucico that would stop accepting things when the >spool got close to full, you could THEN say that human generated mail >will NEVER fill your spool, without any qualifications. > A useful statement. Mail will never fill my spool unless some idiot goes out of his way to fill it. My uucico *does* stop when full. This does not change the fact that it was an idiot who filled it, nor does it change the fact that those people who request file tranfers that fill my spool without checking with me first to see if I have alternatives are idiots. I have allocated sufficient mail spool to handle 200+% normal mail traffic for all of my downstream. If it fills, it is becuase of abuse. How uucico reacts to that abuse it incidental to the fact of abuse. It is the abuse I am trying to stop. Fixing uucico does not address this problem. >> That problem >> can be quickly solved with a phone call to the offending site's upstream >> admin. > > Your spool will be cleaned up by calling another site's admin? What is >he going to do, dial into your system and clean it up for you? No, but I have found that net.courtesy provides for upstream admins removing connectivity for abusers. It prevents recurrence of the problem in most cases. If a reckless driver smashes into me, I cannot change the fact that my car and perhaps myself will be injured, however I will I try to make damn sure that it is a long time before the other driver gets back on the road. --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
emv@ox.com (Ed Vielmetti) (05/20/91)
Peter da Silva writes:
If they can set up *one* script for *one* site, either with a 900 number or
a service agreement, and type:
Are you insisting on BITFTP compatibility, or would that just be one
preferred option? I know there are lots of scripts around that know
how to deal with that...
uux - uunet!rftp ~/from-uunet
Aw, just for the sake of argument make that
uux - msen!rftp ~/from-msen
and let's wrap some stuff around it so it's a one-liner:
ftpget msen wilma.cs.brown.edu:/pub/xmx.tar.Z ~/from-msen
i.e.
ftpget service-provider host:/path/to/sources destination-directory
Write a shell script so that you can pipe comp.archives articles
into it and the sources come back at you, and I think everyone would
be reasonably happy. Naturally, you'd replace "msen" with "uunet" or
"uupsi" or "kremvax" depending on who's providing the service and how
much it costs. And also naturally there would be an interface to the
raw "OPEN, CD, GET" commands if you're dealing with a sufficiently
goofy remote system that expressing things in terms of one-liners is
not adequate to the task.
--Ed
emv@msen.comlyndon@cs.athabascau.ca (Lyndon Nerenberg) (05/20/91)
stanley@phoenix.com (John Stanley) writes: >gws@xenitec.on.ca (Geoff Scully) writes: >> Can and will are different things. Fixing uucico (umpteen different >> versions from umpteen different vendors) > Lsuc runs umpteen different versions? > Fixing YOUR copy of uucico WILL fix your problem. Adding a disk will >NOT fix the problem, it just puts it off for a while. [ Lots 'o drivel deleted ] > A useful statement. Mail will never fill my spool unless mail fills >my spool. If you had a uucico that would stop accepting things when the >spool got close to full, you could THEN say that human generated mail >will NEVER fill your spool, without any qualifications. John, what version of UUCP do you run? It's obviously very different from the version the rest of us run. Please tell me, in detail, how the uucico at your end knows whether or not it has enough room for an incoming file. Describe the protocol negotiations that take place between the two systems to pass such information as the size of the file about to be transferred, and the amount of space available at the receiving end. What was the name of that protocol? It sure as hell wasn't g, or f, or t, or x, or e. Most versions of uucico will refuse an incoming transfer if the amount of space (or the number of free inodes) in the uucp spool directory's filesystem is below a certain threshold (said threshold being compiled in to uucico). That's it. What is so magic about your version of uucico that it doesn't have this behaviour? And why don't you share the code with us? It would be a Good Thing to have a uucp protocol that would pass along things like the size of the file it's about to send. This would allow the receiver to determine if it can infact receive the entire file without running out of resources. Of course it wouldn't be foolproof, since you can have more than one uucico going at a time, and all of them could be receiving 9 MB files into a partition with 15 MB of free space. Of course, this new protocol will only work if both ends speak it. Since none of the machines lsuc talks to (well, maybe there is one) run the same system, you are suddenly faced with the prospect of porting to other architectures. You're argument that fixing uucico on lsuc will solve the worlds problems is utter nonsense. -- 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
stanley@phoenix.com (John Stanley) (05/20/91)
paul@frcs.UUCP (Paul Nash) writes: > As one of those with a long-distance (trans-Atlantic) telephone, and > attendant bill (that comes out of my private and personal pocket :-(), > I can only agree. This problem has caused me to turn off mail forwarding > to other sites, so that they can't get _any_ mail via my link, because > of a few megabytes (and $1000's) of FTP stuff that was spewed over > my phone. This is the proper solution. If you cannot afford it, and cannot get your users to stop, don't do it. > As it is, a few bad-mannered people > have spoiled it for everyone. This makes _me_ feel guilty, but it's > the only way to cope with a bad-mannered bank-manager. Just don't let those few bad-mannered users of YOUR system spoil it for everyone who doesn't use your system. gcs@polari.UUCP (Greg Sheppard) writes: > I wrote: >> 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. The simplest solution to the problem is to filter out all upstream mail to known mail servers. This is trivial to do, and all it takes is a simple script that runs before uucico is executed to scan the mail spool. If you want to make doubly sure you kill it all, grep all mail after uucico runs for From: known mail servers. This could be done in perl very easily. It could be made to look for common automatic splitting formats, or for UUENCODED files. You could have it kill any file bigger than X k. If you have users to whom you want to grant BITFTP privileges, you can check for them and let them through. While killing files going downstream doesn't keep the spool from filling up, it does make it harder for someone to find new and unique ways around the upstream killer. The upstream killer is the main protection: if he can't ask for it, it won't be sent. If you want to get fancier, write something that bounces the request back to the user. Tell the user why it was bounced, and if it was bounced in error to send mail back to you to let you know (so you can fine tune the script). If I get the inclination, and if I thought it would help get BITFTP turned back on, I would write the first version of this perl script. I couldn't guarantee that it would work everywhere (the UUCP here is not standard) it would be close (I hope). If you don't have perl, it is available for anonymous ftp from .... Oops. If you don't have perl, you should get it.
gws@xenitec.on.ca (Geoff Scully) (05/20/91)
In article <I=EBILB@xds13.ferranti.com> peter@ficc.ferranti.com (Peter da Silva) writes: >gws@xenitec.on.ca (Geoff Scully) writes: >> 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. > >I'm not complaining. I'm explaining. > I grant the distinction. I really was not trying to pick on you personally Peter, but just happened to remember your name anong those who stated (often correctly) that setting up connects to anon-uucp sites is a hassle. Perhaps I just had too much of other people's "I don't want to be hassled, I have a right to have it handed to me" attitude. >People *will* do the convenient thing. I'm trying to show how the convenient >thing can be made the right thing to do. Think of it as the moral equivalent >of pushing for more recycling centers. If people have to drive 20 miles to >recycle their milk jugs, they'll toss them in the trash. If people have to >go through hassles to get files from anonymous-uucp, they'll use mail servers. >If they can set up *one* script for *one* site, either with a 900 number or >a service agreement, and type: > > [rftp stuff] > >whenever they want a file, they'll do that instead of > > [BITFTP stuff] > >It's just as easy to set up and way more convenient to unpack. You bet. Just to clear something up for those of you who think I am of the "Don't you dare read a file into mail!" attitude, I have no problem with 1 hop from the internet transfers like this, where it is known in advance by the upstream admin that this will happen. My problem is with mailservers and things like BITFTP which send files over multiple hop connections, where the admins in line may not be prepared or willing to accept such large volumes. I agree that your ideas and others proposed here provide for acceptable alternatives to the BITFTP problems. --- 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
stanley@phoenix.com (John Stanley) (05/20/91)
gws@xenitec.on.ca (Geoff Scully) writes: > In article <TaF723w163w@phoenix.com> stanley@phoenix.com (John Stanley) writes: > Perhpas you don't realize this (running a PC and WAFFLE, for which you > likely have source), Hahahahaha. False assumption. > but most sites do not have sources to uucico. HDB UUCP is distributed in source, I believe. Perhaps not. I haven't looked, but I bet uucico source is available somewhere via anon-ftp. Well, WAS available. > My > immediate problem is email abuse and the network wide problem it is > causing. Why is the alledged abuse of email at my site a problem for you? Does it fill YOUR spool? Do YOU pay the telephone bill? I think not. If you have a problem at YOUR site, deal with it there. > You continue to miss the distinction after it has been pointed > out to you my multiple posters. I missed nothing. The root cause of the problem, as posted by Mr. Mercer, and which caused him his untold grief and to unload that upon BITFTP, is the failure of uucico to ensure it has disk space to write that for which it ACK's. If this were not the case, there would still be a concern about transfer of this information. The cause of the problem is not BITFTP. The cause is the user who requests more than an upstream site can handle. The request could be made of anyone or anything. Deal with your user, don't cry 'shut off BITFTP'. > You show a serious lack of understanding about what it means to run a > site with *ANY* downstream, which is not surprising since your map entry > shows you to have none (or maybe 1, I can't find an entry for syrgrp in > the maps; Nice map entry too, incorrectly formatted, and of course, I did not post the map. > protecting your anonimity should anyone grow tired of your inane > attitude). If protecting my anonymity were such a concern as you seen to think _I_ think it is, then please explain why I am posting this from MY account and not root? You show a serious lack of concern for those who do not wish to announce to the world that they have major computing resources at the following address, and here is a phone number to call to find out when they are not home. And if I REALLY wanted to be anonymous, I wouldn't have sent in a map entry at all. Mull that over for a while. > The problem has nothing to do with uucico writing on a full > disk, but rather with what fills that disk. If you complain about what fills the disk today, then you will complain about what fills it tomorrow. Today it was mail from BITFTP. Tomorrow it will be mail from somewhere else. The next day it will be news. > Since you seem to like analogy so much, how about if you know your car > is built to protect your life in all cases except when hit by another > car moving more than 55MPH, would you try to educate people not to speed > or would you bitch at your auto manufacturer for not making your car safer? Trying to educate people not to speed is much different from demanding that governors be placed on every car. I would do the former, but not the latter. Mr. Mercer, and apparently you, want the latter. > I don't have any failing here. I don't have a problem with my users. Then why are you arguing so hard that BITFTP is bad, and mailservers are bad, and everyone is abusing the net? > The question at hand is one of respect for the time and resources of > upstream admins. Sending a small list of cable freqs that happened to > originate in a file is not going to bother any admin. The reason that > people are starting to ignore the distinction is because of idiots like > you who claim that if it is ok to send a small file, then all files are > ok. I did not make the blanket claim that email was not for file transfer. All I pointed out is that that claim is ridiculous. If you want to claim that email is not for transferring files larger than X kb, that is something else, but to claim it is not for transfer at all is idiotic. Especially when you consider that UUCP works entirely with FILES. > I ask the > question again. No, this is the first time for this one. The last time it was some anonymous 1/3 of the way stopover. > If I were to agree to handle your mail (read: MAIL) for > free, would you be so discourteous as to send me a book? If you asked for a book, I would send it. If you asked for a BOOK, I would send it. If you didn't ask for it, I wouldn't waste my time sending it. Now, if what you really want to ask is 'would I FORWARD a book through you to someone else' I would say 'yes, until you tell me there is a problem with that.' I would assume that when you agree to handle my mail that you have agreed to handle my mail without restriction, unless and until you say otherwise. If you have specific restrictions in mind when you agree to handle my mail, tell me now. In fact, this is one of the reasons I did NOT look for a free feed when I set this site up. I did not want to be at the mercy of someone who was doing me a favor and thus felt that they could change the rules in mid-stream. I pay my feed in return for unlimited news and mail. > Jim did not single handedly get BITFTP shut down. Nobody "got" BITFTP > shut down. From what I know, Princeton took action on their own inititive, > coincidently the day after Jim's initial posting. This problem has been > building for years, growing in magnitude with every occurrence. The people > at Princeton evidently got tired of hearing about the problem and decided > to put the BIT back into BITFTP. Yeah, I would be tired of it too, if I were them, and posting "what would it take to get BITFTP to shut down" would cause me to take action. > As I said above, niether I or anyone else I am aware of was responible > for you losing your free lunch. People are out there raping women all > the time. Does this mean that because none of my female loved ones have > been raped that I should not speak out against it? If you consider mailservers to be the equivalent to rape, I suggest you get some couseling. > >where the software was, I got 100+k of mail from someone who decided > >that it was being nice to mail it to me without asking if I had already > >received it, much less if I wanted it. > > As you seem to be fond of pointing out, that's your problem. But it would > seem to give you an interest in educating users not to send files by > email. Somehow I doubt you will agree with that. :-) It gave me an interest in educating THAT USER not to send files TO ME, that I had not requested, by mail. I have NO PROBLEM with anyone else sending files by mail to anyone else. I WOULD NOT use the problem I had as a call for a stop to all email because one person screwed up. > >want from them. Well, tough titties for Ontario. When they change their > >opinion, maybe I will change mine. > > They will not change their opinion because they are not in business to > service your every whim and desire. Then they should have no opinion about my 'whim and desire'. It has no bearing on them, and they have no say in the matter. > If they choose to not provide > anon-uucp that is their choice and your tuff luck. If you are not on the > internet and can't find alternative methods, you lose. What do I care > about that? Who is now showing a lack of respect for others? > Do you really think that the rest of the world computer > community at large owes you whatever you may desire, regardless of how > much of their time and money is involved? That is stupid, and you know it. I do expect that someone who sets themselves up as a mail router ACT as a mail router. I do expect that if they have a problem with MY mail that they will contact ME. I do not expect YOU, who has never had one piece of my BITFTP mail pass through your site, to tell me that I am abusing the email system by using BITFTP and that BITFTP should be shut down for all. > Wake up. It is not because of Ontario's or anybody elses problems that > you (and everybody else) have lost their free ftp lunch. It is a constant > pattern of abuse, which you seem to advocate, I have never advocated abuse, and unless you can prove it, stop saying it. It is a lie. > >> The point is, if you want it *now*, you pay for it, > >> not me. > > > > When my mail from BITFTP starts to pass through your site, which is > >the only way you would be paying for my mail, then you have a complaint. > >Until then, don't complain about paying for carrying my mail when you > >don't. > > That was the generic "me" I was using. Why do you take it upon yourself to speak for all "me"s? If none of the "me"s who have handled my mail have complained what makes you think that you have the right to decide for them that I am abusing the system? > Obviously I was not clear enough > for your blinkered field of vision. Let me rephrase. If x user on a > machine not directly connected to the internet wants to get some source > *now*, x user can pay for it (not pay *ME*, or his upstream admins, for > it but pay for it himself, with his machine, his modem, his phone bill > and his time). And I already pay for this myself, with my machine, my modem, my phone bill, and my time. > You are looking for nice safe easy scapegoat to crap on about losing > your free access to ftp, and so you choose to dump on Ontario. No, you chose to speak for Ontario. Oh, poor Ontario will have to pay for Internet access. My access is hardly free, and I hope Ontario has to start paying through the nose for its access. > As has > been pointed out many times now, Ontario is not responsible for your loss, > and yet you choose to make snide comments. Makes you look real friendly. When complaints about BITFTP caused it to shut down, Ontario's opinion was "too bad". When Ontario found out that it might have to pay for Internet access, it wanted sympathy. Sorry. That is a two way street. > The generic "my" again. Even after seeing it used this way multiple times > you still don't figure it out. "My" is a personal pronoun. It means "belonging to me". If you are too stupid to write "at others' expense", which is what you are now claiming you meant, then that is YOUR fault. > What I have told you is how little I care about assholes who think that > mail hubs like mine and Jim's are in business to service the every whim > and desire of sites downstream of them. If you don't want to do it, don't. If you want to drop all mail from or to bitftp, or any other place in the world, on the floor, do it. If you want to restrict mail that passes through to 1kb in size, do so. You are free to do what you want with your systems. You can pull the plug and put them in the river if you want. Reread the last paragraph. I have said it many times before, but you apparently can't understand the simple english contained therein. > In fact I care a great deal about > the net as a whole, and consider people with attitudes like yours to be a > threat to that. My 'attitude' is that it should be up to each site to decide. Your 'attitude' of speaking for all sites everywhere is the danger. > >Or Peter da Silva's mail. Or anyone else's. If you have a problem with > >YOUR user's mail costing you time and money, then YOU deal with YOUR > >user's. > > I won't even comment on this again. That was a generic "my" and a generic > "you" again. My user's mail costs me next to nothing in terms of time and > money, and as I said above, I don't have a problem with users doing huge > file transfers. So, which "my" are you using when you say "my user's mail"? Since you are so adamant that you mean a generic "my", you must mean that in this case, too. Oh, did I guess wrong? > I was refering to a general, recurring net-wide problem, > not to my specific site. Then don't use the word "my". Say "other". Don't make me guess what you mean. > I can't possibly believe that you really expect anybody to buy this load > of bullshit. The reason that they are thinking internet when they set up > ftp is because ftp is an internet protocol. They set up ftp because they are thinking Internet first, not thinking internet because they set up ftp. They think internet, then think of the way to handle the situation on Internet. Since they are not thinking UUCP, they don't think of the UUCP solution. This is not bullshit. This is the way it is. > That was my point. BITFTP provided a way to use FTP on a store and > forward network, without regard to the costs incurred by the storing > sites. You are not using ftp on a store and forward network. It is MAIL on the s&f. The contents of the mail TO bitftp is used as input to an ftp session on an Internet host, which does the ftp on the internet network. The results of the ftp session are put into a file(s) and mailed to the requestor. At that point, the protocol is mail, not ftp. At no time is ftp being passed on a S&F network. > In solving the the problem of not being able > to use FTP from a site not on the internet, it created a whole new set of > problems, and hence was not a viable solution. In solving the problem of moving people and products around quickly, Henry Ford and Mack and created cars and trucks. Cars and trucks created a whole new set of problems, and hence they are not viable solutions. The fact that a new system has problems is not proof by itself that that system is not viable nor worthwhile. > Other solutions have been > proposed here which would solve these problems while respecting the > wishes of the admins of resources used along the way. You want so badly to speak for all the admins, and decide what and who is abusing their systems, why do you now care about respecting their wishes? > A useful statement. Mail will never fill my spool unless some idiot goes > out of his way to fill it. My uucico *does* stop when full. This does not > change the fact that it was an idiot who filled it, nor does it change > the fact that those people who request file tranfers that fill my spool > without checking with me first to see if I have alternatives are idiots. You claim that you have no problem with large file transfers via mail, and yet you claim that those who do it are idiots. Wait, another generic "my"? Clearly you are wrong, since Mr. Mercer's uucico does not stop when full, and my uucico does not, so claiming that "my" uucico stops is wrong. > I have allocated sufficient mail spool to handle 200+% normal mail traffic > for all of my downstream. If it fills, it is becuase of abuse. No, if it fills it is because uucico did not stop accepting things it couldn't handle. > > Your spool will be cleaned up by calling another site's admin? What is > >he going to do, dial into your system and clean it up for you? > > No, but I have found that net.courtesy provides for upstream admins > removing connectivity for abusers. Absolutely. But not for all abusers, and not for all potential abusers. And not for accidental abusers. And how do you handle the next case of abuse? > If a reckless driver smashes into me, I cannot change the > fact that my car and perhaps myself will be injured, however I will I try > to make damn sure that it is a long time before the other driver gets back > on the road. And how does that help you prevent the next fellow who runs into you? It doesn't. Fixing ONE source of 'abuse' does not fix them all. But you DO wear your seatbelt to minimize the damage. Put a seatbelt on your uucico and you won't be killed when the mail hits.
gws@xenitec.on.ca (Geoff Scully) (05/20/91)
John, I am sure that you (and no doubt others) will be pleased to hear
that I give up on wasting net.bandwidth with this thread. I would seem
that I have been less then eloquent in phrasing my position on this,
and you have been able to quite skillfully interpret most everything I
have writen in exactly the opposite way I intended. Please continue to
spew your whining and mis-interpretations at length for those who enjoy
listening to you. I've had enough.
---
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/90peter@ficc.ferranti.com (Peter da Silva) (05/21/91)
In article <EMV.91May19170420@poe.aa.ox.com> emv@ox.com (Ed Vielmetti) writes: > Peter da Silva writes: > If they can set up *one* script for *one* site, either with a 900 number or > a service agreement, and type: > Are you insisting on BITFTP compatibility, or would that just be one > preferred option? I don't care about the interface, as long as it lets me do the same things. I don't want to depend on the rftp server having up-to-date archives, or on the source I want being on an "official" archive site. > And also naturally there would be an interface to the > raw "OPEN, CD, GET" commands if you're dealing with a sufficiently > goofy remote system that expressing things in terms of one-liners is > not adequate to the task. Like SIMTEL? Or does rftp know about SIMTEL's <> stuff in your model? -- 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 <PkD921w163w@phoenix.com> stanley@phoenix.com (John Stanley) writes: >paul@frcs.UUCP (Paul Nash) writes: > >> As one of those with a long-distance (trans-Atlantic) telephone, and >> attendant bill (that comes out of my private and personal pocket :-(), >> I can only agree. This problem has caused me to turn off mail forwarding >> to other sites, so that they can't get _any_ mail via my link, because >> of a few megabytes (and $1000's) of FTP stuff that was spewed over >> my phone. > > This is the proper solution. If you cannot afford it, and cannot >get your users to stop, don't do it. > >> As it is, a few bad-mannered people >> have spoiled it for everyone. This makes _me_ feel guilty, but it's >> the only way to cope with a bad-mannered bank-manager. > > Just don't let those few bad-mannered users of YOUR system spoil >it for everyone who doesn't use your system. you miss the point. everyone lost because of a few bad-mannered users on his neighbor's systems. before the abuse, he was willing to let modest amounts of transatlantic mail flow. then some boneheads decided they HAD TO HAVE that stuff from across the pond, and as a result, they connection was shut down to outside use. Mr. Nash was participating in what would now be considered a "classic USENET" role. he had resources, and he allowed the net at large to use them within his constraints. now that is gone. Mr. Stanley, please remember that a larger portion of uucpNET is run using other people's resources which are given as a public service. not everyone has to pay to be a member of USENET, and as a result they can live with the restrictions placed on them. your right to bitch about traffic stops when it leaves PSI. when your service is impeded, you can only yell at PSI. >gcs@polari.UUCP (Greg Sheppard) writes: > >> I wrote: >>> 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. > > The simplest solution to the problem is to filter out all upstream >mail to known mail servers. This is trivial to do, and all it takes is a >simple script that runs before uucico is executed to scan the mail >spool. If you want to make doubly sure you kill it all, grep all mail >after uucico runs for From: known mail servers. another example of your total lack of understanding of the operation of a mail hub. we have 9 modems, X.25 and direct links which can all be concurrently active. trivial to you is not trivial to us. this would also add processing cycles, which could be more effectively used in doing work for the organization that is paying for the resources. remember, most hubs are not in the business of providing mail routing, they do it as a public service. to be nice to the community at large. > While killing files going downstream doesn't keep the spool from >filling up, it does make it harder for someone to find new and unique >ways around the upstream killer. The upstream killer is the main >protection: if he can't ask for it, it won't be sent. if he doesn't ask for it (or can't) it won't be sent. > If I get the inclination, and if I thought it would help get BITFTP >turned back on, I would write the first version of this perl script. I >couldn't guarantee that it would work everywhere (the UUCP here is not >standard) it would be close (I hope). If you don't have perl, it is >available for anonymous ftp from .... Oops. If you don't have perl, you >should get it. and what if perl won't run on your system? yes it is possible there are systems out there who can't run perl (for various reasons). again, you illustrate your ignorance of the environment you are trying to fix. the UUCP you are running, as i understand from a posting referencing your map entry, is WAFFLE on an MS-DOS machine. hmmmm..... how many down stream sites do you have? what speed is your modem? is your system running 24 hr's a day? how much space do you have allocated for uucp/news? don't talk like a sysadmin, if you don't know what you are talking about. [ BTW: WAFFLE, in my experience, the best uucp suite on MS-DOS 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/21/91)
In article <e3k922w163w@phoenix.com> stanley@phoenix.com (John Stanley) writes: >gws@xenitec.on.ca (Geoff Scully) writes: >> In article <TaF723w163w@phoenix.com> stanley@phoenix.com (John Stanley) writes: >> but most sites do not have sources to uucico. > > HDB UUCP is distributed in source, I believe. Perhaps not. I haven't >looked, but I bet uucico source is available somewhere via anon-ftp. Well, >WAS available. this proves beyond a shadow of a doubt, that you have no idea what you are talking about. HDB uucp is property of AT&T Unix Systems Labs. and as such you must be a source licensee (~$3500 Academic license, $50K-$150K commercial), to have legitimate access to them. most other Unix uucp's are also covered under the same conditions. i believe there is a BSD version coming, but it still has portions of AT&T code in it, so it is not freely available. Mr. Stanley, you don't know what you are talking about, and thus it is futile to debate with you. so i won't. [ i may comment, but i will not debate. ] -- [ 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/21/91)
[ ok, so i couldn't resist ] In article <e3k922w163w@phoenix.com> stanley@phoenix.com (John Stanley) writes: > In fact, this is one of the reasons I did NOT look for a free feed >when I set this site up. I did not want to be at the mercy of someone >who was doing me a favor and thus felt that they could change the rules >in mid-stream. I pay my feed in return for unlimited news and mail. as long as your mail begins and ends at the site you are paying, you are not at the mercy of anyone other than them. when your mail leaves that site and enters the internet or uucpNET, then you are at the mercy of the sites that forward your mail. your fees to PSI do not guarantee anything outside of PSI. if you think they do, you are sorely mistaken. >> >want from them. Well, tough titties for Ontario. When they change their >> >opinion, maybe I will change mine. >> >> They will not change their opinion because they are not in business to >> service your every whim and desire. > > Then they should have no opinion about my 'whim and desire'. It has no >bearing on them, and they have no say in the matter. your whim and desire have an impact on all users on USENET. >> Wake up. It is not because of Ontario's or anybody elses problems that >> you (and everybody else) have lost their free ftp lunch. It is a constant >> pattern of abuse, which you seem to advocate, > > I have never advocated abuse, and unless you can prove it, stop saying >it. It is a lie. you advocate use of BITFTP. we consider BITFTP as abuse. therefore, in our opinion, you advocate abuse. clear enough? [ oh, no! geoff, you have been accused of posting a falsehood about someone on the net. better hope Mr. Stanley doesn't know John Palmer, or he'll have private detectives following you and try to have you committed to an asylum. 8^) ] [ Mr. Stanley, if you don't know what the above reference is to, you don't have enough background to be debating USENET quasi-policy ] >> That was the generic "me" I was using. > > Why do you take it upon yourself to speak for all "me"s? If none of >the "me"s who have handled my mail have complained what makes you think >that you have the right to decide for them that I am abusing the system? you are in a minority, where you are paying for your feed and have some feeling that you can dump on your feed when something goes wrong. or that you can demand a level of service because you laid cash out. most sites on USENET have free feeds and are dependent on the generosity of the net in general. >> Obviously I was not clear enough >> for your blinkered field of vision. Let me rephrase. If x user on a >> machine not directly connected to the internet wants to get some source >> *now*, x user can pay for it (not pay *ME*, or his upstream admins, for >> it but pay for it himself, with his machine, his modem, his phone bill >> and his time). > > And I already pay for this myself, with my machine, my modem, my phone >bill, and my time. what about the machines/modems/phonebills of systems beyond you and PSI? >> As has >> been pointed out many times now, Ontario is not responsible for your loss, >> and yet you choose to make snide comments. Makes you look real friendly. > > When complaints about BITFTP caused it to shut down, Ontario's opinion >was "too bad". When Ontario found out that it might have to pay for >Internet access, it wanted sympathy. Sorry. That is a two way street. attention americans!!! Mr. Stanley is reinforcing the stereotype that you don't know much about anything outside of the US and that you believe that anything outside of the US is just some backwater little country. Mr. Stanley, Ontario is a big place. no one has posted on their behalf. i referenced some problems the ontario uucp community was having, but i did not say i was speaking for all of them. >> I can't possibly believe that you really expect anybody to buy this load >> of bullshit. The reason that they are thinking internet when they set up >> ftp is because ftp is an internet protocol. > > They set up ftp because they are thinking Internet first, not >thinking internet because they set up ftp. They think internet, then >think of the way to handle the situation on Internet. Since they are not >thinking UUCP, they don't think of the UUCP solution. This is not >bullshit. This is the way it is. i assume they in this case is the designers of the internet. seems to me, that the designers of the internet should have been concentrating on what needs should be addressed by users (direct users) of the internet. >> In solving the the problem of not being able >> to use FTP from a site not on the internet, it created a whole new set of >> problems, and hence was not a viable solution. > > In solving the problem of moving people and products around quickly, >Henry Ford and Mack and created cars and trucks. Cars and trucks created >a whole new set of problems, and hence they are not viable solutions. >The fact that a new system has problems is not proof by itself that that >system is not viable nor worthwhile. new? since when is the internet and USENET new? >> If a reckless driver smashes into me, I cannot change the >> fact that my car and perhaps myself will be injured, however I will I try >> to make damn sure that it is a long time before the other driver gets back >> on the road. > > And how does that help you prevent the next fellow who runs into you? >It doesn't. Fixing ONE source of 'abuse' does not fix them all. But you >DO wear your seatbelt to minimize the damage. Put a seatbelt on your >uucico and you won't be killed when the mail hits. Mr. Stanley, please move this to rec.autos, thanx -- [ 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 <OZFBHU5@xds13.ferranti.com> peter@ficc.ferranti.com (Peter da Silva) writes: > And also naturally there would be an interface to the > raw "OPEN, CD, GET" commands if you're dealing with a sufficiently > goofy remote system that expressing things in terms of one-liners is > not adequate to the task. Like SIMTEL? Or does rftp know about SIMTEL's <> stuff in your model? my model rftp knows about simtel20 and its syntax, also it knows about the half dozen IBM VM systems on the net that don't have a proper way to fetch files out of subdirectories from the initial prompt. e.g. nis.nsf.net, where a single GET command doesn't work, you have to CD and GET. Just a few special cases, FTP'ing is generally predictable and standard enough to work well without much prior knowlege of the remote site. this rftp would also know that 99 44/100% of what's on simtel (behind horrible syntax and MILNET gateways) also lives on wuarchive.wustl.edu and whatever other official shadow archive systems there are for it. thus the Australian version of it would point to all of local Australian caches. --Ed
paul@frcs.UUCP (Paul Nash) (05/21/91)
Thus spake stanley@phoenix.com (John Stanley): > paul@frcs.UUCP (Paul Nash) writes: > > > > As it is, a few bad-mannered people > > have spoiled it for everyone. This makes _me_ feel guilty, but it's > > the only way to cope with a bad-mannered bank-manager. > > Just don't let those few bad-mannered users of YOUR system spoil > it for everyone who doesn't use your system. Whoa there! These are not users of _my_ system -- if they were, I wouldn't have a problem, 'cos I would be able to break their heads open. The problem is (a very few) users at _downstream_ sites, who route mail through me, and also request big FTP's without asking me if it's OK, or if they can contribute to my phone bill. My feelings are quite simple. I used to use BITFTP a certain amount, but at least _I_ paid the bill for the international link. If it is _really_ that important to anyone to get a specific file in such a hurry, why can't _they_ pay for the long-distance call, and call to uunet's 900 number (or something similar). If it isn't important enough for them to pay for it themselves, they should get someone who has FTP access to dump whatever it is onto a tape and mail it, snail-mail. While I did not call for BITFTP to die, I don't mourn its passing. However, the damage has been done, and a bunch of machines now get mail via an erratic alternative path, or has their mail dropped on the floor :-(. This is not the fault of most of the users of those machines, but is the fault of a few greedy fuckwits. If BITFTP had stayed alive, they would probably have overloaded their alternative link, lost that aswell, and lost _all_ contact with the outside world. While this is not enough reason, _in_ _itself_ for BITFTP to die, it would seem from the discussion here that there are enough sites who are affected for it to be worth a collective whole. Those who think that unlimited access is a good thing should just get a link to a BITNET machine. This will allow them to use BITFTP to their hearts' content. It will probably be expensive, but there's no such thing as a free lunch. ---=---=---=---=---=---=---=---=---=---=---=---=---=---=---=---=---=--- Paul Nash Free Range Computer Systems cc paul@frcs.UUCP ...!uunet!m2xenix!frcs!paul
peter@ficc.ferranti.com (Peter da Silva) (05/21/91)
In article <EMV.91May20155300@crane.aa.ox.com> emv@msen.com (Ed Vielmetti) writes: > my model rftp knows about simtel20 and its syntax, also it knows about > the half dozen IBM VM systems on the net that don't have a proper way > to fetch files out of subdirectories from the initial prompt. Sounds great. When do you expect to ship? -- 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)
From: merce@iguana.uucp (Jim Mercer) > you speak like someone who has a leaf node and has no concept of what > makes a hub in uucpNET. Wrong. > you have no idea what USENET is and how it operates. I know that what we are talking about is UUCP mail and not USENET. I now know why someone mailed me the "What is USENET?" posting from news.announce.newusers. You confused him. It is interesting to see how quickly those who are objecting to file transfers by mail when the recipient is asking for the files, will mail me files from USENET without my asking. > otherwise, you are relying on the goodness of the USENET collective spirit. > abuse it, and it's gone. > that's what happened to BITFTP. I also know that BITFTP is not USENET. > participating in a cooperative network does not give the end users the right > to do ANYTHING they want. It gives them the right to do what their feed allows them to do. > it is our right to say what can and can not pass through our system. But it is not your right to say what can and cannot pass through MY system. > 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. No. I did not look for a cooperative (free) feed because I knew that I would not be able to cooperate by feeding others. I felt strongly enough about that that I am paying money out of my own pocket for something I probably could have gotten for free. If, at some time in the future, I can afford the resources (I am not an organization made up of a bunch of lawyers) to become a feed, I would look for a free one. If that isn't being cooperative enough to suit you, well, tough. > that $900 does not get split amongst all of the systems world wide who > store and forward your traffic. I am one hop from the Internet. There is no store and forward. There is nobody to pay storage fees to (that I am not already paying). If it is correct to be able to anonymous ftp if I were directly on the Internet, then it is just as correct to pass the same traffic over the Internet in mail form. In either case, the traffic flows over the Internet. It does NOT come through lsuc, so lsuc has no right to tell me that I am abusing uupsi. > but you can request multi-megabyte messages which may traverse unwilling > systems. Not via BITFTP. Nor via any of the other mailservers I know of. Uupsi is the ONLY UUCP system my mail passes through, and they are quite willing. > 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. You CAN predict the routing of mail in UUCP land. It is called a bangpath. I can force UUCP mail to travel any specific route I want. All you have to do is get those who want to use MBAS to put explicit return addresses that avoid your system. > > 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). Since I have a connection to PSI, I think that that is a pretty good assumption. There are alot of people who have a connection like mine. > they tend to think that co-operation is a good thing. So do I. > they like the idea that they can get free access to the net so long as they > are reasonable about it. Define reasonable. My feed tells me what it thinks is reasonable, and that is the definition I use. > are you saying that we should only connect to commercial vendors who are > equipped to deal with any amount of mail traffic? I did not say that. I did not say anything like that. > i would think that thousands of sites would disagree with you. And since I didn't say that, and don't believe it anyway, then they wouldn't be disagreeing with me. In later articles, same author: > your whim and desire have an impact on all users on USENET. And you still haven't figured out the difference between USENET and UUCP. > you advocate use of BITFTP. > we consider BITFTP as abuse. The mere use of BITFTP is not abuse. Making 60Mb of mail pass through your system is, according to you, abuse. When I make 60Mb of mail pass through your system, you can accuse me of abuse. Until then, it is still a lie. > [ oh, no! geoff, you have been accused of posting a falsehood about someone > on the net. better hope Mr. Stanley doesn't know John Palmer, or he'll > have private detectives following you and try to have you committed to > an asylum. 8^) ] > > [ Mr. Stanley, if you don't know what the above reference is to, you don't > have enough background to be debating USENET quasi-policy ] If you don't have enough background to be able to differentiate USENET and UUCP mail, you don't have enough background to be debating UUCP policy. [ BTW, I halfway believe that JP and KPD are the same people. I have never seen them together at the same time. And maybe PT, too.] > > Why do you take it upon yourself to speak for all "me"s? If none of > >the "me"s who have handled my mail have complained what makes you think > >that you have the right to decide for them that I am abusing the system? > > you are in a minority, where you are paying for your feed and have some > feeling that you can dump on your feed when something goes wrong. or that > you can demand a level of service because you laid cash out. > > most sites on USENET have free feeds and are dependent on the generosity of > the net in general. That still doesn't tell me why you think you are speaking for all 'me's. > >> *now*, x user can pay for it (not pay *ME*, or his upstream admins, for > >> it but pay for it himself, with his machine, his modem, his phone bill > >> and his time). > > > > And I already pay for this myself, with my machine, my modem, my phone > >bill, and my time. > > what about the machines/modems/phonebills of systems beyond you and PSI? What about them? You already said that I wasn't expected to pay YOU or my upstream admins. Now you EXPECT me to pay. You are making this sound more and more commercial all the time. > Mr. Stanley, Ontario is a big place. no one has posted on their behalf. They certainly have. I have been told, in no uncertain terms, that Ontario's opinion about my not being able to access information that was available before is 'tough'. That is speaking FOR Ontario. > i referenced some problems the ontario uucp community was having, but i did > not say i was speaking for all of them. This generic 'we' crap is clouding things up pretty well. > > They set up ftp because they are thinking Internet first, not > >thinking internet because they set up ftp. They think internet, then > > i assume they in this case is the designers of the internet. No. 'They' refers to the people who set up an anonymous ftp site. All along, this part of the conversation has been about setting up anonymous ftp sites and why they don't set up anon-uucp at the same time. > since when is the internet and USENET new? You weren't talking about the Internet and USENET. You were talking about BITFTP. Since you object to the word "new", here it is again, just as valid: > >The fact that a system has problems is not proof by itself that that > >system is not viable nor worthwhile. > Mr. Stanley, please move this to rec.autos, thanx You brought up the automobiles, Jim. Remember your "unsafe when hit at more than 55" car? And, from the same author: > Marty from PSI, writes: >> 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. Nothing in my posting said anything about a telnet'able resource being available through ftp. I said that I know exactly what PSI's answer to a request from a UUCP customer for material available over ftp would be, because they gave the same answer when a UUCP customer asked about accessing material available only through telnet. Not accessing ftp from telnet, nor vice versa. Now, let's give it a break, ok Jim? You aren't going to convince me that BITFTP is an abuse of the net as a whole, and I am not going to convince you to solve your problems with your users by working with your users. You aren't going to convince me that file transfers via mail are, by default, a bad thing, and I can't convince you that not every user of BITFTP was abusing the net. The last insult was yours. That should be sufficient.
emv@msen.com (Ed Vielmetti) (05/21/91)
In article <X1GBR5F@xds13.ferranti.com> peter@ficc.ferranti.com (Peter da Silva) writes: > my model rftp... Sounds great. When do you expect to ship? In time for X11R5. Or as soon as some other internet service provider beats me to it and does it themselves; I'd recommend contacting your existing feed(s) directly and mention how happy you'd be to have a nice remote ftp facility and a full-text search interface to comp.archives. Presumably anyone with a wet piece of string connecting them to the internet could do this right now. If the 'rftp' design is proper, you could even be a hop or two off the internet and still offer the service as long as you have an 'rftp' link to an upstream site that's on the net. Given a reasonable caching model, and prefetching stuff into the cache that's mentioned in comp.archives, you'd be in real good shape. Make the links quick enough and disk space cheap enough and comp.archives turns into something very much like a comp.sources group. -- Edward Vielmetti moderator, comp.archives emv@msen.com
bdb@becker.UUCP (Bruce D. Becker) (05/21/91)
In article <kyV422w163w@phoenix.com> stanley@phoenix.com (John Stanley) writes: |[...] | Like I said. The problem was not BITFTP. The problem is software |that happily attempts to scribble across a disk on which there is no |space. We would not accept this in any other application, especially an |unattended one, but we will accept this from uucico. | | Well, BITFTP has shut itself off. Disks will now be filled with human |generated mail. Fixing uucico would stop the problem at its root, but |no, the next thing to be dropped will be mail itself. Then newsgroups |will become too large, and those will be dropped. | | Unless you fix the uucico problem, you will never be rid of the |problem of filled disks. I use a program which monitors spools space & inodes, and shuts off uucico or uuxqt if the level goes too low. It uses a shell script as part of its structure so that it can be invoked with different parameters depending on the login name or the system name, whichever is appropriate in the given context. Used carefully, it provides a kind of large- granularity type of flow control with respect to news and email throughput, which seems more useful than C news' approach of throwing away incoming stuff if there isn't room. -- ,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.
mrm@sceard.Sceard.COM (M.R.Murphy) (05/21/91)
In article <1991May20.182222.16345@iguana.uucp> merce@iguana.uucp (Jim Mercer) writes: >don't talk like a sysadmin, if you don't know what you are talking about. It would seem that more heat than light is being generated in this discussion. I'll try for light rather than heat. I suggest we look at the problem from a different perspective. Rather than joeuser making an abusive request of an MBAS, look at the problem as an MBAS abuse of the net. The MBAS makes abusive demands on noncooperative downstream sites. A zeroth level solution is for the MBAS to pull the plug. (Hi Princeton:-). A first level solution would be to have the MBAS check the return path for a request for someting like MBASsite!cooperating_site_or_path!requestingsite!joeuser where "cooperating_site_or_path" might be "uunet" or "uunet!reallybigsite". That would be pretty easy. It could use software that already exists (pathalias, smail2.5), and it would be fast. If the path to the requestor is no good, then don't allow the request or only allow small stuff. A site could certainly send an E-mail message to an MBAS saying that it would cooperate. That could be verified by telephone, registered mail, or DNA typing for you Phorgery Phreaks out there :-) It is easier to deal with an offending MBAS than with the vast morass of us joeusers. -- Mike Murphy mrm@Sceard.COM ucsd!sceard!mrm +1 619 598 5874
peter@ficc.ferranti.com (Peter da Silva) (05/21/91)
In article <6qJa31w163w@phoenix.com> stanley@phoenix.com (John Stanley) writes: > No. I did not look for a cooperative (free) feed because I knew that > I would not be able to cooperate by feeding others. Ahem. -- Peter da Silva; Ferranti International Controls Corporation; +1 713 274 5180; Sugar Land, TX 77487-5012; `-_-' "Have you hugged your wolf, today?"
lyndon@cs.athabascau.ca (Lyndon Nerenberg) (05/22/91)
stanley@phoenix.com (John Stanley) writes: > I am one hop from the Internet. There is no store and forward. There >is nobody to pay storage fees to (that I am not already paying). If it >is correct to be able to anonymous ftp if I were directly on the >Internet, then it is just as correct to pass the same traffic over the >Internet in mail form. In either case, the traffic flows over the >Internet. It does NOT come through lsuc, so lsuc has no right to tell me >that I am abusing uupsi. But you are probably violating the usage agreements of the various regional networks that your internet mail traverses. Do you think all those leased lines and routers come for free? > You CAN predict the routing of mail in UUCP land. It is called a >bangpath. I can force UUCP mail to travel any specific route I want. Heh heh. Most of his outbound uucp mail goes through rutgers :-) -- 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
clewis@ferret.ocunix.on.ca (Chris Lewis) (05/22/91)
In article <103410@becker.UUCP> bdb@becker.UUCP (Bruce D. Becker) writes: >In article <kyV422w163w@phoenix.com> stanley@phoenix.com (John Stanley) writes: >|[...] >| Like I said. The problem was not BITFTP. The problem is software >|that happily attempts to scribble across a disk on which there is no >|space. We would not accept this in any other application, especially an >|unattended one, but we will accept this from uucico. > I use a program which monitors spools space & > inodes, and shuts off uucico or uuxqt if the > level goes too low. It uses a shell script as > part of its structure so that it can be invoked > with different parameters depending on the login > name or the system name, whichever is appropriate > in the given context. > Used carefully, it provides a kind of large- > granularity type of flow control with respect > to news and email throughput, which seems more > useful than C news' approach of throwing away > incoming stuff if there isn't room. Lsuc has one of these too. When I was last working on it (it may have been worked on since), I made a concious decision to not simply shut off uucico completely when the disk space went below the thresholds. Instead, "spoolfull" disables (and kills if necessary) uucicos that are likely to be bringing *in* lots of stuff. Ie: the incoming main feed (attcan) and a couple of other sites (utzoo being one. Becker was for a while - may still be, can't remember whether I disabled that). When the diskspace becomes available again, it automatically reenables uucico. The idea being that other sites (particularly outgoing news feeds) should remain enabled because they are taking stuff *off* lsuc, and if I disabled all uucico's, then it might never turn itself back on, and everything would stall out indefinately. (Jim was new to news at the time, and Dave wasn't doing it anymore, so I thought it should be as automatic as possible). (There are other issues, such as uucp between internal lsuc machines, and ordinary mail that made turning uucico completely off impractical) This can't be done entirely within uucico, because there are other disk partitions (ie: news) to take into account - spoolfull can do that, but it's REAL HARD for something like spoolfull to figger out *who* is shovelling stuff in to be precise in who to shut off. With spoolfull, and some careful c-news tuning lsuc has been remarkably robust in the face of 20Mb+ news surges from its feeds. On the other hand, static decisions such as the ones I made won't work in the face of dorks who insist on imposing their 50MB VMS utility downloads on all and sundry. It's been said before, and I'll say it again: lsuc has been remarkably generous in its disk, line, cpu and human resources over the years (I think I gave it its first feed in '84). And over these years it has been remarkably reliable (especially when you consider what their machine was for the first 5 or so years!). Lsuc and its administrators deserve nothing but praise for doing a good job over a long period of time. No machine has infinite resources, especially ones that don't charge for their services (such as lsuc). People using them, even indirectly, shouldn't abuse it. People who scream and yell that sites that can't handle mail surges shouldn't be in the mail forwarding business should consider two things: 1) There wouldn't be a net AT ALL if every site took that attitude 2) You should try running a site with 50+ mail feeds, and 10+ news feeds for a while. -- Chris Lewis, Phone: (613) 832-0541, Domain: clewis@ferret.ocunix.on.ca UUCP: ...!cunews!latour!ecicrl!clewis; Ferret Mailing List: ferret-request@eci386; Psroff (not Adobe Transcript) enquiries: psroff-request@eci386 or Canada 416-832-0541. Psroff 3.0 in c.s.u soon!
forrie@morwyn.UUCP (Forrie Aldrich) (05/22/91)
Forgive me if this is the wrong newsgroup ...
I was wondering if someone out there would be able to brief me on the
happenings with BITFTP: why it's not working, who shut it off, why, and
the implications behind it. Also, is there another service of the type
that I can turn to? Will BITFTP ever see the light of day again (ie
be restored to working order)?
Thanks
Forrest
--
--------------------=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--------------------
Forrest Aldrich, Jr.| (a reliable path here someday) |forrie@morwyn.UUCP
| <email paths> |
CREATIVE CONNECTIONS| uunet!virgin!unhtel!morwyn!forrie |Graphic Illustration
------------------\-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=/------------------
\___ PO Box 1541 - Dover, NH 03820 ___/ merce@iguana.uucp (Jim Mercer) (05/22/91)
In article <6qJa31w163w@phoenix.com> stanley@phoenix.com (John Stanley) writes:
[ many lines showing what a complete moron he is and illustrating his
complete lack of understanding of USENET. ]
give it up.
you made so many blunders in this posting, that i will not waste the bandwidth
to point them out.
and i thought you couldn't top your "HDB uucp is distributed with source"
blather.
you better prepare for some major flamage on this one.
but then, maybe everyone else will decide that you aren't worth the effort.
only someone on heavy drugs or with severe brain damage could have made
such an utter declaration of incompetence and stupidity.
--
[ 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) ]fenner@jazz.psu.edu (Bill Fenner) (05/24/91)
In article <6qJa31w163w@phoenix.com> stanley@phoenix.com (John Stanley) writes: | |From: merce@iguana.uucp (Jim Mercer) |> you speak like someone who has a leaf node and has no concept of what |> makes a hub in uucpNET. | Wrong. No, he's right. You _do_ speak like someone who has a leaf node and has no concept of what makes a hub in uucpNET. Whether you _are_ that or not, you certainly speak like it. Bill -- Bill Fenner fenner@jazz.psu.edu ..psuvax1!hogbbs!wcfpc!wcf wcf@hogbbs.scol.pa.us (+1 814 238-9633 2400MNP5)
xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan) (05/26/91)
merce@iguana.uucp (Jim Mercer) writes: > stanley@phoenix.com (John Stanley) writes: >> Like I said. The problem was not BITFTP. The >> problem is software that happily attempts to >> scribble across a disk on which there is no >> space. We would not accept this in any other >> application, especially an unattended one, but we >> will accept this from uucico. > isn't this like saying "cars produce so much > pollution, we neet to improve peoples lungs" ? You may well deserve your "butcher of bitftp" appellation if you keep up that kind of response. John is exactly right; the problem is, and always has been, a piece of broken software, and a corresponding broken protocol, that is willing to keep accepting input it no longer has room to store. People will ignore a toothache until the tooth rots to the gum line; uucico has been that kind of a problem; this site has suffered, as I'm sure does every UUCP site with limited disk space, news (and perhaps mail; how would one know?) being dropped on the floor regularly because the transfer protocol hasn't the sense to say "full up, hold the rest for later". That's as broken as broken software can get, but it suffers from the same problem Henry Spenser is trying to correct with some draconian C News decisions: the uucico software is so widespread, getting a maintenance action to take place _literally_ everywhere looks like too much trouble to undertake, so why fix what's broken? The solution would have to be like Henry's; install a new uucico that is _deliberately_ incompatible with the old one, and bring it up (after suitable testing) everywhere with a breathing sysadmin at once to a schedule, and let the rest of the sites go isolate until their sysadmins have been kickstarted by the resulting incompatibility into fixing their sites, too. Volunteers? (Ha!) Kent, the man from xanth. <xanthian@Zorch.SF-Bay.ORG> <xanthian@well.sf.ca.us>
darcy@druid.uucp (D'Arcy J.M. Cain) (05/26/91)
In article <1991May25.202516.12961@zorch.SF-Bay.ORG> Kent Paul Dolan writes: >every UUCP site with limited disk space, news (and >perhaps mail; how would one know?) being dropped on >the floor regularly because the transfer protocol >hasn't the sense to say "full up, hold the rest for >later". That's as broken as broken software can get, Your cure is worse. If someone downstream from me snags gcc and X and only has a 20 Meg DOS system then that stuff (assuming *I* have room for it) sits on my machine forever blocking stuff for everyone on my system and my other downstreams. I have to be able to drop undeliverable stuff. Why should everyone else suffer because of one bozo? >The solution would have to be like Henry's; install >a new uucico that is _deliberately_ incompatible >with the old one, and bring it up (after suitable Huh? Cnews is deliberately *compatible* with the RFCs. That's what some are whining about - that their own software can't go on being incompatible. -- D'Arcy J.M. Cain (darcy@druid) | D'Arcy Cain Consulting | There's no government Toronto, Ontario, Canada | like no government! +1 416 424 2871 |
scott@skypod.guild.org (Scott Campbell) (05/26/91)
In article <1991May25.202516.12961@zorch.SF-Bay.ORG> xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan) writes: [comments on how uucico is broken and needs to be fixed] >The solution would have to be like Henry's; install >a new uucico that is _deliberately_ incompatible >with the old one, and bring it up (after suitable >testing) everywhere with a breathing sysadmin at >once to a schedule, and let the rest of the sites go >isolate until their sysadmins have been kickstarted >by the resulting incompatibility into fixing their >sites, too. The problem is, of course, that most of us do not have source for uucico. If you want to write an entirely new version of uucico that does not include any AT&T code, maybe I will try it after I have seen lots of other people running for several months. However, I talk to sites with several different mail/news/operating systems so any new uucico you write must work on SUN OS, waffle, minix, System V R3, System V R2 and FSUUCP for me to install it (Those are just my neighbours -- I am sure some of you out there talk to other systems). If my uucico won't talk to all of these sites than I won't use it. The uucico I have has its problems but everyone out there is pretty compatible with it and that is what counts. As long as no one sends huge files (ala BITFTP) through my site I can get by pretty well. Sure - I drop news on the floor sometimes -- but is your new uucico going to check my news spool to see that there is room before it accepts news and check the mail spool before it accepts mail and checks the uucppublic spool before it accepts uucp traffic? All this and handle whatever equivalents the DOS versions use? I think making a new uucico for all of the various versions of unix out there (and DOS and whatever else talks UUCP - VMS? VM? Multics? Ultrix?) would be relatively less trivial than you would think... Maybe I am wrong. Someone want to whip off a new version of uucico this weekend? I don't want to pay you for it by the way. scott p.s. on the BITFTP issue: I think that if UUNET and UUPSI set up FTP servers for their customers, then most of the valid complaints would go away. In fact, any site that provides UUCP links off of the internet should provide their own method of providing UUCP-FTP services. If the site upstream from you doesn't offer it then too bad. Any agreement for mail forwarding you have is usually with them and them alone. (ie. paying PSI for mail does not necessarily mean that you are paying for BITFTP access - how much of the money paid to PSI got passed along to Princeton?) -- 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
merce@iguana.uucp (Jim Mercer) (05/27/91)
In article <1991May25.202516.12961@zorch.SF-Bay.ORG> xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan) writes: > merce@iguana.uucp (Jim Mercer) writes: >> stanley@phoenix.com (John Stanley) writes: > >>> Like I said. The problem was not BITFTP. The >>> problem is software that happily attempts to >>> scribble across a disk on which there is no >>> space. We would not accept this in any other >>> application, especially an unattended one, but we >>> will accept this from uucico. > >> isn't this like saying "cars produce so much >> pollution, we neet to improve peoples lungs" ? > >You may well deserve your "butcher of bitftp" >appellation if you keep up that kind of response. >John is exactly right; the problem is, and always >has been, a piece of broken software, and a >corresponding broken protocol, that is willing to >keep accepting input it no longer has room to store. and one of his brilliant solutions for this problem, was to only run uucico under supervision. i agree that uucico is somewhat broken, but as you go on to say, the problem is so widespread, there is not much we can do about it. since it is going to be a long time before someone comes out with a software solution to the problem, i suggest we try to live within its limitations. -- [ 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) ]
bert@medley.ssdl.com (Bert Medley ) (05/27/91)
darcy@druid.uucp (D'Arcy J.M. Cain) writes: > In article <1991May25.202516.12961@zorch.SF-Bay.ORG> Kent Paul Dolan writes: > >every UUCP site with limited disk space, news (and > >perhaps mail; how would one know?) being dropped on > >the floor regularly because the transfer protocol > >hasn't the sense to say "full up, hold the rest for > >later". That's as broken as broken software can get, > > Your cure is worse. If someone downstream from me snags > gcc and X and only has a 20 Meg DOS system then that stuff > (assuming *I* have room for it) sits on my machine forever > blocking stuff for everyone on my system and my other > downstreams. I have to be able to drop undeliverable stuff. > Why should everyone else suffer because of one bozo? > Being a leaf node at home without FTP access, I know exactly what you mean. Because of the selfish/uneducated actions of a few, many are being denied access to FTP services. The problem wasn't BITFTP or the presence of any other mail based archive server. Pure and simple, it is a problem of education for those who are intelligaent enough to understand and policy for those too selfish. If BITFTP and other FTP->mail servers were to limit the number of and size of the files requested, that bozo could not get hold of gcc and X in one fell swoop. Instead, he would have to retrieve it in bite size pieces. A better solution for all concerned. -- Bert Medley ! bert@medley.ssdl.com !
herrickd@iccgcc.decnet.ab.com (06/02/91)
In article <EMV.91May19170420@poe.aa.ox.com>, emv@ox.com (Ed Vielmetti) writes: > > and let's wrap some stuff around it so it's a one-liner: > ftpget msen wilma.cs.brown.edu:/pub/xmx.tar.Z ~/from-msen > i.e. > ftpget service-provider host:/path/to/sources destination-directory > > Write a shell script so that you can pipe comp.archives articles > into it and the sources come back at you, and I think everyone would Ed, maybe it's time for you to start putting unique identifiers on comp.archives articles (like cbip's <vnnnimmm>, or whatever they are). Then msen can offer include by reference: carefget msen <vnnnimmm>:3rd-file ~/from-msen and msen consults the verification at the end of article <vnnnimmm> and retrieves that file. Wildcarding etc. follows. dan herrick herrickd@iccgcc.decnet.ab.com
emv@msen.com (Edward Vielmetti) (06/02/91)
>> ftpget msen wilma.cs.brown.edu:/pub/xmx.tar.Z ~/from-msen > >are). Then msen can offer include by reference: > carefget msen <vnnnimmm>:3rd-file ~/from-msen >and msen consults the verification at the end of article <vnnnimmm> >and retrieves that file. Wildcarding etc. follows. the problems here are with bitrot -- software changes, people move and take their code with them, grant money comes and goes :-). the closest thing to a unique id in each article is the Archive-Name: header; it's something like Archive-name: category/subcategory/package/time-stamp Now my sense of categorization is pretty weak, but the "package" part stays consistent. If you were to ask for getpackage msen xmx ~/from-msen we could fetch the database entry for xmx, discover that either we have a copy locally or we know where to get all of its pieces parts, and send it down to you. bitrot is your enemy here, the half life of a reference to an ftp site location is less than a year, and keeping tabs on all nn hundred different things is real work. --Ed