Re: [Nmh-workers] mts.conf has me Baffled.

[Ken Hornstein]

>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