Re: [Nmh-workers] Local submission queues

[Ken Hornstein]

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