scoob@vlsi.polymtl.ca (Scoob) (06/16/91)
>>> In this thread we could read... > >>> Each user chooses which system and what software to use for posting to >>> Usenet. >> >>No. Each system administrator chooses the system and software. > >Rather, each system's administrator chooses the software, and each >user chooses administrator/system/software as a package. > >>So if you punish users, you will still end up punishing the innocent. > >Who said anything about punishment? I'm talking about the facts of >life, not trying to set policy. OK OK !!! how about trying to get things to work instead of finding the bad guy or the innocent... It's true that the poor user is innocent in all that. (But can one be innocent by ingorance?) Let's just make sure that people know or have an easy way to know weither their posting software works. An easy way is if your feed is a CNEWS site. You simply post a news to something like gnu.test and half a dozen of major sites in the US send you an automated mail saying that your news got to their place (ET VOILA !!!). Now, it would be a nice thing if instead of fighting over who gets to sit beside Henry at the party, we started identifying the "real BAD guys", i.e. the faulty posting softwares... How about the popular ones (sorry I only know about UNIX ones): rn, trn, nn, gnus, gnews, xrn ???? Do they post valid articles? Let's name the GOOD and nane + correct the bad. If the guy fills his header by hand, let him do it. But it's his responsability to write a "LEGAL" header... SO, WHO WILL TROW THE FIRST STONE AT THE BAD GUYS ??? -- --------------------------------------------------------------------------- Christian Marcotte scoob@vlsi.polymtl.ca Ecole Polytechnique de Montreal tel: (514) 340-4476 Laboratoire de recherche en VLSI ---------------------------------------------------------------------------
chip@tct.com (Chip Salzenberg) (06/19/91)
According to scoob@vlsi.polymtl.ca (Scoob): > How about the popular ones (sorry I only know about UNIX ones): > rn, trn, nn, gnus, gnews, xrn ???? Do they post valid articles? Neither rn nor trn guarantees that the article it generates is valid. However, a C News site will reject an invalid article after it is submitted by rn or trn. -- Chip Salzenberg at Teltronics/TCT <chip@tct.com>, <uunet!pdn!tct!chip> "You can call Usenet a democracy if you want to. You can call it a totalitarian dictatorship run by space aliens and the ghost of Elvis. It doesn't matter either way." -- Dave Mack
sob@tmc.edu (Stan Barber) (06/19/91)
In article <285E730F.4EC0@tct.com> chip@tct.com (Chip Salzenberg) writes: >Neither rn nor trn guarantees that the article it generates is valid. >However, a C News site will reject an invalid article after it is >submitted by rn or trn. The responsibility for validating the headers should be the software that posts the software into the system. If the headers are not valid, then the posting software should generate an error message immediately. The posting software for the systems I am familiar with is called inews. It is called by user posting front-ends such as Pnews and postnews. Unfortunately, some news transports spool posted articles for later processing by the posting software. In this case, the poster may not know the article had invalid header lines. An analog with mail is that the mail transfer agent validates the headers and returns the mail if headers are invalid. The user agent (which might just be a text editor) may or may not have any such checking. This is as it should be. As far as I know, news transports don't have the "mailer-daemon" feature of mail. I think there has been some discussion of this elsewhere. Hopefully, something this useful will find its way into today's news transports to help deal with this problem. -- Stan internet: sob@bcm.tmc.edu Director, Networking Olan uucp: rutgers!bcm!sob and Systems Support Barber Opinions expressed are only mine. Baylor College of Medicine
scoob@vlsi.polymtl.ca (Scoob) (06/19/91)
In article <6068@gazette.bcm.tmc.edu> sob@tmc.edu (Stan Barber) writes: >In article <285E730F.4EC0@tct.com> chip@tct.com (Chip Salzenberg) writes: >>Neither rn nor trn guarantees that the article it generates is valid. [...] > >The responsibility for validating the headers should be the software that >posts the software into the system. If the headers are not valid, then the >posting software should generate an error message immediately. The posting >software for the systems I am familiar with is called inews. It is called >by user posting front-ends such as Pnews and postnews. Well I guess we're home free now since Stan JUST happens to maintain BOTH rn (Pnews) and nntp(mini-inews) };-) > >Unfortunately, some news transports spool posted articles for later >processing by the posting software. In this case, the poster may not >know the article had invalid header lines. Pnews (which we use with trrn) does NOT spool posted articles for later processing. Mini-inews (a mini nntp front end to inews) simply drops bad articles on the floor silently (***Sounds familiar***) and terminates as if everything was OK. This behavior is VERY anoying. >An analog with mail is that the mail transfer agent validates the headers >and returns the mail if headers are invalid. The user agent (which might >just be a text editor) may or may not have any such checking. This is as >it should be. > >As far as I know, news transports don't have the "mailer-daemon" feature >of mail. I think there has been some discussion of this elsewhere. Hopefully, >something this useful will find its way into today's news transports to >help deal with this problem. Stan, my friend, YOU HAVE THE POWER to do this. (BUT you probably don't have the time :-<) The mail feedback solution IS possible in this case. We all understand that the mail feedback is NOT reasonnable in the case of the news sites flooding each other with bad article mails but here we can efficiently use this method. As mentionned in Stan's posting, the mail system does it succesfully **WHAT ARE WE WAITNIG FOR**. If I recall correctly from the mini-inews README file, the guy who wrote it was saying something like: "It's a very slim subset of inews but don't bother me for more features. It works like that and it stays like that". Well it was a bit anoying in the past but now that Cnews deciced NOT to be forgiving anymoure it would be nice to get a feed back from mini-inews on weither or not the article was posted correctly. If one tries to post a bobus news from a CNEWS site, it simply won't get to the local news spool. Hence a way to find out if your posting was valid (still not very friendly...). The poor guy at a BNEWS site can only find out by calling a friend at a CNEWS site and ask him to check for his posting (definitly NOT friendly). Stan, how hard would it be to build a mail feedback mechanisim for mini-inews? (Common errors include a typo in a newsgroup name). If a modificaiton to mini-inews is too much work or inews itself doesn't provide feedback (like ok it passed or NO it's rejected), maybe a Perl header checker called from Pnews or something along those lines. How much work is involved in checking for a header validity? BTW: Stan: Thanks a lot for the effort you put in supporting those software. In those days of flaming authors I think a little path on the back is in order. -- --------------------------------------------------------------------------- Christian Marcotte scoob@vlsi.polymtl.ca Ecole Polytechnique de Montreal tel: (514) 340-4476 Laboratoire de recherche en VLSI ---------------------------------------------------------------------------
henry@zoo.toronto.edu (Henry Spencer) (06/19/91)
In article <6068@gazette.bcm.tmc.edu> sob@tmc.edu (Stan Barber) writes: >Unfortunately, some news transports spool posted articles for later >processing by the posting software. In this case, the poster may not >know the article had invalid header lines. I'd be curious to know what transport systems do this. C News, as shipped, doesn't -- the posting validation is done by inews, which runs immediately. (We have talked about having the *validated* article spooled for later processing rather than processed immediately, although at the moment it is done immediately.) Unless we've overlooked something, an article which gets through inews should pass relaynews's checks. -- "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/20/91)
In article <1991Jun19.154645.11885@zoo.toronto.edu> henry@zoo.toronto.edu (Henry Spencer) writes: >In article <6068@gazette.bcm.tmc.edu> sob@tmc.edu (Stan Barber) writes: >>Unfortunately, some news transports spool posted articles for later >>processing by the posting software. In this case, the poster may not >>know the article had invalid header lines. > >I'd be curious to know what transport systems do this. C News, as shipped, One that comes to mind is the mini-inews supplied with NNTP. I hope the new version that Rich Salz announced will solve some of these problems. >doesn't -- the posting validation is done by inews, which runs immediately. >(We have talked about having the *validated* article spooled for later >processing rather than processed immediately, although at the moment it >is done immediately.) Unless we've overlooked something, an article which >gets through inews should pass relaynews's checks. Yes. What you have overlooked is the date checking. An article that passes inews has a syntactically valid date. But the date may not be within the time limits used by the local relaynews. Because of the way inews invokes relaynews, the actual date checking is done by relaynews at the next news site down the line, and this is where the article will be silently dropped with no feedback to the Author. This is particularly a problem with mail gatewayed into news, where wild dates (from unset PC clocks, for example) are common. Yesterday, for example, my Cnews rejected 16 articles (older than 30 days) received from a feed which is also running the latest Cnews. On occasion when I have checked, these articles had dates which were far too old for the feed, but sneaked by because of this loophole. -- =*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*= 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/20/91)
In article <1991Jun19.172544.32267@mp.cs.niu.edu> rickert@mp.cs.niu.edu (Neil Rickert) writes: >...the actual date checking is done by relaynews at the next news >site down the line, and this is where the article will be silently dropped >with no feedback to the Author... Unfortunately, there is absolutely and positively no way inews can check this, and it's not just a problem at the next site down the line. *Any* site could drop your article as too old. The definition of "too old" depends on expiry policy, since it is basically "anything too old to be in the history file". Somebody who is keeping very little history may well drop even relatively recent articles as "too old". It is impossible for inews to do a single check that will cover you against any possible "too old" criterion. This is why we really hoped that detection of recirculating stale news could be done via history, rather than by setting a date threshold. There is just no entirely satisfactory setting for that threshold. Alas, there is simply too much news to keep history for months, which turns out to be what's needed. Checking the date for completely wild values, on the other hand, might be feasible. However... >... This is particularly a problem with mail >gatewayed into news, where wild dates (from unset PC clocks, for example) >are common. As we have commented in the past, just piping mail into inews as a gateway is a mistake. Inews was not built for that. It's becoming clear that we need to address the mail->news gatewaying issue in some more systematic way, but it's not easy. -- "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/20/91)
In article <1991Jun19.182811.19812@zoo.toronto.edu> henry@zoo.toronto.edu (Henry Spencer) writes: >In article <1991Jun19.172544.32267@mp.cs.niu.edu> rickert@mp.cs.niu.edu (Neil Rickert) writes: >>...the actual date checking is done by relaynews at the next news >>site down the line, and this is where the article will be silently dropped >>with no feedback to the Author... > >Unfortunately, there is absolutely and positively no way inews can check >this, and it's not just a problem at the next site down the line. *Any* Why don't you discuss the issue, and not something else? If my site holds a month of history, and the next site only holds two weeks, that is just too bad. I agree with that. If my site holds one month of history, and a user here posts an article with a 1980 date on it, the local inews does not complain, the local relaynews does not complain. It is dropped down the line. The fact that it is dropped down the line is just too bad. But the fact that inews DID NOT COMPLAIN is just a design error, which ought to be fixed in your next release. Don't tell me that "Unfortunately, there is absolutely and positively no way inews can check this", because that is absolutely and positively not a believable position. -- =*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*= Neil W. Rickert, Computer Science <rickert@cs.niu.edu> Northern Illinois Univ. DeKalb, IL 60115 +1-815-753-6940
sob@tmc.edu (Stan Barber) (06/20/91)
In article <1991Jun19.172544.32267@mp.cs.niu.edu> rickert@mp.cs.niu.edu (Neil Rickert) writes: > One that comes to mind is the mini-inews supplied with NNTP. I hope the >new version that Rich Salz announced will solve some of these problems. Mini-inews is NOT a transport. It is just a feed into NNTP which in turn feeds it into the REAL inews in the news transport. THAT is where all these checks should occur. I am afraid that adding more smarts to mini-inews just clouds the real issue. -- Stan internet: sob@bcm.tmc.edu Director, Networking Olan uucp: rutgers!bcm!sob and Systems Support Barber Opinions expressed are only mine. Baylor College of Medicine
rickert@mp.cs.niu.edu (Neil Rickert) (06/20/91)
In article <6098@gazette.bcm.tmc.edu> sob@tmc.edu (Stan Barber) writes: >Mini-inews is NOT a transport. It is just a feed into NNTP which in turn >feeds it into the REAL inews in the news transport. THAT is where all these >checks should occur. But that is exactly the point. mini-inews does not do the error checking of the REAL inews, but if effectively isolates the poster from the REAL inews making good feedback difficult. It also does not support all of the options newsreaders use in a REAL inews, and it sometimes takes interminably long to complete when there is a human sitting impatiently waiting to proceed with the next order of business. Both of these facts encourage installation of buggy shell script front ends to inews which further contribute to the real problem. Perhaps you want mini-inews submitters to log into their news host occasionally and look in ~news/dead.article to see if their articles were dropped? Any well designed REAL inews which does report errors is going to decide that the report should go to ~news (or whatever uid nntpd runs as) on the news host. >I am afraid that adding more smarts to mini-inews just clouds the real issue. And what is the real issue? Is it that once mini-inews has convinced the news software that the article is submitted by news@news.host, the news software is now unable to discover where it should really complain? -- =*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*= Neil W. Rickert, Computer Science <rickert@cs.niu.edu> Northern Illinois Univ. DeKalb, IL 60115 +1-815-753-6940
sob@tmc.edu (Stan Barber) (06/20/91)
In article <1991Jun20.114358.4871@mp.cs.niu.edu> rickert@mp.cs.niu.edu (Neil Rickert) writes: >It also does not support all of the options newsreaders use in a REAL inews, >and it sometimes takes interminably long to complete when there is a human >sitting impatiently waiting to proceed with the next order of business. >Both of these facts encourage installation of buggy shell script front ends to>inews which further contribute to the real problem. Let's see if we can agree on the REAL problem. The REAL problem as I see it is that the inews in the news transport does not to an adequate job of checking headers and returning bad articles to the user. Now, we could add some smarts to mini-inews to move the detection closer to the user. How does this fix the REAL problem? What about software that DOES NOT USE mini-inews to post articles? I don't disagree with the idea of adding capabilities to mini-inews to support all the optional flags of inews. I am concerned that mini-inews and the real inews may disagree on header processing issues. Right now with CNEWS, header processing is a moving target. -- Stan internet: sob@bcm.tmc.edu Director, Networking Olan uucp: rutgers!bcm!sob and Systems Support Barber Opinions expressed are only mine. Baylor College of Medicine
scs@iti.org (Steve Simmons) (06/20/91)
rickert@mp.cs.niu.edu (Neil Rickert) writes: >In article <6098@gazette.bcm.tmc.edu> sob@tmc.edu (Stan Barber) writes: >>Mini-inews is NOT a transport. It is just a feed into NNTP which in turn >>feeds it into the REAL inews in the news transport. THAT is where all these >>checks should occur. > But that is exactly the point. mini-inews does not do the error checking >of the REAL inews, but if effectively isolates the poster from the REAL >inews making good feedback difficult. Good point. What we really need is a "standard library" that will do syntax checking on article headers. Make it real portable, PD, and hand it out to the world. Henry/Geoff, is this section of C-news "libraryizable"? (gads, what a horrid neologism) Once we have this, adding said function to mini-inews, waffle, etc, etc, becomes relatively trivial. It doesn't solve the problem of installation that don't upgrade, but it's a solid step to make the situation better in the future. -- "If we don't provide support to our users someone is bound to confuse us with Microsoft." -- Charles "Chip" Yamasaki
rickert@mp.cs.niu.edu (Neil Rickert) (06/20/91)
In article <6102@gazette.bcm.tmc.edu> sob@tmc.edu (Stan Barber) writes: >Let's see if we can agree on the REAL problem. >The REAL problem as I see it is that the inews in the news transport does >not to an adequate job of checking headers and returning bad articles to the >user. The "user" is identified in three places. The "Path:" header, the "From:" header and the "Sender:" header. With mini-inews, two of these are WRONG. Specifically, the "Path:" header generated by mini-inews does not have the host name where the article was created, so the "Path:" finishes up incorrectly giving an address on the nntp server instead of the client. Because of the way mini-inews submits the article through inews, the "From:" header does not correspond to the actual submitter which is typically news@news.server. Therefore a properly designed inews is obliged to put the authentic sender address in the "Sender:" header. The RFCs are pretty clear that in the presence of both a "From:" and a "Sender:", error reports are to go to "Sender:". The implication is clear to all except those who refuse to admit it. The way mini-inews works is WRONG. The article has to be injected on the server at some point after handling the "Sender:" header, so that an invalid "Sender:" is not generated. However it has to be injected before the "Newsgroups:" header processing so that moderated groups will be managed correctly. Just pumping the article into inews on the server is the wrong approach. It needs a special interface. Either there needs to be an option on the server inews to skip the addition of the "Sender:", or there needs to be a special front end. In the meantime mini-inews must correctly handle the "Path:" and "Sender:" headers itself. Since mini-inews isolates the submitter from the real submitting software, good design would dictate that it should also validate the syntax of the other headers. It probably need not create a "Message-ID:" or "Date:". They are better done on the server, where there is a stronger incentive to keep the clock approximately accurate. However if these headers already exist, they should be checked for correct syntax so that the news submitter can be informed. -- =*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*= Neil W. Rickert, Computer Science <rickert@cs.niu.edu> Northern Illinois Univ. DeKalb, IL 60115 +1-815-753-6940
sob@tmc.edu (Stan Barber) (06/21/91)
In article <1991Jun20.145913.28280@mp.cs.niu.edu> rickert@mp.cs.niu.edu (Neil Rickert) writes: > The "user" is identified in three places. The "Path:" header, the >"From:" header and the "Sender:" header. With mini-inews, two of these >are WRONG. Specifically, the "Path:" header generated by mini-inews >does not have the host name where the article was created, so the "Path:" >finishes up incorrectly giving an address on the nntp server instead of >the client. I reject the idea that the PATH: header does anything more that help news determine if an article has been seen by a particular machine. I will save your bug report for consideration in NNTP 1.6 with respect to "From:" and "Sender:" You might consider sending bug reports to the "nntp@tmc.edu" since that is what it is there for. -- Stan internet: sob@bcm.tmc.edu Director, Networking Olan uucp: rutgers!bcm!sob and Systems Support Barber Opinions expressed are only mine. Baylor College of Medicine
ronald@robobar.co.uk (Ronald S H Khoo) (06/21/91)
In article <6102@gazette.bcm.tmc.edu> sob@tmc.edu (Stan Barber) writes: > The REAL problem as I see it is that the inews in the news transport does > not to an adequate job of checking headers and returning bad articles to the > user. Seems reasonable to me. > Now, we could add some smarts to mini-inews to move the detection closer to > the user. How does this fix the REAL problem? It doesn't? How surprising :-) > I am concerned that mini-inews > and the real inews may disagree on header processing issues. Right now with > CNEWS, header processing is a moving target. That doesn't sound right to me. The target is, of course, 822, 1036 and HR. Yeah, that changes from time to time, but not that often ;-) Now, given that the problems of both a) how to gateway mail->news and b) making sure the local mailer works need to be solved anyway, why not solve those *properly*, then use the resulting technology and _always post via the mailer_ ? Sure, there's some issues to resolve, like the status of headers like Newsgroups: etc. But at least the mechanisms like return-to-sender-on-error, etc are already there to use. And just run an SMTP server on every NNTP host, configuring the local active file into its mail alias table? Seems like the "cleanest" solution to me. At the very least, it means that you only have to maintain news verification software on the servers -- a real issue if you really think that the target moves. -- Ronald Khoo <ronald@robobar.co.uk> +44 81 991 1142 (O) +44 71 229 7741 (H)
clewis@ferret.ocunix.on.ca (Chris Lewis) (06/21/91)
In article <1991Jun19.154645.11885@zoo.toronto.edu> henry@zoo.toronto.edu (Henry Spencer) writes: >In article <6068@gazette.bcm.tmc.edu> sob@tmc.edu (Stan Barber) writes: >>Unfortunately, some news transports spool posted articles for later >>processing by the posting software. In this case, the poster may not >>know the article had invalid header lines. >I'd be curious to know what transport systems do this. Bnews does. If you invoke inews whilst expire is running, or have turned on SPOOLINEWS (I think it's called that), the article will be left in $SPOOLDIR/.rnews until a subsequent "rnews -U" or during the rnews that expire fires up. However, header checking is done before the article is spooled, tho, there's obviously classes of errors that the later rnews run could find that cause the article to be rejected. -- Chris Lewis, Phone: (613) 832-0541, Domain: clewis@ferret.ocunix.on.ca UUCP: ...!cunews!latour!ecicrl!clewis; Ferret Mailing List: ferret-request@eci386; Psroff (not Adobe Transcript) enquiries: psroff-request@eci386 or Canada 416-832-0541. Psroff 3.0 in c.s.u soon!
rickert@mp.cs.niu.edu (Neil Rickert) (06/21/91)
In article <6106@gazette.bcm.tmc.edu> sob@tmc.edu (Stan Barber) writes: >I reject the idea that the PATH: header does anything more that help >news determine if an article has been seen by a particular machine. Stan, I hope you will reconsider this. In theory you are right. But in practice there are many systems which do reply to the 'Path:' header. Even the news2mail program in the newsgate package posted a few months ago uses the 'Path:' to generate the email 'From:', although I admit to not understanding why they made that choice. It is easy to dismiss this by saying that somebody else's misconfigured system is their problem, not yours. But please give a little thought to the implications. Suppose I run a site reading news via nntp, and use your mini-inews which generates a bad address on the 'Path:'. Here are some of the implications. 1. A user as a site which replies to the 'Path:' cannot reply to a poster on my system. 2. The poster on my system will get less replies. 3. My news server host will have to bounce mail addressed to 'Path:'. 4. Some poor user on the news server host, whose login id happens to be the same as that of the post on my site, may finish up being the unintended victim of a flame fest intended for the poster at my site. Now I am quite willing to dismiss 1 and 2. But I will not dismiss 3 and 4 as unimportant. I have an obligation to not cause unnecessary problems for my news server. Saying that the fault is at the site using 'Path:' for replies does not answer the fact that I can avoid it with a different path on postings generated here. -- =*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*= Neil W. Rickert, Computer Science <rickert@cs.niu.edu> Northern Illinois Univ. DeKalb, IL 60115 +1-815-753-6940
chip@tct.com (Chip Salzenberg) (06/22/91)
According to rickert@mp.cs.niu.edu (Neil Rickert): >In practice there are many systems which do reply to the 'Path:' >header. Even the news2mail program in the newsgate package posted a >few months ago uses the 'Path:' to generate the email 'From:' ... Then that program is broken. The Path: is strictly, 100% pure Usenet transport information. It has zero relevance to E-Mail, except by coincidence. To use it for any purpose relevant to E-Mail is a mistake. This fact is obvious when you consider E-Mail to news gateways. If the E-Mail return path were instituted as the Path: of the article, then the article would not be forwarded to those sites mentioned in that return path. The GNU newsgroups had this problem until recently, but now they work correctly. > 4. Some poor user on the news server host, whose login id happens to be > the same as that of the post on my site, may finish up being the > unintended victim of a flame fest intended for the poster at my site. In that case, the "user" part of the Path: should be "unrepliable" or some other such string, not a real user name. -- Chip Salzenberg at Teltronics/TCT <chip@tct.com>, <uunet!pdn!tct!chip> "You can call Usenet a democracy if you want to. You can call it a totalitarian dictatorship run by space aliens and the ghost of Elvis. It doesn't matter either way." -- Dave Mack
rickert@mp.cs.niu.edu (Neil Rickert) (06/23/91)
In article <28636AD9.5E00@tct.com> chip@tct.com (Chip Salzenberg) writes: >According to rickert@mp.cs.niu.edu (Neil Rickert): >>In practice there are many systems which do reply to the 'Path:' >> >> 4. Some poor user on the news server host, whose login id happens to be >> the same as that of the post on my site, may finish up being the >> unintended victim of a flame fest intended for the poster at my site. > >In that case, the "user" part of the Path: should be "unrepliable" or >some other such string, not a real user name. I have no objections to that. My only point was that mini-inews current practice in generating Path: has undesirable side effects on the news server. -- =*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*= Neil W. Rickert, Computer Science <rickert@cs.niu.edu> Northern Illinois Univ. DeKalb, IL 60115 +1-815-753-6940
rsalz@bbn.com (Rich Salz) (06/23/91)
In <6098@gazette.bcm.tmc.edu> sob@tmc.edu (Stan Barber) writes: >Mini-inews is NOT a transport. It is just a feed into NNTP which in turn >feeds it into the REAL inews in the news transport. THAT is where all these >checks should occur. I disagree. I think that a program that took a user's article, verified all the headers, processed the .signature, and then fed it to the NNTP port of the campus server would be a very useful thing indeed. I wrote one, it's in beta-test right now. For historical compatibility, I call the program inews. If my inews accepts your article, you can be very sure that the only reason the server would reject it is because of a transient failure like disk full. It's a very simple program to write: litchi% wc -l frontends/inews.c 937 frontends/inews.c -- Please send comp.sources.unix-related mail to rsalz@uunet.uu.net. Use a domain-based address or give alternate paths, or you may lose out.
henry@zoo.toronto.edu (Henry Spencer) (06/25/91)
In article <1991Jun19.192501.23864@mp.cs.niu.edu> rickert@mp.cs.niu.edu (Neil Rickert) writes: >>>...the actual date checking is done by relaynews at the next news >>>site down the line... >> >>Unfortunately, there is absolutely and positively no way inews can check >>this, and it's not just a problem at the next site down the line... > > Why don't you discuss the issue, and not something else? I was discussing this issue, albeit perhaps in a slightly subtle way. > If my site holds a month of history, and the next site only holds two >weeks, that is just too bad. I agree with that. > > If my site holds one month of history, and a user here posts an article >with a 1980 date on it, the local inews does not complain, the local >relaynews does not complain. It is dropped down the line. The fact that >it is dropped down the line is just too bad. But the fact that inews DID >NOT COMPLAIN is just a design error... What should it complain about? The fact that the date is outside the legal range on *your* site? What does that signify? It certainly doesn't signify that the article is going to get dropped further down the line. Nor does the absence of such an out-of-range condition signify that the article won't be dropped at the very next site. What, exactly, should be the criterion for complaint? What, exactly, are you promising the user if that complaint does not appear? > Don't tell me that "Unfortunately, there is absolutely and positively no >way inews can check this", because that is absolutely and positively not >a believable position. I assumed you wanted it to check whether the date would permit downstream propagation. There is absolutely and positively no way it can do that. Really. The information just isn't available. As I think I mentioned, checking for a utterly nonsensical date is not out of the question, although even there it gets tricky to decide what qualifies. But that's a different problem from making a check that will let you promise the user something. -- "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
henry@zoo.toronto.edu (Henry Spencer) (06/25/91)
In article <scs.677425398@wotan.iti.org> scs@iti.org (Steve Simmons) writes: >Good point. What we really need is a "standard library" that will do >syntax checking on article headers. Make it real portable, PD, and >hand it out to the world. Henry/Geoff, is this section of C-news >"libraryizable"? (gads, what a horrid neologism) Probably not in the sense you're really after. The header syntax is pretty trivial; what's wanted is a *semantic* checker, so to speak, and that's much harder to break out. Header processing is a "hot spot" in timing, so much attention has been paid to optimizing it. -- "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
ben@servalan.uucp (Ben Mesander) (06/25/91)
In article <285E730F.4EC0@tct.com> chip@tct.com (Chip Salzenberg) writes: >According to scoob@vlsi.polymtl.ca (Scoob): >> How about the popular ones (sorry I only know about UNIX ones): >> rn, trn, nn, gnus, gnews, xrn ???? Do they post valid articles? > >Neither rn nor trn guarantees that the article it generates is valid. >However, a C News site will reject an invalid article after it is >submitted by rn or trn. Gee, I'll be sure and patch my CP/M news posting software that I have no source to so that it generates correct dates. Shoot, the darn system doesn't even have a *clock*! Should be an interesting patch. Any of you net.gods want to do it for me? >Chip Salzenberg at Teltronics/TCT <chip@tct.com>, <uunet!pdn!tct!chip> > "You can call Usenet a democracy if you want to. You can call it a > totalitarian dictatorship run by space aliens and the ghost of Elvis. > It doesn't matter either way." -- Dave Mack C news must die. Elvis runs usenet. Mail to elvis@epmooch.UUCP