[Top] [All Lists]

Re: time delayed sending

2019-12-27 11:06:22

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 
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:
    send -> my-back-post-replacement -> disk
    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    [


Attachment: signature.asc
Description: PGP signature

<Prev in Thread] Current Thread [Next in Thread>