git.cworth.org Git - cworth.org/blob - src/sup/a-mail-client-for-geeks.mdwn

   1 [[!meta title="Sup - a mail client for geeks"]]
   2 [[!tag sup tools]]
   3
   4 For quite some time I've been struggling with hundreds of email
   5 messages a day, and hundreds-of-thousands of email messages in
   6 archives to search. I've used several different email programs to try
   7 to handle my mail, (pine, vm, mh-e, wanderlust, evolution, mutt), and
   8 experimented with several others, but not until now did I find one
   9 that really helps me process mail the way I want to.
  10
  11 Before I introduce [sup](http://sup.rubyforge.org/), though, I want to
  12 at least mention in passing a mail indexer named
  13 [mairix](http://www.rpcurnow.force9.co.uk/mairix/) since I've been
  14 meaning to write a blog entry about it for several months. Anthony
  15 Towns first let me know about mairix earlier this year when I was
  16 complaining about email near him. He described his approach to mail as
  17 "mutt for reading mail and mairix for searching".
  18
  19 The way mairix works is that it creates an index of a mail archive
  20 then provides a command-line-based search that creates results by
  21 creating a new maildir, (with just symlinks to original messages if
  22 the original archive is also maildir-based).
  23
  24 So mairix can give you a simple way to add fast, full-archive
  25 searching to a program like evolution when its builtin search
  26 capability is hopelessly inadequate for your large mail archive. The
  27 mail client can be configured to look at a single search-results
  28 maildir folder, and mairix can be used to create the results there.
  29 Do note that mairix is somewhat limited as a mail search engine since
  30 it has no proximity or phrase-based searching, (the best you get is
  31 whether messages contain given words). But the maildir-in and
  32 maildir-out approach it has makes it easy to integrate, and is the
  33 kind of concept that can perhaps let us avoid some of the disasters
  34 out there in the form of monolithic email clients.
  35
  36 But I've got a much more interesting story in sup. I was just a few
  37 days into reinventing my email workflow around mutt when I got into an
  38 interesting conversation with Jamey Sharp about what the ideal
  39 mail-handling system would look like. Here are some of the ideas we
  40 came up with:
  41
  42  * Program presents me with messages that need my attention, (a
  43    chronological sort of the archive with unread items in bold does
  44    not count).
  45
  46  * When I decide a message does not need my attention I can make it
  47    "go away" into the archive, (and "mark as read" does not
  48    count---I want to file away messages but still track whether
  49    they are read or not in the archive).
  50
  51  * Threads must be first-level objects, (in particular I want a
  52    kill-thread command that archives not only the current messages,
  53    but all future messages received in a given thread).
  54
  55  * System should support arbitrary tags on messages. Tags can be
  56    applied automatically, (such as applying categories to mail
  57    received on lists), and applied ad-hoc by the user.
  58
  59  * System should allow searching over the entire archive with most
  60    recent results appearing instantly. Search terms can include
  61    tags, message headers, or full-body search (including phrases).
  62
  63  * In addition to full-archive search, incremental refinement
  64    should be possible, (a new search based on the results of a
  65    previous search).
  66
  67  * There's no need for folders in this system. Tags and
  68    incrementally refined, tag-based searching provide all the
  69    benefits, (without the bug in folder-based systems where a user
  70    has to hunt among many folders to find one where a search
  71    returns non-empty results). In particular, the "inbox" view
  72    should just be a search for unread and non-archived messages.
  73
  74 That was basically our list of core features. Beyond that, we also
  75 discussed some further ideas for improving the prioritization of email
  76 threads to the user. One primary job of the system is to present the
  77 user with the most important thread to be read next, (based on tags,
  78 etc.). The user supplies feedback by either reading the thread or
  79 archiving it, so there's opportunity to apply machine learning to
  80 improve the prioritization.
  81
  82 During the course of this conversation, Jamey mentioned that I should
  83 go look at [sup](http://sup.rubyforge.org/) which he thought might
  84 implement some of these features, but he hadn't tried it out yet. I
  85 was delighted to find that each one of our core features already
  86 exists in sup, (and sup would make a fine platform for research into
  87 the learning-based approaches).
  88
  89 It also does a few things I hadn't specified, such as displaying email
  90 in a full-thread nested view, (rather than one message at a time),
  91 with quoted elements and signatures folded out of view until the user
  92 asks to see them. Another nice touch is that the single-line
  93 presentation of a thread includes the first names of participants in
  94 the thread, (with bold names to indicate unread messages). This
  95 provides some of the essential information needed for applying Joey
  96 Hess's [thread
  97 patterns](http://joey.kitenet.net/blog/entry/thread_patterns/), but
  98 without the tree view at this point.
  99
 100 [Note: I have been told that several of the above features are also
 101 implemented in gmail. I've never tried gmail myself, since it fails to
 102 provide some even more fundamental features: 1. <del>offline
 103 usage</del>, (thanks to both Mark and Greg for pointing out that gmail
 104 has offline support in beta via gears) 2. personal ownership of email
 105 storage, 3. free-software implementation for customization.]
 106
 107 In the few days I've been using sup, it's definitely transformed the
 108 way I process mail. Keeping my inbox empty is simple now, and I now
 109 easily tag messages for specific, future actions without fearing that
 110 I will forget, (and without leaving them cluttering up my
 111 inbox). Searching through my entire archive is fast---the first
 112 results come back instantly and they're generally what I want, (the
 113 index is optimized to return the most-recent messages first).
 114
 115 Sup is implemented in ruby, and the author and maintainers on the
 116 [sup-talk](http://rubyforge.org/mailman/listinfo/sup-talk) mailing
 117 list have been friendly and receptive to me, (in spite of my lack of
 118 ruby-clue), so I've already got a patch or two in the upstream git
 119 repository for sup. The indexing in sup has been performed by
 120 [ferret](http://www.davebalmain.com/), but is currently switching to
 121 [xapian](http://xapian.org/).
 122
 123 Sup is not entirely mature yet, (I discovered fairly easy ways to make
 124 the 0.8.1 version in Debian crash), but I'm happily running the latest
 125 code from git now, and trusting my mail to it. I did find that a bug
 126 in a dependent package causes sup to crash when running sup from git
 127 while sup is also installed from the Debian package. So I recommend
 128 doing "apt-get install sup-mail" to get the dependencies installed,
 129 then "apt-get remove sup-mail" (but don't autoremove the
 130 dependencies), then run sup from:
 131
 132         git clone git://gitorious.org/sup/mainline.git
 133
 134 I've also posted a [short
 135 list](http://rubyforge.org/pipermail/sup-talk/2009-August/002815.html)
 136 of some changes I'd like to see in sup, (mostly in the client
 137 stuff---the indexing and searching stuff seems just fine).
 138
 139 There's a nice New User's Guide included with sup, but no reference
 140 manual yet, so the [sup wiki](http://sup.rubyforge.org/wiki/wiki.pl)
 141 is an essential (and short) substitute for a reference manual for now.
 142
 143 One thing sup does not do yet is that it doesn't separate the
 144 mail-indexing/tagging/searching system from the mail client. So if
 145 you're not happy with a curses client written in ruby, (and perhaps
 146 more significantly, a *different* client than what you're currently
 147 using for composing messages, making attachments, viewing mime stuff,
 148 etc.) then you're currently out of luck. Fortunately, William Morgan
 149 has [plans](http://all-thing.net/old13) to reinvent the most
 150 interesting aspects of sup as a server process and he recently
 151 reported making progress on those plans over the last year. (This
 152 isn't too surprising, since why would William want to maintain all that
 153 code to do things like dealing with mbox, maildir, attachments,
 154 etc. when those are already solved problems for users everywhere.)
 155
 156 And hey, I would *love* to have a mailing list archiver based on sup's
 157 threading. So if anyone wants to cook something like that up, please
 158 feel free, (sup is licensed under the GNU GPLv2).