[...]
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.
So it occurs to me you could MOSTLY do this right now without any changes
to nmh.
Specifically, send is already divorced from the actual message injection;
it calls post(8) to do all of the dirty work (I suspect you already knew
that). You can stuff your own magic in there via postproc.
So, you could have your own postproc check the exit value of the 'real'
post(8) and if it fails, grab the outgoing message and hide in your
queue directory. You'd also have it check for any messages in the queue
directory and try submitting those at the same time. You don't need to
save any SMTP envelope metadata, because post(8) gets that out of the
message headers today.
The 'mhqueue' commands could be simple shell scripts that operate on
the queue directory.
--Ken
_______________________________________________
Nmh-workers mailing list
Nmh-workers(_at_)nongnu(_dot_)org
https://lists.nongnu.org/mailman/listinfo/nmh-workers