|UUCP-Over-TCP: Testing & Reliability|
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.
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.
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|