curtiss@truffula.umiacs.umd.edu (Phil J. Curtiss) (01/23/91)
I use a drafts folder and store a number of mail items in this folder until
I am ready to finish composing the mail and send it off. This works great and
saves me lots of time and keeps me from losing track of my mail.
However, when I get more than 1 mail item in the drafts folder and then try
and send a second or third (etc) mail item via the `push' command to the
`what now?' prompt, the mail item sometimes gets sent and other times does
not get sent. When it fails to be sent, it just sits in my drafts folder and
none of the other mail items are annotated (if I am repl'ing eg.). Currently
I am using `send' in answer to the `what now?' prompt but this takes more
time than the `push' command.
My MH configuration is older than the current version:
version: MH 6.6 #6[UCI] (gyre.umd.edu) of Wed Mar 22 14:44:50 EST 1989
options: [BSD42] [BSD43] [BERK] [DUMB] [MHE] [NETWORK] [BIND] [RPATH]
[SBACKUP='"#"'] [SENDMTS] [SMTP]
Any help would be appreciated.
Thanks
--
Domain: curtiss@umiacs.umd.edu Phillip Curtiss
UUCP: uunet!mimsy!curtiss UMIACS - Univ. of Maryland
Phone: +1-301-405-6744 College Park, Md 20742rickert@mp.cs.niu.edu (Neil Rickert) (01/24/91)
In article <CURTISS.91Jan22184350@truffula.umiacs.umd.edu> curtiss@truffula.umiacs.umd.edu (Phil J. Curtiss) writes: >However, when I get more than 1 mail item in the drafts folder and then try >and send a second or third (etc) mail item via the `push' command to the >`what now?' prompt, the mail item sometimes gets sent and other times does >not get sent. When it fails to be sent, it just sits in my drafts folder and I don't know if this is related. But when are setup to submit mail by SMTP and the system load average is high, 'sendmail' may refuse to accept the mail. With 6.7 I find the effect is that 'push' or 'send' sits there periodically retrying. (Must be a bear if you don't use push.) This raises the following question: What exactly are the benefits of using SMTP with mh? I know of two disadvantages. One I have listed above. (Without SMTP, sendmail will at least queue the message for later delivery.) The other is that with SMTP, sendmail will not look up your full name in the password file if you didn't define a signature. (This is because the envelope sender and the header sender do not compare equal - one of them is <bracketed> and the other is not.) -- =*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*= Neil W. Rickert, Computer Science <rickert@cs.niu.edu> Northern Illinois Univ. DeKalb, IL 60115 +1-815-753-6940
jromine@buckaroo.ics.uci.edu (John Romine) (01/24/91)
rickert@mp.cs.niu.edu (Neil Rickert) writes: > What exactly are the benefits of using SMTP with mh? 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. The mh-mts(8) man page (part of the MH Administrators Guide) talks about this. If you're managing a single large host, instead of a network of workstations, you probably don't need the "/smtp" option. If you do use the "/smtp" option, you should supply a good list of SMTP hosts in your mtstailor file. One method would be to have every client's NFS server run an MTA, and include that at the front of the client's "servers" list. This assumes that if the NFS server is down, so is the client; this way you probably only have to run 1/10 as many MTAs. At UCI, we have three machines out of 200+ which run an MTA. If all three of them are down, chances are everything else is too. > Without SMTP ... sendmail will ... look up your full name in the > password file if you didn't define a signature. There are plenty of ways to fix this, the easiest would be to ask Bug-MH@ics.uci.edu to change it. The next easiest is to just change mts.c yourself to do what you want, and send your changes to Bug-MH. -- John Romine
wohler@sapwdf.UUCP (Bill Wohler) (01/24/91)
curtiss@truffula.umiacs.umd.edu (Phil J. Curtiss) writes: >However, when I get more than 1 mail item in the drafts folder and then try >and send a second or third (etc) mail item via the `push' command to the >`what now?' prompt, the mail item sometimes gets sent and other times does >not get sent. phillip, i've noticed this behavior for years and would be curious if anyone has an explanation or a fix. if a scan of +drafts reveals a message, i use the command, for example, "senddead 1". the alias: alias senddead 'send -draftf drafts' --bw wohler@sap-ag.de
schmitz@hpscdc.scd.hp.com (John Schmitz) (01/26/91)
Perhaps I'm showing my ignorance here, but... 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?
rickert@mp.cs.niu.edu (Neil Rickert) (01/26/91)
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. -- =*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*= Neil W. Rickert, Computer Science <rickert@cs.niu.edu> Northern Illinois Univ. DeKalb, IL 60115 +1-815-753-6940
jf@ap.co.umist.ac.uk (John Forrest) (01/28/91)
In article <5740009@hpscdc.scd.hp.com> schmitz@hpscdc.scd.hp.com (John Schmitz) writes: > >Perhaps I'm showing my ignorance here, but... > > 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 think the argument about managing sendmail on many workstations is a bit of a red herring. As pointed out, many programs do like to invoke sendmail, and you need to set it up so that they can. However, there is an argument relating to efficiency. We've recently changed so that mh uses smtp rather than invoking sendmail directly, and thus sendmail doesn't have to start up from scratch each time. One of the reasons for this is that we prefer not to have frozen configurations - in a group of workstations there *are* hard to manage, as they must be set up individually on each workstations if the .cf file changes. They also use a lot more disk-space. I think this is the major advantage. Apart from that, you *can* run MH on things without sendmail, but this is not really a normal thing. For instance, the mail from rn still has to invoke sendmail directly as far as I know. John Forrest Dept of Computation UMIST
jromine@buckaroo.ics.uci.edu (John Romine) (01/29/91)
schmitz@hpscdc.scd.hp.com (John Schmitz) writes: >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. The easiest solution I know of, is to replace /bin/mail with a link to "mhmail". -- John Romine
rickert@mp.cs.niu.edu (Neil Rickert) (01/29/91)
In article <27A451FD.10013@ics.uci.edu> jromine@ics.uci.edu (John Romine) writes: >schmitz@hpscdc.scd.hp.com (John Schmitz) writes: >>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. > >The easiest solution I know of, is to replace /bin/mail with a link >to "mhmail". At least in BSD systems, /bin/mail has the following properties: 1. It will deliver mail to a user's mailbox. It is used in this way by sendmail to achieve final mail delivery. 2. It supports 'biff' processing when delivering mail to a mailbox. 3. It will accept mail already containing headers. In fact it does not ever create its own headers - it leaves that the the MTA. The last time I checked, either the man pages for mhmail were totally wrong, or else it does not support these functions. Making /bin/mail a link to mhmail will very likely cause a major disaster in the mail system. On the other hand, making /usr/ucb/Mail (or equivalent MUA) a link to mhmail would more or less work. -- =*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*= Neil W. Rickert, Computer Science <rickert@cs.niu.edu> Northern Illinois Univ. DeKalb, IL 60115 +1-815-753-6940
jromine@buckaroo.ics.uci.edu (John Romine) (01/29/91)
rickert@mp.cs.niu.edu (Neil Rickert) writes about /bin/mail: > 1. [/bin/mail] will deliver mail to a user's mailbox. > It is used in this way by [an MTA] to achieve final mail delivery. Yes, this is why you replace /bin/mail with "mhmail" only on systems which don't run an MTA. On systems *with* an MTA, you would simply use /bin/mail as-is to put the mail in /usr/spool/mail/username. If your local situation works better by running a sendmail on every machine and having MH fork/exec a sendmail to post mail, by all means do that. MH can support a more flexible posting method (SMTP), but it is not required. -- John Romine
pinkas@st860.intel.com (Israel Pinkas) (01/29/91)
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
rickert@mp.cs.niu.edu (Neil Rickert) (01/29/91)
In article <PINKAS.91Jan28172136@st860.intel.com> pinkas@st860.intel.com (Israel Pinkas) writes: >In article <1991Jan26.140602.5459@mp.cs.niu.edu> rickert@mp.cs.niu.edu (Neil Rickert) writes: >> > Q. What exactly are the benefits of using SMTP with mh? > >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 Well, it would be pretty dumb to configure MH to use 'sendmail' on a system that doesn't have sendmail. >2. You run mail clusters. All the mail delivery is done on the file >(...) >.. several other reasons deleted. Of course there may be reasons related to the local setup which would make you decide to use SMTP with MH. I certainly consider it a benefit of MH that it supports this. The MH documentation clearly says that SMTP is the preferred method with sendmail. Why is it preferred? Saying it is preferred implies that where both a direct pipe and SMTP are available choices, there are advantages to SMTP. So far the responses have not suggested any such advantages. I am inclined to conclude that this was merely the personal preference of the person who wrote the documentation. -- =*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*= Neil W. Rickert, Computer Science <rickert@cs.niu.edu> Northern Illinois Univ. DeKalb, IL 60115 +1-815-753-6940
dme@doc.ic.ac.uk (Dave Edmondson) (01/30/91)
In article <1991Jan29.124521.22710@mp.cs.niu.edu> rickert@mp.cs.niu.edu (Neil Rickert) writes:
rickert> Well, it would be pretty dumb to configure MH to use 'sendmail' on a
rickert> system that doesn't have sendmail.
that depends. if you use sendmail/smtp, and mail repositries are held
on another machine, then there is no need to have sendmail configured,
as it is never run.
dave.
--
Dave Edmondson, Systems Support. Opinions are all my own.
Department of Computing, Imperial College of Science, Technology and Medicine,
180 Queen's Gate, London SW7 1BZ. phone: 071-589-5111 x5085 fax: 071-581-8024
email: dme@doc.ic.ac.uk, ..!ukc!icdoc!dme, dme@athena.mit.edu
``Be selective, be objective, be an asset to the collective'' -- Jazzy Bandyc@bucky.intel.com (Andy Crump) (02/01/91)
>>>>> 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.