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

[Robert Elz]

    Date:        Fri, 24 Jul 2015 11:41:14 -0400
    From:        Ken Hornstein <address@hidden>
    Message-ID:  <address@hidden>

  | 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.

You obviously don't use "send -push".   I do, and have almost forever.
Without that, sending mail is way too slow for me, I'd never (at least in
the past when sending e-mail was more important to my work/life) get
anything done if I had to wait for mail submission to finish before getting
on with the next.

The man page for send says of -push ...

       If -push is specified, send will detach itself from the user's terminal
       and perform its actions in the background.  If push'd and the draft
       can't be sent, then an error message will be sent (using the mailproc)
       back to the user.

If the problem is that mail can't be sent, because of some network problem,
and if we're requiring the network to work to send any mail, then that
"an error message will be sent ..." is not going to be very useful, is it?
Really, it isn't!

It isn't even all that unusual, I often do (or did) a lot of mail sending
from on planes, where they (at least did, these days sometimes it is
more possible) frown on using (even attempting to use) any kind of
network connection - yet it is an ideal place, with few interruptions, for
catching up with lots of pending messages.   But only if sending works,
eventually.

  | 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.

True, but that isn't relevant.   My comment was not any kind of a
criticism, or whatever - just an indication of what was likely required.
What's more, aside from being more restrictive, config that way also
tends to be easier.

  | - is really not all that hard,
  | Robert, I have to ask ... do you read all of the messages on this list?

Yes, though not always immediately.

  | 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.

Actually, no - I really mean "not all that hard" - it cannot be, or the
OS "vendors" (in quotes, because nmh is I think most commonly used on
free systems) would never survive - it all has to be no more difficult
that anything else to set up, and generally isn't.

The most recent issue was (I believe) with someone whose mail system in general
was working fine, but couldn't get nmh set up to use it easily.   nmh config
was the harder part.   It doesn't need to be.

  | - 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!

We all agree something needs to be configured to know the ISP's smarthost
right?   (At least in common configurations).   Do you really think it best
that that be every MUA on the system (if nmh is there, then there will be
at least 2, probably more - all with different config mechanisms) or would
it be easier to do just once, for a local (submission capable) MTA that
all the MUAs can be set up to use straight out of the box.   MH used to
default to that, and required no config to be able to send mail if anything
else on the system could do it.
 

  | 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.

Most people these days seem to send e-mail via a connection to a web
based e-mail system (hotmail, gmail, ...) and that MUA is almost certainly
connected pretty directly to its MTA - when the user presses the send
button, they can assume the mail will get sent (not just might) and they
don't have to wait for ages for that to happen.   Of course, without a
network, people using that model don't get to even read e-mail, but that's
their choice.

  | 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.

Depends what the issue is.   A one minute glitch while my ISP decides that
it is time to reset my connection so it can give me a different IP address
in the hope of preventing me running any kind of servers I prefer not to
know about at all ... it corrects itself, fairly quickly.   A "problem"
caused by being on a plane isn't something I can do anything about.

If there really is a network issue, and if I'm really unaware of it, I'm
much more likely to be made aware of them when attempting to fetch e-mail,
or even more likely, web browsing - I think I can allow e-mail sending to
look after itself - provided it works - and not try to make it double as
a diagnostic tool.

  | If we have to provide recipies for every MTA out there
  | to make them work with nmh ... ugh.

If we did, yes, that would be horrible.  But the sendmail interface is
so common these days (the basics are provided by just about everyone) that
all nmh needs to do (as a default) is find the sendmail binary (part of its
installation config process to look for it in one of the standard places)
and then run it to deliver mail.    If that doesn't work, then no other
standard basic e-mail interface on the system (like the posix mandated,
I think, "mailx") is likely to work either, and fixing one of them will
fix all.

Then the nmh MTA config can be available for people who want to have more
control or do things in different ways - but people should not be forced
to configure nmh at all, they should be able to just install & use it.

kre