Setting Up UUCP

UUCP is actually a suite of programs to do very specific
tasks. For example, uucp itself is used for copying files between
nodes (the machines connected via UUCP) and uux is used for
executing programs on another node. Programs exist for all kinds of
maintenance, like logfile-trimming and spool-checking. For my
purposes (and the purposes of this article), the most important
programs are uucico and
uuxqt. uucico actually places the
phone call and sets up file transfers, while uuxqt tells the other
machine what program needs to be run for proper handling of the
files.

The following sequence of events is typical:

Typing uucico -s sloth causes uucico to
look up sloth in config. Seeing it should use
serial1 to connect to sloth, it looks in
port and sees that serial1 is
the modem, which is activated by the dialer
entry. Peeking at this entry in dial, uucico initializes the modem
and calls the number specified in sys. When the
CONNECT string is received, it executes the chat
script from sys and logs into sloth.

When the login procedure is complete, perrin is in “master”
mode and sloth is in “slave” mode. Files to be uploaded will be
in the spool directory /var/spool/uucp/sloth/D./filename. If these
files exist, perrin will upload them with instructions for the
slave. The instruction files will be in
/var/spool/news/uucp/sloth/C./filename. When the transfer is
complete, the master and slave exchange roles, with perrin now
receiving any files spooled on sloth, as well as execution
instructions. When both sides have transferred all the necessary
files, the connection is terminated. Logging is done in
/var/log/uucp, so take a look in there for an exhaustive roster of
an average session's work.

When the connection is broken, the second important UUCP
program is fired up: uuxqt. uuxqt looks in the UUCP spool directory
for execution requests and (if permitted) executes them. For
example, files consisting of mail messages must be delivered and
news postings must be moved into the news spool. By default, UUCP
permits only two local programs, rmail and rnews, to be executed,
which not-so-coincidentally accomplish the tasks just
mentioned.

With UUCP configured and tested, it's now time to set up the
transfer of mail and news.

Mail via UUCP

For mail transport and delivery, the two most obvious choices
are sendmail and smail. I have read that for small sites the two
are roughly equivalent in configuration difficulty, but I've also
seen O'Reilly's sendmail book. Nothing that massive could possibly
be required for my little project. Accordingly, I chose smail. The
current release is v3.1.29—while not part of Red Hat's
distribution, some kindly soul has made an RPM available in the
/pub/contrib directory at ftp.redhat.com.

Installing smail

After looking at a full source tree for smail, I chickened
out and grabbed a precompiled rpm from Red Hat's /pub/contrib
directory, then installed it:

rpm -i smail-3.1.29.1-6.i386.rpm

Configuring smail

Two links to smail are needed: usr/bin/rmail and
/usr/sbin/sendmail. The former is invoked when mail comes in for
delivery via UUCP; the latter is often hardcoded into mail user
agents, such as elm. To create these links, use the following
commands:

Note that rmail, or a link to it, must be
placed in the command-path specified in etc/uucp/sys or this will
fail. Your ISP might have permission to run rmail, but if he can't
find it then he'll get all sorts of error messages in his UUCP logs
and might just send you a nasty e-mail message. Of course, if
you've already arranged for mail to be sent via UUCP, this will
backfire on the ISP, and you will quickly find yourself less than
popular. Or so I hear.

The main configuration file for smail is etc/smail/config.
For a site which will be doing all its mailing through a UUCP link,
this is a remarkably simple file, especially since the smail
package comes with very nice sample files in
etc/smail/config.linux. Of the four files smail will use, I had to
modify only config for my particular setup:

The smart_path entry is the UUCP name of
your ISP's machine. This will match the system name in
/etc/uucp/sys. Any non-local mail address will be shipped off to
this machine for DNS resolution and delivery. Specifying uux as the
transport agent will cause any outgoing mail messages to be queued
in the UUCP spool to await the next UUCP connection. I will return
to this when I discuss the other configuration files for smail.

The visible_name entry identifies your
smail domain. If you have registered your UUCP name, append
:uucp to this entry. In many cases, this is
unnecessary. Using my system as an example, the
.swcp.com portion is guaranteed by the InterNIC
(and my ISP's hard-earned dollars) to be unique. Therefore, the
only machines which could have already taken perrin would be
connected to my ISP, who would notify me of a conflict.

The uucp_name entry is (surprise) your
system's UUCP name. By default, smail will generate return paths
from the hostname command, in my case perrin. Since I have not
registered perrin, someone else might. Without this entry, any mail
returned to perrin will go to that other machine. By specifying a
fully qualified domain name, I am guaranteed (because of the way
DNS and UUCP addressing are resolved) the message will go first to
swcp.com, which will recognize perrin as my UUCP account. For a
machine named “perrin”, this is a negligible concern, but a more
common name, e.g., “darkstar”, might cause problems.