weiner@novavax.UUCP (Bob Weiner) (10/24/89)
markg@CAEN.ENGIN.UMICH.EDU (Mark Giuffrida) writes:
Since the vendor, Apollo, doesn't use sendmail internally, they are not
likely to even see the problem. Your only recourse here is to do what
we did and thats to make the modifications to
/usr/lib/sendmail,/bin/mail,/usr/ucb/mail yourselfs.
Mark brings up a good point, which I am fairly sure is true to a large
extent (that is some internal Apollo users may use sendmail which will
gateway to DPSS mail).
As long as Apollo's major e-mail network is based on a proprietary
solution, they will not have a solid testbed from which to make mail
facilities work for large networks. (Note that there is little
information coming from Apollo as to the status of their X.400 mail
product, but since they have not released one yet, they are behind a
number of other vendors.)
I imagine the linkage to HP's large e-mail network will drive Apollo
toward more standard e-mail facilities anyway, but I think the point
should be made that Apollo needs a decent size network internally on
which to stress test all of its products that are network-based.
--
Bob Weiner, Motorola, Inc., USENET: ...!gatech!uflorida!novavax!weiner
(407) 738-2087mishkin@apollo.HP.COM (Nathaniel Mishkin) (10/27/89)
In article <1547@novavax.UUCP>, weiner@novavax.UUCP (Bob Weiner) writes: > Since the vendor, Apollo, doesn't use sendmail internally, they are not > likely to even see the problem. Your only recourse here is to do what > we did and thats to make the modifications to > /usr/lib/sendmail,/bin/mail,/usr/ucb/mail yourselfs. > > Mark brings up a good point, which I am fairly sure is true to a large > extent (that is some internal Apollo users may use sendmail which will > gateway to DPSS mail). > > As long as Apollo's major e-mail network is based on a proprietary > solution, they will not have a solid testbed from which to make mail > facilities work for large networks. Let me make it clear that sendmail is getting quite heavy use internally at Apollo. In the past this was not true, but has become increasingly true over the last 6-12 months. I can't give you hard numbers, but rest assured that a number of us DEPEND on sendmail and friends to send mail. Now just so you don't think I'm misrepresenting the situation, understand that we ARE running some non-standard (unshipped software) to support "local delivery". From the sendmail user's point of view this means that sendmail invokes something other than /bin/mail to do local delivery. The reason is that there's a fundamental problem with the "standard" Unix mail model. Basically, I don't want to have to address mail I send to internal users directly to the machine that user gets mail on. I want to mail to "smith" not "smith@smiths-machine" or the like. Various people have gotten around this problem in various ways: (1) distribute aliases files to all machines (or use links and a distributed file system to link to one or more "central" copies), (2) arrange that all mail gets sent to a "smart" host which has an aliases file or the like and disposes of the mail properly, (3) pretend that your network is really one big timesharing system and use /bin/mail and trust that it will be able to write to a central /usr/spool/mail directory on some fileserver. I'm sure there are others. I don't think there is one "standard" way of dealing with this. We essentially do something like option (2). -- Nat Mishkin Hewlett Packard Company / Apollo Systems Division mishkin@apollo.com
dennis@Peanuts (Dennis Cottel) (10/31/89)
mishkin@apollo.HP.COM (Nathaniel Mishkin) writes: > The reason is that there's a fundamental problem with the "standard" > Unix mail model. Basically, I don't want to have to address mail I send > to internal users directly to the machine that user gets mail on. I > want to mail to "smith" not "smith@smiths-machine" or the like. > Various people have gotten around this problem in various ways: (1) > distribute aliases files to all machines (or use links and a distributed > file system to link to one or more "central" copies), (2) arrange that > all mail gets sent to a "smart" host which has an aliases file or the > like and disposes of the mail properly, (3) pretend that your network > is really one big timesharing system and use /bin/mail and trust that > it will be able to write to a central /usr/spool/mail directory on some > fileserver. Does each node then have an /etc/spool/mail directory and a sendmail daemon running? Otherwise case (2) and (3) can't spool up the mail if the central mail machine is down. A similar problem occurs for case (1) if you use links to find the alias file. [This is another good example of why the operating system should provide some kind of "redundant link".] And this still doesn't address the problem with file locking across nodes: touching your mail spool file from a node other than that where the spool directory lives may break sendmail, causing the mail to be returned to sender (or worse). Dennis Cottel Naval Ocean Systems Center, San Diego, CA 92152 (619) 553-1645 dennis@nosc.MIL sdcsvax!noscvax!dennis
markg@CAEN.ENGIN.UMICH.EDU (Mark Giuffrida) (10/31/89)
Does each node then have an /etc/spool/mail directory and a sendmail daemon running? Otherwise case (2) and (3) can't spool up the mail if the central mail machine is down. A similar problem occurs for case (1) if you use links to find the alias file. [This is another good example of why the operating system should provide some kind of "redundant link".] And this still doesn't address the problem with file locking across nodes: touching your mail spool file from a node other than that where the spool directory lives may break sendmail, causing the mail to be returned to sender (or worse). Actually we at UofM(CAEN) link all our spool dirs to a central machine. Its six of one or half a dozen of another. Either the big one is down or some of the small ones are down. It teaches you to keep an eye on your primary server. This is actually the best scenario for a large Apollo ring. When the server is down, then mail trying to be delivered *should* be temporarily queued (i.e., /bin/mail returns a code that tells sendmail to "leave it queued"). The same for when the file is locked. Actually, we put in our own open which will wait up to 15 seconds for the mail file to unlock before returning the "leave it queued" return code to sendmail. The current behavior of Unix sendmail (to repeat an earlier msg) is for /bin/mail to balk at the locked file and return to sendmail which returns to it to the sender with "unknown mailer error" msg. /bin/mail presumes it can always connect to the mailbox which is wrong in an Apollo or NFS environment. Remember that queuing a msg because it cannot be delivered is not a bad thing. Presumably you run "/usr/lib/sendmail -q" from cron on every node every 30 or 60 minutes that will process any queued mail. This way, these temporary problems are just that, temporary. Mark Giuffrida Univ of Michigan markg@caen.engin.umich.edu