   This file documents Taylor UUCP, version 1.05.

   Copyright (C) 1992, 1993, 1994 Ian Lance Taylor

   Permission is granted to make and distribute verbatim copies of this
manual provided the copyright notice and this permission notice are
preserved on all copies.

   Permission is granted to copy and distribute modified versions of
this manual under the conditions for verbatim copying, provided also
that the section entitled "Copying" are included exactly as in the
original, and provided that the entire resulting derived work is
distributed under the terms of a permission notice identical to this
one.

   Permission is granted to copy and distribute translations of this
manual into another language, under the above conditions for modified
versions, except that the section entitled "Copying" may be included in
a translation approved by the author instead of in the original English.

Taylor UUCP 1.05
****************

   This is the documentation for the Taylor UUCP package, version 1.05.
The programs were written by Ian Lance Taylor.  The author can be
reached at `<ian@airs.com>', or `c/o Cygnus Support, Building 200, 1
Kendall Square, Cambridge, MA, 02139, USA'.

   There is a mailing list for discussion of the package.  To join (or
get off) the list, send mail to `<taylor-uucp-request@gnu.ai.mit.edu>'.
Mail to this address is answered by a person, not a program.  When
joining the list, please give the address at which you wish to receive
mail; do not rely on the message headers.  To send a message to the
list, send it to `<taylor-uucp@gnu.ai.mit.edu>'.

   Jeff Ross has volunteered to maintain patches for UUCP releases.
They may be obtained via anonymous FTP from ftp.fdu.edu, in the
directory pub/taylor-uucp.

Taylor UUCP Copying Conditions
******************************

   This package is covered by the GNU Public License.  See the file
`COPYING' for details.  If you would like to do something with this
package that you feel is reasonable, but you feel is prohibited by the
license, contact me to see if we can work it out.

   Here is some propaganda from the Free Software Foundation.  If you
find this stuff offensive or annoying, remember that you probably did
not spend any money to get this code.  I did not write this code to make
life easier for developers of UUCP packages, I wrote it to help end
users, and I believe that these are the most appropriate conditions for
distribution.

   All the programs, scripts and documents relating to Taylor UUCP are
"free"; this means that everyone is free to use them and free to
redistribute them on a free basis.  The Taylor UUCP-related programs are
not in the public domain; they are copyrighted and there are
restrictions on their distribution, but these restrictions are designed
to permit everything that a good cooperating citizen would want to do.
What is not allowed is to try to prevent others from further sharing any
version of these programs that they might get from you.

   Specifically, we want to make sure that you have the right to give
away copies of the programs that relate to Taylor UUCP, that you receive
source code or else can get it if you want it, that you can change these
programs or use pieces of them in new free programs, and that you know
you can do these things.

   To make sure that everyone has such rights, we have to forbid you to
deprive anyone else of these rights.  For example, if you distribute
copies of the Taylor UUCP related programs, you must give the recipients
all the rights that you have.  You must make sure that they, too,
receive or can get the source code.  And you must tell them their
rights.

   Also, for our own protection, we must make certain that everyone
finds out that there is no warranty for the programs that relate to
Taylor UUCP.  If these programs are modified by someone else and passed
on, we want their recipients to know that what they have is not what we
distributed, so that any problems introduced by others will not reflect
on our reputation.

   The precise conditions of the licenses for the programs currently
being distributed that relate to Taylor UUCP are found in the General
Public Licenses that accompany them.

Introduction to Taylor UUCP
***************************

   General introductions to UUCP are available, and perhaps one day I
will write one.  In the meantime, here is a very brief one that
concentrates on the programs provided by Taylor UUCP.

   Taylor UUCP is a complete UUCP package.  It is covered by the GNU
Public License, which means that the source code is always available.
It is composed of several programs; most of the names of these programs
are based on earlier UUCP packages.

`uucp'
     The `uucp' program is used to copy file between systems.  It is
     similar to the standard Unix `cp' program, except that you can
     refer to a file on a remote system by using `system!' before the
     file name.  For example, to copy the file `notes.txt' to the system
     `airs', you would say `uucp notes.txt airs!~/notes.txt'.  In this
     example `~' is used to name the UUCP public directory on `airs'.

`uux'
     The `uux' program is used to request the execution of a program on
     a remote system.  This is how mail and news are transferred over
     UUCP.  As with `uucp', programs and files on remote systems may be
     named by using `system!'.  For example, to run the `rnews' program
     on `airs' passing it standard input, you would say `uux -
     airs!rnews'.  The `-' means to read standard input and set things
     up such that when `rnews' runs on `airs' it will receive the same
     standard input.

   Neither `uucp' nor `uux' actually do any work immediately.  Instead,
they queue up requests for later processing.  They then start a daemon
process which processes the requests and calls up the appropriate
systems.  Normally the system will also start the daemon periodically to
check if there is any work to be done.  The advantage of this approach
is that it all happens automatically.  You don't have to sit around
waiting for the files to be transferred.  The disadvantage is that if
anything goes wrong it might be a while before anybody notices.

`uustat'
     The `uustat' program does many things.  By default it will simply
     list all the jobs you have queued with `uucp' or `uux' that have
     not yet been processed.  You can use `uustat' to remove any of
     your jobs from the queue.  You can also it use it to show the
     status of the UUCP system in various ways, such as showing the
     connection status of all the remote systems your system knows
     about.  The system administrator can use `uustat' to automatically
     discard old jobs while sending mail to the user who requested them.

`uuname'
     The `uuname' program by default lists all the remote systems your
     system knows about.  You can also use it to get the name of your
     local system.  It is mostly useful for shell scripts.

`uulog'
     The `uulog' program can be used to display entries in the UUCP log
     file.  It can select the entries for a particular system or a
     particular user.  You can use it to see what has happened to your
     queued jobs in the past.

`uuto'
`uupick'
     `uuto' is a simple shell script interface to `uucp'.  It will
     transfer a file, or the contents of a directory, to a remote
     system, and notify a particular user on the remote system when it
     arrives.  The remote user can then retrieve the file(s) with
     `uupick'.

`cu'
     The `cu' program can be used to call up another system and
     communicate with it as though you were directly connected.  It can
     also do simple file transfers, though it does not provide any
     error checking.

   These eight programs just described, `uucp', `uux', `uuto',
`uupick', `uustat', `uuname', `uulog', and `cu' are the user programs
provided by Taylor UUCP. `uucp', `uux', and `uuto' add requests to the
work queue, `uupick' extracts files from the UUCP public directory,
`uustat' examines the work queue, `uuname' examines the configuration
files, `uulog' examines the log files, and `cu' just uses the UUCP
configuration files.

   The real work is actually done by two daemon processes, which are
normally run automatically rather than by a user.

`uucico'
     The `uucico' daemon is the program which actually calls the remote
     system and transfers files and requests.  `uucico' is normally
     started automatically by `uucp' and `uux'.  Most systems will also
     start it periodically to make sure that all work requests are
     handled.  `uucico' checks the queue to see what work needs to be
     done, and then calls the appropriate systems.  If the call fails,
     perhaps because the phone line is busy, `uucico' leaves the
     requests in the queue and goes on to the next system to call.  It
     is also possible to force `uucico' to call a remote system even if
     there is no work to be done for it, so that it can pick up any
     work that may be queued up remotely.

`uuxqt'
     The `uuxqt' daemon processes execution requests made by the `uux'
     program on remote systems.  It also processes requests made on the
     local system which require files from a remote system.  It is
     normally started by `uucico'.

   Suppose you, on the system `bantam', want to copy a file to the
system `airs'.  You would run the `uucp' command locally, with a
command like `uucp notes.txt airs!~/notes.txt'.  This would queue up a
request on `bantam' for `airs', and would then start the `uucico'
daemon.  `uucico' would see that there was a request for `airs' and
attempt to call it.  When the call succeeded, another copy of `uucico'
would be started on `airs'.  The two copies of `uucico' would tell each
other what they had to do and transfer the file from `bantam' to
`airs'.  When the file transfer was complete the `uucico' on `airs'
would move it into the UUCP public directory.

   UUCP is often used to transfer mail.  This is normally done
automatically by mailer programs.  When `bantam' has a mail message to
send to `ian' at `airs', it executes `uux - airs!rmail ian' and writes
the mail message to the `uux' process as standard input.  The `uux'
program, running on `bantam', will read the standard input and store
it, as well as the `rmail' request itself, on the work queue for
`airs'.  `uux' will then start the `uucico' daemon.  The `uucico'
daemon will call up `airs', just as in the `uucp' example, and transfer
the work request and the mail message.  The `uucico' daemon on `airs'
will put the files on a local work queue.  When the communication
session is over, the `uucico' daemon on `airs' will start the `uuxqt'
daemon.  `uuxqt' will see the request to run, and will run `rmail ian'
with the mail message as standard input.  The `rmail' program, which is
not part of the UUCP package, is then responsible for either putting
the message in the right mailbox on `airs' or forwarding the message on
to another system.

   Taylor UUCP comes with a few other programs that are useful when
installing and configuring UUCP.

`uuchk'
     The `uuchk' program reads the UUCP configuration files and displays
     a rather lengthy description of what it finds.  This is useful when
     configuring UUCP to make certain that the UUCP package will do
     what you expect it to do.

`uuconv'
     The `uuconv' program can be used to convert UUCP configuration
     files from one format to another.  This can be useful for
     administrators converting from an older UUCP.  Taylor UUCP is able
     to read and use old configuration file formats, but some new
     features can not be selected using the old formats.

`uusched'
     The `uusched' script is just provided for compatibility with older
     UUCP releases.  It starts `uucico' to call, one at a time, all the
     systems for which work has been queued.

`tstuu'
     The `tstuu' program is a test harness for the UUCP package; it can
     help check that the package has been configured and compiled
     correctly.  However, it uses pseudo-terminals, which means that it
     is less portable than the rest of the package.  If it works, it
     can be useful when initially installing Taylor UUCP.

Taylor UUCP Overall Installation
********************************

   These are the installation instructions for the Taylor UUCP package.

Configuring Taylor UUCP
=======================

   You will have to decide what types of configuration files you want to
use.  This package supports a new sort of configuration file; see
Configuration Files.  It also supports V2 configuration files
(`L.sys', `L-devices', etc.) and HDB configuration files (`Systems',
`Devices', etc.).  No documentation is provided for V2 or HDB
configuration files.  All types of configuration files can be used at
once, if you are so inclined.  Currently using just V2 configuration
files is not really possible, because there is no way to specify a
dialer (there are no built in dialers, and the program does not know
how to read `acucap' or `modemcap'); however, V2 configuration files
can be used with a new style dial file (see dial File.), or with a
HDB `Dialers' file.

   Use of HDB configuration files has two known bugs.  A blank line in
the middle of an entry in the `Permissions' file will not be ignored as
it should be.  Dialer programs, as found in some versions of HDB, are
not recognized directly.  If you must use a dialer program, rather than
an entry in `Devices', you must use the `chat-program' command in a new
style dial file; see dial File.  You will have to invoke the
dialer program via a shell script or another program, since an exit
code of 0 is required to recognize success; the `dialHDB' program in
the `contrib' directory may be used for this purpose.

   The `uuconv' program can be used to convert from V2 or HDB
configuration files to the new style (it can also do the reverse
translation, if you are so inclined).  It will not do all of the work,
and the results should be carefully checked, but it can be quite useful.

   If you are installing a new system, you will, of course, have to
write the configuration files; see Configuration Files.

   You must also decide what sort of spool directory you want to use.
If you will be using only these programs for UUCP, I recommend
`SPOOLDIR_TAYLOR'; otherwise select the spool directory corresponding
to your existing UUCP package.  The details of the spool directory
choices are described at somewhat tedious length in `unix/spool.c'.

Compiling Taylor UUCP
=====================

  1. Take a look at the top of `Makefile.in' and set the appropriate
     values for your system.  These control where the programs are
     installed and which user on the system owns them (normally they
     will be owned by a special user `uucp' rather than a real person;
     they should probably not be owned by `root').

  2. Run the shell script `configure'.  This script was generated using
     the `autoconf' program written by David MacKenzie of the Free
     Software Foundation.  It takes a while to run.  It will generate
     the file `config.h' based on `config.h.in', and, for each source
     code directory, will generate `Makefile' based on `Makefile.in'.

     You can pass certain arguments to `configure' in the environment.
     Because `configure' will compile little test programs to see what
     is available on your system, you must tell it how to run your
     compiler.  It recognizes the following environment variables:

    `CC'
          The C compiler.  If this is not set, then if `configure' can
          find `gcc' it will use it, otherwise it will use `cc'.

    `CFLAGS'
          Flags to pass to the C compiler when compiling the actual
          code.  If this is not set, `configure' will use `-g'.

    `LDFLAGS'
          Flags to pass to the C compiler when only linking, not
          compiling.  If this is not set, `configure' will use the
          empty string.

    `LIBS'
          Libraries to pass to the C compiler.  If this is not set,
          `configure' will use the empty string.

    `INSTALL'
          The program to run to install UUCP in the binary directory.
          If this is not set, then if `configure' finds the BSD
          `install' program, it will set this to `install -c';
          otherwise, it will use `cp'.

    `INSTALLDATA'
          The program to run to install UUCP data files, such as the
          man pages and the info pages.  If this is not set, then if
          `configure' finds the BSD `install' program, it will set this
          to `install -c -m 644'; otherwise, it will use `cp'.

     Suppose you want to set the environment variable `CC' to `rcc'.
     If you are using `sh' or `bash', invoke `configure' as `CC=rcc
     configure'.  If you are using `csh', do `setenv CC rcc; sh
     configure'.

     On some systems you will want to use `LIBS=-lmalloc'.  On Xenix
     derived versions of Unix do not use `LIBS=-lx' because this will
     bring in the wrong versions of certain routines; if you want to use
     `-lx' you must specify `LIBS=-lc -lx'.

     If `configure' fails for some reason, or if you have a very weird
     system, you may have to configure the package by hand.  To do
     this, copy the file `config.h.in' to `config.h' and edit it for
     your system.  Then for each source directory (the top directory,
     and the subdirectories `lib', `unix', and `uuconf') copy
     `Makefile.in' to `Makefile', find the words within `@' characters,
     and set them correctly for your system.

  3. Igor V. Semenyuk provided this (lightly edited) note about ISC
     Unix 3.0.  The `configure' script will default to passing `-posix'
     to `gcc'.  However, using `-posix' changes the environment to
     POSIX, and on ISC 3.0, at least, the default for POSIX_NO_TRUNC is
     1.  This means nothing for uucp, but can lead to a problem when
     uuxqt executes rmail.  IDA sendmail has dbm configuration files
     named `mailertable.{dir,pag}'.  Notice these names are 15
     characters long.  When uuxqt compiled with `-posix' executes
     rmail, which in turn executes sendmail, the later is run under
     POSIX environment too!  This leads to sendmail bombing out with
     `'error opening 'M' database: name too long' (mailertable.dir)'.
     It's rather obscure behaviour, and it took me a day to find out
     the cause.  I don't use `-posix', instead I run `gcc' with
     `-D_POSIX_SOURCE', and add `-lcposix' to `LIBS'.

  4. On some versions of BSDI there is a bug in the shell which causes
     the default value for `CFLAGS' to be set incorrectly.  If `echo
     ${CFLAGS--g}' echoes `g' rather than `-g', then you must set
     `CFLAGS' in the environment before running configure.  There is a
     patch available from BSDI for this bug.  (From David Vrona).

  5. On AIX 3.2.5, and possibly other versions, `cc -E' does not work,
     reporting `Option NOROCONST is not valid'.  Test this before
     running configure by doing something like `touch /tmp/foo.c; cc -E
     /tmp/foo.c'.  This may give a warning about the file being empty,
     but it should not give the `Option NOROCONST' warning.  The
     workaround is to remove the `,noroconst' entry from the `options'
     clause in the `cc' stanza in `/etc/xlc.cfg'.  (From Chris Lewis).

  6. You should verify that `configure' worked correctly by checking
     `config.h' and the instances of `Makefile'.

  7. Edit `policy.h' for your local system.  The comments should explain
     the various choices.  The default values are intended to be
     reasonable, so you may not have to make any changes.

  8. Type `make' to compile everything.  The `tstuu.c' file is not
     particularly portable; if you can't figure out how to compile it
     you can safely ignore it, as it is only used for testing (to use
     STREAMS pseudo-terminals, tstuu.c must be compiled with
     `-DHAVE_STREAMS_PTYS'; this is not automatically determined at the
     moment).  If you have any other problems there is probably a bug
     in the `configure' script.

  9. Please report any problems you have.  That is the only way they
     will get fixed for other people.  Supply a patch if you can (see
     Patches.), or just ask for help.

Testing Taylor UUCP
===================

   This package is in use at hundreds, perhaps thousands, of sites, and
has been running at `airs.com' for several years.  However, it will
doubtless fail in some situations.  Do not rely on this code until you
have proven to yourself that it will work.

   You can use the `uuchk' program to test your configuration files.
It will read them and print out a verbose description.  This program
should not be made setuid, because it will display passwords if it can
read them.

   If your system supports pseudo-terminals, and you compiled the code
to support the new style of configuration files, you should be able to
use the `tstuu' program to test the `uucico' daemon (if your system
supports STREAMS based pseudo-terminals, you must compile tstuu.c with
`-DHAVE_STREAMS_PTYS', at least at the moment; the STREAMS based code
was contributed by Marc Boucher).

   To run `tstuu', just type `tstuu' with no arguments while logged in
to the compilation directory (since it runs `./uucp', `./uux' and
`./uucico').  It will run a lengthy series of tests (it takes over ten
minutes on a slow VAX).  You will need a fair amount of space available
in `/usr/tmp'.  You will probably want to put it in the background.  Do
not use `^Z', because the program traps on `SIGCHLD' and winds up
dying.  It will create a directory `/usr/tmp/tstuu' and fill it with
configuration files, and create spool directories
`/usr/tmp/tstuu/spool1' and `/usr/tmp/tstuu/spool2'.

   If your system does not support the `FIONREAD' call, the `tstuu'
program will run very slowly.  This may or may not get fixed in a later
version.

   The program will finish with an execute file named `X.SOMETHING' and
a data file named `D.SOMETHING' in the directory
`/usr/tmp/tstuu/spool1' (or, more likely, in subdirectories, depending
on the choice of `SPOOLDIR' in `policy.h').  Two log files will be
created in the directory `/usr/tmp/tstuu'.  They will be named `Log1'
and `Log2', or, if you have selected `HAVE_HDB_LOGGING' in `policy.h',
`Log1/uucico/test2' and `Log2/uucico/test1'.  You can test `uuxqt' by
running the command `./uuxqt -I /usr/tmp/tstuu/Config1'.  This should
leave a command file `C.SOMETHING' and a data file `D.SOMETHING' in
`/usr/tmp/tstuu/spool1' or in subdirectories.  Again, there should be
no errors in the log file.

   Assuming you compiled the code with debugging enabled, the `-x'
switch can be used to set debugging modes; see the `debug' command for
details (see Debugging Levels.).  Use `-x all' to turn on all
debugging and generate far more output than you will ever want to see.
The `uucico' daemons will put debugging output in the files `Debug1'
and `Debug2' in the directory `/usr/tmp/tstuu'.  After that, you're
pretty much on your own.

   On some systems you can also use `tstuu' to test `uucico' against
the system `uucico', by using the `-u' switch.  For this to work,
change the definitions of `ZUUCICO_CMD' and `UUCICO_EXECL' at the top
of `tstuu.c' to something appropriate for your system.  The definitions
in `tstuu.c' are what I used for Ultrix 4.0, on which
`/usr/lib/uucp/uucico' is particularly obstinate about being run as a
child; I was only able to run it by creating a login name with no
password whose shell was `/usr/lib/uucp/uucico'.  Calling login in this
way will leave fake entries in `wtmp' and `utmp'; if you compile
`tstout.c' (in the `contrib' directory) as a setuid `root' program,
`tstuu' will run it to clear those entries out.  On most systems, such
hackery should not be necessary, although on SCO I had to su to `root'
(`uucp' might also have worked) before I could run
`/usr/lib/uucp/uucico'.

   You can test `uucp' and `uux' (give them the `-r' switch to keep
them from starting `uucico') to make sure they create the right sorts
of files.  Unfortunately, if you don't know what the right sorts of
files are, I'm not going to tell you here.

   If `tstuu' passes, or you can't run it for some reason or other,
move on to testing with some other system.  Set up the configuration
files (see Configuration Files.), or use an existing configuration.
Tell `uucico' to dial out to the system by using the `-s' system switch
(e.g.  `uucico -s uunet').  The log file should tell you what happens.

   If you compiled the code with debugging enabled, you can use
debugging mode to get a great deal of information about what sort of
data is flowing back and forth; the various possibilities are described
under the `debug' command (see Debugging Levels.).  When initially
setting up a connection `-x chat' is probably the most useful (e.g.
`uucico -s uunet -x chat'); you may also want to use `-x
handshake,incoming,outgoing'.  You can use `-x' multiple times on one
command line, or you can give it comma separated arguments as in the
last example.  Use `-x all' to turn on all possible debugging
information.  The debugging information is written to a file, normally
`/usr/spool/uucp/Debug', although the default can be changed in
`policy.h' and the `config' file can override the name with the
`debugfile' command.  The debugging file may contain passwords and some
file contents as they are transmitted over the line, so the debugging
file is only readable by the `uucp' user.

   You can use the `-f' switch to force `uucico' to call out even if
the last call failed recently; using `-S' when naming a system has the
same effect.  Otherwise the status file (in the `.Status' subdirectory
of the main spool directory, normally `/usr/spool/uucp') will prevent
too many attempts from occurring in rapid succession.

   Again, please let me know about any problems you have and how you got
around them.  If you do report a problem, please include the version
number of the package you are using, and a sample of the debugging file
showing the problem (debugging information is usually what is needed,
not just the log file).  General questions such as "why doesn't uucico
dial out" are impossible to answer without much more information.

Installing Taylor UUCP
======================

   You can install the executable files by becoming `root' and typing
`make install'.  Or you can look at what `make install' does and do it
by hand.  It tries to preserve your old programs, if any, but it only
does this the first time Taylor UUCP is installed (so that if you
install several versions of Taylor UUCP, you can still go back to your
original UUCP programs).  You can retrieve the original programs by
typing `make uninstall'.

   Note that by default the programs are compiled with debugging
information, and they are not stripped when they are installed.  You may
want to strip the installed programs to save disk space.  See your
system documentation for strip for more information.

   However, simply installing the executable files is not enough.  You
must also arrange for them to be used correctly.

Running uucico
--------------

   By default `uucp' and `uux' will automatically start up `uucico' to
call another system whenever work is queued up.  However, the call may
fail, or you may have put in time restrictions which prevent the call
at that time (perhaps because telephone rates are high) (see When to Call.).
Also, a remote system may have work queued up for your
system, but may not be calling you for some reason (perhaps you have
agreed that your system should always place the call).  To make sure
that works get transferred between the systems withing a reasonable
time period, you should arrange to periodically invoke `uucico'.

   These periodic invocations are normally caused by entries in the
`crontab' file.  The exact format of `crontab' files, and how new
entries are added, varies from system to system; check your local
documentation (try `man cron').

   To attempt to call all systems with outstanding work, use the command
`uucico -r1'.  To attempt to call a particular system, use the command
`uucico -s SYSTEM'.  To attempt to call a particular system, but only
if there is work for it, use the command `uucico -C -s SYSTEM'.

   A common case is to want to try to call a system at a certain time,
with periodic retries if the call fails.  A simple way to do this is to
create an empty UUCP command file, known as a "poll file".  If a poll
file exists for a system, then `uucico -r1' will place a call to it.
If the call succeeds, the poll file will be deleted.

   The file can be easily created using the `touch' command.  The name
of a poll file currently depends on the type of spool directory you are
using, as set in `policy.h'.  If you are using `SPOOLDIR_TAYLOR' (the
default), put something like this in your `crontab' file:
     touch /usr/spool/uucp/SYS/C./C.A0000
   In this example SYS is the system you wish to call, and
`/usr/spool/uucp' is your UUCP spool directory.  If you are using
`SPOOLDIR_HDB', use
     touch /usr/spool/uucp/SYS/C.SYSA0000

   For example, I use the following crontab entries locally:

     45 * * * * /bin/echo /usr/lib/uucp/uucico -r1 | /bin/su uucpa
     40 4,10,15 * * * touch /usr/spool/uucp/uunet/C./C.A0000

   Every hour, at 45 minutes past, this will check if there is any work
to be done, and, if there is, will call the appropriate system.  Also,
at 4:40am, 10:40am and 3:40pm this will create a poll file file for
`uunet', forcing the next check to call `uunet'.

Using UUCP for mail and news.
-----------------------------

   Taylor UUCP does not include a mail package.  All Unix systems come
with some sort of mail delivery agent, typically `sendmail' or `MMDF'.
Source code is available for some alternative mail delivery agents,
such as `IDA sendmail' and `smail'.

   Taylor UUCP also does not include a news package.  The two major Unix
news packages are `C-news' and `INN'.  Both are available in source
code form.

   Configuring and using mail delivery agents is a notoriously complex
topic, and I will not be discussing it here.  Configuring news systems
is usually simpler, but I will not be discussing that either.  I will
merely describe the interactions between the mail and news systems and
UUCP.

   A mail or news system interacts with UUCP in two ways: sending and
receiving.

Sending mail or news via UUCP
.............................

   When mail is to be sent from your machine to another machine via
UUCP, the mail delivery agent will invoke `uux'.  It will generally run
a command such as `uux - SYSTEM!rmail', where SYSTEM is the remote
system to which the mail is being sent.  It may pass other options to
`uux', such as `-r' or `-g'.

   News also invokes `uux' in order to transfer articles to another
system.  The only difference is that news will use `uux' to invoke
`rnews' on the remote system, rather than `rmail'.

   You should arrange for your mail and news systems to invoke the
Taylor UUCP version of `uux' when sending mail via UUCP.  If you simply
replace any existing version of `uux' with the Taylor UUCP version,
this will probably happen automatically.  However, if both versions
exist on your system, you will probably have to modify the mail and news
configuration files in some way.

   Actually, if both the system UUCP and Taylor UUCP are using the same
spool directory format, the system `uux' will probably work fine with
the Taylor `uucico' (the reverse is not the case: the Taylor `uux'
requires the Taylor `uucico').  However, data transfer will be somewhat
more efficient if the Taylor `uux' is used.

Receiving mail or news via UUCP
...............................

   As noted in Sending mail or news, mail is sent by requesting
a remote execution of `rmail'.  To receive mail, then, all that is
necessary is for UUCP to invoke `rmail' itself.

   Any mail delivery agent will provide an appropriate version of
`rmail'; you must simply make sure that it is in the command path used
by UUCP (it almost certainly already is).  The default command path is
set in `policy.h', and it may be overridden for a particular system by
the `command-path' command (see Miscellaneous (sys).).

   Similarly, for news UUCP must be able to invoke `rnews'.  Any news
system will provide a version of `rnews', and you must ensure that is
in a directory on the path that UUCP will search.

Trimming UUCP Log Files
-----------------------

   You should also periodically trim the log files, as they will
otherwise continue to grow without limit.  The names of the log files
are set in `policy.h', and may be overridden in the configuration file
(see config File.).  By default they are are `/usr/spool/uucp/Log'
and `/usr/spool/uucp/Stats'.

   You may find the `savelog' program in the `contrib' directory to be
of use.  There is a manual page for it in `contrib' as well.

TCP together with Taylor UUCP
=============================

   If your system has a Berkeley style socket library, or a System V
style TLI interface library, you can compile the code to permit making
connections over TCP.  Specifying that a system should be reached via
TCP is easy, but nonobvious.

   If you are using the new style configuration files, see
Configuration Files.  Basically, you can just add the line `port type
tcp' to the entry in the system configuration file.  By default UUCP
will get the port number by looking up `uucp' in `/etc/services'; if
`uucp' is not found, port 540 will be used.  You can set the port
number to use with the command `port service XXX', where XXX can be
either a number or a name to look up in `/etc/services'.  You can
specify the address of the remote host with `address A.B.C'; if you
don't give an address, the remote system name will be used.  You should
give an explicit chat script for the system when you use TCP; the
default chat script begins with a carriage return, which will not work
with some UUCP TCP servers.

   If you are using V2 configuration files, add a line like this to
`L.sys':

     SYS Any TCP uucp HOST.DOMAIN chat-script

   This will make an entry for system SYS, to be called at any time,
over TCP, using port number `uucp' (as found in `/etc/services'; this
may be specified as a number), using remote host `HOST.DOMAIN', with
some chat script.

   If you are using HDB configuration files, add a line like this to
Systems:

     SYS Any TCP - HOST.DOMAIN chat-script

   and a line like this to Devices:

     TCP uucp - -

   You only need one line in Devices regardless of how many systems you
contact over TCP.  This will make an entry for system SYS, to be called
at any time, over TCP, using port number `uucp' (as found in
`/etc/services'; this may be specified as a number), using remote host
`HOST.DOMAIN', with some chat script.

   The `uucico' daemon can also be run as a TCP server.  To use the
default port number, which is a reserved port, `uucico' must be invoked
by root (or it must be set user ID to root, but I don't recommend doing
that).

   Basically, you must define a port, either using the port file (see
port File.) if you are using the new configuration method or with an
entry in Devices if you are using HDB; there is no way to define a port
using V2.  If you are using HDB the port must be named `TCP'; a line as
shown above will suffice.  You can then start `uucico' as `uucico -p
TCP' (after the `-p', name the port; in HDB it must be `TCP').  This
will wait for incoming connections, and fork off a child for each one.
Each connection will be prompted with `login:' and `Password:'; the
results will be checked against the UUCP (not the system) password file
(see Configuration File Names.).

   Of course, you can get a similar effect by using the BSD `uucpd'
program.

   You can also have `inetd' start up `uucico' with the `-l' switch,
which will cause it to prompt with `login:' and `Password:' and check
the results against the UUCP (not the system) password file (you may
want to also use the `-D' switch to avoid a fork, which in this case is
unnecessary).  This may be used in place of `uucpd'.

Taylor UUCP Configuration Files
*******************************

   This chapter describes the configuration files accepted by the Taylor
UUCP package if compiled with `HAVE_TAYLOR_CONFIG' defined in
`policy.h'.

   The configuration files are normally found in the directory
NEWCONFIGDIR, which is defined by the `Makefile' variable
`newconfigdir'; by default NEWCONFIGDIR is `/usr/local/conf/uucp'.
However, the main configuration file, `config', is the only one which
must be in that directory, since it may specify a different location
for any or all of the other files.  You may run any of the UUCP
programs with a different main configuration file by using the `-I'
option; this can be useful when testing a new configuration.  When you
use the `-I' option the programs will revoke any setuid privileges.

Configuration File Format
=========================

   All the configuration files follow a simple line-oriented `KEYWORD
VALUE' format.  Empty lines are ignored, as are leading spaces; unlike
HDB, lines with leading spaces are read.  The first word on each line
is a keyword.  The rest of the line is interpreted according to the
keyword.  Most keywords are followed by numbers, boolean values or
simple strings with no embedded spaces.

   The `#' character is used for comments.  Everything from a `#' to
the end of the line is ignored unless the `#' is preceded by a `\'
(backslash); if the `#' is preceeded by a `\', the `\' is removed but
the `#' remains in the line.  This can be useful for a phone number
containing a `#'.  To enter the sequence `\#', use `\\#'.

   The backslash character may be used to continue lines.  If the last
character in a line is a backslash, the backslash is removed and the
line is continued by the next line.  The second line is attached to the
first with no intervening characters; if you want any whitespace between
the end of the first line and the start of the second line, you must
insert it yourself.

   However, the backslash is not a general quoting character.  For
example, you cannot use it to get an embedded space in a string
argument.

   Everything after the keyword must be on the same line.  A BOOLEAN
may be specified as `y', `Y', `t', or `T' for true and `n', `N', `f',
or `F' for false; any trailing characters are ignored, so `true',
`false', etc., are also acceptable.

Configuration File Overview
===========================

   UUCP uses several different types of configuration files, each
describing a different kind of information.  The commands permitted in
each file are described in detail below.  This section is a brief
description of some of the different types of files.

   The `config' file is the main configuration file.  It describes
general information not associated with a particular remote system, such
as the location of various log files.  There are reasonable defaults for
everything that may be specified in the `config' file, so you may not
actually need one on your system.

   There may be only one `config' file, but there may be one or more of
each other type of file.  The default is one file for each type, but
more may be listed in the `config' file.

   The `sys' files are used to describe remote systems.  Each remote
system to which you connect must be listed in a `sys' file.  A `sys'
file will include information for a system, such as the speed (baud
rate) to use, or when to place calls.

   For each system you wish to call, you must describe one or more
ports; these ports may be defined directly in the `sys' file, or they
may be defined in a `port' file.

   The `port' files are used to describe ports.  A port is a particular
hardware connection on your computer.  You would normally define as
many ports as there are modems attached to your computer.  A TCP
connection is also described using a port.

   The `dial' files are used to describe dialers.  Dialer is
essentially another word for modem.  The `dial' file describes the
commands UUCP should use to dial out on a particular type of modem.  You
would normally define as many dialers as there are types of modems
attached to your computer.  For example, if you have three Telebit
modems used for UUCP, you would probably define three ports and one
dialer.

   There are other types of configuration files, but these are the
important ones.  The other types are described below.

Examples of Configuration Files
===============================

   This section provides few typical examples of configuration files.
There are also sample configuration files in the `sample' subdirectory
of the distribution.