UUCP-Over-TCP: Testing & Reliability

Copyright, License, and Disclaimer

Configuring UUCP-over-TCP: A Practical, Skeletal "How To"
Copyright (C) 1999-2004 James S. Seymour 

This information is free; you can redistribute it and/or modify it
under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 2 of the License, or
(at your option) any later version.

This work is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
GNU General Public License for more details.

You may have received a copy of the GNU General Public License
along with this work; if not, write to the Free Software
Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.

An on-line copy of the GNU General Public License can be found
here.

UUCP-Over-TCP: Testing

In order to simulate UUCP-over-TCP in a dialup scenario I also tried
both 1) removing the destination machine's host entry from /etc/hosts
and 2) disconnecting the host machine from the network.  (See notes
below.)

In both cases: the sending machine would try to make the UUCP connection,
fail, and queue the mail up for later attempts.  (See notes below.)

In both cases: after restoring the host entry or re-connecting the
destination machine, a subsequent manually-initiated "uutry"
(or uucico -S ) would then make the connection, and deliver and
pick up queued email.  (See notes below.)


Notes:

    The Linux laptop didn't recover from the "disconnect test" as
    quickly as did the Sun box.  But it did recover.  This may have
    been an artifact of it having been completely disconnected from
    the network for several minutes.

    Queuing needs to be tried with destination hosts not on the local
    network.  (I.e.: PPP connection is down.)

    Queuing from  a client machine that's running DNS will have to
    wait until a "live" experiment can be conducted.  If such a
    machine had a "forwarders" entry pointing to an inaccessible name
    server, less robust versions of "named" might choke.  (I've
    seen it happen.  Usually requires that "named" be bounced.)

    A client machine with an /etc/resolv.conf entry pointing to
    a non-existent "nameserver" doesn't *appear* to create a
    problem.

    None of these "unreachable host" issues affect a "server", since
    a server never initiates a UUCP connection.

UUCP-Over-TCP: Reliability

It has been noted that some UUCP implementations may not be robust
in the face of exception conditions.  For example: filesystem full
or quota reached/exceeded.  When email is delivered via UUCP, a
utility named "rmail" is normally executed on UUCP's behalf to "move"
the email file(s) from the incoming UUCP queue to the destination
system's mail queue.  What is supposed to happen, if rmail fails,
is that the error condition is propagated back to the sender and
the sender re-tries the entire operation later.  It has been
reported that this mechanism doesn't always work as it's supposed to.

Comments or Questions?

Created: 31 Jan, 1999 / Last updated: 12 Oct, 1999