snooze your INBOX

A few days ago Chris made me realize that my GTD setup was still missing a piece: a proper tickler file implementation.

As I wanted an IMAP-free implementation, I've rolled up my own: rotate-tickler. Nothing too fancy: shell script triggered by cron, which moves mails around a set of DELAYED.{1,..} maildir-s. Still, it is careful about clashes (which shouldn't happen according to the maildir specs, but better be paranoid with mails), and properly cleans up the "seen" flag for the final (re)delivery in INBOX.

Give it a try and feel free to git format-patch-me your improvements. (BTW, does it make any sense today to publish any piece of software, no matter how small, without shelving it into some DVCS?)

I had that for a long time and found it quite inflexible due to two main reasons:

  1. The mails would be in Mail.DELAYED.* folders, rather than in the store I use for all received/sent mails, and mutt would not be able to present me with the entire thread.

  2. I found that I wanted delays up to a couple of months and that a folder for each day didn't scale. Also, if the cronjob didn't run one day, everything would be delayed.

I ended up rewriting the messages with an X-Tickler header, containing the timestamp when to resubmit the message. A cron job scans the store mailbox regularly and picks those messages that have "expired". It also adds a Received line to tell my mailer that it's a recent message.

This works fine and now allows me to tickle messages in 30 minutes, 7 hours, or 2,5 years. It scales just fine. My store box has several tens of thousands of e-mails at a time, and I don't index them for X-Tickler, but I just grep them all. This could be improved (I did try with an sqlite index at some point), but so far there has been no need to add complexity and redundancy.

All my code is on, though it's arguably not very clear. Eventually, I hope to complete

Comment by Mon 10 May 2010 12:02:13 PM CEST

The original tickler file proposal by Allen spans at most 1 year and has two different granularities: day-by-day for the period now + 30 days, month for the rest of the year. My script only support day-by-day granularity and in fact I'm considering adding month support.

The reason why I've refraining from doing that thus far, is that I don't postpone for too long delays. Instead of doing that I prefer to shelve actions under "someday/maybe" as for how I work commitment too far away in the future are by no mean certain.

That notwithstanding, I would definitely welcome the integration of this into your mailfilter, as the current description of it (at least in Debian) was silent for me on the fact that it does support this kind of stuff.

Thanks for your feedback!

Comment by zack Mon 10 May 2010 02:34:04 PM CEST
sweet! I also liked the idea of Chris' post but also wanted something without imapfilter. thanks for writing that script before I found the time to do so :)
Comment by gregoa Mon 10 May 2010 05:52:19 PM CEST

As of now, rotate-tickler is now able to do the final delivery (or DELAYED/0 if you want) via procmail.

That way, mails which get into the tickler file from a specific maildir (since delivered there by procmail in the first place) will be able to re-enter back from where they left.

Code is available at the usual place.

Comment by zack Wed 03 Nov 2010 08:07:43 PM CET