[news.software.b] More article munging - who's doing this?

lmb@vsi1.UUCP (Larry Blair) (10/20/88)

In article <25047@tut.cis.ohio-state.edu> karl@triceratops.cis.ohio-state.edu (Karl Kleinpaste) writes:
=Another article has been found to be trashed by someone along the way.
=
=Original copy of article, in good condition:
=
=Message-ID: <3580@cs.utexas.edu>
=
=Second copy of article, damaged:
=
=Message-ID: <3580@cs.utexas.eds:<

When you consider how susceptible to noise modem connections are, I find it
amazing that you don't see this 10 times a day.  Actually, we probably do,
but it goes unnoticed.  Maybe that would explain at least some of the times
when you see the (apparently) same article twice.

Maybe there should be a "Crc:" field in the header.  Old news versions
would ignore it, but the new versions could throw away the article and
generate a "sendme" for the Message-ID.
-- 
Larry Blair   ames!vsi1!lmb   lmb%vsi1.uucp@ames.arc.nasa.gov

dtynan@sultra.UUCP (Der Tynan) (10/20/88)

In article <1118@vsi1.UUCP>, lmb@vsi1.UUCP (Larry Blair) writes:
> 
> Maybe there should be a "Crc:" field in the header.  Old news versions
> would ignore it, but the new versions could throw away the article and
> generate a "sendme" for the Message-ID.
> -- 
> Larry Blair   ames!vsi1!lmb   lmb%vsi1.uucp@ames.arc.nasa.gov

This won't work.  If the CRC is corrupt, then NOTHING in the article is OK,
including the Message-ID.  What happens if the modem damage does something
like putting a tab in the Message-ID (sound familiar? - how many sendme's
does it take to get a microsoft article?? :-).  If the CRC is shot, then
bye-bye article.   Of course, why fix the problem by changing news, when
the *real* problem is a buggy uucp connection.  Of course this isn't a
perfect world, or anything...
						- Der
-- 
Reply:	dtynan@sultra.UUCP		(Der Tynan @ Tynan Computers)
	{mips,pyramid}!sultra!dtynan
	Cast a cold eye on life, on death.  Horseman, pass by...    [WBY]

lmb@vsi1.UUCP (Larry Blair) (10/20/88)

In article <2584@sultra.UUCP> dtynan@sultra.UUCP (Der Tynan) writes:
>In article <1118@vsi1.UUCP>, lmb@vsi1.UUCP (Larry Blair) writes:
>> 
>> Maybe there should be a "Crc:" field in the header.  Old news versions
>> would ignore it, but the new versions could throw away the article and
>> generate a "sendme" for the Message-ID.
>This won't work.  If the CRC is corrupt, then NOTHING in the article is OK,
>including the Message-ID.

This is not a problem because if the Message-ID is corrupted, the sendme will
be just be requesting a nonexistent article.  Not a problem.

There is a problem with sending a sendme, though.  You can only send it to
a feed that is also running the crc check, otherwise a loop will result.
A possible way to tell might be to use a different to.site group for these,
such as to.site.crc.  Only sites with crc checking create the group.

-- 
Larry Blair   ames!vsi1!lmb   lmb%vsi1.uucp@ames.arc.nasa.gov

randy@umn-cs.CS.UMN.EDU (Randy Orrison) (10/21/88)

In article <1118@vsi1.UUCP> lmb@vsi1.UUCP (Larry Blair) writes:
|In article <25047@tut.cis.ohio-state.edu> karl@triceratops.cis.ohio-state.edu (Karl Kleinpaste) writes:
|=Original copy of article, in good condition:
|=
|=Message-ID: <3580@cs.utexas.edu>
				 ^
|=
|=Second copy of article, damaged:
|=
|=Message-ID: <3580@cs.utexas.eds:<
				 ^^
People often do global changes of '>' to something else to fool the
inews line counter.  Perhaps a better fix is to have inews check
message ids in articles being posted and complain if the ids have been
munged; on the other hand this wouldn't help with people who don't use
real news (UUPC type things, for example).

	-randy
--
Randy Orrison, Chemical Computer Thinking Battery  --  randy@cctb.mn.org
(aka randy@{ux.acss.umn.edu, umn-cs.uucp, umnacca.bitnet, halcdc.uucp})
"Nondeterminism means never having to say you are wrong."

karl@triceratops.cis.ohio-state.edu (Karl Kleinpaste) (10/21/88)

randy@umn-cs.CS.UMN.EDU (Randy Orrison) writes:
   |=Message-ID: <3580@cs.utexas.eds:<
				    ^^
   People often do global changes of '>' to something else to fool the
   inews line counter.  Perhaps a better fix is to have inews check
   message ids in articles being posted and complain if the ids have been
   munged...

Um...The Message-ID: is generated by inews directly, not by the person
writing a note.  Perhaps you were thinking of bad changes to the
References: line?

--Karl