Path: utzoo!attcan!uunet!mcsun!tuvie!iiasa!wnp
From: wnp@iiasa.AT (wolf paul)
Newsgroups: comp.mail.sendmail
Subject: Re: Problem: mail spool area and .forward on different machines
Message-ID: <926@iiasa.UUCP>
Date: 31 Oct 90 12:42:47 GMT
References: <5476@uqcspe.cs.uq.oz.au>
Reply-To: wnp%iiasa@relay.eu.net (wolf paul)
Organization: IIASA, Laxenburg/Vienna, Austria, Europe
Lines: 81

In article <5476@uqcspe.cs.uq.oz.au> pdb@batserver.cs.uq.oz.au writes:

(I have rearranged his text to group related stuff together in order
to be able to reply in a more logical manner)

>     1.   Using file-system sharing. You can deliver to a
>          mail spool area which is visible to all platforms,
>          or,
>
>o    You also want users to be able to (easily) tailor
>     actions to be taken when their mail is delivered (where
>     "delivered" is a bit vague...). Classic examples of
>     this are .forward or .maildelivery files.
>
>So, where's the problem? Well, solution (1) means that
>delivery takes place on a platform other than the user's
>native machine. This means that if the .forward file speci-
>fies execution of a program, the program will either be the
>wrong type of executable, or run on the wrong machine.

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.

>     2.   alternatively you can deliver to a user's home
>          area, and make their home globally visible.
>
>Solution (2) means that you have to support (potentially)
>large amounts of MTA and UA stuff on what might be small
>diskless workstations or PCs (if you actually do the
>delivery on their machine), or alternatively face the same
>problem as (1), if you deliver on the fileserver.
>
>     3.   Using a message-store and message-specific access
>          and delivery protocols (such as POP, or X.400 P7).
>
>Solution (3) means very restricted choice of UAs and/or MTAs
>at the moment.

I find that you have to provide UA stuff on the machines people
work on habitually, anyway, since most people will not use e-mail if
it requires them to log in to some other machine. And while it's o.k.
if Joe Blow does not want to use e-mail, it also hampers other users
who do want to use it, if Joe does not ever get to read what they
send him, because he can't be bothered to log in on the machine with
the UA.

However, all small diskless workstations of the same architecture
could share a common "mailbin" containing the UA/MTA stuff, which
reduces the maintenance drag; those folks who need to use a PC
would have to be encouraged (more or less successfully, of course)
to log in to a designated UNIX machine once or twice a day to check
their mail, or be satisfied with a less sophisticated UA. In a
PC-NFS environment, it is not too difficult to have a PC's
AUTOEXEC.BAT check the mail spool on the server by using the
"rsh" command, so at least you can have the PC users notified
if there is mail in the spool, and you could even list it using
BSD or ELM "fr[o]m". If you could persuade your management to
get something like MKS Toolkit, their "mailx" command also can
be made to read a common spool and send out mail using a
"rsh hostname /usr/lib/sendmail ..." construct in the "sendmail"
variable. Not in the background, of course, and thus not very
elegantly, but it can be done.

The central mail spool seems to me the best solution, if one
could be sure that the different mailers running on the different
machines will not interfere with each other, i.e. that they will
respect each others lockfiles. Anyone care to authoritatively
answer this for all known mailers under UNIX?


-- 
Wolf N. Paul, UNIX SysAdmin, IIASA, A - 2361 Laxenburg, Austria, Europe
PHONE: +43-2236-71521-465     FAX: +43-2236-71313      UUCP: uunet!iiasa!wnp
INTERNET: wnp%iiasa@relay.eu.net      BITNET: tuvie!iiasa!wnp@awiuni01.BITNET