Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!uwm.edu!gem.mps.ohio-state.edu!tut.cis.ohio-state.edu!snorkelwacker!mit-eddie!apollo!apollo.hp.com!mishkin
From: mishkin@apollo.HP.COM (Nathaniel Mishkin)
Newsgroups: comp.sys.apollo
Subject: Re: Apollo should use sendmail internally
Message-ID: <4676c05b.20b6d@apollo.HP.COM>
Date: 26 Oct 89 20:17:00 GMT
References: <1547@novavax.UUCP>
Sender: root@apollo.HP.COM
Reply-To: mishkin@apollo.HP.COM (Nathaniel Mishkin)
Organization: Hewlett-Packard Apollo Division - Chelmsford, MA
Lines: 42

In article <1547@novavax.UUCP>, weiner@novavax.UUCP (Bob Weiner) writes:
>    Since the vendor, Apollo, doesn't use sendmail internally, they are not
>    likely to even see the problem.  Your only recourse here is to do what
>    we did and thats to make the modifications to
>    /usr/lib/sendmail,/bin/mail,/usr/ucb/mail yourselfs.
> 
> Mark brings up a good point, which I am fairly sure is true to a large
> extent (that is some internal Apollo users may use sendmail which will
> gateway to DPSS mail).
> 
> As long as Apollo's major e-mail network is based on a proprietary
> solution, they will not have a solid testbed from which to make mail
> facilities work for large networks.

Let me make it clear that sendmail is getting quite heavy use internally
at Apollo.  In the past this was not true, but has become increasingly
true over the last 6-12 months.  I can't give you hard numbers, but rest
assured that a number of us DEPEND on sendmail and friends to send mail.

Now just so you don't think I'm misrepresenting the situation, understand
that we ARE running some non-standard (unshipped software) to support
"local delivery".  From the sendmail user's point of view this means
that sendmail invokes something other than /bin/mail to do local delivery.
The reason is that there's a fundamental problem with the "standard"
Unix mail model.  Basically, I don't want to have to address mail I send
to internal users directly to the machine that user gets mail on.  I
want to mail to "smith" not "smith@smiths-machine" or the like.  

Various people have gotten around this problem in various ways:  (1)
distribute aliases files to all machines (or use links and a distributed
file system to link to one or more "central" copies), (2) arrange that
all mail gets sent to a "smart" host which has an aliases file or the
like and disposes of the mail properly, (3) pretend that your network
is really one big timesharing system and use /bin/mail and trust that
it will be able to write to a central /usr/spool/mail directory on some
fileserver.  I'm sure there are others.  I don't think there is one
"standard" way of dealing with this.  We essentially do something like
option (2).

                    -- Nat Mishkin
                       Hewlett Packard Company / Apollo Systems Division
                       mishkin@apollo.com