Xref: utzoo news.software.b:7963 news.admin:14658 Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!maverick.ksu.ksu.edu!deimos.cis.ksu.edu!mccall.com!tp From: tp@mccall.com (Terry Poot) Newsgroups: news.software.b,news.admin Subject: Re: Really funny jokes being missed Message-ID: <1991May26.082113@mccall.com> Date: 26 May 91 13:21:13 GMT References: <28357D59.17BB@tct.com> Reply-To: tp@mccall.com (Terry Poot) Organization: The McCall Pattern Co., Manhattan, KS, USA Lines: 126 In article , tim@dell.co.uk (Tim Wright) writes: >In mathew@mantis.co.uk (CNEWS MUST DIE!) writes: >>chip@tct.com (Chip Salzenberg) writes: >>> Administrators who get "bogus header" messages and don't pass them on >>> deserve flamage. > >>Unfortunately, it seems there are quite a few sites out there whose system >>administrators have better things to do with their time than read the log >>files and send mail messages to people whose articles have been junked. > >You don't need to read the log files. I take it you do have access to awk, >cron and mail. It can't be that hard to put together a small summarising >script to mail you, can it ?? Quite a few sites conversely do take the time. In my case, 2. If you have such a tool, why don't you send it to Henry or Geoff so they can include it with C news? C news does not include such a facility. Do you actually believe even a majority of C news admins will take the time to write one? >One of the biggest obstacles to improving usenet over time has been the >problem of shoddy software. Whilst it is regrettable that some sites lost >some articles, it was quite amazing to see how quickly the volume of bad >articles dropped. You want traffic volume to go down? Do a parity check on the message ID, and drop the article if the parity is even. It will have amazing results on bandwidth. Of course, that, too, is antisocial. >If you really spend >hours preparing articles, surely you can spend 30 seconds verifying the >validity of your headers. Novice users should not go around editing headers >anyway unless they have read the specs and deserve to have their articles >dropped if they don't. Are you saying you do or don't want novice users to attempt to correct the headers in ways C news likes? I've been talking about headers that are valid to B news, but not C news. You seem to be saying that the user should verify his headers, but that he should be required to read and understand the RFC's before doing so. Are all your users required to read RFC822 and RFC1036 before using news? Mine aren't, and I don't think they should be. >The only sympathy I can have is if someone is using common and supposedly >correct news software and finds that it is generating bad headers. I do not >believe that there have been many/any examples of this. I would welcome >counterexamples. I am a user (not author) of the mxrn newsreader, which generated B news format dates that C news did not like. I found out about this whole issue this last week, and have generated a patch. I've sent the patch out and hopefully in the near future, other sites running mxrn (or dxrn, the other variant built from the same sources) will have the patch installed. In the mean time, all C news sites are dropping all messages from users of this software, and I'd venture to guess that almost none of them know about it, as nobody has made any effort to find them and tell them about it. I've attempted to post the patch widely, but I imagine that this problem will persist for quite some time, given the general problem of trying to get software updated on the net. If you think I should have known about this before, look again at the subject line of this thread. Exactly 2 news admins, world wide, told me there was a problem. Thus, obviously, logging these things as a method of reporting has failed miserably. (I have since gotten mail from at least 2 news admins that knew I had a problem, and DIDN'T tell me.) Given the wide range of date formats that B news handles, did you honestly believe that there is no news software that generates any of them but the one in RFC822? In article , tim@dell.co.uk (Tim Wright) writes: >In <1991May20.141852.30919@kuhub.cc.ukans.edu> >sloane@kuhub.cc.ukans.edu writes: >>In what groups were these warnings posted? I don't recall seeing >>them. If the only group was news.software.b, then I can understand >>why poeple not runing b or c news wouldn't see them. Or are you >>contending that everyone should read n.s.b just in case some change >>was made that would cause them problems? Do you read n.s.anu-news? > >No, but since the majority of the net is made up of B and C news sites >and news.software.b carries articles of importance to all net users I >would say that any VMS news sysadmin not reading it was foolish. What an incredibly chauvinistic attitude! The whole point of separate newsgroups is so people that aren't concerned with a topic don't have to read it. If everyone needed to know everything about B news and C news, it'd be discussed in news.admin. On the contrary, when B news and C news people are going to do something that affects other than their own user community, it is appropriate for them to seek to reach that other community, not the other way around. In this case, that means news.admin as a minimum. In this particular case, I happen to think that news.announce.important would have been in order. (That is, theoretically, the only group that supposedly all usenet sites carry, and probably has an extrememly high readership, possibly enough to have avoided most of the problems, and maybe even a lot of this debate.) I can quite readily guarantee that if an announcement of this had been posted there well before this action were taken, I'd (or the author) would have fixed dxrn/mxrn well before the C news patches were installed. BTW, I think a posting to news.announce.important is still in order. It won't avert problems, as an early posting would have done, but it may help people who don't know their messages are being dropped find out about it and take some appropriate action. If you believe these people will be told by some kindly C news admin that their articles are being rejected, you are hopelessly naive. BTW, I applaud the list that scott@zorch posted to news.lists. However, I suggest it be retitled. The subject line looks like a C news bug report, and in any case totally uninteresting to non-C news admins. I only looked at it because it was mentioned here. I would have skipped it. Also, I'm not in it. Since C news dropped my articles (before I patched mxrn) they presumably never made it to zorch. Thus, one such list will only find a small minority of the sites having the problem. If, however, this had been done as I have suggested, by putting in the messages one release before discarding the articles, this would have found many more problems. I'm interested if Henry has considered this, and what flaw it has that I'm overlooking. Lists could have been collected from large sites around the net and merged (by a program of course), producing a reasonable list of sites generating bogus headers. It wouldn't be complete, but would have been better than nothing. (Yes, I know the suggestion was after the fact, but I didn't know about this issue before the fact.) -- Terry Poot The McCall Pattern Company (uucp: ...!rutgers!ksuvax1!deimos!mccall!tp) 615 McCall Road (800)255-2762, in KS (913)776-4041 Manhattan, KS 66502, USA