kherron@ms.uky.edu (Kenneth Herron) (06/16/91)
Please note the large number of entries from goofy.Apple.COM,
cbmvax.commodore.com, nntp-server.caltech.edu, and ucrmath.ucr.edu;
all of these show up regularly in these dropped-article logs. I've
sent mail to these sites with no result.
There's also a site generating message IDs like
<12912.pancake.0212912>
These articles are getting dropped as well.
Dropped Articles, week ending Sun Jun 16 07:44:37 EDT 1991
Header contains non-header line:
<1991Jun11.062042.21226@csc.canberra.edu.au>
<6930@gara.une.oz.au>
<91164.140326KICL1MG@BYUVM.BITNET>
<91161.132041YZKCU@CUNYVM.BITNET>
<91164.140824JCEHC@CUNYVM.BITNET>
<9106140246.AA17281@client>
<2370@abvax.AB.Com>
<5bEB02Zw08Nj01@JUTS.ccc.amdahl.com>
<5cjp02gY08.901@JUTS.ccc.amdahl.com>
<53832@apple.Apple.COM>
<53911@apple.Apple.COM>
<53983@apple.Apple.COM>
<13977@goofy.Apple.COM>
<13981@goofy.Apple.COM>
<14002@goofy.Apple.COM>
<14023@goofy.Apple.COM>
<14024@goofy.Apple.COM>
<14029@goofy.Apple.COM>
<14047@goofy.Apple.COM>
<14049@goofy.Apple.COM>
<14065@goofy.Apple.COM>
<14068@goofy.Apple.COM>
<14070@goofy.Apple.COM>
<14074@goofy.Apple.COM>
<64612@bbn.BBN.COM>
<1943@wsc-sun.BOEING.COM>
<3038@public.BTR.COM>
<13073@claris.com>
<13074@claris.com>
<22280@cbmvax.commodore.com>
<22325@cbmvax.commodore.com>
<22326@cbmvax.commodore.com>
<22421@cbmvax.commodore.com>
<22423@cbmvax.commodore.com>
<22465@cbmvax.commodore.com>
<1991Jun10.144107.5475@europa.asd.contel.com>
<3300@esquire.dpw.com>
<15165@encore.Encore.COM>
<20407@crdgw1.crd.ge.com>
<20556@crdgw1.crd.ge.com>
<11355@bunny.GTE.COM>
<1991Jun14.232203.6103@mav.com>
<9106112006.aa00492@ingate.microsoft.COM>
<87@swpyr2.sbc.com>
<RJOHNSON.91Jun10121056@olorin.shell.com>
<684@quad.sialis.com>
<25357@unix.SRI.COM>
<6061@lectroid.sw.stratus.com>
<6138@lectroid.sw.stratus.com>
<751@synopsys.COM>
<9711@sail.LABS.TEK.COM>
<499@tymix.Tymnet.COM>
<17976@burdvax.PRC.Unisys.COM>
<3669@happym.WA.COM>
<3681@happym.WA.COM>
<14051@pasteur.Berkeley.EDU>
<83653@bu.edu>
<78537@eerie.acsu.Buffalo.EDU>
<1991Jun11.005001.26940@nntp-server.caltech.edu>
<1991Jun13.193937.27939@nntp-server.caltech.edu>
<1991Jun13.200202.28462@nntp-server.caltech.edu>
<1991Jun13.201929.28836@nntp-server.caltech.edu>
<1991Jun14.014158.8575@nntp-server.caltech.edu>
<1991Jun14.015823.9102@nntp-server.caltech.edu>
<1991Jun14.020143.9210@nntp-server.caltech.edu>
<4cJaw1m00WAxI=sGp1@andrew.cmu.edu>
<13346@pt.cs.cmu.edu>
<13382@pt.cs.cmu.edu>
<13409@pt.cs.cmu.edu>
<13458@pt.cs.cmu.edu>
<26823@as0c.sei.cmu.edu>
<1991Jun11.162118.14490@slate.mines.colorado.edu>
<22369@duke.cs.duke.edu>
<22383@duke.cs.duke.edu>
<22385@duke.cs.duke.edu>
<22387@duke.cs.duke.edu>
<22388@duke.cs.duke.edu>
<22390@duke.cs.duke.edu>
<22393@duke.cs.duke.edu>
<3177@sun13.scri.fsu.edu>
<3199@sun13.scri.fsu.edu>
<3229@sun13.scri.fsu.edu>
<3232@sun13.scri.fsu.edu>
<1991Jun11.011412.12771@gmuvax2.gmu.edu>
<6985@husc6.harvard.edu>
<6989@husc6.harvard.edu>
<6990@husc6.harvard.edu>
<6994@husc6.harvard.edu>
<6995@husc6.harvard.edu>
<6998@husc6.harvard.edu>
<6999@husc6.harvard.edu>
<7003@husc6.harvard.edu>
<18264@venera.isi.edu>
<8660@jhunix.HCF.JHU.EDU>
<8664@jhunix.HCF.JHU.EDU>
<8665@jhunix.HCF.JHU.EDU>
<1991Jun15.014854.21061@pencil.cs.missouri.edu>
<1991Jun15.014900.21109@pencil.cs.missouri.edu>
<1991Jun12.211942.26169@athena.mit.edu>
<1991Jun11.023531.26871@ncsu.edu>
<1491@opus.NMSU.Edu>
<1991Jun12.051514.11031@casbah.acns.nwu.edu>
<1991Jun14.034811.24854@casbah.acns.nwu.edu>
<2033@anaxagoras.ils.nwu.edu>
<2061@anaxagoras.ils.nwu.edu>
<2063@anaxagoras.ils.nwu.edu>
<2064@anaxagoras.ils.nwu.edu>
<2074@anaxagoras.ils.nwu.edu>
<2087@anaxagoras.ils.nwu.edu>
<2094@anaxagoras.ils.nwu.edu>
<2095@anaxagoras.ils.nwu.edu>
<2120@anaxagoras.ils.nwu.edu>
<C116950D44001150@MCCLB0.MED.NYU.EDU>
<7146@vela.acs.oakland.edu>
<5D565394229F40607D@vms.cis.pitt.edu>
<61DBEF33E53FA1C4FF@vms.cis.pitt.edu>
<91160.142530AAA5@psuvm.psu.edu>
<1991Jun11.195758.9663@gn.ecn.purdue.edu>
<1991Jun12.133944.29379@noose.ecn.purdue.edu>
<2744@stsci.EDU>
<2748@stsci.EDU>
<2755@stsci.EDU>
<17143@helios.TAMU.EDU>
<9163@ucdavis.ucdavis.edu>
<1991Jun11.203639.5155@math.ucla.edu>
<15121@ucrmath.ucr.edu>
<15130@ucrmath.ucr.edu>
<15153@ucrmath.ucr.edu>
<15156@ucrmath.ucr.edu>
<15157@ucrmath.ucr.edu>
<15158@ucrmath.ucr.edu>
<15159@ucrmath.ucr.edu>
<15160@ucrmath.ucr.edu>
<15176@ucrmath.ucr.edu>
<15181@ucrmath.ucr.edu>
<15191@ucrmath.ucr.edu>
<15196@ucrmath.ucr.edu>
<15199@ucrmath.ucr.edu>
<15235@ucrmath.ucr.edu>
<15237@ucrmath.ucr.edu>
<15244@ucrmath.ucr.edu>
<15249@ucrmath.ucr.edu>
<15274@ucrmath.ucr.edu>
<15276@ucrmath.ucr.edu>
<15281@ucrmath.ucr.edu>
<15297@ucrmath.ucr.edu>
<15310@ucrmath.ucr.edu>
<15311@ucrmath.ucr.edu>
<15320@ucrmath.ucr.edu>
<15321@ucrmath.ucr.edu>
<kscott.676777795@locke.mmwb.ucsf.edu>
<22133@brahms.udel.edu>
<1991Jun10.190901.17468@ms.uky.edu>
<1991Jun13.223029.2389@umbc3.umbc.edu>
<44487@netnews.upenn.edu>
<1991Jun11.170604.19464@cse.uta.edu>
<1991Jun10.194454.14344@cs.utk.edu>
<1991Jun15.160851.2926@cs.utk.edu>
<1991Jun11.221300.18003@murdoch.acc.Virginia.EDU>
<1991Jun14.013236.22900@murdoch.acc.Virginia.EDU>
<1991Jun12.183419.26932@cs.wayne.edu>
<1991Jun10.221102.15030@serval.net.wsu.edu>
<1991Jun11.073502.2389@nntp.hut.fi>
<3968@loria.crin.fr>
<237@taloa.unice.fr>
<14182@dog.ee.lbl.gov>
<14224@dog.ee.lbl.gov>
<14320@dog.ee.lbl.gov>
<14324@dog.ee.lbl.gov>
<99605@lll-winken.LLNL.GOV>
<99606@lll-winken.LLNL.GOV>
<1991Jun10.183117.13044@eagle.lerc.nasa.gov>
<1991Jun14.180525.8777@eagle.lerc.nasa.gov>
<1991Jun9.173752.20367@nas.nasa.gov>
<1569@nih-csl.nih.gov>
<1574@nih-csl.nih.gov>
<1798@ariadne.csi.forth.GR>
<956@puck.mrcu>
<1991Jun13.084959.10437@ulrik.uio.no>
<1991Jun14.172417.11993@linus.mitre.org>
<1947@giaea.gi.oz>
<CB.91Jun13143317@tamarack12.timbuk>
<1746@csisles.Bristol.AC.UK>
<1991Jun10.090230.13059@lut.ac.uk>
<11241@nfs4.rl.ac.uk>
<10294@suns8.crosfield.co.uk>
<25372@well.sf.ca.us>
<25373@well.sf.ca.us>
<25419@well.sf.ca.us>
<25460@well.sf.ca.us>
<2485@aber-cs.UUCP>
<16257@adobe.UUCP>
<1738@ether.UUCP>
<15259@hacgate.UUCP>
<1991Jun10.235637.23134@lunatix.uucp>
<1991Jun11.172435.29503@lunatix.uucp>
<1991Jun12.031750.3258@lunatix.uucp>
<1991Jun15.182230.29182@lunatix.uucp>
<1127@stewart.UUCP>
<1133@stewart.UUCP>
<0613910320@works.UUCP>
No @ in Message ID:
<01918040601991.12823.01>
<12912.pancake.0112912>
<12912.pancake.0212912>
<12912.pancake.0312912>
<12912.pancake.0412912>
<12912.pancake.0512912>
<12912.pancake.0612912>
<12912.pancake.0712912>
<13394.pancake.0113394>
<13394.pancake.0213394>
<13394.pancake.0313394>
<13394.pancake.0413394>
<13394.pancake.0513394>
<13394.pancake.0613394>
<13394.pancake.0713394>
<13861.pancake.0113861>
<13861.pancake.0213861>
<13861.pancake.0313861>
<13861.pancake.0413861>
<13861.pancake.0513861>
<13861.pancake.0613861>
<15919040601991.12899.01>
<1991Jun11.033707.19057Bsol.UVic.CA>
<1991Jun6.199.21001>
<5288pancake5288>
<5389pancake5389>
<5719.pancake.015719>
<5719.pancake.025719>
<5719.pancake.035719>
<5719.pancake.045719>
<6014.pancake.016014>
<6014.pancake.026014>
<6014.pancake.036014>
<6014.pancake.046014>
<6014.pancake.056014>
<6113.mfsdkl.016113.Capt.Kirk>
<6374.pancake.016374>
<6374.pancake.026374>
<6374.pancake.036374>
<6374.pancake.046374>
<6374.pancake.056374>
<7099.pancake.017099>
<7099.pancake.027099>
<7099.pancake.037099>
<7099.pancake.047099>
<7099.pancake.057099>
<7450.pancake.017450>
<7450.pancake.027450>
<7450.pancake.037450>
<7450.pancake.047450>
<7450.pancake.057450>
<pancake>
No Subject or empty Subject:
<1991Jun13.160914.20134@cs.dal.ca>
<1991Jun14.191023.28480@mprgate.mpr.ca>
<1991Jun11.171541.11649@engage.pko.dec.com>
<dxvsop9@openlook.Unify.Com>
<1991Jun12.160037.15378@athena.mit.edu>
<1991Jun13.085836.14351@athena.mit.edu>
<1991Jun15.201733.15159@athena.mit.edu>
<1991Jun12.150840.17666@news.nd.edu>
<1991Jun12.023715.14238@rice.edu>
<1991Jun12.183337.25325@umbc3.umbc.edu>
<1991Jun14.190505.29814@umbc3.umbc.edu>
<1991Jun14.214438.16568@ariel.unm.edu>
<1991Jun13.171152.23386@jato.jpl.nasa.gov>
<1991Jun12.150223.15089@eagle.lerc.nasa.gov>
<1991Jun11.115954.14440@nas.nasa.gov>
<1991Jun12.210741.12595@linus.mitre.org>
<1991Jun14.190423.16003@linus.mitre.org>
No From: header:
<1991Jun12.012436.24977@amd.com>
<1991Jun12.012708.25550@amd.com>
<1991Jun14.075919.19846@amd.com>
<1991Jun14.080126.20320@amd.com>
<1991Jun11.112331.7396@crash.cts.com>
<1991Jun11.112334.7450@crash.cts.com>
<j7nsuk1@openlook.Unify.Com>
<s8psibn@openlook.Unify.Com>
<zdpserw@openlook.Unify.Com>
<1991Jun10.195236.27753@mthvax.cs.miami.edu>
<3yaL41w163w@lobster.hou.tx.us!n5abi>
<qBaa41w163w@lobster.hou.tx.us!n5abi>
<1991Jun11.023053.25741@bitnerd.uucp>
<1991Jun15.184015.1123@bitnerd.uucp>
<9106091853.AA04084@lemsys.UUCP>
<H5HF41w164w@octogard.UUCP>
No Date or unparsable Date:
<1991Jun14.084025@proton.mpr.ca> -- `Fri Jun 14 15:40:25 1991 GMT'
<1991Jun14.084353@proton.mpr.ca> -- `Fri Jun 14 15:43:53 1991 GMT'
<1991Jun14.013236.22900@murdoch.acc.Virginia.EDU> -- missing
<9106131338.aa17767@loper.cs.vu.nl> -- `Thu, 13 Jun 91 13:38:27 MET DST'
Date in future (when received):
<9106131611.AA07182@hp5.mcs.kent.edu> -- `6 Feb 06 06:28:15 GMT'
<229835589@p5.f36.n245.z2.fidonet.org> -- `30 Jun 91 09:00:19 GMT'
<9106120920.AA08552@fkrs1.phc.chalmers.se> -- `12 Jun 91 09:20:08 GMT'
<matt.0081@vrtwo.UUCP> -- `15 Jun 91 07:13:10 GMT'
--
Kenneth Herron kherron@ms.uky.edu
University of Kentucky +1 606 257 2975
Department of Mathematics "So this won't be a total loss, can you make
it so guys get to throw their mothers-in-law in?" "Sure, why not?"grr@cbmvax.commodore.com (George Robbins) (06/18/91)
In article <1991Jun16.144010.15240@ms.uky.edu> kherron@ms.uky.edu (Kenneth Herron) writes: > > Please note the large number of entries from goofy.Apple.COM, > cbmvax.commodore.com, nntp-server.caltech.edu, and ucrmath.ucr.edu; > all of these show up regularly in these dropped-article logs. I've > sent mail to these sites with no result. This is really f**king useful. Without access to the contents of the articles as you received them, there is nothing I can do to help you. Looking at the commodore.com articles cited as they sit in the news spool here, there is nothing obviously wrong with the header lines, not even any of those DIY header lines that people like to add. I get mail addressed to usenet, postmaster and root, the only message I've received from you was something about k12 via rutgers. Please, keep in mind that chances are that some intermediate site or bogus gateways is mashing the articles or that *your* news software is being fascist about some more or less reasonable header. It may be something that the orginator has no control over or is relatively local to the recipient. Either post/forward samples of the defective artices, or modify your software to show what it is that it's complaining about. > Dropped Articles, week ending Sun Jun 16 07:44:37 EDT 1991 > > Header contains non-header line: ... > <22280@cbmvax.commodore.com> > <22325@cbmvax.commodore.com> > <22326@cbmvax.commodore.com> > <22421@cbmvax.commodore.com> > <22423@cbmvax.commodore.com> > <22465@cbmvax.commodore.com> ... B-news has more than a few cryptic messages too, but I've improved my version enough to find out just what it's actually bitching about. -- George Robbins - now working for, uucp: {uunet|pyramid|rutgers}!cbmvax!grr but no way officially representing: domain: grr@cbmvax.commodore.com Commodore, Engineering Department phone: 215-431-9349 (only by moonlite)
rickert@mp.cs.niu.edu (Neil Rickert) (06/18/91)
In article <22527@cbmvax.commodore.com> grr@cbmvax.commodore.com (George Robbins) writes: > >This is really f**king useful. Without access to the contents of the >articles as you received them, there is nothing I can do to help you. Wonderful. We have had eons of ranting by someone complaining that he was not notified articles were droppped. Now it looks as if we must suffer complaints that someone was notified. -- =*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*= Neil W. Rickert, Computer Science <rickert@cs.niu.edu> Northern Illinois Univ. DeKalb, IL 60115 +1-815-753-6940
scs@iti.org (Steve Simmons) (06/18/91)
rickert@mp.cs.niu.edu (Neil Rickert) writes: >In article <22527@cbmvax.commodore.com> grr@cbmvax.commodore.com (George Robbins) writes: >> >>This is really f**king useful. Without access to the contents of the >>articles as you received them, there is nothing I can do to help you. > Wonderful. We have had eons of ranting by someone complaining that he was >not notified articles were droppped. Now it looks as if we must suffer >complaints that someone was notified. George overreacted there, but he does have a point -- without the article to examine *as it arrived at the rejecting site*, it can be quite difficult to determine what is going on. Consider this another vote for placing dead articles in a special junk-like place. This at least gives us a fighting chance to see what's up. -- "If we don't provide support to our users someone is bound to confuse us with Microsoft." -- Charles "Chip" Yamasaki
henry@zoo.toronto.edu (Henry Spencer) (06/18/91)
In article <scs.677261631@wotan.iti.org> scs@iti.org (Steve Simmons) writes: >George overreacted there, but he does have a point -- without the >article to examine *as it arrived at the rejecting site*, it can be >quite difficult to determine what is going on. Consider this another >vote for placing dead articles in a special junk-like place... This is planned, although the details are tricky. -- "We're thinking about upgrading from | Henry Spencer @ U of Toronto Zoology SunOS 4.1.1 to SunOS 3.5." | henry@zoo.toronto.edu utzoo!henry
rickert@mp.cs.niu.edu (Neil Rickert) (06/19/91)
In article <22527@cbmvax.commodore.com> grr@cbmvax.commodore.com (George Robbins) writes: >In article <1991Jun16.144010.15240@ms.uky.edu> kherron@ms.uky.edu (Kenneth Herron) writes: >> >> Please note the large number of entries from goofy.Apple.COM, >> cbmvax.commodore.com, nntp-server.caltech.edu, and ucrmath.ucr.edu; > >This is really f**king useful. Without access to the contents of the >articles as you received them, there is nothing I can do to help you. Attached are three article header rejected recently at our site. The first is from cbmvax.commodore.com. Note that several headers do not have a blank after the ':'. (They don't have anything after the ':'). In the second article, the author apparently tried hard to have a valid RFC-822 Message-ID. Perhaps he tried a little too hard. The third article too was rejected due to a missing '@' in the Message-ID. I can't tell what software was used to generate these articles. However the newsgroups suggest that an Amiga may have been implicated in two of them. Path: fnnews!lll-winken!elroy.jpl.nasa.gov!swrinde!cs.utexas.edu!rutgers!cbmvax!mks From: mks@cbmvax.commodore.com (Michael Sinz) Newsgroups: comp.sys.amiga.hardware Subject: Re: 4 meg ZIPS=3.5 megs installed? Message-ID: <22495@cbmvax.commodore.com> Date: 17 Jun 91 13:14:05 GMT References: <8476@oasys.dt.navy.mil> Reply-To: mks@cbmvax.commodore.com (Michael Sinz) Organization: Commodore, West Chester, PA Lines: 28 Summary: Expires: Sender: Followup-To: Distribution: Keywords: Path: fnnews!lll-winken!elroy.jpl.nasa.gov!swrinde!cs.utexas.edu!uwm.edu!uwvax!ub.d.umn.edu!cs.umn.edu!uc!noc.MR.NET!gacvx2.gac.edu!hhdist From: Schwarzlmueller@tu-harburg.dbp.de (Dan Schwarzlmueller) Newsgroups: comp.sys.handhelds Subject: Unsubscribe Message-ID: <RFC-822:> Date: 17 Jun 91 12:53:00 GMT Lines: 3 Return-path: <Schwarzlmueller@tu-harburg.dbp.de> To: hhdist@gacvx2.gac.edu Path: fnnews!lll-winken!elroy.jpl.nasa.gov!decwrl!ucbvax!tardis.cs.ed.ac.uk!dh From: dh@tardis.cs.ed.ac.uk Newsgroups: comp.sys.atari.st Subject: Double click software Message-ID: <sent.Tue.Jun.18.18:18:33.GMT.1991.via.CS.TARDIS> Date: 18 Jun 91 18:18:33 GMT Sender: daemon@ucbvax.BERKELEY.EDU Lines: 13 -- =*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*= Neil W. Rickert, Computer Science <rickert@cs.niu.edu> Northern Illinois Univ. DeKalb, IL 60115 +1-815-753-6940
henry@zoo.toronto.edu (Henry Spencer) (06/26/91)
In article <1991Jun26.024210.9578@ccu.umanitoba.ca> mills@ccu.umanitoba.ca (Gary Mills) writes: >>They do. We've done a lot of things for standards conformance that we >>don't particularly like, actually. > >Whatever happened to: ``be liberal in what you accept ...''? I don't want >to stir the fire, but would it be sufficent if Cnews only _generated_ >conformant articles? ... Unfortunately, no. We did more or less that for quite a while. It caused grief for a lot of people, because nonconforming articles we passed along wreaked havoc with other (arguably poorly written) software. It is important to remember that the Internet robustness principle reads, precisely (from section 1.2.2 of RFC1122): Be liberal in what you accept, and conservative in what you send. Not "generate". "Send". When you relay an article, you are sending it. The site next door sees little difference between articles you originate and articles you pass on. 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. -- "We're thinking about upgrading from | Henry Spencer @ U of Toronto Zoology SunOS 4.1.1 to SunOS 3.5." | henry@zoo.toronto.edu utzoo!henry
kyle@uunet.uu.net (Kyle Jones) (06/27/91)
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 ... :-)
henry@zoo.toronto.edu (Henry Spencer) (06/27/91)
In article <1991Jun26.220203.17522@uunet.uu.net> kyle@uunet.uu.net (Kyle Jones) writes: >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 ... > >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... This is a curious definition of robustness, and one that is not supported by existing practice. If you read RFC1122, for example, you will find a number of cases where it is not merely permitted but *demanded* that you silently discard bad input, because experience has shown that any attempt to deal intelligently with those cases can easily make things much worse. That is precisely the problem here. There are things that are worse than lost articles, and while it may be desirable to improve the situation, it is *imperative* not to worsen it. >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. We decided long ago that relaynews will not attempt to repair articles. Nothing in this dreary and repetitive debate has changed our minds on that. We do, however, plan to do something about preserving the evidence for human investigation. >There's already a newsgroup for wayward articles: "junk"... Not quite right, unfortunately, since articles in "junk" still get sent on to other sites. (There are good reasons for this, by the way; the junk-handling policy took *A LOT* of thought and experimenting to get right.) Having another pseudogroup for discarded articles is an obvious possibility, although something has to be done to bound its size and be selective about what gets included. -- "We're thinking about upgrading from | Henry Spencer @ U of Toronto Zoology SunOS 4.1.1 to SunOS 3.5." | henry@zoo.toronto.edu utzoo!henry
mathew@mantis.co.uk (Giving C News a *HUG*) (06/28/91)
henry@zoo.toronto.edu (Henry Spencer) writes: > It is important to remember that the Internet robustness principle reads, > precisely (from section 1.2.2 of RFC1122): > > Be liberal in what you accept, and > conservative in what you send. > > Not "generate". "Send". When you relay an article, you are sending it. > The site next door sees little difference between articles you originate > and articles you pass on. 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. Right. But "rejecting nonconforming articles" is not being "liberal in what you accept". So C News does not obey the robustness principle of RFC1122 as written. You may or may not be right to disobey RFC1122, but I wish you'd just come clean and say that that is what you are doing, rather than quoting the RFC in your responses as if you were actually following it. mathew
chip@chinacat.unicom.com (Chip Rosenthal) (06/28/91)
In article <1991Jun26.230017.21259@zoo.toronto.edu> henry@zoo.toronto.edu (Henry Spencer) writes: >Having another pseudogroup for discarded articles is an obvious >possibility, although something has to be done to bound its size and be >selective about what gets included. Why? The stuff that is getting chucked was localized by B news. Note I'm not claiming that because B news did it, C news should. Instead, I'm saying that we've been able to afford the disk space for these messages in the past, and I think we still can. I'm very much in favor of the type of checking C news does, and I have zero qualms about non-conforming articles being chucked. I just wish the location they were chucked into wasn't the bit-bucket. -- Chip Rosenthal 512-482-8260 | Closed user interfaces for open systems? Unicom Systems Development | No, thank you. <chip@chinacat.Unicom.COM> | Boycott Lotus Development Corp.
rickert@mp.cs.niu.edu (Neil Rickert) (06/28/91)
In article <1991Jun27.221243.778@chinacat.unicom.com> chip@chinacat.unicom.com (Chip Rosenthal) writes: >In article <1991Jun26.230017.21259@zoo.toronto.edu> > henry@zoo.toronto.edu (Henry Spencer) writes: >>Having another pseudogroup for discarded articles is an obvious >>possibility, although something has to be done to bound its size and be >>selective about what gets included. > >Why? The stuff that is getting chucked was localized by B news. Note >I'm not claiming that because B news did it, C news should. Instead, >I'm saying that we've been able to afford the disk space for these >messages in the past, and I think we still can. I'm very much in I believe you missed an essential point. These articles are INVALID. Therefore they should not be entered into the history database since that would prevent a VALID version of the same article. You might therefore receive a copy from each of your feeds. In the past you never had more than one copy. -- =*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*= Neil W. Rickert, Computer Science <rickert@cs.niu.edu> Northern Illinois Univ. DeKalb, IL 60115 +1-815-753-6940
cudep@warwick.ac.uk (Ian Dickinson) (06/28/91)
In article <1991Jun26.220203.17522@uunet.uu.net> kyle@uunet.uu.net (Kyle Jones) writes: >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 ... :-) Hey I like this idea! I certainly want to see the texts of articles which are rejected. It would require some special casing though: junk is currently forwarded (by most sites) onto your feeds. This still needs to continue for junk.not-in-active, but not for junk.really-crappy-articles. And for articles which have frogged message-id, and therefore wouldn't be in history, some special expiry would have to take place. Further thoughts? -- \/ato /'\ /`\ Ian Dickinson TED KALDIS FOR PRESIDENT! /^^^\/^^^\ vato@warwick.ac.uk /TWIN/TEATS\ @c=GB@o=University of Warwick@ou=Computing Services@cn=Ian Dickinson / \
rickert@mp.cs.niu.edu (Neil Rickert) (06/28/91)
In article <Xio8412w164w@mantis.co.uk> mathew@mantis.co.uk (Giving C News a *HUG*) writes: > >Right. But "rejecting nonconforming articles" is not being "liberal in what >you accept". C news is very liberal in what it accepts. All the way to the bit bucket. -- =*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*= Neil W. Rickert, Computer Science <rickert@cs.niu.edu> Northern Illinois Univ. DeKalb, IL 60115 +1-815-753-6940
henry@zoo.toronto.edu (Henry Spencer) (06/28/91)
In article <Xio8412w164w@mantis.co.uk> mathew@mantis.co.uk (Giving C News a *HUG*) 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. > >Right. But "rejecting nonconforming articles" is not being "liberal in what >you accept". > >So C News does not obey the robustness principle of RFC1122 as written. Perfection is not possible. We are as liberal as we can be about accepting, given the constraint on sending, the need for speed, and the grave dangers of repair attempts. Rejecting sufficiently-nonconforming input does not contravene 1122; 1122 *demands* that in some cases. -- Lightweight protocols? TCP/IP *is* | Henry Spencer @ U of Toronto Zoology lightweight already; just look at OSI. | henry@zoo.toronto.edu utzoo!henry
ske@pkmab.se (Kristoffer Eriksson) (06/29/91)
In article <1991Jun26.155257.5692@zoo.toronto.edu> henry@zoo.toronto.edu (Henry Spencer) writes: > Be liberal in what you accept, and (1) > conservative in what you send. (2) >when you relay traffic you *must* make sure it meets the specs, either >by repairing deviations or by rejecting nonconforming articles. I don't see how unconditionally rejecting nonconforming articles meets (1) above. Care to explain? What provisions have you included to achieve (1)? I've received the impression that C-news concentrates solely on (2). Is there anything you can point to that shows that you have thought about (1), too? -- Kristoffer Eriksson, Peridot Konsult AB, Hagagatan 6, S-703 40 Oerebro, Sweden Phone: +46 19-13 03 60 ! e-mail: ske@pkmab.se Fax: +46 19-11 51 03 ! or ...!{uunet,mcsun}!sunic.sunet.se!kullmar!pkmab!ske
xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan) (06/29/91)
henry@zoo.toronto.edu (Henry Spencer) writes: > mathew@mantis.co.uk (Giving C News a *HUG*) writes: >> 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. >> Right. But "rejecting nonconforming articles" is >> not being "liberal in what you accept". >> So C News does not obey the robustness principle >> of RFC1122 as written. > Perfection is not possible. We are as liberal as > we can be about accepting, given the constraint on > sending, the need for speed, and the grave dangers > of repair attempts. Rejecting > sufficiently-nonconforming input does not > contravene 1122; 1122 *demands* that in some > cases. Ah, yes, you've said that several times, each time being careful to avoid mentioning _which_ cases. So the question of interest, of course, is: does RFC 1122 demand that you reject _those articles under controversy_, or is this merely another clever distraction tactic you're using to try still longer to weasel out of the apology and admission of guilt for yet another Cnews design blunder (YACnDB(tm)) that should have been forthcoming long ago? I know you can do it: you apologized for flooding the net with old news. I can wait. Patience is one of my long suits. It comes with the grey hair. Kent, the man from xanth. <xanthian@Zorch.SF-Bay.ORG> <xanthian@well.sf.ca.us> -- Convener, rec.arts.sf.* grand reorganization.