Xref: utzoo news.admin:15553 news.software.b:8448
Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!uunet!kyle
From: kyle@uunet.uu.net (Kyle Jones)
Newsgroups: news.admin,news.software.b
Subject: Re: Articles rejected by C news at ukma
Message-ID: <1991Jun26.220203.17522@uunet.uu.net>
Date: 26 Jun 91 22:02:03 GMT
References: <1991Jun25.172300.24154@zoo.toronto.edu> <1991Jun26.024210.9578@ccu.umanitoba.ca> <1991Jun26.155257.5692@zoo.toronto.edu>
Organization: UUNET Communications Services
Lines: 26

henry@zoo.toronto.edu (Henry Spencer) writes:
 > To properly implement the robustness principle, when you relay
 > traffic you *must* make sure it meets the specs, either by
 > repairing deviations or by rejecting nonconforming articles.
 > 
 > We chose rejection because of repeated bad experience with software that
 > attempts repairs.  Repair works fine when the deviations are the expected
 > ones.  Unexpected deviations, however, all too often get "repaired" into
 > legal but erroneous trash.  When dealing with the sort of volume we see
 > in news traffic, this can be disastrous for you, your neighbors, or even
 > the entire net.

The flaw in this logic is that you are discarding data that you
cannot reproduce.  This is not robustness.  Robustness is coping
intelligently with bad input, not discarding it.  A local agent
like postnews can afford to be finicky and refuse to send
articles, since the local user can try again.  A relay many hops
removed from the original sender doesn't have that luxury.  If
relaynews can't figure out how to repair an article, then the
very _least_ it should do is put the article into a place where a
smarter program (or a human) can have a crack at it.

There's already a newsgroup for wayward articles: "junk".  Why, you could
even partition it into subgroups, e.g. junk.not-in-sys, junk.not-in-active,
junk.bad-date, junk.no-subject, junk.no-newsgroup, junk.no-message-id,
junk.bad-message-id, junk.fubar ... :-)