Managing sendmail in a Mixed UUCP/PPP Environment
Doing business over the Internet is common practice
today, and electronic
mail is the most common communication method. It is
thus very important
that email arrive at the destination quickly and reliably,
means possible. This article describes a setup for an
system that automatically chooses between SMTP or UUCP
on which is available at the time of sending.
Why Mix UUCP and Dialup PPP?
Why bother setting up sendmail for a mixed UUCP and
PPP environment? Configuring sendmail is difficult as
even with a fixed delivery policy. There are a few reasons
My organization, Le Reseau, operates a dialup PPP connection
Internet. This connection is used for downloading software
and accessing the booming number of Web services. Apart
users may also send mail directly to the addressee by
SMTP reduces the number of intermediate hops a message
must go through
before reaching its destination; in fact, most of the
time the message
goes directly to the destination via SMTP. Direct delivery
to message privacy. We do a lot of business via the
Internet, so a
lot of confidential information is exchanged through
email, such as
credit card numbers. A direct, interactive connection
to the destination
meansthat this confidential information can be encrypted.
no store-and-forward of the data or the crypting keys,
so there is
less chance of losing your confidential information.
Because our dialup PPP connection is established by
hand, we have
to have some sort of fallback delivery for normal mail
when our Internet
connection is down. We chose UUCP for this because it
mail and sends it out at regular intervals. Combining
lets us send mail through SMTP when the connection is
up, and through
UUCP when the connection is down. This is all done transparently
Another reason for this combined setup is the emerging
use of portable
computers. By equipping a portable computer with some
version of UNIX,
we enable people to travel and carry their work with
are not connected to any network, but with UUCP, they
may still send
electronic mail. UUCP batches and stores their mail
until they can
dial out and send the batch. Once back in the office,
connect the portable to the network and send all their
The Current Setup
The situation in the Netherlands regarding service providers
to that in the United States. A number of providers
handle the routing
of TCP/IP packets and store-and-forward mail and news
for you. Most
of them offer some sort of dialup SLIP or PPP, but some
a UUCP service.
At our end, we established a mail/news gateway using
on the net. We implemented our gateway using Linux,
Taylor UUCP, and other publicly available packages.
This setup's advantage
is source code availability. Whenever you need to adapt
you can do it yourself. Bug fixes are also available
the vast Internet community. Our experiences with this
kind of software
are very positive.
However the techniques described in this article are
not limited to
net-available, source code software. Anyone running
UNIX with some
sort of UUCP and dialup Internet connection can apply
The key factor in this setup is sendmail 8.6.9, which
be built for many UNIX platforms. By applying the different
for sendmail, you can also use this setup on SunOS,
V, and other UNIX flavors.
How Does sendmail Work?
As explained in the sendmail sidebar, sendmail does
not do any delivering. That task is delegated to one
of the available
delivery agents. sendmail determines what agent to select
and calls it with the appropriate interface. It does
this both for
local delivery of incoming mail, and for remote delivery
sendmail's input derives from a user entering mail on
local system or from the outside world. A user runs
a special mail
program, such as ELM, to enter the mail message. The
supplies the necessary message headers without any intervention
the user other than entering the message body and the
name or address. After completing the message, the mailer
to sendmail for further processing.
Remote mail is handled very much the same way. For instance,
message is offered through SMTP, it is sent to the sendmail
daemon running on the system. Through a special dialog
is offered to the daemon, which then processes it. With
is no dialog, but the complete message is offered to
through an intermediate mailer. This transforms the
message into a
Delivery Agents: SMTP vs UUCP
The bottom part of sendmail is the set of available
agents. sendmail itself contains a delivery agent for
mail through SMTP. This delivery agent sends mail across
This agent is also used to receive mail when sendmail
as a daemon. When running as a daemon, sendmail listens
TCP port 25 for incoming mail. If a foreign host wants
to send mail,
it connects to our machine's port 25. As soon as a connection
a dialog starts to exchange mail. sendmail uses this
to send outgoing mail, so sendmail must contain this
UUCP's delivery agent, uux, is not built-in: UUCP must
it with the appropriate parameters. uux invokes the
program, which communicates UUCP and sendmail.
SMTP's delivery agents deliver mail directly to the
to the destination's mail handling host. UUCP's delivery
a store-and-forward mechanism to send the mail. First
the mail is
batched on the local host. At regular intervals, determined
system administrator on the local host, the mail is
sent to an upstream
host, which might use SMTP or UUCP to forward the message.
repeats until the message reaches its destination.
Specifying a delivery agent can be done from the master
file, which is the input for the M4 macro processor.
have been predefined and can be selected with the MAILER()
function. You can also define your own delivery agent.
You must then
define the different fields of the mailer specification
The example in Figure 1 uses the predefined SMTP and
For local delivery the procmail system is used; this
automatic mail processing depending on the contents
of the message.
After processing the master configuration file, M4 generates
file. sendmail uses sendmail.cf to specify the configuration.
In Figure 2, the selected local delivery agent is procmail.
The program delivery agent (Mprog) is a bonus generated
the MAILER(local) function. sendmail uses this mailer
when it sends mail to a program. A well-known example
would be delivering
mail to a pipe specified in the .forward file in the
Each mailer specification contains a number of fields.
field specifies the name of the delivery agent. Each
should at least contain a local and a prog delivery
agent. The P field specifies the path to the agent's
[IPC] refers to the built-in SMTP mailer. The F field
specifies the capabilities of the agent, and sendmail
this field to determine what the agent can do. The S=
defines the rule set used to rewrite the sender's address
so the agent
can handle it. The R= field defines the rule set used
the recipient's address.
These delivery agents are generic and should not be
changed. The decision
on how to deliver a message happens during another step
of the delivery
Rule Sets, or, Which Way to Go?
A sendmail configuration file consists of many rule
subsets, but an intimate knowledge of every rule set
is not necessary.
The most important ones are rule sets 0, 1, 2, 3, and
4. These sets
are interrelated, as shown in Figure 3.
Rule set 0 selects a delivery agent based on the recipient's
This rule set produces three pieces of information:
The delivery agent's name.
The receiving host's name.
The recipient's name.
The delivery agent's name must be one of the agents
specified in the
Magent rules (M field). The receiving host's name
does not necessarily have to match the name of the host
to which the
message is sent. In UUCP, for instance, the receiving
is not the same as the name of the UUCP hub which will
the message. This is the rule set I adapt to suit my
Rule sets 1, 2, and 4 rewrite the sender's and recipient's
so it can be handled by sendmail and the delivery agent.
are pre-cooked by rule set 3. Rule 3 splits addresses
chunks, strips all comments from the address specification,
the different parts in the proper place for processing
by rules 1
Customizing Rule 0
Figure 4 contains the customized settings for rule set
0. This customization
is divided into two parts. The first one expands the
local part of
the rule set. This part is typically used for anything
local delivery. The first three rules come directly
from the sendmail
configuration. They primarily detect special addressing
to the local domain.
I added a new fourth rule because, apart from our local
we are part of another domain, xs4all.nl. xs4all.nl
is the domainname of one of our providers, and at the
same time it
is an alias of its dial-in host. We have therefore added
of the xs4all.nl host to our /etc/host table. That
way we can always access it by this name, despite the
state of our
nameserver. The complication this presents is that sendmail
is always able to resolve the name xs4all and will decide
to contact this host using SMTP. This is often not the
case, so mail
to this host could get stuck in the mail queue for a
long time. This
fourth rule forces all mail going to the xs4all domain
instead go through our UUCP channel, thus guaranteeing
delivery. Using this method might not be ideal, but
it always delivers the mail with a maximum delay of
one hour, our
UUCP polling interval.
The second part of the customization applies to remote
It rewrites remote addresses and decides how to contact
host. All hosts on the local network are handled by
the first two
rules. If the address contains our local domain name,
mail is delivered
through SMTP to the host on the network. The same goes
for mail addressed
to the domain itself, which is sent to our mail gateway,
When mail is addressed to a nonlocal host, the last
four rules activate.
The decision whether we can contact this remote host
or not is taken
by the name resolver. Whenever we can resolve the MX
eXchange) name for the destination, we decide it is
to contact the host through SMTP. The destination's
might be the destination itself, or the address of a
host that handles
all SMTP traffic for the destination. This setup has
for our nameserver and dialup connection.
Exactly how do we use the nameserver for this? The trick
lies in the
R$* << @ $* $~P >> $* $: $1 << @ $[ $2 $3 $: $2
$3.NOTFOUND $] >> $4
We try to make the destination host canonical through
the special symbol $~P. This queries the nameserver.
nameserver can resolve the hostname, $~P will be replaced
by the $2 $3 expression before the $: within the 
expression on the right-hand side of the rule. If the
resolve the name, $~P will be replaced by the expression
the $: within the  expression, which appends the
nonexisting domain NOTFOUND to the address. To prevent
rule from looping, the $: that begins the right-hand
evaluates the rule only once.
The next rule in this part is used as a safety net.
It handles all
mail addressed to unknown hosts within the local domain.
is rerouted to the local delivery agent, preventing
addressed mail from getting lost.
The last two rules select the appropriate delivery agent,
the presence of the NOTFOUND pseudodomain. If NOTFOUND
is present, the UUCP delivery agent is chosen and the
mail is forwarded
to the upstream UUCP relay. If the pseudodomain is not
gets directly sent to the destination's MX address.
Relationship between BIND and sendmail
Using the nameserver to decide whether we can contact
directly or not has some implications for the nameserver's
A number of problems can occur and, according to Murphy,
The nameserver caches any information it has retrieved.
that whenever mail is sent to an address still in the
would decide that it should use the SMTP delivery whether
or not our
Internet link is up. The nameserver supplies the address
cache despite the state of the Internet link. If the
link is down,
sendmail times out on the delivery, and the mail sticks
in the mail
queue until the queue is rerun when the Internet link
A second problem relates to the nameserver query itself.
If the link
is down and the destination address is not present in
cache, a query for this address times out after about
While querying the nameserver, sendmail would not be
do anything else. This causes problems when we want
to serve our mailing
list. The mail gateway also serves our Dutch Linux mailing
list of about 100 addresses. If each addressee on the
takes 30 seconds to process, processing the complete
list takes almost
one hour. To handle this, it would be necessary to reconfigure
nameserver so that it quickly times out when the Internet
down and takes its normal time to resolve whenever the
link is up.
The first problem, starting and stopping the nameserver
link goes up or down, is the more difficult. The second
be solved by using two different nameserver configurations:
an established Internet link, and one for a standalone
This technique is described in the sidebar on BIND.
But how can we start and stop the nameserver? This is
where PPP comes
to the rescue.
Establishing and Tearing Down the Internet Link
Our Internet link is based on PPP. We use an implementation
that lets us execute a special script whenever the link
When we tear down the link, we execute another script.
We use these
two special scripts to reconfigure the nameserver.
The first script, pppconnect (Listing 1), uses the pppchat
program to talk to the modem. This pppchat program is
similar to the expect-send strings used to configure
UUCP. A pppchat
script for communication with the modem appears in Figure
The IP addresses of the local and remote hosts are dynamic
while establishing the connection. The script sets the
to the remote host so all Internet traffic is sent to
this host, then
stores a few more options for the PPP link in the default
file (Figure 5). These options tell PPP that the modem
should be locked
to prevent UUCP from dialing out, and to use the hardware
To establish the connection, I call pppconnect manually.
puts itself in the background and calls pppchat. Once
connection is established, the PPP daemon calls the
script (Listing 2). This script is executed whenever
the IP part of
the PPP link is started.
The lines related to mirroring are of no importance
to this article,
but the line
/etc/ns start net
is. This line restarts the nameserver in Internet mode
(see the sidebar on BIND).
To tear down the Internet link, the script sends a HUP
to the PPP daemon. The daemon then executes the ip-down
(Listing 3) and hangs up the modem.
/etc/ns start minimal
restarts the nameserver in local (minimal) mode. Any
query to the nameserver for a remote host quickly times
delaying mailing list processing.
Of course, there is room for further improvement. The
whether a dial-on-demand PPP would solve the problem.
is an experimental implementation of a dial-on-demand
daemon for Linux.
This daemon can be configured to dial the provider whenever
to the Internet is desired. The problem with this is
that any nameserver
query will then result in a call to the provider. This
can mean that
the connection is alive during the greater part of the
in a huge phone bill.
Another improvement might be the requeueing of mail.
If many messages
are stored in the UUCP mail queue, it might be best
to send these
when the Internet connection is established.
A last improvement might be another configuration of
Restarting the nameserver each time a connection is
torn down is not a very elegant solution.
This setup works! For more than half a year, all mail
has been sent
either by SMTP or UUCP. By tweaking the sendmail configuration
file, you can change the behavior of this program to
suit your needs.
Good documentation is essential in this process.
About the Author
Arthur Donkers graduated from the Delft Universiy of
with a degree in Electrical Engineering, with a major
Architecture. He has since worked for a number of major
in the Netherlands, specializing in projects relating
to data communications,
especially the integration of multi-vendor network systems.
four years he worked as an independent consultant for
his own company,
Le Reseau (The Network). He sees electronic communication
as a means of connecting people quickly and reliably
and software boundaries and, most important of all,