Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cornell!uw-beaver!mit-eddie!killer!vector!chip
From: chip@vector.UUCP (Chip Rosenthal)
Newsgroups: comp.unix.xenix
Subject: Re: Xenix mail system
Keywords: xenix, mail
Message-ID: <698@vector.UUCP>
Date: 2 Feb 89 03:35:49 GMT
References: <417@ispi.UUCP> <295@tessera.UUCP> <694@vector.UUCP> <232@tiamat.FSC.COM> <1989Jan31.170500.19635@ateng.ateng.com>
Reply-To: chip@vector.UUCP (Chip Rosenthal)
Organization: Dallas Semiconductor
Lines: 51

In article <1989Jan31.170500.19635@ateng.ateng.com> chip@ateng.ateng.com (Chip Salzenberg) writes:
>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
>

Amazing coincidence.  About 12 hours before this message appeared, I
brought up the "deliver" program and replaced the SCO XENIX mail system
as I had proposed in the parent article.  Things work exactly as I had
hoped.  The difference between the above diagram and my original diagram
is due to "smail".  With smail 2.5, "deliver" is needed for delivery to
user mailboxes and "|command" type aliases.

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.

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.)

If anybody out there wants to try it, I setup the smail 2.5 "defs.h" file as:

	#define DELIVER		"/usr/lib/mail/deliver"
	#define LMAIL(frm,sys)	"%s -r '%s'",DELIVER,frm

Then things (Rnmail, control.c, Elm, etc.) should be setup to mail through
smail rather than /usr/bin/mail.  (The cost of not doing this is a couple
of arg parses and fork/exec's.)  I put the path "/bin/smail" into a bunch
of places, but I think I'm going to go back and bring up the "svbinmail"
program (which is distributed with smail 2.5) as "/bin/mail".

>I configure Elm to think that it has sendmail, which Smail 3 emulates.
>(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?
-- 
Chip Rosenthal     chip@vector.UUCP    |      Choke me in the shallow water
Dallas Semiconductor   214-450-5337    |         before I get too deep.