Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1+some 2/3/84; site dual.UUCP
Path: utzoo!linus!decvax!decwrl!dual!fair
From: fair@dual.UUCP (Erik E. Fair)
Newsgroups: net.bugs.uucp,net.mail
Subject: dual -> ihnp4 UUCP lossage on 10/17
Message-ID: <845@dual.UUCP>
Date: Thu, 18-Oct-84 16:54:56 EDT
Article-I.D.: dual.845
Posted: Thu Oct 18 16:54:56 1984
Date-Received: Fri, 19-Oct-84 06:48:16 EDT
Distribution: net
Organization: Dual Systems, Berkeley, CA
Lines: 48

Last night when ihnp4 called us, we had 17 messages queued for them.
Something was wrong with the UUCP spool directory on ihnp4 (this
surmised from the LOGFILE and the nasty notes I got back from UUCP) and
ihnp4 rejected all attempts to send it stuff with ``access to remote
path/file denied.'' As a result, all 17 messages were dumped down the
proverbial bit bucket.  While the problem appears to have been fixed
relatively quickly (they called us again this morning, and all went
well; a tribute to Gary Murakami and the other people who run ihnp4),
17 people somewhere are going to wonder who dropped their mail on the
floor.

This is one of the reasons that UUCP is considered ``unreliable.''
When something goes wrong in the transport, there is no way to get
back to the original requestor if the transaction was mail, because
the mail program is not an active part of the actual transport.

Now for Peter Honeyman: since ihnp4 is running honey danber UUCP, the
question comes up about the UUCP spool directory and what UUCP should do
when it isn't accessable for some reason. Currently, when you try and
initiate a transfer, UUCP will check the path to see if it can write on
it (both through access(2) and the USERFILE). If the path is
inaccessable, UUCP will send an error code back to the requesting
remote, which will in turn delete the request and mail a note back to
who it thinks is the requestor that the transfer failed. For actual
``uucp'' requests, this is reasonable. For mail (uux), it sucks.

My inclination is to say that if the requesting side gets back an error
on path/file access, and the destination was the remote system's UUCP
spool directory, UUCP should:

	1) notify ``uucp'' by mail that a request failed.
		(i.e. put a human being in the loop)

	2) Keep the request around, on the assumption that the remote
		has a temporary problem (consequently trying again later)

Given this view of things, clearly my System V UUCP was at fault (for
deleting the requests). I'm curious though, what honey danber would do
if the positions had been reversed?

	Erik E. Fair	ucbvax!fair	fair@ucb-arpa.ARPA

	dual!fair@BERKELEY.ARPA
	{ihnp4,ucbvax,hplabs,decwrl,cbosgd,sun,nsc,apple,pyramid}!dual!fair
	Dual Systems Corporation, Berkeley, California

P.S.	This can also be considered notice that other systems might have
	had problems with UUCP to ihnp4 last night.