Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!udel!rochester!kodak!uupsi!fozzie!stanley From: stanley@phoenix.com (John Stanley) Newsgroups: comp.mail.uucp Subject: Re: BITFTP grief! Message-ID: Date: 18 May 91 01:52:49 GMT References: <1991May17.041635.4503@iguana.uucp> Organization: Mad Scientist Lines: 126 merce@iguana.uucp (Jim Mercer) writes: > In article stanley@phoenix.com (John Stanley) write > > changing uucico is not solving the problem of MBAS abuse. it solves the > problem of low spool space. > > this can also be solved by throwing hardware at it. Throwing hardware at it solves nothing. As long as uucico accepts more data that can be stored on disk, you are vulnerable to uucico filling your spool area. You are BETTING that when you have more hardware it won't happen, but until you fix uucico, it can. You are not the only one in this situation. I learned the hard way at this site that uucico is untrustworthy. When it happened to me, I didn't blame USENET and tell everyone to stop posting. I "fixed" the uucico I have by running it only under supervision. Since that time, I have NEVER suffered a filled spool. There are two kinds of admins on the net: those who have had uucico hose them, and those that will have it happen. Here is a question for all admins. I am writing a software package that will run unattended. Output from this package is saved to disk, and is based on automatic external input. (E.g. data logger that logs significant events at a nuke plant.) I have written this software with the knowledge (i.e. it's a fact!) that normal nuke operations will never generate too much data to be loggable to disk, and so I have not written in any tests to make sure that there is enough disk space for logging. How many admins think this is a failure waiting to happen? How many admins would be on the phone to me, or their lawyers, about it? Now, everyone who has their hands up on the last one, why is uucico different? > the point is that we are providing email forwarding services as a benefit > to the local uucp community, So do many others. > it's assholes and ignoramuses who absolutely positively have to have THAT > file, but are not willing to pay their own way. If you have a problem with the users of your system, take it up with them. Don't come out into the world and demand that everyone else give up what they have just because you can't afford to give it to your users. If you want THEM to pay their way, well, then, CHARGE THEM. With all the lawyers you must have floating around there, the legal issues certainly wouldn't be a problem. > email is for messaging, not file transfers. Email is for what the users email. When someone asks me, in mail, for the frequencies for cable channels, am I supposed to type it in or am I allowed to send him the FILE I have already typed in? Is he now prohibited from saving this information in a FILE, because "email is for messaging, not file transfers."? Email is an analog to paper mail, and sometimes people mail books. > > What will you do when someone posts a request for something and > >dozens of people mail it to him? > > again, email is for messaging, not file transfers. Respond to the question. People are already posting requests for files to be mailed to them as a direct result of you getting BITFTP shut off. What will you do when your spool fills up from people mailing files to each other? You are going to cut off mail. Then people will be asking for stuff to be posted. Blam! No more news. That's the only real solution to your problem, you know. Don't. > >> how much of a net.lobby do we have to do to get pucc.princeton.edu to shut > >> down BITFTP? > > > > No! This is a valuable service to the entire UUCP community. Well, at > >least it is here. > > No! BITFTP is a terrible DIS-service to the entire UUCP community. Your uucico hosed you while transferring BITFTP mail, so BITFTP is bad for everyone. That is a grand-daddy of over-generalizations. BITFTP makes available a huge amount of information, much of which is not available in any other way. Alot of the traffic on USENET (one of those UUCP things, you know) is eliminated by the single posting "X is available via anonymous ftp at A.B.C.D." The fact that YOU might have to pass the same thing twice or thrice is more than compensated for by all the things you won't have to carry AT ALL because they weren't posted. When EVERY anonymous ftp site is also available via a mailserver, THEN you can argue that BITFTP is of NO service to UUCP. It will be a long time before that happens. Those who set up anon-ftp sites tend to think in terms of Internet and forget about anyone who can't ftp. You will NEVER be able to make that 'DIS-service' claim stick. > talk to the sites in Ontario, Canada, who are possibly going to lose all > internet connectivity partially due to increased mail volume (ie. BITFTP). And just how is BITFTP going to increase your mail volume when it no longer accepts mail requests? Or is this your threat for when human generated mail fills your spool? If I were one of these sites I would start looking for another feed right now, because you have already indicated that you aren't happy carrying their mail and are looking for the next available excuse to cut it totally. > > Your problem (which is the same problem here, BTW) is that a UUCP > >connection will happily accept that which it cannot store. The BITFTP > >connection is just a symptom. > > excuse me? There is none. You bitched about your spool area filling up, mail and news being lost, and your disk being trashed. You blamed users downstream from you, and BITFTP. If YOUR uucico didn't accept more stuff from your feed than there was room on your disk, your disk wouldn't have been trashed, mail and news would not have been lost, and your spool area wouldn't have filled. Your system would have processed what it could, and then, when there was space, would accept more. If you have a problem with supplying mail service to people that causes your disks to fill, then fix your uucico so it doesn't fill your disks. If you have a problem because you think your users should pay their own way, charge them. Don't supply mail services to your users and then tell them that they can't use them, and worse, don't tell the rest of the world not to do something just because you can't handle it.