time delayed sending

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

time delayed sending

Michael Richardson-5

I find myself making todo notes for emails that I need to send after Jan. 1.
Because sending them now will just wind up in people's "dig out bucket", and
I actually want to pause a bit before sending things.

Do I want this for times other than Xmas?
I suspect it would useful for people who are trying to establish time
boundaries for when they expected to answer email: They could avoid posting
work email on the weekend (or outside 9-5) until the next work time period.

(and actually, this email should be in that list...)
This somehow fits into how I do Gettings Things Done.

I was thinking whether it was worth having some mechanism where I would write
an email, get it all ready to send (including GPG signing it in mh-e), but
keep in a numbered/dated draft directory and then send it on the appropriate day.
I think that this would involve an alternate post program; I haven't thought
at all about how I'd control that.

**
   I just thought I'd ask if there were other people who
   might have such a need
**

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.

What I also really want is to be able to mark an email as needing responding
to, and to keep the outgoing content in some list (a folder with a -link to
+outgoing) as having been not responded to.  If I keep the outgoing email in
my inbox, it kinda works, but then it clutters my inbox :-)

Ideally, the acknowledgement to the Disposition-Notification-To would get
matched back to that email, but also any incoming In-Reply-To/References
would linked up.  Basically, I want TCP ACKs for email.
It would also be nice if I could better link up bounce messages so that
stuff in my "Waiting for Others" list could bump back up.

Gmail does this right.  (Maybe Thunderbird does too now)
But, if I wanted to use a search engine in a browser for my email, I'd be
doing that :-)



ps: I've been watching a ton of youtube videos from the 8-bit guy.
    http://www.the8bitguy.com/ many of you are of a similar technical age as
    me.  I am considering whether teaching my 14-year old programming on the
    C-64 would make sense.


--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     [hidden email]  http://www.sandelman.ca/        |   ruby on rails    [





signature.asc (497 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: time delayed sending

Ralph Corderoy
Hi Michael,

> I find myself making todo notes for emails that I need to send after
> Jan. 1.
...
> I was thinking whether it was worth having some mechanism where I
> would write an email, get it all ready to send (including GPG signing
> it in mh-e), but keep in a numbered/dated draft directory and then
> send it on the appropriate day.  I think that this would involve an
> alternate post program; I haven't thought at all about how I'd control
> that.

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).

> 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

> What I also really want is to be able to mark an email as needing
> responding to, and to keep the outgoing content in some list (a folder
> with a -link to +outgoing) as having been not responded to.  If I keep
> the outgoing email in my inbox, it kinda works, but then it clutters
> my inbox :-)
>
> Ideally, the acknowledgement to the Disposition-Notification-To would
> get matched back to that email, but also any incoming
> In-Reply-To/References would linked up.  Basically, I want TCP ACKs
> for email.  It would also be nice if I could better link up bounce
> messages so that stuff in my "Waiting for Others" list could bump back
> up.

What do you mean by ‘bounce messages’?  I don't see how what I think of
as bounces would fit in.

--
Cheers, Ralph.

Reply | Threaded
Open this post in threaded view
|

Re: time delayed sending

Michael Richardson-5

Ralph Corderoy <[hidden email]> wrote:
    >> I find myself making todo notes for emails that I need to send after
    >> Jan. 1.
    > ...
    >> I was thinking whether it was worth having some mechanism where I
    >> would write an email, get it all ready to send (including GPG signing
    >> it in mh-e), but keep in a numbered/dated draft directory and then
    >> send it on the appropriate day.  I think that this would involve an
    >> alternate post program; I haven't thought at all about how I'd control
    >> that.

    > 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).

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.

    >> 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

Yes, I knew how it worked.
We don't offer any way to respond, and I'd like to be able to optionally
respond :-)

    >> What I also really want is to be able to mark an email as needing
    >> responding to, and to keep the outgoing content in some list (a folder
    >> with a -link to +outgoing) as having been not responded to.  If I keep
    >> the outgoing email in my inbox, it kinda works, but then it clutters
    >> my inbox :-)
    >>
    >> Ideally, the acknowledgement to the Disposition-Notification-To would
    >> get matched back to that email, but also any incoming
    >> In-Reply-To/References would linked up.  Basically, I want TCP ACKs
    >> for email.  It would also be nice if I could better link up bounce
    >> messages so that stuff in my "Waiting for Others" list could bump back
    >> up.

    > What do you mean by ‘bounce messages’?  I don't see how what I think of
    > as bounces would fit in.

If you mis-address an email, then you get an email back from postmaster
saying so.  The problem is that there are also lots of spammer who forge
origin addresses, and so for years (decades...) 99% of email from postmaster
is spam backscatter, and one tends to skip it.

I want to re-associate the bounce back to the message I sent, particularly if
it's one that I marked for "reliable" email.

That would be a clear user-level NAK, which means I need to figure out what happened.
Otherwise, I'm just waiting wondering why the other person hasn't answered
yet.  And I for instance, sometimes take a month to answer an important, but
not urgent query.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     [hidden email]  http://www.sandelman.ca/        |   ruby on rails    [


signature.asc (497 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: time delayed sending

Ken Hornstein-2
In reply to this post by Ralph Corderoy
>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.

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

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

--Ken

Reply | Threaded
Open this post in threaded view
|

Re: time delayed sending

Michael Richardson-5

Ken Hornstein <[hidden email]> 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   [
]     [hidden email]  http://www.sandelman.ca/        |   ruby on rails    [


   


signature.asc (497 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: time delayed sending

Ken Hornstein-2
>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.

Weeellll ... I mean, we have the command-line INTERFACE for that, I
think; pick(1) seems like the obvious answer.  Sure, right NOW it
trawls through every message in a folder, but there's no reason it
couldn't look at some kind of metadata index.  Paul Vixie wrote
something like that a while ago.

>so, it's gonna be okay to do:
>now:
>   send -> my-back-post-replacement -> disk
>later:
>   disk -> send -> post

Yeah, that should be fine.

--Ken

Reply | Threaded
Open this post in threaded view
|

Re: time delayed sending

Michael Richardson-5
Ken Hornstein <[hidden email]> wrote:
    >> 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.

    > Weeellll ... I mean, we have the command-line INTERFACE for that, I
    > think; pick(1) seems like the obvious answer.  Sure, right NOW it

okay. But, I want it to operate across "all" folders.
I realize that the definition of "all" is pretty loose.
So I'll say everything in ~/Mail

    > trawls through every message in a folder, but there's no reason it
    > couldn't look at some kind of metadata index.  Paul Vixie wrote
    > something like that a while ago.
   
I'd like it to look through a database in the local folder if it's not
in ~/Mail, and otherwise look in ~/Mail.

I am open to logic like, look up the file system for ../.MAGIC until you find
it so that one can do stuff like:
   mv ~/Mail /otherdisk/oldstuff/y2009

but then you also think you might like it to look through a $PATH of files
too...

There are two things that matter:
1) updating the reference in the right place when moving/filing messages. (building)
2) where pick --message-id will look.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     [hidden email]  http://www.sandelman.ca/        |   ruby on rails    [



Reply | Threaded
Open this post in threaded view
|

Re: time delayed sending

Ralph Corderoy
Hi Michael,

> > Weeellll ... I mean, we have the command-line INTERFACE for that, I
> > think; pick(1) seems like the obvious answer.
>
> okay. But, I want it to operate across "all" folders.
> I realize that the definition of "all" is pretty loose.
> So I'll say everything in ~/Mail

folders(1) can give you that list.  For each of them, with $f the folder
name, build an index with something like

    scan -width 0 -forma "%{message-id} $f %(msg)" +$f last:20 |
    sed 's/^ /- /'

This can be sorted and used with join(1), egrep(1), etc.  It only reads
the headers of each email's file, not the body, and is quite quick once
they're cached in RAM.

> 1) updating the reference in the right place when moving/filing
> messages.  (building)

You might find it easier to have inotify(7) watch directory hierarchies
of interest rather than try and modifying all the things that might
cause the index to diverge.  Or just see if the index can be a useful
first approximation that works in 99.9% of cases, falling back on a
search when it doesn't, and re-building the whole index periodically.

--
Cheers, Ralph.