Mail Forwarding Puzzle

[Tony Guzzi]

>> From: "Michael A. Covington" <mcovingt at athena.cs.uga.edu>
>> Subject: Mail forwarding puzzle
>> Date: 24 Jan 91 20:01:51 GMT
>> To:       unix-wizards at sem.brl.mil
>> 
>> Can two accounts on different CPUs have the same incoming mailbox?
>> 
>> Here's the situation. I have two Sparcstations that share practically
>> all their files. Each user has the same home directory regardless of
>> which CPU he logs on to. So it really doesn't matter which CPU a person
>> is using. That's very convenient for evening out the system load, etc.

Yes.  Choice one host to server as the `mailbox file system server' and
have it export its '/usr/spool/mail'.  Then have all your other hosts NFS
mount it.  NOTE: all hosts that mount '/usr/spool/mail' must use the same
set of login names and uid's (i.e. they use the same version of an NIS
(formally YP) 'passwd' database). We have a network of diskless Sun3's
which are all serviced by a single SPARCstation (all running SunOS4.x) and
all the Sun3's mount the '/usr/spool/mail' of the SPARCstation as well as
its '/user' filesystem.

>> The only problem is mail. Mail goes to (for example) _either_
>> mcovingt at aisun1 _or_ mcovingt at aisun2, and if you log on to the other
>> CPU, you don't receive it. 

Previously (i.e. before we started having our diskless hosts mount the
server's mail spool directory), each hosts had its own mail spool directory.
At that time, we advised our users to select a single hosts (preferably
the host they used the most) and have all their mail forwarded (via the
.forward file) to that host.  To read their mail, the users had to log into
that host.  Since in most cases it _was_ the host they used requently, this
wasn't a problem.  ***One note of warning.  With the mail system typically
run under 'daemon''s uid (an ordinary user as far as most file system access
situations go) and the fact that roots on NFS clients (the diskless hosts
in our case) are treated as ordinary users by the NFS server), we learned
that the user's home directory _MUST_ have at least world execute permission
(and preferably world read permission) so that the mail system can get access
to the '.forward' file.  We had some users who insisted on not using
subdirectories (i.e. the old 'flat file system'), setting the permission on
their home directory to 'drwx------' and then complained that thier mail
wasn't being forwarded.  

>> Is there a simple way that mail can be made to arrive where the
>> user can get his mail regardless of which CPU he's on?

Only if they both mount the _same_ mail spool directory.

>> This does not seem to be a case for .forward files because each
>> user has the same files regardless of which CPU he's on; thus if
>> I used a .forward file to forward from aisun1 to aisun2, it would
>> also forward, loopingly, from aisun2 to aisun2.

I hope you don't mean looping endlessly.  The system should not do that.
Assuming your e-mail system in not brain-damaged, it should examine the
contents of the '.forward' file and remove any address that would cause
looping. In other words, if mail arrives for USER on host HST.localnet,
the mail system should remove the address USER at HST.localnet (and hopefully
any address with corresponding host-name aliases) from the list of addresses
it reads out of USER's .forward file and mark the mail as ``local'' as well
as forwarding it to any remaining addresses (remember, '.forward' file can
have multiple address listed in which case each address gets a copy of the
message).  If the local host is the only address listed, then no forwarding
should be done.  A word of caution.  Someone on our network once tried
listing three forwarding address to three _local_ hosts on our network in
his .forward file thinking that he could then read this mail on any of the
three hosts.  The result was that when first host (hostA) received the mail,
it read the .forward, mark the mail as local and delivered it and then
forwarded it to the remaining two hosts (hostA ==> hostB & hostC). Both of
these did the same thing:
	- deliver locally and then forward (hostB ==> hostA & hostC)
	- deliver locally and then forward (hostC ==> hostA & hostB)
When these third generation copies were received, all copies where processed
in the same way, giving us an endless loop for *EACH* copy of the message:
	- deliver locally and then forward (hostA ==> hostB & hostC)
	- deliver locally and then forward (hostB ==> hostA & hostC)
	- deliver locally and then forward (hostC ==> hostA & hostB)
The result: an explosion in the number of mail messages propagating between
the three hosts.  The end results were 1) the mail spool on all three hosts
filled up rapidly and 2) the network came to the screeching halt.  All three
hosts had to have their mailer daemons killed and their mailer queues cleaned
manually.  Be careful with the '.forwards'.


Tony Guzzi				E-mail: tony at brcvax.brc.uconn.edu
Booth Research Center
University of Connecticut		Work Phone: (203) 486-5955 or 486-5305
Storrs, CT 06269-4031