>I know that was really asking about TLS features, but if you were really >to be serious about creating an environment where it was truly possible >to run nmh without a local MTA (or half MTA - receiving & delivering incoming >mail is not needed) then you'd have to add queue & retry to nmh's send.
Meh. I've lived with the lack of queue and retry for a long time in the nmh send(1) program; it seems in practice it's not a real problem. If there is a failure the user gets immediate notification. That seems to be as good as other MUAs do. If you really want queue/retry you are of course welcome to configure a MTA submission agent. >Personally I don't think that's rational - configuring any of the common MTAs >to a sufficient state to allow it to accept local mail, queue it, and deliver >it to a "smarthost" (like the ISP's MTA if that's what you have to do) is >really not all that hard, most systems nmh will run on tend to come (almost) >set up that way out of the box anyway (they do need to be told where mail needs >to be sent, and when appropriate, the relevant credentials to use.) Sigh. I cannot disagree more strongly with you. First, let's break down what you said: - (like the ISP's MTA if that's what you have to do) We all know you have an amount of control over your email setup that is far beyound the norm. So if the user is NOT Robert Elz, then the odds are very likely that you have to submit to your ISP's smarthost, and you probably don't have a choice about it. - is really not all that hard, Robert, I have to ask ... do you read all of the messages on this list? I can completely understand if you don't ... but I do. And I can tell you that while there are a number of people, like yourself, who are perfectly capabable of configuring their MTA, there's also a good number of people who cannot, either from lack of knowledge or interest. nmh should serve those people as well. So when you say, "really not all that hard", you're speaking as someone who's been in and out of the deep levels of Unix for many decades. That is not true of everyone (and I hope it's not a nmh requirement). For many people, yes, it is too hard. - most systems nmh will run on tend to come (almost) set up that way out of the box anyway "almost"? To me, that means that it's NOT configured! It doens't work! - But not being able to send mail (and depending upon how you use nmh, often not even being told about it - beyond an unsent draft being left around) just because the network happens to be out at the time you finish composing is totally unacceptable. Well, like I said ... in practice it doesn't seem to be a problem. And this seems to be pretty much the standard in terms of how MUAs behave nowadays. I could certainly see that users might want to know about network issues and have a chance to correct them instead of having email silently queued. The real problem, to me, boils down to the issue that nmh technically is not in the business of telling you how to configure your MTA. That's up to you and that's fine. But ... it turns out as we've seen on this list times and times again, that's hard for a number of users. Essentially no other MUA requires you to have a properly configured local MTA; they all can submit directly to a smarthost. So it is entirely reasonable in my opinion that a) we provide, natively, all of the tools to do SMTP mail submission, b) we document how all of our tools work, and c) we tell users that this is supported mechanism (but we point them to the man page if they want to do something else). Telling people that the preferred mechanism is to configure their local MTA and submit to that is just lousy. If we have to provide recipies for every MTA out there to make them work with nmh ... ugh. That just seems like the wrong approach. But like I said, if you want to use what I call "expert mode" and submit to your local MTA, please, do that! --Ken _______________________________________________ Nmh-workers mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/nmh-workers
