Xref: utzoo news.admin:14593 news.software.b:7908 Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!wuarchive!dsuvax!ghelmer From: ghelmer@dsuvax.uucp (Guy Helmer) Newsgroups: news.admin,news.software.b Subject: Re: Really funny jokes being missed Message-ID: <1991May23.232504.11648@dsuvax.uucp> Date: 23 May 91 23:25:04 GMT References: <1991May17.170033.17759@dsuvax.uucp> Organization: Dakota State University Lines: 160 In mathew@mantis.co.uk (CNEWS MUST DIE!) writes: >ghelmer@dsuvax.uucp (Guy Helmer) writes: >> In <5ukZ24w164w@mantis.co.uk> mathew@mantis.co.uk (CNEWS MUST DIE!) writes: >> >chip@tct.com (Chip Salzenberg) writes: >> >> True, C News drops articles on the floor. But it logs having done so, >> >> and it notifies the Usenet administrator in the output of newsdaily. >> >> >So what the hell use is that? None of those Usenet administrators told *ME* >> >about it, and I'm the one who has to fix my software. >[ Point not answered ] I don't have the message references handy, but I've seen postings from at least one admin that said he sent you mail about your non-conformant news headers when his machine dropped them. >> >If an article can be corrected to conform, then it should be, and should the >> >be delivered. >> >> Henry has pointed out many times that it is difficult to correct >> problems in an article. >And I have pointed out that certainly in this specific case (my articles >being thrown away due to a bad Date: header) it is trivially easy to fix the >header. Mail systems do it. So fix your own header before any conforming software downstream has to look at it. >> No. You better not pass on the article, or you're part of the problem. >If the error is non-critical and you can still pass on the article, why not >pass it on? Software which falls over in a heap as a result of bad input is >extremely broken, and C News should not attempt to Nanny it. C-news doesn't fall over when it sees bad input, it dumps the input. Software which ignores a bad input is not broken. >> Attempts to notify the article originator would be a bad thing to do, too. >> A site producing news may not receive mail or there may not be a path >> for a message to follow back to the sender. >In which case the notification will fail to get through. Fair enough. Mail >bounce messages sometimes fail to get through, but that doesn't mean you >shouldn't try to send them. Worst case senario: a machine suddenly munges the headers of a huge batch of old news and dumps it into a backbone site that isn't dropping improperly formed articles. The backbone site feeds 20 or sites through full feeds, which each feed another 10 to 20 sites each. Eventually, between twenty and a few thousand sites running your "improved" software will notice these articles and each site will think it's doing the "right thing" by trying to notify the original authors. At this point, everyone could sit back and watch the net eat itself. If the net ever recovered, the original authors of the old news would be drowning under mail from stupid news systems incorrectly pointing the finger at these poor authors. This senario isn't far fetched. Think about how many times over the past year sites have munged headers and injected bad articles into the news stream. >> Worse yet, if you attempt to both pass on the article and notify the sender, >> you and everyone running software like yours will clog the net with tons, er, >> megabytes, of useless messages. >Fair enough. So either pass on the article or notify the sender. I'm happy >with either. All I'm not happy with is not passing on the article AND not >notifying the sender. Again, the way I heard it, you were notified. >> And what about a message that's had it's headers munged by a single machine >> running junky software? A person would be deluged with messages from >> stupid news software incorrectly attributing the bad article to him/her >> and his/her software. >Deluged with one message, assuming that you don't both forward and report. >Or maybe ten or so messages if you're in a bit of the net which is >exceptionally well-connected via non-C-news sites. Refer back to the "worst case senario". You cannot back up a claim that only "ten or so messages" would be sent. >> >Rubbish. Throwing away data containing correctable errors, without issuing >> >any warning message, is NEVER the right thing. >> >> There are warning messages. Be a good admin---correctly configure your >> machine's news and mail software (i.e., have news send mail about problems >> to usenet and alias usenet to the news admin id, but don't depend on news >> to tell you when it is having trouble)---and watch your system. >I do. I read our system logs, I check for mail bounces and assist, I respond >to queries, I check out errors. Great! It sounds to me like your downstream sysadmin also watches his system, and tried to inform you when your system was producing non-conformant articles. That's what I meant by "be a good admin". >Unfortunately, there isn't a log file on our system which will tell me >whether UUNET's copy of C News is throwing away all my articles. If there >were, there would be no problem. >ALL I AM ASKING is that if a posting from a site X is dropped, SOMEONE from >site X should be told about it. This notification should NOT rely on some >random system administrator happening to take pity on site X. >> Dump your self-righteous attack against C-news. News isn't mission-critical; >> news isn't life-sustaining; delivery of articles isn't guaranteed. >True. However, delivery of articles is much less guaranteed now that C News >works in "drop all data on error" mode. >As to news not being important -- some people spend literally hours writing >stuff to post to Usenet. I'd rather that they continued to do so. And they >won't if they think that some big C News site will throw it all away because >they made a typo in a header field. >> The RFC's >> exist, and if your software doesn't implement them correctly, that's tough. >Interesting attitude. Am I to take it that you would not object if I wrote a >program to forge cancel messages for all articles which were not STRICTLY RFC >compliant? That actually might not be too bad of an idea. :-) It would get a lot of people's attention very quickly. >> Check your software to make sure it generates RFC-compliant articles. That's >> the only way you can be guaranteed that you have a good chance of getting >> your article distributed throughout the net. >So what if I'm an arts graduate? Do you really expect every random user of >Usenet to read through the RFC documents and check the news software which >exists on his system? I'd expect a news admin to be aware of whether his software has problems. With the finite number of news packages available, news admins can quickly become aware of problems (especially like this "bad header" discussion) by just reading the news. >> You can't blame anyone or >> any software for dumping your article and not telling you about it, >> especially if your software is faulty. >Of course I can. C News did not need to dump my article. It deliberately >chose to do so, however. It also deliberately chose not to warn me, and so >the error continued. Therefore it was at least partly C News' fault that the >articles were lost. You are entitled to your opinion. I don't agree. >mathew -- Guy Helmer, Dakota State University Computing Services helmer@sdnet.bitnet, dsuvax!ghelmer@wunoc.wustl.edu, ghelmer@dsuvax.dsu.edu "Everybody need a soft filter / Everybody need reverse polarity" - Rush