Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!think.com!zaphod.mps.ohio-state.edu!uwm.edu!linac!att!news.cs.indiana.edu!nstn.ns.ca!uupsi!fozzie!stanley From: stanley@phoenix.com (John Stanley) Newsgroups: comp.mail.uucp Subject: Re: BITFTP grief! Message-ID: Date: 20 May 91 04:12:09 GMT References: Organization: Mad Scientist Lines: 84 smd@lsuc.on.ca (Sean Doran) writes: > If the people who had ordered huge VMS files or gcc/gas had asked us first, > we would have pointed them at the University of Toronto or taken steps to > uucp the files directly to them. > > Instead, they (like many proponents of BITFTP) argue that BITFTP is an > essential service, and that intermediate sites for some reason ought to be > able to handle 16 Mbytes worth of extra data, just go ahead and grab files > willy-nilly. I have the ls-lR from my feed. If it is there, I ask for it from there. None of the stuff I have asked for has been. If you have a problem with sites downstream from you, deal with the sites downstream from you. Don't kill a service that IS being used responsibly by many sites just because you can't handle your downstream sites. > | email is for messaging, not file transfers. > > Unless _everyone_ along the way gives a direct OK to a file transfer. Agreeing to route mail is approval to route mail. > | > What will you do when someone posts a request for something and > | >dozens of people mail it to him? > > If the somebody had been thinking, she or he would have asked for tips on > where to find the material in question, rather than posting a "please send > XYZ to me" message. Nobody wants to handle this question. They keep saying that the user who did this shouldn't have. It is too late. He already did. How do you handle what he already did? Do you cut off all mail because users can't handle it? As for asking how to get things, I can't count the number of times I have gotten the response 'anonymous ftp' when I ask that. > | talk to the sites in Ontario, Canada, who are possibly going to lose all > | internet connectivity partially due to increased mail volume (ie. BITFTP). > > Alternatively, talk to the sites in Ontario face the prospect of paying > $500/a to our Regional Internet (ONet) if they want to send or receive mail > across it. The policy is justified by pointing out that the unconnected And I will be paying $900 this year. Cry for Ontario. And $US are bigger than $CAN. > No, John Stanley, the problem here is that people do not think of the > consequences of ordering huge files across a store-and-forward network of > UUCP sites (and an often costly one, too) and even if they do, they don't No, Sean Doran, the problem was that Mr. Mercer's disks filled up and he lost mail and news. If the store-and-forward network did not hose disks and drop news and mail, the consequences would be much less severe, and would fall under 'cost of doing business'. The other problem here is that nobody wants the hassle of managing their users, they want to take the easy way out by stopping EVERYONE from doing what they won't tell their users to stop. > A simple note to the postmaster of every mail-handling site between you and > BITFTP saying: ``I would like to order file xyz from BITFTP. It will > probably travel back through you. Is that OK?'' is a good idea. And just who are the mail handling sites between me and bitftp? The only one I know for sure is uupsi, and I have a contract with them that says unlimited news and mail. I cannot predict who will handle the mail once PSI puts it on the Internet. How am I supposed to contact them? Second, if a site agrees to route mail, they have agreed to route mail. If they have problems with mail I send, I expect that they will contact me about it and we can go from there. Since I cannot at any time predict all possible permutations of mail routing, I cannot send these simple notes. > It's an > especially good idea, given that one of those postmasters might have a copy > that doesn't have to be chopped up and mailed to you, but can be uucped > directly. UUCPing anything from anywhere but uupsi is tieing up slower UUCP resources to the benefit of faster Internet ones. This is not a good tradeoff.