Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!aplcen!wb3ffv!ka3ovk!raysnec!shwake
From: shwake@raysnec.UUCP (Ray Shwake)
Newsgroups: comp.unix.xenix
Subject: Re: Trouble with Xenix rmail.
Summary: Yet another approach
Message-ID: <53@raysnec.UUCP>
Date: 6 Jun 90 16:32:03 GMT
References: <54@aos.UUCP> <1990Jun3..23459@rdk386.uucp> <382@wells.UUCP> <1298@chinacat.Unicom.COM>
Reply-To: shwake@raysnec.UUCP (Ray Shwake)
Distribution: na
Organization: R|S|X Technical Services
Lines: 19

In article <1298@chinacat.Unicom.COM> chip@chinacat.Unicom.COM (Chip Rosenthal) writes:
>
>There are a couple of approaches to the installation.  Chip Salzenberg
>introduces an execmail replacement which just passes off the message to
>smail.  I prefer to hack smail to understand the execmail flags, and thus
>link /bin/smail to /usr/lib/mail/execmail.  The advantage of my approach
>is that it removes one level of complexity (i.e. a fork/exec) from an
>already convoluted system.  The disadvantage is that it has never been
>tested with Micnet.

Our own installations are a bit simpler than many others on the Net. Our
deliveries are to local users and users linked through UUCP. That being
the case, we can support an even simpler system where rmail is replaced by
an alternative version that recognizes user alias and pathalias lists,
and does its OWN delivery. A number of tests show efficiency to be almost
an order of magnitude better than smail for typical messages.

Since we offer our own user interface to mail, we're able to completely
remove the mail package provided under SCO Xenix.