Path: utzoo!bnr-vpa!bnr-fos!bmers58!schow From: schow@bmers58.UUCP (Stanley Chow) Newsgroups: news.admin Subject: Re: Noise in Message ID's causing dupes Summary: Is there not a checksum?? Message-ID: <284@bmers58.UUCP> Date: 29 Sep 89 19:30:36 GMT References: <14751@bfmny0.UU.NET> Reply-To: schow%BNR.CA.bitnet@relay.cs.net (Stanley Chow) Distribution: na Organization: Bell-Northern Research, Ottawa, Canada Lines: 56 Followup-To: Keywords: In article <14751@bfmny0.UU.NET> tneff@bfmny0.UU.NET (Tom Neff) writes: >OK, here's an example. Someone trashed a message ID en route, >enabling B news to post a dupe. > [extra info deleted.] >! Path: bfmny0!uunet!ginosko!gem.mps.ohio-state.edu!tut.cis.ohio-state.edu!ucbvax!ARISTOTLE-GW.JPL.NASA.GOV!pjs >! Message-ID: <8909271818.AA01035@aristotle.Jpl.Nasa.Gov> > >! Path: bfmny0!uunet!wuarchive!brutus.cs.uiuc.edu!apple!bionet!ames!lll-lcc!unisoft!mtxinu!ucbvax!ARISTOTLE-GW.JPL.NASA.GOV!pjs >! Message-ID: <890=271818.AA01035@aristotle.Jpl.Nasa.Gov> First of all, I am a relatively new *user* of Usenet and don't know a lot about the mysteries of the various news software and the protocols. Since this business of the duplicate articles is getting annoying and many people have looked at it with no resolution, I figured throwing in my guesses won't hurt anything. I am a little surprised this can happen. Isn't there a checksum somewhere that covers the message ID? Assuming (some news software) does not have checksum protecting the message ID (or that some idiot disabled it), then I have a scenerio that may explain the problem. The history of the article have to be something like: -- Site3, Id2 -- / \ --> Site1, Id1 Site4, Id1+Id2 \ / -- Site2, Id1 -- The error would have happened on the transmission from Site1 to Site3. (This assumes each site only transmites one copy of any article to its downstream sites). Following this reasoning, the duplicate article in question must have originated during the transmission from ucbvax to mtxinu. All other sites are propagating articles as they should. It is possible (barely) for the error to have been JPL -> ucbvax, but this requires that JPL thinks the first transmission failed but ucbvax to have accepted the first article. One confirmation would be to look at the path of the erroneous article at the "innocent" sites. The path should be "abnormal" in that it took a longer path of the form originator!..!Site1!Site3!...!Site4!..Site2. Another confirmation would be to look at the log files of the suspected link. It should have lots of transmission errors. (Assuming that at least the bodies of articles are protected by checksum). -- Stanley Chow BitNet: schow@BNR.CA BNR UUCP: ..!psuvax1!BNR.CA.bitnet!schow (613) 763-2831 ..!utgpu!bnr-vpa!bnr-fos!schow%bmers58 Me? Represent other people? Don't make them laugh so hard.