Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!tut.cis.ohio-state.edu!ucbvax!CAEN.ENGIN.UMICH.EDU!markg
From: markg@CAEN.ENGIN.UMICH.EDU (Mark Giuffrida)
Newsgroups: comp.sys.apollo
Subject: mail
Message-ID: <4341a7bf1.0017b5e@caen.engin.umich.edu>
Date: 16 May 89 13:52:08 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 37


	>We are a large Apollo site (about 700 nodes) running 9.7.1
	>(soon to be 10.1) Domain/IX.  We use primarily Unix Sys V
	>since we are now part of an ATT JV.
	...
	>adding to the mailbox (all 700 nodes are linked to one /usr/mail dir).
	 
	This is really not a good idea.  Very few mail programs check to
	make sure that their 'write()'s succeed.  If the network gets flakey,
	or something else goes wrong you could easily lose your entire
	mailbox.  In addition you have the cost of 700 users beating on
	a single directory every few minutes checking to see if there
	is new mail.

I must disagree with this statement.  I am responsible for the mail environment
here at the University of Michigan CAEN.  We have 500 Apollos and they all
link to one spool directory.  We modified SENDMAIL extensively to work in
a distributed enviornment.  One of the changes is to accomodate Apollos file
locking.  If the mailbox cannot be opened for write, it simply leaves the 
message queued (it will not bounce) and tries again later.  With syslog
output going to the main node, you can watch the entire mail environment as
it happens by "tail -f" that log file (we call it Mail-TV or MTV for short).
A smart administrator can catch problems long in advance of them becoming a
problem by watching the log output.  To give another small example, the
message-id incorportes the nodeid in it so that we can tell exactly which
node generated the message.  We now traffic about 1500 msgs/day (1/3 of them
nonlocal) and have very few problems.  Also, we find the cost of checking for
new mail is not even noticeable.

The sendmail Apollo ships is a straight port from BSD and it isn't specifically
modified to handle the situations that arise in a distributed environment.  Until
X.400 takes over, vendors need to be concerned with current mailers like SENDMAIL
and tune them to a network environment.

Mark Giuffrida
University of Michigan (CAEN)
markg@caen.engin.umich.edu