Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watnot!watmath!clyde!rutgers!husc6!seismo!mcvax!jack
From: jack@mcvax.UUCP
Newsgroups: comp.os.minix,comp.mail.uucp
Subject: Re: uucp source copyright status - IMPORTANT
Message-ID: <7333@boring.mcvax.cwi.nl>
Date: Mon, 6-Apr-87 06:14:24 EST
Article-I.D.: boring.7333
Posted: Mon Apr  6 06:14:24 1987
Date-Received: Sat, 11-Apr-87 04:08:31 EST
References: <1643@ttrdc.UUCP> <692@atari.UUCP>
Reply-To: jack@boring.UUCP (Jack Jansen)
Distribution: comp.os.minix
Organization: AMOEBA project, CWI, Amsterdam
Lines: 52
Xref: utgpu comp.os.minix:528 comp.mail.uucp:415

In article <692@atari.UUCP> apratt@atari.UUCP (Allan Pratt) writes:
>in article <1643@ttrdc.UUCP>, levy@ttrdc.UUCP (Daniel R. Levy) says:
>> 
>> Can Kermit work auto-dialers and negotiate the login protocol?  Also--does
>> Kermit negotiate bad-data retry on a smaller scale than whole files?  Just
>> curious (I'm not a Kermit guru as you can plainly see).
>
>Kermit would not be called upon to negotiate logins: what people are
>talking about is placing Kermit at the file-transfer level rather
>than uucp.  The login protocol layer would be the same in both cases.

Well, no. I think I started this discussion, and my idea was to replace
uucp *totally*. Or, rather than replacing it, providing an alternative.

The point I tried to make in the original article is that implementing uucp
on every other micro is a lot of work, while kermit is available, and
quite a few kermits will already do things like auto-dailing and uucp-like
scripts.

So, the only thing you have to do is write two shell scripts, one to deposit
outgoing mail into a spooling area, and another to empty the incoming
spool area. Of course, on a big timesharing machine these programs will
probably be 1000+ lines C programs, checking all sorts of access
privileges, etc. but on your own micro, some simple shellscripts will be
good enough.
Now, you make sure that once in a while kermit is started, dials to the
remote site, sends all files in the outgoing spool area to the remote side,
grabs all files sitting in the remote outgoing spool area and deposits them
in your incoming spool area, and start the second shell script.

The files you transfer could be the client side of an SMTP conversation, 
for instance. As an example, for a micro with only one connection, the following
script would be good enough for /bin/rmail:
(
	echo 'HELO <mysys.mydomain>'
	echo "MAIL FROM: <$USER@mysys.mydomain>"
	for i
	do
	    echo "RCPT TO: <$i>"
	done
	echo "DATA"
	cat
	echo "QUIT"
) > /usr/spool/outgoing/tmp.$$
mv tmp.$$ msg.$$

Voila, you can send mail from your micro. Granted, a script for incoming mail
is slightly more complex, but still less that 100 lines.

-- 
	Jack Jansen, jack@cwi.nl (or jack@mcvax.uucp)
	The shell is my oyster.