Secure Batch Email with UUCP and SSH

by Christophe Prévotaux
03/10/2005

As I started a new company, I was stranded for a few weeks (thanks to the local telco and the company registration office) with no ADSL link, no optical fiber link, and no leased line to the Internet. The only thing that remained for me to use was my trusty old USR 33.6Kbps dial-up modem and a dial-up account. We greatly needed communication, with email the most pressing need. So I sat down and started to think about what I could do to solve this problem.

I had a domain name and a dial-up link with no fixed IP. My personal machine at home plugged into a HNS Direcway Satellite Link 128/2048Kbps and had a fixed IP address. I naturally thought I could do something with all of this.

In a former life, I set up some large UUCP systems, when the Internet had not made its way into the everyday life and PPP did not exist. I took a look at age-old UUCP and decided there must be some way to run UUCP in order to attain my goals.

UUCP is the Land Rover of data communication. It is an old protocol dating back the inception of Unix, Arpanet, Usenet, and the Internet. I have personally so far used it over:

Serial links, such as dial-up modems of all speeds and types
ISDN adapters
Amateur radio links
CB radio links
Satellite links
Current loops
Tie lines
GSM
Protocols such as X.25
TCP/IP with all kind of physical transport and latency ranging from optical fiber to satellite links
VPNs (IPSEC, PPTP, OPENVPN etc.
And now, SSH

Advantages of the UUCP over SSH Solution

The POP protocol is no solution for people (like me) who want to fetch their email in a practical and efficient manner from multiple locations, be it from a dial-up account or a fixed Internet link. Thus, it seemed to me that UUCP over SSH provides great benefits for those people.

UUCP is a batched protocol; therefore, it enables you to leave your email unpolled for long periods of time without risking its loss. ETRN does not, and too many providers will garbage collect unread POP3 or IMAP email on a regular basis.

UUCP is also resilient on failed transfers and can resume unfinished transfers where they stopped. This is by design, as it originated on unreliable links. So far, I know of no other email transfer protocol capable of this feat. Other protocols will retransfer the whole shebang every time there is an error.

UUCP does not require you to have a permanent link to the Internet.

However, UUCP has one minor inconvenience: you will neither receive instant responses to your emails nor the error messages. At best, you'll receive them on the next UUCP poll your system places.

UUCP can poll at any time interval you wish, allowing you to queue mail for a whole network for as long as you wish. It can also transfer data as files--not necessarily attached to emails. You can fetch a news feed in the Usenet fashion and/or create your own newsgroups, and last but not least, execute remote commands and send yourself back the results in an email. I merely wanted my email, though.

The Real Thing

Here are the assumptions I've made for my explanation:

You have root access on two FreeBSD systems. This article assumes FreeBSD 4.10, but will work on FreeBSD 5.x if you install UUCP from the ports tree. It can also work under all versions of NetBSD and OpenBSD, with some minor modifications.
The two FreeBSD systems are respectively "client" and "server."
The "server" has a fixed IP address or a DynDNS FQDN and an always-on link to the Internet or a callback link with a fixed IP (if people still use them nowadays). The speed and latency of the links do not matter as far as the workings of the system.
UUCP polling will occur from "client" to "server" and not in the opposite way around. It would be trivial to do a server-to-server setup if both sides have fixed IP addresses and always-on Internet links, but that is outside of the scope of this article.
Both machines must have OpenSSH installed and sshd running. Fortunately, this is the default under FreeBSD.
I'll use Postfix -> 2.1. To find out which version you use, type postfconf | grep mail_version.

The networking setup calls:

The UUCP server "server" with a FQDN address of server.domain.tld and a UUCP name of server.
The UUCP client "client" with a FQDN address of client.domain.tld and its UUCP name client.
The email domain name to host on "client" is hosted-domain.tld.
The local domain name of the "client" is localdomain.local.

Client Setup

To install Postfix on the client, install it from the /usr/ports/mail/postfix/ FreeBSD port. Edit /usr/local/etc/posftix/main.cf to resemble the following:

myhostname           = machine.localdomain.local
myorigin             = $mydomain
inet_interfaces      = $myhostname, localhost
mydestination        = $myhostname, localhost.$mydomain, $mydomain
local_recipient_maps = unix:passwd.byname $alias_maps
mynetworks           = $config_directory/mynetworks
relay_domains        = $config_directory/relay_domains
transport_maps       = hash:$config_directory/transport
alias_maps           = hash:$config_directory/aliases
alias_database       = hash:/etc/aliases

This sets up the Postfix environment. You may already have done this when you installed Postfix for other usage.

Edit /usr/local/etc/posftix/main.cf to add:

disable_dns_lookups=yes

This tells Postfix not to try resolving names through DNS when sending email to the server, because that would bypass the UUCP connection to try sending through SMTP instead.

Create a file called /etc/postfix/transport, containing the following:

################### this is POSTFIX 'transport' file #############################
# Every time this file is modified it need a 'postmap' and postfix needs a reload#
##################################################################################

hosted-domain.tld      :         # this domain emails are delivered locally
.hosted-domain.tld     :         # this domain emails are delivered locally
                                 # in case you need subdomains or machine routing
*                  uucp:server   # All other emails get transported by UUCP

This change introduces a new transport type, namely UUCP, on the last line of the file. It tells Postfix that any email that is not something@hosted-domain.tld or something@<subdomain>.hosted-domain.tld needs to use the UUCP transport. As for hosted-domain.tld and .hosted-domain.tld, their respective transport is :, which tells Postfix to deliver email for these domains locally.

Now tell Postfix about these changes by issuing the command:

$ postmap /usr/local/etc/postfix/transport && postfix reload

Create a file called /usr/local/etc/postfix/virtual, containing:

#################### This is POSTFIX 'virtual' file ##############################
# Every time this file is modified it need a 'postmap' and postfix needs a reload#
##################################################################################

########### hosted-domain.tld virtual users table ##############
postmaster@hosted-domain.tld      postmaster@localdomain.local
virtualuser1@hosted-domain.tld    localuser1@localdomain.local

Tell Postfix about these changes with the command:

$ postmap /usr/local/etc/postfix/virtual && postfix reload

Create a file called /usr/local/etc/postfix/mynetworks, containing:

#################### This is POSTFIX 'mynetworks' file ###########################
# Every time this file is modified it need a 'postmap' and postfix needs a reload#
##################################################################################

xxx.xxx.xxx.xxx/xx      OK      # where xxx.xxx.xxx.xxx is your local private IP address
                                # and /xx is the mask for your networks for exple
                                # 192.168.1.1/24
xxx.xxx.xxx.xxx         OK      # single host for exemple 192.168.2.1
127.0.0.0/8             OK      # this is localhost interface(s)

This file lists which IP addresses can send email through this machine using SMTP to the client just before being queued by UUCP for sending to the UUCP server.

You may also want to modify the canonical file in order to rewrite emails sent by the local daemon or users. To do this, modify the /usr/local/postfix/canonical file with something like this:

#################" This is POSTFIX 'canonical' file ##############################
# Every time this file is modified it need a 'postmap' and postfix needs a reload#
##################################################################################

@localdomain.local       @hosted-domain.tld

Again, tell Postfix about these changes:

$ postfix stop && postfix start

In case you modified aliases, it's always a good idea also to run newaliases and then postfix reload. You can also (this is the way I do things) make a shell script that rebuilds all of the necessary files and reloads or restart Postfix when you change a file. For example, here is the very simple script I made:

#! /bin/sh

postmap virtual
postmap transport
postmap mynetworks
postmap relays_domains
postmap access
postmap canonical
newaliases
postfix reload

Use postcheck to check that your configuration is valid.

Pages: 1, 2