While the Internet allows communication among a diverse collection of systems, people without static IP addresses often seem to be second-class citizens. For example, SMTP is very good at moving email between machines with static addresses, but works less well with dynamic or dial-up addresses.
Though it has become easier for end users to get always-on connections,
wireless hot spots have made mobility more attractive to users. Though
technologies exist to assist mobile users, they have their own challenges. For
example, consider what it takes to read and send email while travelling:
configuring multiple protocols (POP, IMAP, SMTP) and tools (
Sendmail), and working around email-relaying blocks.
I have found that UUCP (Unix to Unix CoPy) provides a compelling alternative to the more typical email solutions for mobile users. I converted over to a laptop as my primary machine back in January of 2000, and UUCP was an important part of that setup. Without it, I'm sure I wouldn't have been as happy with my untethered lifestyle.
The benefits of UUCP for email include:
UUCP provides an integrated solution for sending and receiving email, and is particularly well suited for systems that are not permanently connected. Before going any further, there are two drawbacks that I want to mention. These are the issues most likely to stand in the way of adopting UUCP for email.
First, ISPs rarely support UUCP. This didn't affect me, because I control my own mail server — effectively, I'm my own ISP. In many cases, users will require the mail server administrator to configure UUCP. I've included a UUCP configuration recipe with this article to get both the server and client system administrators started.
Also, UUCP does not internally support link encryption. While UUCP sessions
are authenticated with a user name and password, this data is sent in
plain text. This is fine for direct serial or modem connections, but is not
suitable for transmission over an Internet link. The example configuration
recipe includes a simple client-to-server
stunnel configuration for
encryption. See below for more details on security.
If those aren't show stoppers for you, I believe you'll find many benefits to UUCP that outweigh the drawbacks. Some of the best reasons for using UUCP to handle the transport of your email:
Jobs can be prioritized by size, so smaller emails will be sent before large attachments. This is useful when someone sends you a large attachment while you are traveling.
Partially transferred messages can be resumed where you left off. This is great for getting large attachments on slow and unreliable modem lines or low-speed wireless connections, such as CDPD or Iridium.
It can be configured to connect whenever a new email message is ready, or using scheduled polling like more traditional POP/IMAP clients.
A single connection can handle both incoming and outgoing email (as opposed to dealing with both POP and SMTP).
A bi-directional protocol sends and receives messages at the same time, fully using both channels of a connection and reducing connect times.
All connections are authenticated, removing the issues with reconfiguring mail clients for different SMTP servers, relaying restrictions, and SMTP connection blocking.
It can be configured for direct use of a modem, including dialing when jobs are ready or on a scheduled basis, and disconnection as soon as all jobs are sent. It can even be configured to send large transfers only during certain times of the day. This is perfect for long-distance calls.
UUCP was invented back in the mid 1970s by Mike Lesk as a research project at AT&T Bell Labs. It was in widespread use until the mid-1980s, most visibly for email and Usenet news. Originally designed for dedicated serial lines and modems, it has since been adapted for use over TCP/IP networks.
The heart of UUCP is the ability to copy files among machines and request remote execution of programs. In many ways, it's very similar to SSH; however, UUCP operates as a background task, where SSH is more interactive.
A command or argument may be prefixed with a system name and a "bang"
(an exclamation point:
!), in what are known as "bang paths" to refer to
different systems. For example:
uux "host1!diff host2!/etc/passwd host3!/etc/passwd"
This uses the UUCP
uux command to request that the system
host1 run the
diff command to show the differences
/etc/passwd files on systems
host3. UUCP will then negotiate getting the passwd files from
host3, sending them to
and running the job. Once completed, UUCP will email the results of the job
to the user.
In the case of an email transfer, UUCP would not email the completion results unless there is an error. UUCP considers commands that generate no output and have a successful exit code to be a success, following the "no news is good news" policy. Error output or unsuccessful exit codes will result in a status message to the user who submitted the job.
Unlike SSH, which executes its commands immediately and returns, UUCP
batches the job. Queuing a job may immediately trigger a call to the remote
machine, or the job may wait for the next scheduled call. You can control this
-r option to the
uux command. If the
connection fails, the job will be saved to run during a future call.
UUCP uses a set of configuration files to specify how to contact the different machines in its "UUCP network," the commands remote machines may execute, phone numbers and connection scripts for modem connections, etc. These files typically live in /etc/uucp. The sample recipe included with this article demonstrates setting up two systems for email delivery via UUCP.
UUCP may be used for many tasks. It's traditionally been used most for
email, Usenet news transfer, and remote file copy. Other systems such as FTP,
HTTP, SSH, and
rsync have largely taken over for file copying. Similarly,
SMTP, POP, and IMAP have largely taken over for email, but the mobile user may
find UUCP very useful.
In the context of UUCP, it's useful to think of sending an email message as a request to execute a program on a remote machine with some data for the program to consume. For an incoming message, the server wants to run a program on your workstation, which delivers the mail to your mailbox. When sending email, your workstation wants the server to attempt to deliver email to the final destination. The data associated with the program execution is the email message (and associated data).
This is how UUCP deals with email.
The base UUCP code was designed for communication over serial or modem lines. While it's been extended to support communication over network connections, there is no built-in encryption. Simple account/password authentication is used, but this is transmitted in plain text, as is the email and other data being sent.
You can encrypt the normal UUCP traffic in several different ways, though
they boil down to two different types: tunnel and VPN. Tunnels can be done
using SSH port forwarding, or via wrappers like
sslwrap. VPNs tend
to be more work to set up, but pay off the extra effort by being significantly
VPNs set up a virtual network that can give a dedicated IP address to a mobile client. This will allow the server to connect to the mobile machine when email is ready for it. A VPN setup delivers email as soon as it's ready (as long as the mobile machine is on the network), without requiring polling.
I personally use a VPN for securing my UUCP connections. In addition to the UUCP benefits, it can also secure other communications. For example, any traffic I send to my hosting facility goes over the VPN, protecting HTTP and other unencrypted communications.
The sample configuration presented here uses
stunnel, due to its
UUCP is best known for transferring email and Usenet news. Under the hood, both of these use a generic remote execution facility with some helper scripts to get the job done. UUCP is, at its heart, a mechanism for transferring data between machines and running commands.
commands option in the /etc/uucp/sys
configuration file specifies which commands the remote machine can execute.
If you wish to experiment with using UUCP for running other types of jobs, you
will have to list other commands in the sys file. The
sys configuration file restricts remote file copying as well.
UUCP's usefulness extends far beyond the realm of email. Any process that requires execution of a command on a remote machine, perhaps with data passed to or from it, may be suitable for UUCP. A major advantage is UUCP's batching, which will retry the job in the event of a network or system failure. Data is checksummed and communication failure or data corruption will not compromise the integrity of the job.
While SSH is a good system for doing remote, interactive command execution, UUCP may be better for batched and non-interactive jobs. It's certainly worth adding to your toolbox of possible network transport options.
For further reading, I recommend:
Sean Reifschneider has been working with Unix systems since the mid 1980's, and has been with tummy.com, ltd. since 1995 as a co-founder and Member of Technical Staff.
Return to ONLamp.com.
Copyright © 2009 O'Reilly Media, Inc.