There is really only one way that newsgroup articles get OUT of a TSX system, in releiving contrast to the various ways they can come IN. The way out is via NNTP. In this page, we are going to go into the painstaking details as we track a message, from the point it comes INTO the sytsem, to the point it should be going out. By knowing how it's supposed to work, you will hopefully figure out what link in the chain is not currently connected or working right.
Before a newsgroup message has a snowball's chance in the French Quarter of getting out to the rest of the world, TSX has to THINK it should be sent out. How this works depends on where the message came from in the first place.
For messages which come into your system from the outside world (as opposed to being posted interactively by on-line users while browse the contents of a specific forum), some checking is done to prevent message loops. This checking is all based on the contents of the "Path:" line in the header of the message. The rules are as follows:
As we mentioned, the above multi stage exclusion or inclusion for sending out is not done for messages entered in the TSX on-line editor while browsing a newsgroup, since we know those messages are fresh. So our message has either been entered by an online user or passed the tests listed above, and it wants to go out. What next?
Well, next, the name of the newsgroup itself is analyzed to see if it's a local forum or a forum which the rest of the world participates in. This determination is made on the "grand division name". This rather grand monicker refers to the string before the first dot; the top level forum division. For example, in a newsgroup named usenet.alt.binaries.pictures.kittens, the grand division name is "usenet". In a newsgroup named "fido.beerbellies", the grand division name is "fido". In a newsgroup (bear with me here, I'm not making these examples up to bore you) named "local.tsx.amazing", the grand division name is -- you guessed it -- "local". OK, smartie, what's the grand division name for a forum named "bug_reports"? The answer is NOT "bug_reports"; the answer is that the grand divison name is empty, because there is not "." in that forum name.
Now that you get the concept of grand division names, let's see what grand division name tests our anxious message has to pass. First test: if the grand division name is "usenet" (capitalization does not matter), then this is assumed to be a message for a usenet newsgroup. This means that such a message is written to the USENET MESSAGE BASE to await further processing.
Second test: if the grand division name matches the name of any Fidonet network defined in SYSOP (under mail, Fidonet), then the newsgroup is assumed to be a Fidonet "echo forum", and the message is placed in the FIDONET MESSAGE BASE to await further processing.
If the message fails one of these two tests, it is assumed to have been contributed to a local discussion forum and no effort is made to share it with the rest of the world.
Before we talk about the definition of "further processing" for these two types of outgoing news messages, let's talk about message bases. If you do not set up a message base to store outgoing messages for Usenet, no Usenet messages will be sent out, and no complaints will If you do not set up a message base to store outgoing messages for Fidonet, no Fidonet messages will be sent out, and still no complaints are made. The reason for this "silent failure" is as follows: maybe you don't have the capacity, or privilege, to send outgoing articles. Still, you might want your online users to be able to post articles that at least the other online users can see. Do you want those users dealing with some error message every time they post an article? I thought not.
You set up message bases in SYSOP, under Mail, Message Bases. So if your Usenet messages are not going out (we will use Usenet as a basis for the remainder of this diatribe and mention Fido only on occasion) get in that screen and see if you have created such a message base. The critical think is that it needs to have area number 4, which is the way the USESCAN program, which we will discuss in a minute, is going to locate these messages. The area number for Fido is 3. It's common to name your usenet message base USENET and give it ID letter "U". Remember, if you don't have a message base with area 4, no outgoing newsgroup messages will be sent.
Let's assume that our newsgroup article passed all the rigorous tests we have described, and found itself written into a nice cozy message base especially designated for messages of its type. This message is going to wait in this message base untill the appropriate SCANNER program runs and sends it. For Usenet the scanner program is named USESCAN; for Fidonet it's FIDOSCAN. This scanner program is not going to run, ever, unless you go into the SYSOP program, under scheduled events, and schedule it for periodic execution -- once an hour is enough, don't you think? For USESCAN, the "program" should be BBSBIN:USESCAN.EXP. Designate a log file -- I recommend BBS:USESCAN.LOG -- to store any "standard output" type errors from this program. For example, if you never set up that message base, you will discover the error message "there is no message base defined for Usenet messages", right there in that file.
While we are on the subject of debugging outgoing Usenet mail, and in the SYSOP program anyway, go into general setup, then into debug settings, then into mail debug settings. There are two fields which mention Usenet. One activates a record of the NNTP conversation between USESCAN and your provider in the USENET event log. The other tells the USESCAN program to write a copy of this conversation to the permanent ever growing log file named BBS:USENET.LOG. Turn them both on for now so you will be able to see all this NNTP control language close up and personal.
Then the USESCAN program runs, it will scan the message base for messages waiting to go out. You can verify that messages are in there, waiting, using the "sysop super browse" mode of the mailbrowse menu action. Upon discovering the first undelivered message, USESCAN will connect to the NNTP posting host specified in SYSOP, under mail setup, under Usenet setup. This should be the domain name of your provider, who better be willing and able to accept your posts. If there is a problem connecting, or a problem posting, you are going to see it in the USENET event log, which scrolls in memory and stores about the last 50 messages, and also in BBS:USENET.LOG, which has a much greater storage capacity. If your messages are not going out, look that and see what's up.
The only other constructive advice I can give you is this: if you see the client -- USESCAN using a 'POST' command, folowed by some sort of error message from the server -- like "Post not allowed" -- then we have you covered. Some posting hosts prefer the use of the IHAVE command instead of POST; you can read all about it, and switch between the two, in the SYSOP Usenet setup screen. Any other problems should be accompanied by English-like descriptions which you may understand. If not, ask your provider, read the RFC, or give us a call.