Ken Hornstein <kenh@pobox.com> wrote:
>> I occasionally do this by combing at(1) with mhmail(1) or send(1). MH
>> is designed to integrate with the Unix shell so instead of MH growing
>> features, I'd initially look more at combining cron(8) with a shell
>> script that sends email whose time has come. Perhaps that's detected
>> by the name of the draft folder where they reside, or a header that's
>> --searched for with pick(1).
> I'm with Ralph here; it seems like nmh already has these tools to
> leverage. But it would be interesting to hear whatever solution you
> come up with.
I don't think I'll need core changes to code :-)
I might wind up with a one-off someplace to make my life easier.
I just wondered if I was building only for me.
>>> On a related (organizationally, but technically probably orthogonal)
>>> note, I have been thinking that it would be nice if nmh supported
>>> responding to Disposition-Notification-To: headers somehow.
>>
>> https://tools.ietf.org/html/rfc8098#section-2
> I think the technical issues are relatively straightforward, except
> maybe that we'd need to make sure messages are marked so they don't
> ever get notified multiple times. There are some UI issues to work
> out; like, do you want to do some action to repond to that? Or have it
> done automatically? The latter might be hard today, but the former
> should be easy.
There are two aspects: generating the responses, and processing the responses.
One of the things I think we lack of a message-ID -> message map.
We have discussed ways to store per-message meta-data outside of the message
file many times, and I don't think we ever came to a conclusion here.
While I can see implementing this without the mapping, it would make it easiest
to
do if one could leverage that.
>> That's where I was going. I would use a custom post that looked for
>> some header, and if found, would move the outgoing email to some
>> directory. A cronjob would for f in SOMEDIR/`date +something`/*; do
>> post <$f; done.
> I would just caution you that "post" is really designed as a backend
> program, and you have to be careful when you use it directly. I'd
> suggest you use 'send' instead.
so, it's gonna be okay to do:
now:
send -> my-back-post-replacement -> disk
later:
disk -> send -> post
--
] Never tell me the odds! | ipv6 mesh networks [
] Michael Richardson, Sandelman Software Works | IoT architect [
] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [
signature.asc
Description: PGP signature