Article View: news.admin
Article #3418Re: What to do about humongous postings
From: mathew
Date: Fri, 22 Feb 1991 17:16
Date: Fri, 22 Feb 1991 17:16
66 lines
3846 bytes
3846 bytes
mcb@reason.ig.com (Michael C. Berch) writes:
> In the referenced article, mathew <mathew@mantis.co.uk> writes:
> > Recently there have been a couple of instances of people posting enormous
> > uuencoded files in one piece, causing various systems to crash.
[...]
> > People seem to think that something should be done. I suggest that any
> > posting longer than a certain threshold length should be dropped, and an
> > error report mailed to the originator [...]
>
> I think the statements about "getting around the limit" in the above
> posting shows that the author seems to be confusing two "problems" [I
> put "problems" in quotes as I am not willing to admit that either is
> sufficiently obnoxious so as to require a software-based correction]:
>
> 1) Certain large individual articles may harm particular systems
> by filling up disk partitions allocated to news or causing
> transport-level (e.g., UUCP) problems; and
>
> 2) Certain individual posters are thought to abuse the network by
> posting too many bytes (in the aggregate) in too short a period.
No, I'm quite aware that these are two separate problems.
I believe that there are a sufficient number of sites which have problems
with large articles that large articles should be discouraged. You _could_
drop large articles only when they hit UUCP, but that would be extremely
confusing to the user, not to mention annoying for those in the UUCP world who
_want_ to get the articles, but need them split up. (I don't think software
is up to intelligently splitting an article into multiple pieces depending
upon content...)
> Sites which are
> affected by large articles should either install filters to protect
> themselves, or drop those groups in which large articles often appear,
> i.e., the binary and image groups.
(1) It's not much use our dropping these articles _AFTER_ our system
has spent half an hour downloading them from our feed site. I want
inappropriately-long articles to be junked _BEFORE_ I pay for them and
before they cause our system to crash.
(2) We do drop the binary and image groups. I'm talking about incidents where
people post entire movie scripts, core dumps or whatever to a discussion
group.
(3) Spool space is limited. UUCICO doesn't know how big a file is until it's
too late.
So to clarify what I am proposing:
Single messages longer than a certain length (to be decided) which appear in
any newsgroups should be dropped, and mail sent to the originator. Personally
I can't think of any reason for single messages of more than (say) 128K in
a discussion group, or even in a binaries group for that matter. I'd probably
support a limit of about 32K for discussion groups.
I believe that most incidents of this type are caused by people who do not
understand that lots of us pay money to shunt Usenet articles around. This
was certainly the case in comp.sys.acorn, where I received mail from people
saying "if you don't like huge binary postings in a discussion group, just
hit 'n' and read the next article". It was also the case in
alt.fan.monty-python, where the naive user concerned was apparently unaware
that posting 700K in one message could cause any problems.
mathew.
Technical Details
Message-ID:
<uu6RX26w163w@mantis.co.uk>Path:
arc1-ca.pugleaf.net!utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!elroy.jpl.nasa.gov!sdd.hp.com!wuarchive!mit-eddie!bloom-beacon!eru!hagbard!sunic!mcsun!ukc!slxsys!ibmpcug!mantis!mathewReferences:
<Feb.20.16.34.15.1991.1272@reason.ig.com>Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!elroy.jpl.nasa.gov!sdd.hp.com!wuarchive!mit-eddie!bloom-beacon!eru!hagbard!sunic!mcsun!ukc!slxsys!ibmpcug!mantis!mathew From: mathew@mantis.co.uk (mathew) Newsgroups: news.admin,news.software.b Subject: Re: What to do about humongous postings Message-ID: <uu6RX26w163w@mantis.co.uk> Date: 22 Feb 91 17:16:53 GMT References: <Feb.20.16.34.15.1991.1272@reason.ig.com> Organization: Mantis Consultants, Cambridge. UK. Lines: 66