Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!think.com!mintaka!bloom-beacon!eru!hagbard!sunic!mcsun!ukc!mucs!cns!umaida!jf
From: jf@ap.co.umist.ac.uk (John Forrest)
Newsgroups: comp.mail.sendmail
Subject: Re: Problem: mail spool area and .forward on different machines
Message-ID: <1990Nov1.102200@ap.co.umist.ac.uk>
Date: 1 Nov 90 10:22:00 GMT
References: <5476@uqcspe.cs.uq.oz.au> <926@iiasa.UUCP>
Sender: usenet@cns.umist.ac.uk (News System)
Reply-To: jf@ap.co.umist.ac.uk (John Forrest)
Organization: UMIST Computation, Manchester, UK.
Lines: 25

In article <926@iiasa.UUCP>, wnp@iiasa.AT (wolf paul) writes:
|> That is a question I have also. I guess it depends on whether having 
|> a central spool really means delivering only on the machine which
|> the spool is physically attached to. So: do Sendmail's lock files
|> depend on unique process ids, or are they generic enough that
|> you could have sendmails on different machines deliver mail to the
|> same cross-mounted spool? If the latter, you just create aliases for
|> your users to insure that delivery to the central spool takes place
|> on the correct machine, thus running their ".forward" programs on
|> the correct machine.
|> 

I can verify that you can run sendmail on several different machines that each
use the same mail directory - or, at least I can for our Apollo network. We have
a single incomming host (at least at present) which runs on the machine with the
mail directories. This is a good idea - if this node is down the directories are
unreachable anyway. However, outgoing mail is done by the mailer (usually mh)
forking a copy of sendmail which does the actual send. This arrangement works
fine. We run a standard(ish) copy of Sendmail 5.61 - no mods were required for
this arrangement. However, access to mail directories is done by the mailing
system - for us, usually mh's inc. We use the standard Apollo mh distribution -
it is possible this had been modified to cope with locks across the network. I
doubt it, but I can't say for certain.

John Forrest.