Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!decwrl!ogicse!littlei!gandalf!andyc From: andyc@bucky.intel.com (Andy Crump) Newsgroups: comp.mail.mh Subject: Re: Problems with whatnow/send Message-ID: Date: 1 Feb 91 10:28:00 GMT References: <5740009@hpscdc.scd.hp.com> <1991Jan26.140602.5459@mp.cs.niu.edu> Sender: news@littlei.UUCP Organization: Intel Corporation, Hillsboro, Oregon Lines: 88 In-reply-to: pinkas@st860.intel.com's message of 29 Jan 91 01:21:36 GMT >>>>> On 29 Jan 91 01:21:36 GMT, pinkas@st860.intel.com (Israel Pinkas) said: Israel> In article <1991Jan26.140602.5459@mp.cs.niu.edu> rickert@mp.cs.niu.edu (Neil Rickert) writes: Israel> Here are some reasons to set MH up to deliver via SMTP rather than Israel> sendmail: Israel> 1. You don't have sendmail set up. SVR4 is a good example of such an Israel> environment. There is no sendmail or (yucky) sendmail.cf. (Yes, I know Israel> about ease.) There is an alternate delivery system, and all of the Israel> utilities have been converted to call it instead. While it does not Israel> speed up delivery, it makes it very easy to set up system, mail Israel> clusters, special cases, etc. This is not true. Sendmail is in /usr/ucblib along with sendmail.cf files. In fact, these are the same cf files that are provided on Sun. I am using MH with sendmail as my MTA on SVR4 version 3.0 now and it works fine. In fact I use sendmail as my MTA to send mail and the SVR4 mail/smtpd asm my recieving MTA. It was very easy to configure sendmail.cf to work on my workstation, only 5 lines needed to be changed to work. I don't consider this complex. Israel> By connecting to SMTP, all the problems are bypassed, and no code needs Israel> to be changed. THis is a problem if the remote host is down. What do you do with the mail and delayed deliveries? Israel> 2. You run mail clusters. All the mail delivery is done on the file Israel> server. The client machines just mount /var/spool/mail. The clients' Israel> sendmail.cf is set up to forward all mail, unconditionally, to the Israel> server. The server recognizes all mail for the clients and delivers it Israel> locally. This makes it very simple to manage mail on a large number of Israel> workstations. It also allows you to make the file server do a large Israel> number of rewrites that change often, depending on gateway availability. Israel> The nice part is that you don't have to run sendmail on every Israel> workstation. All mail looks like it comes from the server. But you need to worry about the filesystem maintenance and backup stategies. 6 of one and 1/2 dozen of another. Israel> By setting MH uptalk SMTP directly to your server, you remove the extra Israel> process from the loop. True, but note what do you do when the remote host is down? Israel> 3. sendmail startup can be slow, especially when sendmail.cf is not frozen. Israel> By contrast, the sendmail daemon is always there. The daemon does not need to run when sending mail, only receiving it. I have noticed almost no noticable delay in sending mail via sendmail on SVR4. I do not freeze the cf file and it is soo small, the benefit is questionable. Israel> 4. We found a local problem by setting MH up to deliver by SMTP. Our Israel> sendmail was dying occasionally, but only if it did certain things. The Israel> problem was that nobody ever noticed, UNLESS THEY RAN MH. Users that Israel> ran Elm, Mail, Mush, etc. never noticed that the sendmail daemon died. Israel> The problem was that that most mail to these users was sent to a file Israel> server, where the daemon almost never died. The few pieces of mail that Israel> were sent directly to the workstation would either bounce after 3 days Israel> in the queue, or get delivered when sendmail got restarted (like after a Israel> reboot). The other problem was that if these users send mail, and the Israel> mail got queued for later delivery, there was no daemon to run the Israel> queue. MH users would find out very quickly when the sendmail daemon Israel> died, because they couldn't send any mail. This sounds like a bug in sendmail or MH. If it is a bug in sendmail, then there should be a problem report logged with USL on the SVR4 version of sendmail regarding this (Israel, you know how to do this). Otherwise, the problem maybe with MH and a problem note should be sent to ...!ucbvax!ucivax!bug-mh. It is important that we not just workaround bugs, but rather report them to the appropriate responsible parties so that the bug is not perpetuated to each successive version of the s/w. We all have seen this in the UNIX world far too long and it is the responsibility of each of us to stop it. -- -- Andy Crump ...!tektronix!reed!littlei!andyc | andyc@littlei.intel.com ...!uunet!littlei!andyc | andyc@littlei.uu.net Disclaimer: Any opinions expressed here are my own and not representive of Intel Corportation.