Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cornell!batcomputer!itsgw!steinmetz!uunet!ateng!chip From: chip@ateng.ateng.com (Chip Salzenberg) Newsgroups: comp.unix.xenix Subject: Re: Xenix mail system Message-ID: <1989Feb11.162631.11083@ateng.ateng.com> Date: 11 Feb 89 21:26:30 GMT References: <417@ispi.UUCP> <132500003@cpe> Organization: A T Engineering, Tampa, FL Lines: 76 According to tif@cpe.UUCP: >According to chip@ateng.uucp (Chip Salzenberg): >>In article <694@vector.UUCP>, chip@vector.UUCP (Chip Rosenthal) writes: >>> Hey Chip ... what does your mail setup look like? >> >>/usr/bin/mail -----> execm ---. >> | >> Elm -----. | .----------> (user mailboxes) >> | v | >> uuxqt -----+-----> smail,rmail -----+----------> uux >> | | >> recmail -----' `----------> deliver > >Hey Chip ... (Sarcasm for humor only, i.e. :-) ) >(Firstly, I'm not familiar with the features of deliver) >Unless deliver is real smart, that won't cover ALL the Xenix options. [mention of Micnet deleted] Deliver can handle just about anything. This is because its "delivery files" are shell scripts. Therefore, anything you can express in a shell script can be used to control mail messages. For example, Micnet could be handled by the system delivery file. Assume that "fred" and "joe" are remote users on machines "fredmach" and "joemach" respectively: # system delivery file # Use Micnet for fred and joe for u do machine= case "$u" in fred) machine=fredmach ;; joe) machine=joemach ;; *) echo $u; continue ;; esac if [ "$machine" ] then cat $HEADER $BODY | remote - $machine rmail $u fi done The Micnet-only machines would have a similar delivery file, but with an additional case "*!*" to handle UUCP addresses. Incidentally, the hostname is available to delivery files in the environment variable $HOST (or is it $HOSTNAME?), so all machines can have identical system delivery files with behavior that varies according to the host name. >Anyway, for the micnet only machine, the right hand side of the diagram, >in my system, is replaced by the original /usr/lib/mail/execmail (moved >to execmail.x). It has the smarts to find the real uucp machine and send >the mail there (it actually goes through smail again on that machine). The >philosophy was to leave as much of the existing system intact as possible. Well, that's fine. It is not, however, necessary. Deliver is flexible enough to handle a mixed Micnet/UUCP network. Combined with Smail 3 it's just about all I can imagine needing, short of mind-reading. >Now, did I just waste my time discussing a problem that deliver solves? No waste. It's an interesting problem. Perhaps I can come up with a more elegant solution if I think about it. One thing that will help is my plan to add a second system delivery file, one that is executed after the user delivery files but before actual delivery takes place. This would permit user delivery files to output plain addresses, and then have them processed just like incoming addresses. Also, as separate programs, I'm planning to write an alias file lookup program and a message header parser. Currently I make do with grep, but it's not sufficient to handle multi-line header fields. Such is life in the big city. -- Chip Salzenberg or A T Engineering Me? Speak for my company? Surely you jest! "It's no good. They're tapping the lines."