Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!uflorida!gatech!mcdchg!ddsw1!karl
From: karl@ddsw1.MCS.COM (Karl Denninger)
Newsgroups: comp.unix.xenix
Subject: Re: Xenix mail system
Summary: Smail3 might, with a little hacking, do this.
Message-ID: <2842@ddsw1.MCS.COM>
Date: 2 Feb 89 17:34:45 GMT
References: <417@ispi.UUCP> <132500003@cpe>
Reply-To: karl@ddsw1.UUCP (Karl Denninger)
Organization: Macro Computer Solutions, Inc., Mundelein, IL
Lines: 33

In article <132500003@cpe> tif@cpe.UUCP writes:
>
>Gee, it's still growing, I better send it before it gets any longer ...

>Both of us (remember us two Micnet fans) came up with a two part solution.
>(Honestly, I can't remember right now why I needed a two part solution.)
>One for a micnet only machine, and one for a micnet/uucp machine.
....
>It's not as elegant as I'd like but it works.  A single solution that
>is no less efficient than the original XENIX mail system would be best.
>Any better ideas?  

Well, having smail3 here, and LOVING it, I can say this:

We modified it to handle a completely different transport mechanism AND
routing requirements in about two hours.  It drops right in place of
"execmail" (I linked it to /bin/rmail & /bin/smail too for good measure).

Now, if someone knows how micnet works internally (ie: what it delivers mail
to for resolution, and how a process would go about setting up or queueing
outgoing requests for it) then I'll just have to hack up another director
entry for smail3 to handle that as well.  Anyone want to spill the beans to
my mailbox?

If so, everyone can have a fully integrated solution to the problem.

As it is, I've got everything except MICNET working great; micnet we don't
use here internally...

--
Karl Denninger (karl@ddsw1.MCS.COM, ddsw1!karl)
Data: [+1 312 566-8912], Voice: [+1 312 566-8910]
Macro Computer Solutions, Inc.    	"Quality solutions at a fair price"