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.

