dan@asihub.UUCP (Dan O'Neill) (08/10/89)
This is a sort of novice question -
In the default /etc/sendmail.cf as provided by DEC, there is a mailer
defined for "uucpd" mail. What is uucpd? Would it allow users to
uucp files from their workstation to other sites without being on the
machine with the modems connected?
Just curious. Thanks.
--
Dan O'Neill dan@asihub.uucp {uunet|ncr-sd}!asihub!dan
Automated Systems, Inc. San Diego R&Dgrr@cbmvax.UUCP (George Robbins) (08/10/89)
In article <119@asihub.UUCP> dan@asihub.UUCP (Dan O'Neill) writes: > > This is a sort of novice question - > > In the default /etc/sendmail.cf as provided by DEC, there is a mailer > defined for "uucpd" mail. What is uucpd? Would it allow users to > uucp files from their workstation to other sites without being on the > machine with the modems connected? > > Just curious. Thanks. Look; there are rules against posting *hard* questions here, especially sendmail questions that always cause severe headaches while resolving to null... 8-) 8-) Really, just kidding, but this one was a pain... It turns out that this mailer definition is pretty much what the comments suggest. Normaly, if you send mail thru a TCP (i.e. SMTP) connection, the mail headers are improved according to internet style (i. e. domain) rules, while mail sent across a uucp connection is improved according to different rules appropriate to a source routed network. If you change the rules to invoke uucptcp mailer, then it will use the uucp header improvment rules, but use TCP to actually tranport the mail. This allows you to pass mail thru a TCP link in a way that should be more transparent to "dumb" uucp systems upstream/downstream of the TCP link. As the sample sendmail.cf file is setup, this mailer is never invoked. Depending on your needs, you could either subtitute it for the normal uucp mailer or define a class of hosts/networks that would resolve to using this mailer. Back to the original qustion(s), this doesn't allow file transfers or general purpose uucp. That is handled by a combination of programs not distributed with Ultrix. Normally to support uucp over a TCP network, you have daemon (uucpd) that is either spawned from inetd or or free running. The remote system establishes a TCP (socket) connection to this daemon, which does a "pseudo-login" verification, and then spawns off a copy of uucico which communes with the remote system via the TCP linkage. Once started, operation is fairly normal, except I/O is taking place over this TCP connection instead of a serial line... Now why Ultrix doesn't suppport this is a good question, perhaps the simplest answer is that DEC makes no commitment to keep up with what Berkeley is doing, Ultrix being defined as 4.2 BSD + NFS + what DEC decides to add. You lose on some details, gain on others. To make uucp over TCP work, you need to following components: Receiving end: 1) A functional uucpd daemon - this is redistributable Berkeley source 2) A uucico smart enough not to try to do stty type ioctl calls on a TCP/socket connection. Sending end: 1) A uucico that has a "dialer" section that knows how to establish a TCP/socket connection to a remote uucpd deamon. There are also some special "protocols" that can be used over a "reliable" TCP link to gain speed/efficiency of the normal serial line "g" protocol, however "g" works fine over TCP connections... Needless to say, a version of uucico that does all these things is present in the 4.3 BSD/tahoe sources, however it is not redistributable, and it does not support the few Ultrix'isms like shared dial-in/dial-out lines, modemcap and and spool directory/system. These wouldn't be hard to add. -- George Robbins - now working for, uucp: {uunet|pyramid|rutgers}!cbmvax!grr but no way officially representing arpa: cbmvax!grr@uunet.uu.net Commodore, Engineering Department fone: 215-431-9255 (only by moonlite)