Xref: utzoo news.admin:14499 news.software.b:7821 Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!think.com!zaphod.mps.ohio-state.edu!wuarchive!rex!uflorida!gatech!rutgers!maverick.ksu.ksu.edu!deimos.cis.ksu.edu!mccall.com!tp From: tp@mccall.com (Terry Poot) Newsgroups: news.admin,news.software.b Subject: Re: Really funny jokes being missed Message-ID: <1991May20.093018@mccall.com> Date: 20 May 91 14:30:18 GMT References: <1991May16.151523.28123@zoo.toronto.edu> <1991May18.211109.20401@zoo.toronto.edu> Reply-To: tp@mccall.com (Terry Poot) Organization: The McCall Pattern Co., Manhattan, KS, USA Lines: 119 In article <1991May18.211109.20401@zoo.toronto.edu>, henry@zoo.toronto.edu (Henry Spencer) writes: >You may call it what you wish. Our experience is that all alternatives >are >worse. The losses, while regrettable, are necessary. They are >reported >to the local sysadmin, which is the best that can be done safely. If >you >want this to be changed, propose a workable, fully thought out >alternative >without serious side effects. (Hint: you're going to have to put >some >serious effort into this, because all the obvious schemes occurred to >us >long ago. You needn't bother repeating them, and I'm not going to >bother >telling you yet again what's wrong with them.) Are you saying that this is a problem that doesn't merit attention? I just found out from 2 sysadmins (one in Kentuky, USA, one in New Zealand), that C news is now dropping my articles on the floor. I don't keep track of C news, I was unaware that there was a problem with the newsreader I use, the subject line of this thread is not exactly informative (I don't know why I actually read any of it, I've been ignoring it for some time), and C news reporting of the problem appears to be obscure enough that only 2 sysadmins on the entire net were willing to put forth the effort to determine where the messages came from, and who sent them. This could have been done with prior announcement, an attempt to find non-conforming news software and notify users and authors of the impending change, and some mechanism to ease the transition (like generating a specific report that would list for each article specifically affected by the change, the From: line, Message-Id:, and what was wrong with the article. Sysadmins that care could then do something about it. You could have even done something reasonable, like in this version bitching about the formatting problem, but accepting it, and in the NEXT version, rejecting it. That would have given the rest of the net some chance fix our software BEFORE you started throwing away articles. In article <28357D59.17BB@tct.com>, chip@tct.com (Chip Salzenberg) writes: >Administrators who get "bogus header" messages and don't pass them on >deserve flamage. Software that (finally!) implements the relevant RFCs >doesn't. Everyone other than the 2 people who told me about the problem, consider yourselves flamed if you have my articles in your bogus header file. I am reasonable sure that there are more the 2 entry-points in to otherwise fully connected C news sites on this net. I'd say hundreds of sysadmins out there are ignoring bogus header messages as a matter of routine. Chip, if you aren't one of them, I'd say your neighbors must be, because if you didn't get my articles, your neighbors dumped them. I'd guess very few sysadmins are doing anything at all about these messages. In article <1991May19.022322.29056@zoo.toronto.edu>, henry@zoo.toronto.edu (Henry Spencer) writes: >In article <1991May19.013616.10567@ms.uky.edu> kherron@ms.uky.edu >(Kenneth Herron) writes: >>... The message IDs are logged >>along with the complaint , but the messages themselves are thrown away >>>(of course) so the concerned administrator has to do a bit of >detective work. > >This is something we'd kind of like to do *something* about -- it's >not >nice to throw away the evidence -- but defining exactly what should be >done >is a little tricky and we haven't yet sorted it all out. Maybe you should have thought it out a little further before releasing this version? In article <1991May19.022219.18956@cs.cmu.edu>, cactus@zardoz.club.cc.cmu.edu (Todd Masco) writes: >In article ben@wri.com (Ben Cox) >writes: >>This is the lazy man's answer. Given sufficient effort, one could >probably >>write a shell script that would fix a Date: header. > >Oh? What would you do with a header, > >Date: 910201 You are aware of some software currently in use that generates this? >... >As has been said by othes, there's a reason behind RFCs. Better to >drop everything that doesn't conform to the standard -- otherwise, >some people will have some articles that mysteriously drop while >others posted by the same person will die. "My articles were >working," the user will whine to the admins. "What changed?" The >admins in at least one case would probably scratch their heads for a >few hours and then give up. > >The standard is almost useless if it isn't conformed to by everybody. >Dropping all non-conforming articles makes it perfectly clear what the >problem is -- the RFCs aren't being followed. Have you ever heard of a defacto standard? The defacto standard for dates in usenet messages has for sometime been that set of dates recognized by B news, which has apparently been more generous than the RFC. The C news change now drops messages that have always been acceptable to every news system on the net. The authors are correct in that we should comply with the RFC, but it was handled very poorly. I, as a reader of news.admin, should have been aware of this change before it was propagated world wide, installed, and started junking my messages, which are generated by dxrn, and are acceptable to ANU News, C news (all previous versions), B news, and to the best of my knowlege, all other news software in use on the net. Obviously, Henry Spencer is under no obligation to do anything at all in particular with software he writes, so don't even start that flame war. He doesn't have to even know standards exist. However, please don't try to construe this action as being in the public good. It wasn't. It could have been, if transition had been considered. -- 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