Path: utzoo!utgpu!news-server.csri.toronto.edu!torsqnt!lsuc!becker!bdb From: bdb@becker.UUCP (Bruce D. Becker) Newsgroups: comp.mail.uucp Subject: Re: BITFTP grief! Message-ID: <102085@becker.UUCP> Date: 20 May 91 04:56:46 GMT References: <1991May15.042146.29800@iguana.uucp> <1991May17.041635.4503@iguana.uucp> Organization: G. T. S., Toronto, Ontario, Canada Lines: 106 In article <1991May17.041635.4503@iguana.uucp> merce@iguana.uucp (Jim Mercer) writes: |In article stanley@phoenix.com (John Stanley) writes: |>merce@iguana.uucp (Jim Mercer) writes: |>> we can put in place all the filters we want, but the only way to resolve this |>> issue of file transfer by email is Education. |> |> The only way to solve the problem is to teach uucico to keep track of |>free space and inodes, and to stop accepting anything until there is |>space. "Can't tango - no space". And to notify the admin about the |>problem. This would solve the problem since uucico would happily pass |>the mail on, news would unbatch and expire, and then there would be |>space for more. | |changing uucico is not solving the problem of MBAS abuse. it solves the |problem of low spool space. | |this can also be solved by throwing hardware at it. | |the point is that we are providing email forwarding services as a benefit |to the local uucp community, who by and large use it in a reasonable manner. | |it's assholes and ignoramuses who absolutely positively have to have THAT |file, but are not willing to pay their own way. | |email is for messaging, not file transfers. *BZZZZZZZT* I'm sorry, contestant - that's the Wrong Answer! There's no use trying to pass off your personal opinion as Proven Fact. You may well wish to have such policies in effect at *your* site, but you've got no call to try to restrict other sites from using uucp/email in some way in which you don't approve. That's a kind of techno-censorship which has pretty bad implications. Perhaps it would be better if uucp/email services had better tools for re-routing so that you/others could automatically route email away from your site by some category method (or perhaps not, that's just an off-the-cuff suggestion). The real point is that whatever policies you implement for traffic thru your system, they should not interfere with the policies of your neighbors or downstream connections where such policies differ. That point is in a way quite idealistic without some qualification. In order to make this work, there needs to be some agreed notions between sites as to what is acceptable use. In addition, some kind of "culture" overall needs to prevail, so that new users can expect relatively similar services at any entry point on the net, and can expect to have to fulfill relatively similar obligations. Currently the propogation of such understandings (vague as they are at this time) seems to be lagging far behind the propogation of email/uucp connectivity. Not surprisingly the base uucp/email technology has implications which cannot always be met in practice due to capacity problems, etc. A naive but intelligent user might well try to put things into practice which negatively impact other systems, without being aware of the possibilities. Consequently some kind of system of education needs to be available in a form which is integral to the installation/implementation of uucp/email services on each system where it is provided. That itself is dependent on what is agreed are the "facts" of such education, which at the present time are still incompletely defined. Your "reasonable manner" may not be at all the same as another site's, due to your requirement, whims, bureaucracy, etc. Better if you were somehow able to encode what services your site was able/willing to provide, and somehow globally advertise them. Such "capability-based" connectivity would solve a number of these kinds of issues, and create a context for fresh new contentious problems to replace the current tiresome old ones we have now 8^). |>> how much of a net.lobby do we have to do to get pucc.princeton.edu to shut |>> down BITFTP? |> |> No! This is a valuable service to the entire UUCP community. Well, at |>least it is here. | |No! BITFTP is a terrible DIS-service to the entire UUCP community. | |talk to the sites in Ontario, Canada, who are possibly going to lose all |internet connectivity partially due to increased mail volume (ie. BITFTP). Bull. There are real problems with Internet connectivity here, but your assertion hardly describes them. Increased mail volume is not in and of itself an issue. -- ,u, Bruce Becker Toronto, Ontario a /i/ Internet: bdb@becker.UUCP, bruce@gpu.utcs.toronto.edu `\o\-e UUCP: ...!utai!mnetor!becker!bdb _< /_ "It's the death of the net as we know it (and I feel fine)" - R.A.M.