Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!aplcen!wb3ffv!ka3ovk!raysnec!shwake
From: shwake@raysnec.UUCP (Ray Shwake)
Newsgroups: comp.unix.sysv386
Subject: Re: '386 Unix Wars
Message-ID: <188@raysnec.UUCP>
Date: 2 Jan 91 15:22:09 GMT
References: <1990Dec30.193929.16181@kithrup.COM> <1990Dec31.053142.10444@robobar.co.uk> <1990Dec31.100329.23178@kithrup.COM> <1991Jan1.025724.25700@NCoast.ORG>
Organization: IRS/CI - Technical Solutions Branch
Lines: 25

allbery@NCoast.ORG (Brandon S. Allbery KB8JRR) writes:

>MMDF is one of the things SCO did right.  I plan to bring it up on a number of
>other systems --- it beats sendmail all hollow for ease of maintenance.  And
>the fact that it can handle a pathalias file by itself is nice, too.

	Consider yourself one of the lucky ones. I've had a few frustrating
years working with earlier and more recent versions of the package, and 
experienced nothing but frustration with the version included in ODT 1.0.
Since we distribute our own mailer, it's not like we "need" MMDF, but we
did want to see what, if anything, it offered and how well we would work
together.

	As it happens, the more we substituted our own components, the
more reliable the box became. The last straw came one morning when I found
104 undelivered messages in the spool directory, but all the tools indicated
an empty queue. I'll certainly check out the next version when ODT 1.1 comes
out, but for now, it's been purged from our system.

	As to pathaliasing, we found no way to use the existing paths file;
rather we had to create an mmdf-specific variant of same. Given a 1 MB paths
file, the variant came to more than 2 MB. We junked it.

----------------
uunet!media!ka3ovk!raysnec!shwake			shwake@rsxtech