[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Nmh-workers] Local submission queues
Re: [Nmh-workers] Local submission queues
Sun, 21 Feb 2016 17:27:18 -0800
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
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 <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
> 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 address@hidden