In order to figure out why your system is not receiving mail, we have to take you very carefully through all the steps which are involved when the system DOES receive mail correctly. We will talk about how to determine whether each step is working successfully. Following this analysis might well get your mail working without our help. Furthermore, if it does not, at least you will gain some insight into how it does work and hopefully where it has broken down.
In order to be able to receive mail, or do practically anything for that matter, your system has to be on the net. If it's not, how could you expect it to be getting mail? To verify that your system is on the net, the most simple check is to use a NETCHECK command, and "ping" something by IP address. Feel free to ping us if you can't think of somebody closer to your system:
You are not allowed to read this paragraph unless you have seen that
you are on the net with a NETCHECK command. If the NETCHECK waited
a long time a failed, then you are off the net, and you need to
go and look at the page for
system is off the net.
Let's talk a little about how an SMTP mail message is sent from another computer to yours. Internet mail is sent using a conversational client server protocol called SMTP (Simple Mail Transport Protocol). The client program is the one that wants to send the message. The server program is the one that receives the message. The client connects to the computer and sends english like commands which mean things like "I have a message for so-and so", and "here it is".
From this vastly simplified description it should be apparent that for your system, which have now verified is at least on the net, has to have a server program ready to accept incoming SMTP mail. The name of this program for TSX is SMTPS. The way the SMTPS program gets started for TSX is that the TSGEN parameter DOSMTP must be set to 1. Go on, type the command:
and see if you have a job out there running the program SMTPS. The process name will be "SMTP Server". If you don't, then one of two things must be the case: either you don't have the DOSMTP gen parameter set to 1, or the SMTP server died. The way you can tell if the SMTP server ever got going at all is to type this command:
There should be SOMETHING in the SMTPIN event log because when the SMTP server first starts, it puts messages in the event log telling us that it is accepting connections.
If the EVENT program says something like "I'm waiting for the SMTPIN event log to be created", then your SMTP server never started at all, and you need to check that gen parameter. If there is info in the SMTPIN event log, but there is no SMTP server running, then I'd say it has crashed. Hopefully it has left a job dump file you can get to us.
From this point on in the discussion, we will assume that you are on the net and that your SMTP Server is running; i.e., it shows in the "SHOW SYSTEM" display. To receive mail, you get on the net, you get the SMTP server going, and a remote SMTP client connects to your server. When this happens the client and the server are going to exchange a mail message. Whether that has happened since your system first started will be a function of what shows at the end of the SMTPIN event log. If all you see is the initial messages about accepting connections, then no mail has come in since your system first started. This could be due to two things: either nobody has tried to send mail yet, or remote sites are having trouble connecting to you. If this is the case, my guess is that your domain name may not be translating properly to an IP address. Get a friend on the net to send mail to your ip address instead. This should tell you if it's a domain name problem. If you are up, and on the net, and your server is waiting to accept connections, and your domain name translates to the ip address associated with an interface that the SMTP server is accepting connections on, the mail is gonna come in.
At this point in the discussion we will assume that you see evidence of mail coming in in the SMTPIN event log, but you are still not getting mail delivered to inboxes. Let's talk a little about what happens after mail comes in. Each incoming message is stored in a temporary file called a ".SIN" file (for SMTP IN), in a directory named BBS:\SMTPIN. Periodically a program named SMTPTOSS is scheduled to run and "toss" (i.e., deliver) these messages. So the next thing you need to do is verify that you have scheduled the SMTPTOSS program for periodic execution. Scheduling events is all documented so we are not going to tell you how here, read the manual.
If the SMTPTOSS program is scheduled, but you are not getting mail, then you are reading this paragraph. Maybe the tosser is bombing out. Until December of 1996, a message which killed the tosser would halt all mail delivery. Here is why: each time the tosser runs it looks for all the files named *.SIN. TSX tends to supply it with the names of the oldest files first. Suppose the tosser wakes up and there are 10 files, the 5th of which is going to kill it. It will toss 4 and die on the fifth. Next time it's scheduled, it will try to toss that poisonous message again, and die again, never getting to the messages which have appeared since the bad one. In December of 1996 we enhanced the tosser to detect this condition, rename the poison message to .BAD, and advance on.
In any case, there are two trails of evidence left when the SMTPTOSS program runs. First, the schedule specifies the name of a job log file such as BBS:SMTPTOSS.LOG. If you are having mail problems than it behooves you to have a look in that file. There could be messages to the effect that the tosser is aborting, or that TSX can't find the tosser, or any number of possible things. If all is well you will only see a message saying that the job logged off. The log file is where the "standard output" from the job goes.
If the tosser is running, and terminating normally, you have reached this paragraph, which is getting pretty near the end. The second and all important trail of evidence left by the tosser is the file BBS:EMAILIN.LOG. This is where the tosser provides you with detail about the disposition of each individual message. You might see messages like "I'm not delivering this message because I don't know who it goes to". In fact, the series of questions asked about each incoming message is such a deep topic that it will be the topic of another page, but I have not written it yet.