Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!olivea!orc!inews!pinkas From: pinkas@st860.intel.com (Israel Pinkas) Newsgroups: comp.mail.mh Subject: Re: Problems with whatnow/send Message-ID: Date: 29 Jan 91 01:21:36 GMT References: <5740009@hpscdc.scd.hp.com> <1991Jan26.140602.5459@mp.cs.niu.edu> Sender: news@inews.intel.com Organization: Software Technologies, INTeL Corporation, Santa Clara, CA Lines: 87 In-reply-to: rickert@mp.cs.niu.edu's message of 26 Jan 91 14:06:02 GMT In article <1991Jan26.140602.5459@mp.cs.niu.edu> rickert@mp.cs.niu.edu (Neil Rickert) writes: > In article <5740009@hpscdc.scd.hp.com> schmitz@hpscdc.scd.hp.com (John Schmitz) writes: > > Q. What exactly are the benefits of using SMTP with mh? > > > > A. Well, the primary one I know of is that you don't have to run a > > Mail Transport Agent on every host. When you have several hundred > > client workstations, it's a major hassle to manage a Sendmail (or > > MMDF, etc.) on every one of them. > > > >It seems to me that unix really relies on being able to use mail. All > >sorts of programs have built in calls to mail (vi, cron, etc.) and it > >would be difficult to administer systems without having an MTA. > >Further, other mailers aren't capable of this feature, so if you want > >them to work, you must have a MTA. Or did I miss something? > I don't think you missed a thing. I am still waiting for a satisfactory > answer to that question. I guess with a network there is some small > benefit in MH using the file server and SMTP, thereby saving one mail hop > (compared to sending to the local sendmail which will perhaps itself pass > it to the server). > I didn't find any answer that would be useful to me. I can't benefit > from listing multiple SMTP servers for mh, since this will only work if > all have exactly the same idea of email addresses, including local > addresses without any '@domain'. The inconvenience to users of having to > add full domain names to all local addresses would negate any benefits > from multiple servers. Here are some reasons to set MH up to deliver via SMTP rather than sendmail: 1. You don't have sendmail set up. SVR4 is a good example of such an environment. There is no sendmail or (yucky) sendmail.cf. (Yes, I know about ease.) There is an alternate delivery system, and all of the utilities have been converted to call it instead. While it does not speed up delivery, it makes it very easy to set up system, mail clusters, special cases, etc. By connecting to SMTP, all the problems are bypassed, and no code needs to be changed. 2. You run mail clusters. All the mail delivery is done on the file server. The client machines just mount /var/spool/mail. The clients' sendmail.cf is set up to forward all mail, unconditionally, to the server. The server recognizes all mail for the clients and delivers it locally. This makes it very simple to manage mail on a large number of workstations. It also allows you to make the file server do a large number of rewrites that change often, depending on gateway availability. The nice part is that you don't have to run sendmail on every workstation. All mail looks like it comes from the server. By setting MH uptalk SMTP directly to your server, you remove the extra process from the loop. 3. sendmail startup can be slow, especially when sendmail.cf is not frozen. By contrast, the sendmail daemon is always there. 4. We found a local problem by setting MH up to deliver by SMTP. Our sendmail was dying occasionally, but only if it did certain things. The problem was that nobody ever noticed, UNLESS THEY RAN MH. Users that ran Elm, Mail, Mush, etc. never noticed that the sendmail daemon died. The problem was that that most mail to these users was sent to a file server, where the daemon almost never died. The few pieces of mail that were sent directly to the workstation would either bounce after 3 days in the queue, or get delivered when sendmail got restarted (like after a reboot). The other problem was that if these users send mail, and the mail got queued for later delivery, there was no daemon to run the queue. MH users would find out very quickly when the sendmail daemon died, because they couldn't send any mail. Obviously, there might be disadvantages to running MH set up to SMTP. But I haven't found any yet. -Israel Pinkas Intel Corp. -- -------------------------------------- Disclaimer: The above are my personal opinions, and in no way represent the opinions of Intel Corporation. In no way should the above be taken to be a statement of Intel. UUCP: {amdcad,decwrl,hplabs,oliveb,pur-ee,qantel}!intelca!mipos3!st860!pinkas ARPA: pinkas%st860.intel.com@relay.cs.net CSNET: pinkas@st860.intel.com