Sup Rocks

For the past 2 years or so, I’ve been using GMail to handle my main mail feed for jmason.org. I’m an absolute convert to its “river of threads”/search-based workflow.

Since starting at Amazon, I’ve had to start dealing with a heavy volume of work mail. Previously jobs have either had low mail volumes, or used Google Apps hosting for their mail, but Amazon’s volumes are high and — obviously — they’re not using Google. ;) For a while, I tried using Thunderbird, but it just didn’t really cut it; I could never keep track of mails I wanted archived, or remember which folder they were in, etc. — the same old problems that GMail solved.

Enter Sup. It’s a console-based *nix email client, with a Mutt-like curses interface, which offers something closely approximating the GMail experience:


Sup is a console-based email client for people with a lot of email. It supports tagging, very fast full-text search, automatic contact-list management, custom code insertion via a hook system, and more. If you’re the type of person who treats email as an extension of your long-term memory, Sup is for you.

Inbox Zero is a daily occurrence for my work email now; I can simply archive pretty much everything, and reliably know the excellent full-text search support will allow me to find it again in an instant when I need it. The new-user guide is well worth a read to get an idea of its featureset and UI.

Setting it up

The process of getting it set up is quite hairy; here are some instructions for Ubuntu, which thoroughly failed to work for me on 9.04. I had a similarly tricky time using some Ruby packages on the Red Hat work desktop, but eventually avoided it by just building vanilla Ruby from source, then using that to install “gem” and from that, “sudo gem install sup”. Much easier…

Next step is to get the mail. From some reading, it appears the most reliable way to deal with a MS Exchange 2007 server is to use offlineimap to sync it to a local set of maildirs, then add those as Sup “sources” using sup-add, one by one. This is very well supported in Sup, and works well. Offlineimap is very easy to install on Ubuntu, and can easily be built from source if that’s not an option. My config is pretty much a vanilla copy of the minimal config.

There’s a good Sup hook to run “offlineimap” every poll interval, and rescan synced sources that contain new mail. It works well.

Sup has an interesting approach to mail storage — it doesn’t. Instead, it stores pointers to the messages’ locations in their source storage. This is a great idea, since bugs in Sup therefore cannot lose your mail — just your metadata about your mail. However, it means that if the source changes in a way which moves or removes messages, you need to tell Sup to rescan (using “sup-sync”), but that’s no big deal in practice; in the more usual case, if new mail arrives, it’s automatically rescanned.

I have just under 7000 mail messages in my Sup index, and rescans are speedy and searches super-fast. It’s very nicely done.

Outbound mail is delivered using /usr/sbin/sendmail by default, which should be working on any decent *nix desktop anyway ;)

Recommended Hooks

The Hooks wiki page has a few good hooks that you should install:

  • ~/.sup/hooks/before-poll.rb: the above-mentioned offlineimap poll hook
  • ~/.sup/hooks/mime-decode.rb: ‘uses w3m to translate all HTML attachments that don’t have a text/html alternative.’ Well worth installing.
  • ~/.sup/hooks/before-add-message.rb: essential to filter out cron noise and the like so it doesn’t hit the inbox; unfortunately Sup doesn’t (yet) support GMail’s “filter messages like this” UI.

Bad Points

  • Long URIs: unfortunately, very long URIs are broken by Sup’s renderer, and it doesn’t offer a native way to “activate” URIs and have them displayed in the browser; instead one has to cut and paste them. This is pretty lame. I’ve hacked up a perl script that will reconstruct the full URLs from the broken rendering, when the text is piped to it, but that’s a horrible hack.

  • Index Corruption: I’ve had the misfortune (once, in the month since I started) of corrupting my search index, causing Ruby exception stack traces when I attempted to run “sup-sync” to scan new mail. The only fix appeared to be to restore my index from a “sup-dump” backup. Thankfully all seems fine now, but it was a definite reminder of the product’s beta status.

  • Calendaring: still as painful as it’s ever been with UNIX command line email.

  • HTML: A good-quality, email-oriented, native HTML renderer would be awesome.

  • MIME: Sup again takes the traditional approach from UNIX command line clients of delegating to the mailcap file and its rules; unfortunately my RHEL5 desktop is too crappy to have a good mailcap setup. So I’ve had to write this from scratch to deal with the usual .docs and .xls’s etc., flying about.

  • Inconsistent Key Mapping: Given that it shares so much UI with GMail in other respects, it’s a little annoying that Sup doesn’t have the same key mapping. Not a big deal, as it took only a couple of hours to get the hang of Sup’s, though.

Overall

If you’re happy enough to spend a day or two getting the damn thing installed, and aren’t afraid of a little dalliance with the bleeding edge, I strongly recommend it. It’s definitely the best *NIX mail reader at the moment.

This entry was posted in Uncategorized and tagged , , , , , , , . Bookmark the permalink. Both comments and trackbacks are currently closed.

6 Comments

  1. ben
    Posted December 19, 2009 at 01:39 | Permalink

    Jebus. A ringing endorsement this ain’t.

  2. Posted December 20, 2009 at 00:56 | Permalink

    You’ve seen notmuch? (http://notmuchmail.org/)

  3. Steve Burke
    Posted December 20, 2009 at 01:33 | Permalink

    Interesting. How does it handle gnupg? Can it decrypt gpg messages, and/or allow you to sign, encrypt emails? Thanks.

  4. Posted December 20, 2009 at 03:43 | Permalink

    @Steve: Sup does crypto (decrypt, encrypt, sign), dunno about notmuch really (if you were referring to it).

  5. Posted December 20, 2009 at 19:39 | Permalink

    Hello!

    The Sup mailing list was happy to see your post, and we do realize some of the sucky things you pointed out. Some points

    • If you use Xapian instead of Ferret (default) you may have a better time with search speed and index corruption. Ferret hasn’t been developed for ages.
    • You can use a hook to render html at times through w3c.

    Cheers.

  6. Posted December 21, 2009 at 14:46 | Permalink

    @Aristotle: haven’t tried it — I generally avoid stuff that hasn’t put out a tarball yet ;)

    @Andrei: thanks for the follow-up! I hope I haven’t been too critical, I’m really liking it.

    I looked at Xapian, but the wiki node makes it sound pretty bleeding-edge. if it’s not too hard to use, maybe it’d be nice to get that into the release?

    Also, I know about the w3m hook, but I’m more thinking about cases like when the message has a multipart/alternative containing a text/plain and a text/html; often the text/plain is a pretty crappy rendering, and a good native HTML renderer could do a better job. it’d be nice to have that option, and currently I think the hook won’t do it. I could be wrong though. (actually, I think I am wrong after all, looking again. ;)