[Nmh-workers] Local submission queues

[Lyndon Nerenberg]

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

> On Jul 24, 2015, at 6:09 PM, Robert Elz <address@hidden> wrote:
> 
> 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.

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 
:-P)

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

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


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.

--lyndon