Note: GIGO TCP/IP tools are based on: >SMTPD, an SMTP daemon for OS/2. >Author: Pete Appleton, pete@rayko.demon.co.uk Copies of the source code for either Pete's original work [found at hobbes.nmsu.edu:/os2/unix] or of the current source code are availabe on request to jfesler@gigo.com. Source code is available for the simpler SMTPD and for NNTPD; it is not available for the SMTPD-DELUXE version, due to the nature of it's contents. TCP/IP AND OS/2 OS/2 Starting with the August 1995 release, GIGO has supported TCP/IP connections for people running either OS/2 Warp (with the Bonus Pack), or for people running OS/ 2 version 2.1 along with the expensive TCP/IP add-on package from IBM. OS/2 Warp with the Bonus Pack is fine for anybody who intends to use only a modem connection to the internet. GIGO.COM is hooked up like that. If you have instead an ethernet connection to the internet, then you will need the OS/2 Warp Con-nect package. Please, before working on adding SMTP and NNTP capabilities to GIGO, ensure that your OS/2 internet connection is working properly. You should be able to web browse, telnet, etc properly before attempting to play with SMTP and NNTP. WindowsEtc TCP/IP under Windows (3.1, 95, NT, or anything else) is not supported at this time. It is likely that somebody will build WinSock programs for NNTP and SMTP; it is likely that they will be released as shareware. In any case, I won't be able to provide those programs myself. If you are a WinSock developer, I'll be more than happy to colaborate with you in building those programs. I'll over the technical information, and even my source code if it helps. SMTP and NNTP are very simple protocals; they are only ASCII based. THINGS YOU MUST DO Other things you must do to make GIGO work with SMTP and NNTP: I strongly urge you only go this route if you are going to have a dedciated inter-net connection, ie one that is hooked up 24 hours a day. If it is not, I suggest UUCP instead. If you must do part-time TCP/IP, then ask for help in the GIGO mailing list -it is not something I support, but others are doing it with some difficulty. EMXRT.ZIP version 0.9B REV 5 : You must get the "emxrt.zip" package. This is the runtime library DLL's needed to run EMX-compiled programs. All of the TCP/IP tools built for GIGO require this package (as well as nearly every other freeware or tcp/ip related package for OS/2). It is not included automaticly because many people already have it. A copy can be found at ftp.gigo.com, as well as at hobbes.nmsu.edu. Make sure it is version 0.9a,rev6 or later if you get it from any other source. LATER VERSIONS WILL WORK. The above requirement is the _minimum_ requirement. * You must tell GIGO that you are using the TCP/IP add-ons, by adding "TCPIP" to your config file. This alters the way outgoing messages are created slightly (it eliminates *.CMD files, as well as omits the "From " line that uucp needs). Ie, TCPIP You must tell GIGO where to expect .BAG files. This is done with the BAGS directive. All BAG files need to go to this directory, whether they are for email You must have a static IP address; ie, every time you get on the internet, your machine's IP address will be the same. You must have DNS set up properly. You or your ISP will need to make sure: forward DNS works: ie, your machine name -> IP address reverse DNS works; ie, your IP address -> your machine name MX records for your machine are set up. These are needed if you plan on receiving email. MX records with wildcards are set up, if you plan on feeding other local BBS's. (ie, in additional to gigo.com, I have *.gigo.com MX records pointing to my machine). Your ISP will know what this means. If you want to learn what all this means, I suggest any of several books on the subject matter by O'Reilly and Associates. Look for them in the library; most of the chapters won't be terribly useful for you unless you are also getting a unix box. Hopefully, your ISP has already read these books.. NNTPD - INCOMING NEWSGROUPS This program is only meant for people who are getting an NNTP feed from their provider. NNTPD does not "fetch" the newsgroups; instead, it sits and waits for your news feed to deliver the news to you. If you instead need to fetch the newsgroups from your provider, instead of having them delivered to you, look at the section on "Using UQWK and SOUPER". Using nntpd.exe is simple. The following script will run nntpd.exe in a loop (in case of critical errors, the loop ensures that nntpd reloads automaticly). At the begin-ning of the script, we need to set NNTPSERVER to the name of the server that will be sending us news. In my case, news.calweb.com delivers news to me. WARNING: This must be the "canonical" name - and not an alias of the ma-chine. The reason for this, is that GIGO will only know the IP address of the machine, and will have to look up it's name. Reverse DNS lookups only return the CNAME (canonical name) of the IP address in question. NEWS.CMD: set nntpserver=news.calweb.com rem This must be your news feed's CANONICAL name rem if it's wrong, you'll see your provider attempt to connect rem and get refused. :loop nntpd -p c:\bags\ rem in case of errors... goto loop After running this script, nntpd will load and await a connection from the news server. The "-p c:\bags\" tells it to write the incoming news files into c:\bags\ instead of it's current directory. You'll need to make sure that you tell GIGO where to find the BAGS directory. The loop is set, *just in case* nntpd bombs. It will force it to reload. I have not seen this behavior in quite some time - but then again, Murphy was an optimist! If you wish to use INETD (see below!), here is the line I use: nntp stream tcp nowait root nntpd -s %s -q -p c:\bags\ The -s specifes the socket number; the -q specifies quiet mode (otherwise, you see a message about every single message you import); the -p specifies where to put the bag files. USING UQWK OR SOUPER TO GET NEWSGROUPS Some people may not have (or want) the luxary of having news delivered to them, for a variety of reasons. Some news servers simply don't offer the service. Some gateways, are not connected 24 hours a day (I still suggest UUCP if you're not hooked up full time..). You can use a program such as UQWK or SOUPER to fetch the news from the news server. The benefits include being able to edit the "lastread" entries of those programs, as well as easily adding or removing the list of newsgroups you want to get. The downside is, is that it's resource and bandwidth hungry, as it has to ask once for every single newsgroup for the news server to get any new messages. There's a fair amount of time overhead involved, no matter how much or how little you are receiving for that batch - it simply requires "x" amount of time per newsgroup minimum, period. Whether you run UQWK or SOUPER, you will want to have them configured to download "SOUP" format news files. The will named something similiar to "00000001.MSG", "00000002.MSG", etc. These are not fidonet .MSG files; they are (essentially) .BAG files. Merely rename them, and move them to your BAGS direc-tory for GIGO; GIGO will then be able to toss them. If you decide to try other methods of getting newsgroup files, the only thing to keep in mind is that they must be standard "#! rnews" bundles, raw ascii (or com-pressed with "compress", and start with "#! cunbatch"). I've heard of "slirp" being a viable alternative, but I can not tell you anything about it. Information on how I got "souper" to work with GIGO is in the GIGTxxxx archive. It has sample files to work with, and is likely to be one of the more volatile documents. I'm hoping that others can give me a cleaner looking alternative for it, as well as perhaps something for uqwk and slirp. SMTPD - INCOMING EMAIL This is the mail receiver program. It can be ran one of two ways: either standalone (like the NNTPD program), and only accepting one connection at a time; or off of inetd (NOT the IBM released one - see the section on "Via INETD", below). The inetd method will allow multiple connections at once; however, there is no protec-tion against having too many of them running, so beware! STANDALONE: Usage is rather similiar to the NNTPD program. Make the following script: MAIL.CMD: :top smtpd -p c:\bags\ rem just in case of error.. goto top VIA INETD.CNF: Note: Do not use IBM's INETD. If you are using it, and you can not switch, then use the standalone version of smtpd instead. The IBM version is unable to pass unix socket numbers to it's spawned children, and rely instead on only using STDIN/ STDOUT. For our purposes, use the unix port of inetd. I have a copy of it at ftp.gigo.com:/ pub/misc/inetd10.zip ; it's also at hobbes.nmsu.edu:/os2/unix/inetd10.zip. Here is the line I use at gigo.com: smtp stream tcp nowait root smtpd -s %s -p c:\bags\ The "-s %s" tells smtpd what socket number SMTPD should pick up. Don't forget it - without it, smtpd will run in standalone mode! The "-p c:\bags\" tells GIGO to place all incoming mail bags into c:\bags\ instead of the current directory. MAIL FILTERING - SMTPD.OK Please see "SMTPD-OK.TXT", written by David Nugent. His technical writing skill surpass mine by a mile. It's worth reading - since you are receiving email by SMTP, you have control over what you are willing to receive. You do not have to arbitrarilly download everything. This saves you lots of bandwidth if you have a lot of mail that would otherwise be bounced by GIGO. SMTPD - THE DELUXE VERSION I have included a special copy of SMTPD, that will read GIGO's temp files for configs. This is a rude, crude way for SMTPD to be able to understand GIGO configs (mainly because they are made with different compilers, and it takes too long to read GIGO configs constantly). The deluxe version will read GIGO's temp files, in an effort to know what messages it should accept, and which ones it should not. This will help prevent accepting mail for users that you no longer support, saving you bandwidth and CPU time in processing. To use this version, you must do the following.. Add "KEEPTEMP" to your gateway.cfg file. This tells GIGO to not delete it's temporary files that contain the parsed GIGO configs. Make a "GIGO" directory under your ETC directory (usually, this will be c:\tcpip\etc\gigo) Run GIGO at least once. Copy the $*.TMP files from your temp directory (often: c:\tcpip\tmp) into your etc\gigo (c:\tcpip\etc\gigo) directory A few suggestions: 1: Use the "INETD" method for running things. 2: After every run of GIGO, copy the $*.TMP files into the proper place These two rules will help ensure that any changes you make to your GIGO configs, will _also_ make their way into your SMTD-DELUXE daemon. GIGOSLIP - OUTGOING EMAIL AND NEWS GIGOSLIP, GIGOHELP, GIGOMAIL, AND INEWS These are the programs that will get your outgoing traffic out. GIGOSLIP will scan your UUCP spool directory, and determining what packages are news, and which ones are email. It will then call either GIGOMAIL or INEWS (via GIGOHELP). Everything is configured through environment variables. A future version, should be able to use a config file. A sample batch file follows: PBATCH.CMD set mailserver=mail.calweb.com set nntpserver=news.calweb.com set bags=c:\bags\ set tz=PST8 cd \gateway\spool\myfeed gigoslip both These environment variables can be set via your CONFIG.SYS if you wish (don't forget to reboot!). The "cd" command switches to the directory where you have outgoing mail or news; it is always a combination of your SPOOL and your MYFEED variables from gateway.cfg. This program is safe to run multiple copies of; any files that are presently being transfered are locked until they are done being sent. However, you'll want to make sure that you don't have too many copies running, or else your CPU or bandwidth limits may be reached. On my 28k modem, I only allow up to 2 copies to run simultaneously. One idea is to make a "cron" type event that starts a new copy every 15 minutes. Another idea, is to make the batch file loop, with a few minute delay between loops, and perhaps have two copies that batch file running. LASTEST CHANGES: SMTPD: deluxe version understands GIGO configs NNTPD: now writes 100-message bags instead of 1 message bags - far faster for GIGO to process.