Xref: utzoo news.admin:14488 comp.mail.uucp:6585 Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!think.com!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!linac!att!news.cs.indiana.edu!nstn.ns.ca!uupsi!fozzie!stanley From: stanley@phoenix.com (John Stanley) Newsgroups: news.admin,comp.mail.uucp Subject: Re: BITFTP Message-ID: Date: 20 May 91 05:39:36 GMT References: <489@frcs.UUCP> Organization: Mad Scientist Lines: 58 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.