Newsgroups: news.software.b
Path: utzoo!henry
From: henry@zoo.toronto.edu (Henry Spencer)
Subject: Re: article "header" contains non-header line
Message-ID: <1991Apr16.200219.8743@zoo.toronto.edu>
Date: Tue, 16 Apr 1991 20:02:19 GMT
References: <1991Mar25.220106.25166@zoo.toronto.edu> <1991Mar28.080325.7729@Daisy.EE.UND.AC.ZA> <1991Mar28.165240.13757@zoo.toronto.edu> <5299@pkmab.se>
Organization: U of Toronto Zoology

In article <5299@pkmab.se> ske@pkmab.se (Kristoffer Eriksson) writes:
>> The above suggestions work fine for one or two articles, but less well for
>>ten thousand "obviously bad" articles.
>
>Where would you get ten thousand bad articles from?

It's not prohibitively difficult to arrange it, if one of your news feeds
has been badly constipated -- or had to be restored from an old backup --
and suddenly dumps several megabytes of very stale news on you.  Systematic
mangling likewise is not hard to arrange, especially if you're a neighbor
of a gateway machine running badly-written software.

>And why would it not work
>to store them somewhere (for instance in junk), if it would have worked to
>store them together with all other news had they just contained a few more
>spaces in strategic places?

Maybe they would have been rejected for other reasons (e.g. duplication)
if those headers had been legal.  Putting them in junk, at the moment,
also means passing them on to other sites, which is definitely not wanted.
(Although Geoff has talked about changing this.)

>>There were various possibilities for how to go about this, but it always
>>seemed to boil down to the hard, cold fact that people seldom fix their
>>news software until they are forced to.  Alerts just don't help much.
>
>Since silently dropping bad articles won't force anyone to do anything...

It's not (quite) silent; the dropping is logged and newsdaily reports on it.

>... If you think the problem will not go away,

We think the problem will go away, albeit slowly.  Word will percolate
upstream that postings are getting dropped.  We'd prefer a more direct
method of notification, but there really isn't any way to get it to the
people at fault -- the software authors -- without inconveniencing a lot
of innocent people and possibly making them pay substantial phone bills
for the privilege.

>the only reasonable thing to do is to give in and make the best of the
>situation as it is, as others have already pointed out: be liberal in what
>you receive and conservative in what you send. Headers missing a space are
>very far from irrecoverable.

As I've said before, we are *still* more liberal in what we receive than
most other news packages, notably B News.

Headers missing a space are recoverable, *if* you're sure that's the only
problem, and *if* you're willing to rewrite headers in the conviction that
you know what the problem is.  We see no way the software can be confident
of either of these things.  We've seen too many examples of software that
is *sure* it understands the situation, and proceeds to make it worse by
well-meaning attempts at repair.

>You might look at the articles path and only send complaints if the article
>hasn't passed an unreasonable number of sites.

That's workable unless one of those reasonably-few sites is, say, uunet.
What you really want to control for is fanout, which is only very loosely
correlated to path length.

It's easy to concoct methods that will send a small number of complaints
to the author in the typical case.  The problem is making them work in
the extreme cases.  Believe me, we *have* thought about this.  At length.
We see no solution.

>But apart from that, why would a few hundred comlaints be such a bad thing?

You've obviously never had to pay Usenet phone bills yourself, or justify
them to a skeptical management.

>And, talking about forcing people to fix their software, isn't a full
>mailbox of complaints more of a force than plain silence?

Sure, if there were some way to send them to the software author, rather
than his innocent victims.  Contrary to popular misconception, not everyone
on Usenet has the expertise to fix the software when something goes wrong.
-- 
And the bean-counter replied,           | Henry Spencer @ U of Toronto Zoology
"beans are more important".             |  henry@zoo.toronto.edu  utzoo!henry