[news.software.b] Apology for repostings in alt - 2 C News bugs

lmb@vicom.com (Larry Blair) (09/25/90)

Bug 1:

An admin here reposted everything that he found in `junk' (I stopped creating
alt groups long ago) by removing the Message-ID and using `inews -d local'.
Unfortunately, our version of C News (PL 18, if you were counting) only
inserts `Distribution: local' if there is no Distribution header already
present.  As a result, any of the repostings that already had a Distribution
header got sent out to the world with a new Message-ID.

Bug 2: (or maybe not)

The path contained in the reposting shows `Path: vsi1!vsi1!...'.  I'm pretty
sure that 2.11 checked for your site in the path to prevent propagation loops.
C News obviously doesn't.  Is this a bug (or a feature :-)?  The path has to
be scanned to determine whether to pass the article or not so why not check to
see if your site is already in the list?
-- 
Larry Blair   ames!vsi1!lmb   lmb@vicom.com

mjr@hussar.dco.dec.com (Marcus J. Ranum) (09/25/90)

In article <1990Sep24.220833.230@vicom.com> lmb@vicom.com (Larry Blair) writes:

>Bug 2: (or maybe not)

>The path contained in the reposting shows `Path: vsi1!vsi1!...'.  I'm pretty
>sure that 2.11 checked for your site in the path to prevent propagation loops.

	I've been seeing exactly the same problem, and was starting to
wonder if I was hallucinating. [some of our month old+ news has leaked
back out onto the net - thanks to those of you who have pointed this
out] I'm running Cnews, patchlevel "most recent that I know of" :)

	If I post an article with a path like
Path: deucac!decuac.dec.com!decuac!decuac.dec.com!mjr

	it propagagates out just fine.

	We're also getting (though I hope that's fixed, now) articles making
a long, slow loop, and reaching our machine after their history entries have
expired here, and going back around. What's the best way to ensure against
this kind of problem ? I wonder if various Cnews sites have been lucking
out by virtue of Bnews sites "compartmenting" article loops...

mjr.

henry@zoo.toronto.edu (Henry Spencer) (09/25/90)

In article <1990Sep24.220833.230@vicom.com> lmb@vicom.com (Larry Blair) writes:
>... by removing the Message-ID and using `inews -d local'.
>Unfortunately, our version of C News (PL 18, if you were counting) only
>inserts `Distribution: local' if there is no Distribution header already
>present...

I don't think it has ever been clear what the semantics are supposed to be
if the same header crops up in both inews options and the article itself.
(Actually, we think most of the inews options are silly ideas, since it's
no harder to just plug the header into the article.)

>The path contained in the reposting shows `Path: vsi1!vsi1!...'.  I'm pretty
>sure that 2.11 checked for your site in the path to prevent propagation loops.
>C News obviously doesn't.  Is this a bug (or a feature :-)?  The path has to
>be scanned to determine whether to pass the article or not so why not check to
>see if your site is already in the list?

It's one more check to do on a critical path, and one that in normal (and
most abnormal) circumstances serves no purpose.  Loop breaking is normally
done by your neighbors not sending you the article, not by you recognizing
that it's yours.
-- 
TCP/IP: handling tomorrow's loads today| Henry Spencer at U of Toronto Zoology
OSI: handling yesterday's loads someday|  henry@zoo.toronto.edu   utzoo!henry

jerry@olivey.olivetti.com (Jerry Aguirre) (09/26/90)

In article <1990Sep24.220833.230@vicom.com> lmb@vicom.com (Larry Blair) writes:
>The path contained in the reposting shows `Path: vsi1!vsi1!...'.  I'm pretty
>sure that 2.11 checked for your site in the path to prevent propagation loops.

I don't think that it should.  Checking the path to see if a site is
already listed is an optimization performed by the SENDER.  It is
important for UUCP feeds to non-leaf sites.  The real protections against
duplicates are the message ID and posting date.  Articles older than what
is retained in the history file should be discarded.

I think it is a bad idea to rely to heavily on the path because there is
no guarantee against duplicate news names.  Before someone mentions the
UUCP map project remember that is for UUCP, not news.  There are sites
that run news without UUCP and sites that just don't register.

As a specific example I was sending an aged ihave to sun.com with all
the articles from the previous day.  I monitored the articles they were
requesting (finding a minor bug in my sys line for them) and noticed
that they were also requesting articles that they should have received.
A little further investigation showed that those articles alread had
"sun" in the path so none of sun.com's neighbors were sending them to
sun.

The problem was that the "sun" in question was "sun.soe.clarkson.edu".
So, any articles originating on or passing thru the other "sun" won't
get to sun.com.  As there is no official control, or even registration,
of news sites there is no mechanism to prevent such naming clashes.
If sun.com rejected those articles then it was doing the wrong thing as
it had never seen them before.

I wonder how the small amout of overhead C news saves by not parsing the
date compares to the CPU, modem, and PEOPLE overhead spent on processing
recirculated expired articles.

				Jerry Aguirre

lmb@vicom.com (Larry Blair) (09/26/90)

In article <1990Sep25.153457.2612@zoo.toronto.edu> henry@zoo.toronto.edu (Henry Spencer) writes:
=In article <1990Sep24.220833.230@vicom.com> lmb@vicom.com (Larry Blair) writes:
=>... by removing the Message-ID and using `inews -d local'.
=>Unfortunately, our version of C News (PL 18, if you were counting) only
=>inserts `Distribution: local' if there is no Distribution header already
=>present...
=
=I don't think it has ever been clear what the semantics are supposed to be
=if the same header crops up in both inews options and the article itself.
=(Actually, we think most of the inews options are silly ideas, since it's
=no harder to just plug the header into the article.)

I was so sure of your response, Henry, that I composed the following paragraph
yesterday:

The decision about what to do when a directive appears as both a command line
option and in the file being acted upon is not ambiguous.  Unix, as defined
by its many utilities, has a clear direction: command line options take
precedence.  Programming difficulty or execution speed should not be an
issue here.

As to whether one should use the command line option or not: you can't be
serious about your argument.  Do you really think that it would have been
just as easy to have modified the 400 articles that were being locally
reposted as it was to stick `-d local' on the command line?

You have made it clear innumerable times that you feel that inews and other
2.11 programs are silly.  Why, then, did you implement look-alikes?  I
suspect it was to make life easier on people making the transition.
Unfortunately, users are bound to assume that they operate the same as their
2.11 namesakes, particularly if the documentation doesn't point out any
differences.  By regarding inews as silly and only making a half hearted
attempt to implement it properly, you have unwittingly released hundreds of
bogus newgroups to the net and now hundreds of dups.

There is nothing wrong with having made mistakes in the original
implementation.  That is to be expected with a system this size.  What is
needed is to acknowledge the problems and try to correct them.

If you think that inews is silly, yank it.
-- 
Larry Blair   ames!vsi1!lmb   lmb@vicom.com

mjr@hussar.dco.dec.com (Marcus J. Ranum) (09/26/90)

In article <1990Sep25.210842.9@vicom.com> lmb@vicom.com (Larry Blair) writes:
>By regarding inews as silly and only making a half hearted
>attempt to implement it properly, you have unwittingly released hundreds of
>bogus newgroups to the net and now hundreds of dups.

	*Henry* did that ?! That seems rather out of character to me. If
someone can give me concrete proof, I'll call him and rattle my copy of
Sabre-C at him.  :)

	Maybe naming Cnews' "inews" after Bnews' was a mistake, but any
news admin who doesn't familiarize h*self with the difference is making a
bigger and more damaging mistake. (I know - I made this mistake myself.)

mjr.

henry@zoo.toronto.edu (Henry Spencer) (09/28/90)

In article <1990Sep25.210842.9@vicom.com> lmb@vicom.com (Larry Blair) writes:
>=I don't think it has ever been clear what the semantics are supposed to be
>=if the same header crops up in both inews options and the article itself.
>
>The decision about what to do when a directive appears as both a command line
>option and in the file being acted upon is not ambiguous.  Unix, as defined
>by its many utilities, has a clear direction: command line options take
>precedence...
>
>You have made it clear innumerable times that you feel that inews and other
>2.11 programs are silly.  Why, then, did you implement look-alikes?  I
>suspect it was to make life easier on people making the transition.

No, sorry, you have misunderstood badly.  We implemented lookalikes because
these are part of the *user interface*, and zillions of things would break
if we changed that.  That does not alter our very low opinion of a lot of
the silly, frivolous features that those programs have acquired over time.

That being the case, the relevant question is *not* what the "clear
direction of Unix" is, but what the existing behavior is.  The B News
documentation simply does not address the point at all, which can be
taken to imply either (a) that no specific behavior is guaranteed, or
(b) that this was an oversight in the documentation.  In case (a), we're
in the clear.  In case (b), it's not clear how to proceed, because it
is hard to sort out the implementation accidents from the deliberate
decisions if you read the code or experiment with it... and we really
don't have time for either.  If someone would care to find out (not
"speculate"; "find out"!) what 2.11 does, we would be interested.
(Not "committed to doing the same", mind you, just "interested".)

Incidentally, it is unwise to rely on undocumented features.

>As to whether one should use the command line option or not: you can't be
>serious about your argument.  Do you really think that it would have been
>just as easy to have modified the 400 articles that were being locally
>reposted as it was to stick `-d local' on the command line?

Just about, since presumably you did not type "inews -d local ..." 400
times by hand, and you would not do the modifications by hand either.
Awk is a very useful program.


All of this leaves aside what I'm inclined to consider the real question
here:  what is the *most useful* behavior?  That depends on what you're
trying to do with -d.  There are about three plausible approaches, given
that -d ought to do *something*:

1. -d supplies a default distribution, used only if there is none in
	the article.  This is roughly the effect C News gets now, by
	accident I think.

2. -d overrides any distribution in the article.  This would be the most
	useful approach in Larry's position when using his solution -- not
	obviously the best solution to his problem, by the way, but not
	a ridiculous one either -- but may not be right for others.

3. Presence of both -d and a distribution is an error.  This is probably
	the right solution if you think of inews as primarily a human
	interface.

Contributions from others who have run into this issue would be welcome.
-- 
TCP/IP: handling tomorrow's loads today| Henry Spencer at U of Toronto Zoology
OSI: handling yesterday's loads someday|  henry@zoo.toronto.edu   utzoo!henry