anwyn@hrnowl.lonestar.org (System Operator) (01/10/91)
Consider the following interesting news administration problem. We have three nodes call them C, WAF, and UF. C is an unix site running cnews. WAF is an MS-DOS site running WAFFLE 1.63. And UF is an MS-DOS site running UFGATE. C is connected to WAF which is connected to UF. It is not feasible to connect C directly to UF because C has a telebit modem and UF does not and the administrator of C objects to the long connect times that would result from a 2400 baud connection. Now the node UF wishes to receive certain newsgroups from C. The node WAF is willing to act as an intermediary, however node WAF does not want to have the newsgroups on his board and sees no reason why they should be decompressed or kept any longer than is necessary for transmission to UF. How may this be accomplished? I am not a news expert, but I believe from reading _Managing UUCP and Usenet_ by Tim O'Reilly and Grace Todino that the node C can get his news to node UF by adding the following line to his "sys" file: uf:newsgroups/all:f:uux - -z -r waf!uux - uf!rmail (Waffle uux does not have a "-z" or "-r" switch.) (In the above "newsgroups" represents a comma separated list of the newsgroups that node UF wants.) The compressed news is sent to uux on node WAF that in turn sends it to rmail on node UF. Of course the static file for the WAFFLE node will have to have the line: uuxqt : rmail rnews uux to allow the uux command to be executed on node WAF. Is this correct cnews experts? Have I made an error? I have read the UFGATE documentation, but am unable to solve the converse problem of getting news generated on UF back to node C. As I understand it the ".C" ".DAT" and ".XQT" files for news will be generated by a program called newsout. They will then be sent by a program called uuslave to the remote system. But I can not find any command in the .CTL file or switch on any of the programs that will alter the command to transmit the compressed news to the remote system. Have I missed anything UFGATE experts? Has anyone encountered such a problem before? anwyn@hrnowl.lonestar.org
henry@zoo.toronto.edu (Henry Spencer) (01/12/91)
In article <RT8iV1w163w@hrnowl.lonestar.org> anwyn@hrnowl.lonestar.org (System Operator) writes: >uf:newsgroups/all:f:uux - -z -r waf!uux - uf!rmail > >... Is this correct >cnews experts? Have I made an error? 'Fraid so, but not a massive one. The "f" flag signifies that the next field is a filename; you can't combine it with a command. What you'll have to do is tell the batcher to use a new "via" command, and put the uux incantation in there. That aside, this sounds plausible, assuming that the "rmail" on "waf" is prepared to cope with compressed news as input without an address. (I'd have expected to either use "rnews" or give rmail an argument like "news", but I have no experience with waffle...) -- If the Space Shuttle was the answer, | Henry Spencer at U of Toronto Zoology what was the question? | henry@zoo.toronto.edu utzoo!henry
mju@mudos.ann-arbor.mi.us (Marc Unangst) (01/13/91)
anwyn@hrnowl.lonestar.org (System Operator) writes: > baud connection. Now the node UF wishes to receive certain newsgroups > from C. The node WAF is willing to act as an intermediary, however > node WAF does not want to have the newsgroups on his board and sees Node WAF doesn't have to have newsgroups on his board, but there's no way to forward the compressed news batches without decompressing them, unbatching them, and then rebatching them and recompressing them. The reasons for this are simple: 1. Each site an article passes through must add its node name to the Path: header line. Obviously, you can't do this to a compressed news batch. 2. The intermediate site would have no way of knowing what was inside the news batch until it unpacked it, and thus would not know which messages to forward on to the next host. (Yes, in this case you can assume that everything can be forwarded, but in most cases, it's not that easy.) It's possible for the WAF node to use a time-based expire(8) program, such as the Perl version written by Roy Silvernail. In this case, you would set the expire time to one day, and then you would only need a minimal amount of space around for the news articles. > the remote system. But I can not find any command in the .CTL file or > switch on any of the programs that will alter the command to transmit > the compressed news to the remote system. Have I missed anything UFGATE > experts? Has anyone encountered such a problem before? No, you haven't missed anything. You just can't do this with UFGATE. Perhaps it's poor design; I'm more likely to believe it's just that you're trying to do something that the Usenet software was never intended to do. No doubt, it's probably possible to kludge something up. But I think it would be easier to just use the software the way God intended it to be used. -- Marc Unangst | mju@mudos.ann-arbor.mi.us | "Bus error: passengers dumped" ...!umich!leebai!mudos!mju |
rees@pisa.ifs.umich.edu (Jim Rees) (01/15/91)
In article <1iuPV1w164w@mudos.ann-arbor.mi.us>, mju@mudos.ann-arbor.mi.us (Marc Unangst) writes:
1. Each site an article passes through must add its node name
to the Path: header line. Obviously, you can't do this to a
compressed news batch.
The path is just a clue as to how the article got here. If it's wrong, it
doesn't break anything that wasn't already broken (like software that tries
to reply along the path).philip@vogon.cetia.fr (Philip Peake) (01/16/91)
In article <4f340ead.1bc5b@pisa.ifs.umich.edu>, rees@pisa.ifs.umich.edu (Jim Rees) writes: |> In article <1iuPV1w164w@mudos.ann-arbor.mi.us>, mju@mudos.ann-arbor.mi.us (Marc Unangst) writes: |> |> 1. Each site an article passes through must add its node name |> to the Path: header line. Obviously, you can't do this to a |> compressed news batch. |> |> The path is just a clue as to how the article got here. If it's wrong, it |> doesn't break anything that wasn't already broken (like software that tries |> to reply along the path). It does break things. If you have any connections to any of the sites in the list, and you have at least one, or you wouldn't have then news, would you :-) then a copy of the article will be sent to all sites NOT mentioned in the list - if they have the same policy of ignoring (or zapping, or whatever) the list, then they will send a copy back to you - and you will ......... Philip
mju@mudos.ann-arbor.mi.us (Marc Unangst) (01/19/91)
rees@pisa.ifs.umich.edu (Jim Rees) writes: > The path is just a clue as to how the article got here. If it's wrong, it > doesn't break anything that wasn't already broken (like software that tries > to reply along the path). No, the Path: header is also used to prevent propagation of duplicate messages. Although the Message-ID: header is the primary method of rejecting duplicates, Usenet software is supposed to examine the Path: header for the name of the site it's about to send the article to; if it's there, that indicates that the article has already been there and need not be sent again. Also, like it or not, there *is* software out there that uses the Path: mudos!header to send the reply. Yes, they're using broken software -- but are YOU going to be the one to explain to your users why their inbound mail isn't getting to them? -- Marc Unangst | mju@mudos.ann-arbor.mi.us | "Bus error: passengers dumped" ...!umich!leebai!mudos!m
cks@hawkwind.utcs.toronto.edu (Chris Siebenmann) (01/23/91)
mju@mudos.ann-arbor.mi.us (Marc Unangst) writes: ... | Also, like it or not, there *is* software out there that uses the | Path: mudos!header to send the reply. Yes, they're using broken software -- | but are YOU going to be the one to explain to your users why their | inbound mail isn't getting to them? Mail replies done using Path: are already broken; they occasionally get through only out of luck and a fair bit of work by postmasters between hither and yon. The best thing to do is to put them out of their misery as fast as possible, so people will stop being fooled. People who disbelieve me should feel to ask any postmaster of a major news machine or gateway machine. I'm the postmaster of our local BITNET/NETNORTH<->Internet gateway, and we've recently had a spate of messages bouncing off us because the huge To: address derived from a Path: line was mangled by a previous mailer, probably because it overflowed a fixed-sized buffer somewhere; this is merely one example of what can happen to such messages. -- "Anyone forging articles should be writing news software instead, if you get the headers right you're ahead of some implementations. Try writing a gateway, that'll test your skills." - Ed Vielmetti cks@hawkwind.utcs.toronto.edu ...!{utgpu,utzoo,watmath}!utgpu!cks
wcf@psuecl.bitnet (Bill Fenner) (01/31/91)
In article <kVoZV2w164w@mudos.ann-arbor.mi.us>, mju@mudos.ann-arbor.mi.us (Marc Unangst) writes: > Also, like it or not, there *is* software out there that uses the > Path: mudos!header to send the reply. This is neat... took me a while to figure out why Marc said "mudos!header". Then I realized, he didn't, mudos did. The word Path: was right at the beginning of the line, so mudos said "oh, gee, looks like a Path: header", and prepended itself. Someone needs to fix something . . . -- Bill Fenner wcf@ecl.psu.edu wcf@psuecl.bitnet psuvax1!hogbbs!wcfpc!wcf