mcb@reason.ig.com (Michael C. Berch) (02/21/91)
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. > > One person posted 400K in one chunk to alt.sex.pictures; another posted an > enormous file of sampled sounds to alt.fan.monty-python. > > 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 [...] > > True, it's easy to get around the limit by splitting the file into bits; > but I believe that most of the net.bandwidth.abuse which goes on is down to > simple ignorance. [...] 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. If #1 is seen to be the problem, then there is nothing wrong with "getting around the limit" by splitting large encoded articles into parts. This is the accepted practice in groups that contain uuencoded binaries or image files. All that a site needs to do is reject incoming postings that are longer than a certain site-specified threshold. I would support a modification to the news transport software that implemented this. There is no need to send complaining mail to anyone or their site administrator about large postings; just drop them if your site can't handle them. It's your site's problem, not the network, so I suggest fixing the problem there. If #2 is seen to be the problem, we will need some very sophisticated software to sum up and drop/complain about agreegate postings by an individual. I personally don't see the need. As far as our site is concerned, large postings do not (yet) cause a problem. We got the massive Monty Python article and it got posted like anything else and expired when appropriate like anything else. (We receive news via NNTP which is able to handle arbitrarily large articles, and have a decent-sized news partition.) 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. -- Michael C. Berch mcb@presto.ig.com / uunet!presto.ig.com!mcb / ames!bionet!mcb
dan@gacvx2.gac.edu (02/22/91)
In article <A0b12860@mwowm.mantis.co.uk>, mathew@mwowm.mantis.co.uk (mathew) writes: > 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 (and possibly his system > administrator). This length-checking should be performed not just by the > originator's news software, but by the software which handles news > propogation for every site. > > Can anyone think of any good objections? Obviously the limit to impose needs > to be chosen carefully, but I'd say that something around 128KB would be > suitable. That should allow space for even a lengthy Kent Paul Dolan > posting :-) How would the size of the posting be measured? As the "Path:" header grows, so does the length of the message. Will sites downstream reject the message because the size has grown. How would 129KB files be handled. It would be nice to be able to turn this option off on local groups (not propagated to the net, or propagated only within a section of the net. Many mail gateways enforce a message length limit of 100KB. By policy BITNET message/file size limit is 300KB. While the 128KB limit would work within BITNET, it would run into a problem with the sites that have 100KB limits. Whos size limit would be used. How about a message given while posting "The message you are in the process of posting is larger than the recommended limit. If you choose to post this message you will probably be flamed and labeled a bad.net.citizen. You want to avoid the flames and abort this posting? ([Y] or N)" How about a semi-inteligent method of auto spliting a message when the message is posted. JOKE WARNING: (the next lines are not to be taken too seriously.) :-) Modify the news software to save users and the system manager time and :-) automaticly flame the poster of 400kb files. For maximum effect, the :-) flame should be sent when news adds the batch containing the 400kb :-) posting, and then whenever it is read by a user. To save more time news :-) software could even post a message in news.admin starting a discusion :-) about large posting, and create a forged alt group to put the user on :-) "net.display.for.all", something along the lines of: :-) :-) alt.shame.shame.bandwidth-eater.<user>.at.<site>.howbig.<size> :-) END OF JOKE: :-) -- Dan Boehlke Internet: dan@gac.edu Campus Network Manager BITNET: dan@gacvax1.bitnet Gustavus Adolphus College St. Peter, MN 56082 USA Phone: (507)933-7596
mathew@mantis.co.uk (mathew) (02/23/91)
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.
emv@ox.com (Ed Vielmetti) (02/25/91)
In article <uu6RX26w163w@mantis.co.uk> mathew@mantis.co.uk (mathew) writes: well, he writes something, but I didn't see it until two pages worth of some old posting which I had already read had already scrolled by. then I find out it's about overly long postings. i don't know about you but i am not convinced about someone going on overly long and with lots of excess verbiage about how we have to worry about big articles. -- Msen Edward Vielmetti /|--- moderator, comp.archives emv@msen.com
tneff@bfmny0.BFM.COM (Tom Neff) (02/25/91)
In article <EMV.91Feb24154102@poe.aa.ox.com> emv@ox.com (Ed Vielmetti) writes: >In article <uu6RX26w163w@mantis.co.uk> mathew@mantis.co.uk (mathew) writes: > >well, he writes something, but I didn't see it until two pages worth ^^^^^^^^^^^^^^^ >of some old posting which I had already read had already scrolled by. >then I find out it's about overly long postings. Hmm, that <uu6RX26w163w@mantis.co.uk> article had about 15 quoted lines, total. Two pages worth? Ed, I thought I told you to trade in that Casio Wizard :-)
pete@nyet.UUCP (Pete Hardie) (02/28/91)
In article <uu6RX26w163w@mantis.co.uk> mathew@mantis.co.uk (mathew) writes: >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 would prefer to see some form of limit arranged between feeds, incorporated into the UUCP/news software, such that I could get with my feed site and say: (my machine, my_sys) my_sys:MAX_FILE_SIZE = 32K his_sys:MAX_FILE_SIZE = 64K (feed machine, his_sys) my_sys:MAX_FILE_SIZE = 32K his_sys:MAX_FILE_SIZE = 64K Thus, it would find the size of the articles, and not queue up those that exceed the limit, marking them as skipped. This would allow the sites with megadisks pass on whatever is posted, but those of us with microdisks need never see the monster articles. It also prevents problems with trying to centralize the control, and update it, and so on. -- Pete Hardie mail: ...!emory!stiatl!slammer!nyet!pete "Well, Darkness has a hunger that's insatiable, And Lightness has a call that's hard to hear" -- Indigo Girls
jerry@olivey.olivetti.com (Jerry Aguirre) (03/01/91)
In article <580@nyet.UUCP> pete@nyet.UUCP (Pete Hardie) writes: >I would prefer to see some form of limit arranged between feeds, incorporated >into the UUCP/news software, such that I could get with my feed site and say: > >(my machine, my_sys) > my_sys:MAX_FILE_SIZE = 32K > his_sys:MAX_FILE_SIZE = 64K Or perhaps a syntax like: his_sys:world,comp,sci,...:F<64000: That already exists in the current version of B news.