[Top] [All Lists]

Re: [Nmh-workers] Local submission queues

2016-02-21 19:27:34
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).


On Sun, 21 Feb 2016 17:07:30 -0800 Lyndon Nerenberg 
<lyndon(_at_)orthanc(_dot_)ca> sez:

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

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

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.


_______________________________________________ Nmh-workers
mailing list Nmh-workers(_at_)nongnu(_dot_)org

Nmh-workers mailing list

<Prev in Thread] Current Thread [Next in Thread>