Normally the SMTPTOSS program is scheduled to run from SYSOP. The scheduled entry simply reads "BBSBIN:SMTPTOSS.EXP", which is the name of a program.
The SMTPTOSS program looks for files in BBS:\SMTPIN\ with extensions of .SIN, which stands for SMTP INcoming data. There is one .SIN file for each message which we have received since the last time the SMTPTOSS program ran.
Normally the SMTPTOSS program, if simply run with no qualifiers, deletes these .SIN files after it's finished tossing them. HOWEVER -- and this is the reason you are reading this now -- sometimes we might need to save these .SIN files in another directory for a few days. Why? Because Krazy Dan is trying, trying so desperately, to help you diagnose some problem or mystery with your incoming mail, and wants to re-toss a message whilst running the SMTPTOSS program under the debugger to analyze its behavior. How can Dan do this if the .SIN file has been wiped off the face of the disk?
Dan has explained, and gotten on and just done, setting up systems to save a few day's worth of mail one too many times. Invariably, Dan forgets he did that, and SYSOPs don't understand what has been done, or how to undo it. This lack of understanding can only lead to an impotent incapacity to manage one's own life, and we are here to solve it NOW! So, with out further B.S., here are instructions on how to convert your system to save the last 2 days worth of mail:
Step one is to create a file named BBSBIN:SMTPTOSS.CMD. Use your favorite editor to do this. Put these lines in the file:
COPY/CREDIR BBS:\SMTPIN\*.SIN BBS:\SMTPSAV\*.SIN
DELETE/BEFORE="-48" BBS:\SMTPSAV\*.SIN
RUN BBSBIN:SMTPTOSS
The first line of this command procedure makes the copies of all the .SIN files in a backup directory (creating the directory the first time the command procedure is run). This backup directory will be the SMTPSAV subdirectory of BBSBIN:, typically \TSXBBS\DATA\SMTPSAV\. The second command, the DELETE command, wipes out any files from that directory which are over 48 hours (two days) old. That way we don't fill up your disk with old messages. Note that this means that you are going to have a most two days to catch the mail system doing whatever it is that you want Dan to look at! Remember, the entire point of this exercise is to catch a message which is not being tossed correctly and have Dan toss it under the debugger.
Finally, our BBSBIN:SMTPTOSS.CMD file runs the tosser, just as the scheduler has been doing. Now we are ready for our second step, which is to run SYSOP, type 'S' for "Schedule", locate the "Incoming mail tosser" scheduled event, and edit it. Change the scheduled event from "BBSBIN:SMTPTOSS.EXP" to "BBSBIN:SMTPTOSS.CMD". What should be obvious is that the schedule server will start running this command file instead of directly running the SMTPTOSS.EXP program. The command file will begin storing the last two day's worth of messages -- we are laying a trap for a bug!
What stuns the humble author is that people never understand how to UNDO this procedure once it's been set up. Hopefully by forcing people to set it up themselves, by reading this document, it will be more clear. But here is some guidance on how to set everything back to normal, after you have found and capured the troublesome mail message and given Dan the opportunity to toss it under the debugger and fix the problem and make the world right and rosy once again. First, go into the SYSOP program, back into that schedule screen, and changed the scheduled event back to BBSBIN:SMTPTOSS.EXP. Next, if you want, delete the file BBSBIN:SMTPTOSS.CMD. Finally, if you want, delete the contents of the BBSBIN:\SMTPSAV\ directory. Here are the COMMANDS for doing this.
DELETE BBSBIN:SMTPTOSS.CMD
CD BBSBIN:\SMTPSAV
DEL *.*
CD ..
RMDIR SMTPSAV