Xref: utzoo comp.mail.misc:5567 comp.mail.uucp:6669 news.admin:14580
Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!ucsd!mvb.saic.com!ncr-sd!sceard!mrm
From: mrm@sceard.Sceard.COM (M.R.Murphy)
Newsgroups: comp.mail.misc,comp.mail.uucp,news.admin
Subject: Re: BITFTP grief!
Message-ID: <1991May22.141737.26521@sceard.Sceard.COM>
Date: 22 May 91 14:17:37 GMT
References: <1991May19.183202.5575@sceard.Sceard.COM> <1991May20.064047.13740@iguana.uucp> <1991May21.031016.9269@sceard.Sceard.COM> <1991May22.040039.21721@iguana.uucp>
Reply-To: mrm@Sceard.COM (M.R.Murphy)
Distribution: na
Organization: The Mole and Badger Association of Northern San Diego County
Lines: 66

In article <1991May22.040039.21721@iguana.uucp> merce@iguana.uucp (Jim Mercer) writes:
>In article <1991May21.031016.9269@sceard.Sceard.COM> mrm@Sceard.COM (M.R.Murphy) writes:
>>Is it surprising that lsuc (Law Society...) would seek the administrative
>>rather than the technical solution? :-)
>
>sometimes the administrative solution is better than the technical solution.

Sometimes the administrative solution is better than the poorly thought out
technical solution.

>
>Goal: reduce MBAS impact on USENET

Agreed. A noble endeavour. Really agreed. No smiley.

>
>Technical: install filters at many major mail hubs

A technical solution. Part of an overall solution. Not the whole solution.
Not the most important part of the solution. A kludge.

>
>Administrative: get MBAS's to straighten up their act.

Close. Real close. How to straighten up the act is another question.
How about having the MBAS not abuse its downstream sites unless they are
masochistic enough to accept the abuse willingly. That is, have the MBAS
check if the entire path for a transfer is cooperative. If it doesn't
know that an element of the path is cooperative, then that element should
be deemed non-cooperative, and the whole path is ng. Politely notifiy the
requestor to that effect. By "check the path", I mean "check the path."
As in "an address isn't good enough, you gotta check the path, and
every element in the path must be explicitly cooperative." Not hard to
do in software.

>
>which is easier, faster and more effective in the long run?
>

It is easier, faster, and more effective in the long run to fix a few friendly,
large, well-managed MBASes than it is to try to educate, coerce, or constrain
the vast morass of USENET, THISNET, THATNET, and THEOTHERNET. The administrative
solution of pulling the plug is a first level solution. It is not a real good
solution, but it is better than nothing.

WRT MBAS abuse, can you say attractive nuisance? I knew that someone who wanted
to play a lawyer on TV could :-)

WRT MBAS in general, I'm pretty sure that others thought the same as I did,
"What a Neat Idea (smile, smile). It can't last (smile, smile). Wow! What
a mess it'll be if ever more than just a few people use it. Oops. It'll be
interesting to see what happens."

50MB of VMS stuff in a 10MB spool is just another denial of service attack.
In this case it is an attack by the MBAS. Inadvertant, just trying to be
of service, genuinely trying to be useful and helpful, but still a denial of
service attack. The administration of the MBAS might be expected to know
better. To expect the user to know better is also a noble endeavour, but
probably will be disappointing.

Sort of like connecting two very large user communities with a 9600 baud
line, telling 'em they can communicate including sending data files of
humongous proportion, and then empirically observing the phenomenon of
bottleneck. :-)
-- 
Mike Murphy  mrm@Sceard.COM  ucsd!sceard!mrm  +1 619 598 5874