Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!tut.cis.ohio-state.edu!ucsd!ogccse!blake!milton!uw-beaver!fluke!ssc-vax!bcsaic!vince
From: vince@bcsaic.UUCP (Vince Skahan)
Newsgroups: comp.sys.apollo
Subject: Re: GETTING RID OF APOLLO
Message-ID: <16154@bcsaic.UUCP>
Date: 24 Oct 89 02:42:30 GMT
References: <30474@pbhya.PacBell.COM>
Reply-To: vince@bcsaic.UUCP (Vince Skahan)
Organization: Boeing Computer Services - Phila.
Lines: 30

It strikes me that getting rid of Apollo because you can't devote the
time (and pain...I've been there too) to learn sendmail is a pretty
shaky decision.  Yes, it's painfil but ti does work once you've bled
enough.

That doesn't make it right, and there's no excuse in my mind for the
brain-dead sendmail.cf's you get by default from Apollo...but once you
set it up it DOES work.  our > 15 subnets will attest to it.

I also agree with the bit about the file-locking in one /usr/spool/mail
being a pain in the neck.  We get around that by having on
/usr/spool/mail PER RING and you hvae to know where somewhere is working
to get mail to their ring.  

There are lots of semi-easy ways to get around it like:
	- sticking everyone in your .mailrc by alias
	- using system-wide /usr/lib/aliases that point to the right
ring
	- messing with sendmail.cf to make pseudo-aliases by department,
		building, etc.


It CAN be done but it (and unix - by definition) is never plug-and-play.
This is not necessarily Apollos's fault but is more probably the result
of being blindly unix-like (even when the unix way is lacking).
-- 
     Vince Skahan            Boeing Computer Services - Phila.
    (215) 591-4116           ARPA:  vince@atc.boeing.com
                             UUCP:  bcsaic!vince
Note: the opinions expressed above are mine and have no connection to Boeing...