pdb@batserver.cs.uq.oz.au (Peter Barnes) (10/30/90)
I would like to solicit comments about the following mail
problem:
o You have a site with a mixture of PCs, workstations
(disked and diskless) and multi-user machines.
o You want peoples' incoming mail to be accessible to
them from as many platforms as possible, preferrably
all (other than by giving them all an account on the
"mail hub"). There are several ways to do this:
1. Using file-system sharing. You can deliver to a
mail spool area which is visible to all platforms,
or,
2. alternatively you can deliver to a user's home
area, and make their home globally visible.
3. Using a message-store and message-specific access
and delivery protocols (such as POP, or X.400 P7).
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.
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.
Solution (3) means very restricted choice of UAs and/or MTAs
at the moment.
It's clear that classical UNIX solutions which implicitly
assume a single multiuser machine are stretched to the
breaking point. What is not so clear is the new solu-
tion...
So, what are people doing at the moment? Is there any con-
sensus on a clean solution? Is it available free :-)? Etc.
Thanks for your thoughts.
Peter
-------------------------------------------------------------------------------
Peter Barnes pdb@uqcspe.cs.uq.oz.au +61 7 377 2185 (voice) +61 7 371 0783 (fax)
Systems Programming Manager, Computer Science, University of Queensland
Queensland 4072, Australiawnp@iiasa.AT (wolf paul) (10/31/90)
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
jf@ap.co.umist.ac.uk (John Forrest) (11/01/90)
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.
michael@uni-paderborn.de (Michael Schmidt) (11/06/90)
We have ONE mail directory mounted on all machines, we are using. We
do local delivery to make "mail user" work (although we encourage to
use the full domain address). All sent mail will have the fully
qualified mail address without any hostname in the from field. All
incoming mail gets delivered on the main mail machine.
You have to ensure, that all mailers involved respect the same lock.
In our case it is the standard lock file "user.lock" in the
maildirectory. It is respected by all our mailers including mail, elm,
mh, GNU Emacs rmail, ...
--
Michael Schmidt, FB 17, Uni-GH Paderborn, Warburgerstr. 100,
D-4790 Paderborn, West Germany
Mail: michael@pbinfo.UUCP or michael@uni-paderborn.derickert@mp.cs.niu.edu (Neil Rickert) (11/07/90)
In article <MICHAEL.90Nov6142139@athene.uni-paderborn.de> michael@uni-paderborn.de (Michael Schmidt) writes: > >We have ONE mail directory mounted on all machines, we are using. We >do local delivery to make "mail user" work (although we encourage to >(...) >You have to ensure, that all mailers involved respect the same lock. >In our case it is the standard lock file "user.lock" in the >maildirectory. It is respected by all our mailers including mail, elm, >mh, GNU Emacs rmail, ... How reliable is this locking method? In particular what is the possibility of the following sequence: Machine 1 creates the file user.lock. Machine 2 tries checks and finds that user.lock doesn't exist, because NFS hasn't yet copied back the buffers. etc. I am just curious. I am not an NFS expert, but I have seen some behavior which at leasts makes me wonder. -- =*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*= Neil W. Rickert, Computer Science <rickert@cs.niu.edu> Northern Illinois Univ. DeKalb, IL 60115. +1-815-753-6940
lbo@ztivax.UUCP (Dr Lothar Borrmann) (11/07/90)
In article <MICHAEL.90Nov6142139@athene.uni-paderborn.de> michael@uni-paderborn.de (Michael Schmidt) writes: > >We have ONE mail directory mounted on all machines, we are using. We >do local delivery to make "mail user" work (although we encourage to >use the full domain address). ... > >You have to ensure, that all mailers involved respect the same lock. >... I think there is one more problem involved here: Don't you run into trouble when a local mailer wants to do "local delivery" to the central mail directory via the network, and the net (or the node holding the mail directory) is temporarily down? I mean, the usual thing to do would be to hold the message in the sendmail queue but standard binmail (the usual local delivery agent) was not programmed to behave that way. So in this case the mail delivery would fail and the message would be returned to the sender, wouldn't it ? (I once hacked binmail to behave differently but never had time to test this thing ...)
rickert@mp.cs.niu.edu (Neil Rickert) (11/08/90)
In article <2549@ztivax.UUCP> lbo@ztivax.UUCP (Lothar Borrmann) writes: >In article <MICHAEL.90Nov6142139@athene.uni-paderborn.de> michael@uni-paderborn.de (Michael Schmidt) writes: >> >>We have ONE mail directory mounted on all machines, we are using. We >>do local delivery to make "mail user" work (although we encourage to >>use the full domain address). ... >> >>You have to ensure, that all mailers involved respect the same lock. >>... >Don't you run into trouble when a local mailer wants to do >"local delivery" to the central mail directory via the network, >and the net (or the node holding the mail directory) is >temporarily down? >I mean, the usual thing to do would be to hold the message in >the sendmail queue but standard binmail (the usual local >delivery agent) was not programmed to behave that way. So >in this case the mail delivery would fail and the message would >be returned to the sender, wouldn't it ? You might have to test it to see what happens. There are some causes of failure for which binmail returns a status to sendmail such that the message is queued for future delivery. If, for example, the local sender has set a ulimit which is too small for the recipient's current mailbox size, the final delivery by binmail fails but, at least on my system, the mail is requeued. Next time the queue is run it works, because sendmail then is a child of the root daemon, and has not executed the sender's '.login' which set the ulimit. -- =*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*= Neil W. Rickert, Computer Science <rickert@cs.niu.edu> Northern Illinois Univ. DeKalb, IL 60115. +1-815-753-6940
Craig_Everhart@TRANSARC.COM (11/08/90)
Excerpts from netnews.comp.mail.sendmail: 7-Nov-90 Re: Problem: mail spool are.. Dr Lothar Borrmann@ztiva (981) > Don't you run into trouble when a local mailer wants to do > "local delivery" to the central mail directory via the network, > and the net (or the node holding the mail directory) is > temporarily down? We had exactly this problem with AFS, even in its early versions back in 1985. That's why we rewrote a local mail delivery mechanism, that we call AMDS, for the Andrew Message Delivery System, available on the X.V11R4 tape under the Andrew contribution.
michael@uni-paderborn.de (Michael Schmidt) (11/08/90)
>>>>> About Re: Problem: mail spool area and .forward on different >>>>> machines, Dr Lothar Borrmann said: Dr> In article <MICHAEL.90Nov6142139@athene.uni-paderborn.de> Dr> michael@uni-paderborn.de (Michael Schmidt) writes: > >We have ONE mail directory mounted on all machines, we are using. We >do local delivery to make "mail user" work (although we encourage to >use the full domain address). ... > >You have to ensure, that all mailers involved respect the same lock. >... Dr> I think there is one more problem involved here: Don't you run Dr> into trouble when a local mailer wants to do "local delivery" to Dr> the central mail directory via the network, and the net (or the Dr> node holding the mail directory) is temporarily down? Sure. But first, the central mail host is conseidered to be down very seldom. Then all mail from outside gets delivered on this hosts. So no mail from outside will be returned. And the last thing is, that local delivery is the exception, just for convenience (remember, that we encourage the use of the full domain address, which causes the mail to be dropped on the central mail host. Dr> I mean, the usual thing to do would be to hold the message in Dr> the sendmail queue but standard binmail (the usual local Dr> delivery agent) was not programmed to behave that way. So Dr> in this case the mail delivery would fail and the message would Dr> be returned to the sender, wouldn't it ? Yes. Sad, but true. Dr> (I once hacked binmail to behave differently but never had time Dr> to test this thing ...) That'd be great. Returning somthing like EX_TEMPFAIL instead of EX_UNAVAILABLE (or whatsoever). -- Michael Schmidt, FB 17, Uni-GH Paderborn, Warburgerstr. 100, D-4790 Paderborn, West Germany Mail: michael@pbinfo.UUCP or michael@uni-paderborn.de
michael@uni-paderborn.de (Michael Schmidt) (11/13/90)
>>>>> About Re: Problem: mail spool area and .forward on different >>>>> machines, Neil Rickert said: Neil> How reliable is this locking method? Neil> In particular what is the possibility of the following sequence: Neil> Machine 1 creates the file user.lock. Neil> Machine 2 tries checks and finds that user.lock doesn't exist, because Neil> NFS hasn't yet copied back the buffers. Neil> etc. Neil> I am just curious. I am not an NFS expert, but I have seen Neil> some behavior which at leasts makes me wonder. Yes, you're right. If NFS has a problem, we have a problem. And, once in a while, we have a problem with elm complaining about acorrupted folder. -- Michael Schmidt, FB 17, Uni-GH Paderborn, Warburgerstr. 100, D-4790 Paderborn, West Germany Mail: michael@pbinfo.UUCP or michael@uni-paderborn.de
michael@uni-paderborn.de (Michael Schmidt) (11/13/90)
>>>>> About Re: Problem: mail spool area and .forward on different >>>>> machines, Neil Rickert said: Neil> You might have to test it to see what happens. There are some Neil> causes of failure for which binmail returns a status to sendmail Neil> such that the message is queued for future delivery. If, for Neil> example, the local sender has set a ulimit which is too small Neil> for the recipient's current mailbox size, the final delivery by Neil> binmail fails but, at least on my system, the mail is requeued. Neil> Next time the queue is run it works, because sendmail then is a Neil> child of the root daemon, and has not executed the sender's Neil> '.login' which set the ulimit. ulimit? Wattsat? (:-) I just checked the binmail sources (both 4.3 and from sendmail-5.65+). There is only one exit with EX_TEMPFAIL and that is in the case, that execv(sendmail) fails. -- Michael Schmidt, FB 17, Uni-GH Paderborn, Warburgerstr. 100, D-4790 Paderborn, West Germany Mail: michael@pbinfo.UUCP or michael@uni-paderborn.de