[ Old subject: Re: [Nmh-workers] mts.conf has me Baffled.] > On Jul 24, 2015, at 6:09 PM, Robert Elz <[email protected]> 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 [email protected] https://lists.nongnu.org/mailman/listinfo/nmh-workers
