Path: utzoo!utgpu!water!watmath!clyde!ima!minya!jc From: jc@minya.UUCP (John Chambers) Newsgroups: news.software.b Subject: Re: Bounced incoming news Message-ID: <48@minya.UUCP> Date: 27 Jun 88 03:19:06 GMT References: <827@rivm05.UUCP> <351@geovision.UUCP> Organization: (none) Lines: 56 In article <351@geovision.UUCP>, graham@geovision.uucp (Graham Ashby) writes: > I am having trouble with the following groups: > comp.mail.elm, comp.std.c, comp.sources.games.bugs, comp.society.futures > > What happens is that when they are recieved here, they are immediately > sent out as if they had originated here. Of course there is a bogus > address and person generated (well, they might not be bogus where they > really are :-) > > These are not the only moderated groups, but other moderated groups are fine. If anyone knows the answer, please tell me, too. I can impart some information that you probably don't want to know, however. A couple months ago, I got a few (obviously machine-generated) letters from some daemon at berkeley, informing me that my news software was doing this, and I was a turkey because I hadn't diligently installed all the updates, one of which would correct this problem. I was ordered to install all the updates, or they would continue to shoot down articles from me. Well, I took the hint, and I am now up to patch level 13. Did it solve the problem? Not on your life! My inews is still re-transmitting all articles in comp.std.c (the only one of the above four that I allow on my machine ;-) to a bogus recipient, and they end up in my mailbox the next day. Not only that, but there are a LOT of other things now broken that weren't before. For instance, you may have noticed the lack of a Summary: line in my headers. If I accept the invitation to do one of these (from readnews or vnews), the result is that some unspecified subprocess (I suspect it's inews) bombs out with a Segmentation Fault. Maybe someday I'll hunt it down. On the other hand, I probably won't. I've already wasted far too much time just getting to the point where I can get a followup posted. I've given up making "rnews -U" work (it just exits with status=0), and use a script that runs thru the .rnews/* files one at a time. And on and on... Were the letters from the Berkeley daemon a hoax? Was some upgrade supposed to fix this problem? Can someone point me at the culprit code? Sending patches may be pointless; I've had to add so incredibly much debug output to find all the dereferenced null pointers and overrun buffers and all the other things wrong, that I doubt I'll ever be able to apply a patch to any of the files again. Some of my source files are more than twice their original size, all from added "if (debug>5) fprintf(...)" statements. Oh, well, at least rnews no longer builds both history and history.d/[0-9]. That's a big gain, at least. I hope 3.0 news is better debugged before it is released. -- John Chambers <{adelie,ima,maynard,mit-eddie}!minya!{jc,root}> (617/484-6393) [Any errors in the above are due to failures in the logic of the keyboard, not in the fingers that did the typing.]