nmh-workers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Robert Elz
Subject: Re: [Nmh-workers] mts.conf has me Baffled.
Date: Fri, 24 Jul 2015 12:55:45 +0700

    Date:        Thu, 23 Jul 2015 11:42:43 -0400
    From:        Ken Hornstein <address@hidden>
    Message-ID:  <address@hidden>

  |   See send(1) for more details; if features are missing
  |   or things are broken, please let us know!

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.

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

Duplicating all that work in nmh would really be pretty silly.   Adding the
ability to recognise local messages, and just deliver them locally isn't
usually all that much harder, if that is desired.

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.

There's only one system you can guarantee to be able to contact at any
arbitrary time, and that's the system you're starting from (we know it is
running, after all) - so that system has to have the ability to hold onto
outgoing messages, and deliver them wherever they need to go next, when it
becomes possible to do so.   nmh does not currently (without human assistance)
to do that.   Having nmh connect (via fork/exec, or via MSP or SMTP) to a
process (aka MTA) on the local host that does have that ability is the
only current really rational approach that's reliable.

kre




reply via email to

[Prev in Thread] Current Thread [Next in Thread]