[ Old subject: Re: [Nmh-workers] mts.conf has me Baffled.]
On Jul 24, 2015, at 6:09 PM, Robert Elz <kre(_at_)munnari(_dot_)OZ(_dot_)AU>
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,
While doing some inbox cleanup I came across this thread from last June. This
issue with MH not being able to queue and retry a failed send has been hitting
home. Since last fall I have had no DSL connectivity at home. To get on the
net, I have to tether up to my mobile's LTE service. And if you are at all
familiar with Canada's third-world data charging scheme, you will understand
this something I do selectively. (Actually, the "third world" has
significantly cheaper data rates than anything offered by the Canadian carriers
Now 'offline mode' has long been an issue (e.g. laptops on airplanes), and my
normal solution is to use UUCP between my laptop and the machine running my
MTA. MH can submit through rmail(1) quite cheerfully. But really, that's a
bit of overkill. And in the mobile phone universe, MUAs have grown the
capability of queueing sent mail if the network connection flakes out. There's
no reason why we can't do the same.
It could be as simple as divorcing send from the actual message injection.
I.e., send performs its current processing (e.g. call mhbuild), but '-push'
becomes the default, via an intermediate queue directory and an addition set of
The updated send would write the built message (with appropriate SMTP envelope
metadata) to a private queue directory, then exec a new 'mhsubmit' process that
would perform the actual message submission (via SMTP, or exec()ing some
external command). If the submission failed for lack of resources (no internet
connection), the message sits in the queue directory until something triggers
another delivery attempt.
Triggers would be things like trying to send another message (indirect
invocation of 'mhsubmit'), or an explicit request to run the queue. Probably a
new 'mhqueue' command should be grown, that allows the queue to be examined
and manipulated, rather than just kicked.
This would sort of emulate what I can do with, e.g., Apple Mail right now. I
can compose offline, and after clicking through some nag boxes, the MUA will
queue the message up and try sending again the next time it sees a network
How many of you would find this actually useful? Is it even relevant any
longer? I know I'm an outlier, and the UUCP hack still works well for me when
I need it.
Nmh-workers mailing list