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 Keywords: xenix, mail Message-ID: <1989Feb11.164941.11283@ateng.ateng.com> Date: 11 Feb 89 21:49:40 GMT References: <417@ispi.UUCP> <295@tessera.UUCP> <694@vector.UUCP> <232@tiamat.FSC.COM> <1989Jan31.170500.19635@ateng.ateng.com> <698@vector.UUCP> Organization: A T Engineering, Tampa, FL Lines: 52 According to chip@vector.UUCP (Chip Rosenthal): >With smail 2.5, "deliver" is needed for delivery to >user mailboxes and "|command" type aliases. The need for "|command" processing -- with security! -- was my original excuse to begin writing deliver. The project, well, grew from there. >The result is a very lean and flexible mail system. I'm very happy with >it. Yes, micnet has been lost -- but no great loss as far as I'm concerned. >However, you could probably hack "deliver" to recognize micnet sites and >feed the message to "/usr/lib/mail/mail.mn". I did a similar thing: I >hacked my deliver sys file to recognize "user%site" addresses for internal >machines on our ethernet. An interesting approach. It could work for Micnet too. In my previous article I described another approach, one driven by username instead of by address syntax. Of course, the approaches could be combined. >It looks to me when the really-it-is-going-to-be-here-someday version >of smail is out, "deliver" could be dropped from its primary position >in the mail system. (Just as my changes dropped /usr/bin/mail -- but >left it available for use.) The only thing left for deliver to do in my mail system is to (1) vary behavior based on message *content* (as opposed to destination address), and (2) modify message contents, as when forwarding. Smail 3 does the rest. >>(One of the ten (!) links to /usr/bin/smail is /usr/lib/sendmail.) >OK ... /bin/smail, /bin/rmail, /usr/lib/sendmail ... >What are the rest? Here they are, in /usr/local/bin: -r-sr-xr-t 10 root 265702 Jan 25 11:30 mailq -r-sr-xr-t 10 root 265702 Jan 25 11:30 optto -r-sr-xr-t 10 root 265702 Jan 25 11:30 pathto -r-sr-xr-t 10 root 265702 Jan 25 11:30 rsmtp -r-sr-xr-t 10 root 265702 Jan 25 11:30 runq -r-sr-xr-t 10 root 265702 Jan 25 11:30 smail -r-sr-xr-t 10 root 265702 Jan 25 11:30 uupath Of course, /usr/local/bin/smail is redundant, given /usr/bin/smail, but it doesn't hurt anything. The "mailq" and "runq" links are for mail spooling, a feature which I won't need until I do batch SMTP over UUCP -- that will be a real time-saver for uunet, since I'll need to send only a single file for each batch of messages. The "rmstp" link is for when other people send BSMTP to me. The other links provide utility functions. Smail 3 is great... worth the wait, without a doubt. -- Chip Salzenberg or A T Engineering Me? Speak for my company? Surely you jest! "It's no good. They're tapping the lines."