Re: [Nmh-workers] Local submission queues

[Bob Carragher]

I would definitely try something like what Lyndon proposed.

I'm almost certainly another outlier.  I also have a home-grown
way of dealing with deferred email posting.

In my case, I simply (and literally) refile messages into a
Pending folder instead of "send"-ing at the end of a
comp/repl/forw.  I have a script which I run once I'm reasonably
sure that I have good Internet connectivity; the script renames
the message files, one at a time, to the default "draft"
filename, and then requests MH to send them without further
processing.  (There are a few check and safety bits in the script
as well.)

The main reason is that I sometimes find myself with my laptop in
a place with no reliable connection to the Internet, either
through WiFi/ISP or mobile phone network hotspots.  (Despite
living in Silicon Valley, my ISP and cell phone carrier can both
be flaky.  Monopolies can also lead to "third world" situations.
I also travel to relatives' places, which can be even worse.)  In
addition, I sometimes want to wait to send some messages until
later, but want to compose them earlier -- regardless of the
(current) connectivity level.  (It's one trick I use to keep
email from completely taking over my life.)

What would work well for me would be a setup where I can have
"queue processing" settings -- e.g. by default always queue
messages and wait for Bob to invoke 'mhsubmit' (and then keep
[re]trying until all are successfully sent) -- that can be
overridden in the existing commands (e.g. in addition to the
"send" option you have a new "send_right_now_i_mean_it" option).

                                Bob

On Sun, 21 Feb 2016 17:07:30 -0800 Lyndon Nerenberg <address@hidden> sez:

> [ 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
>
>
> _______________________________________________ Nmh-workers
> mailing list address@hidden
> https://lists.nongnu.org/mailman/listinfo/nmh-workers