[go: up one dir, main page]

|
|
Log in / Subscribe / Register

Not much of an email review

By Jonathan Corbet
March 24, 2010
Back in 2004, your editor grumbled about the state of electronic mail clients, noting that much of the wisdom encoded in the venerable MH system seemed to have been lost. Nearly six years later, it often seems that the situation has not improved much. Contemporary email clients are large, monolithic blobs which may look pretty, but they do not play well with other tools and seem to get in the user's way as often as not. So, when Dave Jones said in 2007:

I'm convinced there's some contest to see who can make the worst graphical mail client for Linux. I'm not sure what the prize is, or who's winning, but the entries so far are horrific.

Your editor had no choice but to agree. Since then, the situation does not appear to have improved much.

The Notmuch mail client has been on your editor's radar for some months now. Recently, the opportunity to play with this new tool came by; this review is the result. In short: Notmuch looks like it is coming from the right place, but, as befits a program in such an early stage of development, it has some ground to cover yet.

The core of Notmuch is a command-line client which, as they say, does not much. One starts by running notmuch setup to put some basic information into the configuration file, followed by notmuch new to initialize the mail database. That process involves reading and indexing every message you have (messages are stored one-per-file, so Notmuch deals just fine with MH or Maildir trees). Even though the program cheerily declares that you have "not much mail" at setup time, the indexing process can take quite a while; it also doubles the size of the mail store. This step is not optional, though; indexing is at the core of how Notmuch works.

After setup, one can use the notmuch client to perform searches, modify tags, display messages, and compose replies. In a sense, it looks back to the early MH days, when everything was done at the shell prompt. The Notmuch developers do not really expect that users will use the [Notmuch search results] command-line client directly, though; instead, it is assumed that some sort of user interface will be layered over it. There are a few such interfaces available now, but the interface of choice for the Notmuch developers at the moment would appear to be Emacs.

The Emacs notmuch-mode looks, in many ways, like most other Emacs-based mail clients. There are a few differences, though, starting with the fact that folders are a completely alien concept. This is 2010, and folders have been consigned to a dim, dusty, and hierarchical past; now we do everything with tags. So there's no "inbox" in Notmuch; instead, one sees the results of a search for the "inbox" tag. Something similar to refiling can be done, should one so desire, by attaching different tags to the message, but one gets the sense that's not expected to happen very often. This is the era of search, so a specific view of the mail store is just a search away.

Indeed, searches in Notmuch (powered by Xapian) are very fast and very flexible. The syntax is reasonably straightforward and the results are nearly instantaneous. There is an easy feature for further narrowing the results of a search. It is a powerful and flexible way to deal with large quantities of mail.

The process of reading through mail, though, is still in need of some work; the Emacs interface is not, yet, at the level of usability offered by, say, MH-E - and one would ideally set the bar higher than that. There does not appear to be a way to look at the structure of threads in the [Notmuch message display] folder search results view; each thread is collapsed into a single line with a few of the participants listed. Displaying that thread dumps all of the messages into a single Emacs buffer, which can then be paged through. Your editor would rather see the thread structure and individual messages, preferably at the same time.

Working through mail, your editor notes, can be quite slow, with noticeable delays between messages. That would appear to be a result of the removal of the "unread" tag from each message as it is viewed. Tagging operations in general seem to require significant index changes; it may well be that storing mail on a solid-state storage device will be required to get acceptable performance for this kind of operation.

Notmuch doesn't handle composition and sending of mail at all; it defers to the standard Emacs message mode for that. It also doesn't try very hard to display attachments; images, for example, are handed off to external helper programs even though Emacs can display such things inline. When it comes to HTML parts, notmuch-mode does not even try; this, of course, might be seen as a significant advantage.

Is your editor switching to Notmuch? Not yet. Notmuch requires that all mail be stored locally, but your editor likes having that central IMAP server available. There are developers working on tools for synchronizing mail and tags between stores; some folks are even seriously looking at using git as the underlying mail store. There's also no support for multiple email accounts; that is probably trivially fixable by adding a command-line option allowing easy use of multiple configuration files. And the interface remains a little rough.

In the longer term, though, Notmuch could well become your editor's mail tool of choice. The fundamental approach looks right, and the tool-oriented nature of the plumbing should enable the easy scripting of operations on messages. There is an active and growing community of users and contributors; Notmuch has the look of a successful project. This tool looks like it could become a powerful utility indeed in not much time at all.


to post comments

Not much of an email review

Posted Mar 25, 2010 4:12 UTC (Thu) by kvaneesh (subscriber, #45646) [Link] (1 responses)

"Working through mail, your editor notes, can be quite slow, with noticeable delays between messages. That would appear to be a result of the removal of the "unread" tag from each message as it is viewed"

This below should help in speed up of tag updates.
http://article.gmane.org/gmane.mail.notmuch.general/1106

-aneesh

Not much of an email review

Posted Mar 29, 2010 4:48 UTC (Mon) by cworth (subscriber, #27653) [Link]

It's too bad that our editor had to see this performance bug---it's just
the kind of thing that might make him grumpy.

Upgrading Xapian should make notmuch quite snappy when making tag
manipulations such as removing the "unread" tag while reading messages.
The performance bug is fixed in the upstream Xapian versions (1.1) as
well as backported to Xapian 1.0.18 (which appears in Debian testing now,
I believe).

But all in all, a very reasonable review. Thanks, corbet!

-Carl

Not much of an email review

Posted Mar 25, 2010 5:30 UTC (Thu) by b7j0c (guest, #27559) [Link] (1 responses)

booyah! as far as i can tell these are the only screenshots of notmuch on the internet!! thanks, i've been trying to get more info on this project

Not much of an email review

Posted Mar 25, 2010 16:34 UTC (Thu) by eparis123 (guest, #59739) [Link]

Not much indeed ;)

Not much of an email review

Posted Mar 25, 2010 18:35 UTC (Thu) by nix (subscriber, #2304) [Link] (4 responses)

This is 2010, and folders have been consigned to a dim, dusty, and hierarchical past; now we do everything with tags.
Unless tags can be added by procmail, or by implication ('directory' tags corresponding to the mail's storage location, for example) it seems to me that this makes the whole thing nearly useless: how do you keep distinct mailing lists separate, for instance?

I still haven't found anything to compare to Gnus's 'everything looks like Usenet' approach. Gnus with a xapian searching backend would be amazing. ... and now I look for it I see that there is an nnmairix backend, which all the cool people probably knew about years ago. I think I'll be trying that...

Not much of an email review

Posted Mar 25, 2010 21:07 UTC (Thu) by foom (subscriber, #14868) [Link] (1 responses)

If you use sieve instead of procmail, you can add tags during delivery. Probably if you use an
alternative delivery agent with procmail you can add tags too, but I don't know.

Not much of an email review

Posted Mar 26, 2010 13:29 UTC (Fri) by nix (subscriber, #2304) [Link]

Well, procmail can execute arbitrary code at delivery time, so I suppose it probably can add tags. If it's as simple as adding a mail header, it'll be easy.

Not much of an email review

Posted Mar 25, 2010 22:06 UTC (Thu) by spaetz (guest, #32870) [Link] (1 responses)

You can assign tags according to rules. When I sync with my imapserver, I also assign tags according to mail addresses. Folder location in not yet a tag/search criteria but it is in the todo.

Not much of an email review

Posted Mar 25, 2010 22:21 UTC (Thu) by nix (subscriber, #2304) [Link]

Well, if procmail can assign tags, there is no problem :)

I hadn't realized there was an Emacs mode...

Posted Mar 25, 2010 23:25 UTC (Thu) by ejr (subscriber, #51652) [Link]

Thank you! I had looked at notmuch but didn't want to put the effort into an Emacs mode... Now if someone would write an nnnotmuch for Gnus... ;)

Not much of an email review

Posted Mar 26, 2010 7:16 UTC (Fri) by spaetz (guest, #32870) [Link]

Shameless self-plug follows: Notmuch is a primarily a command line tool at the moment. But it is also a shared library offering its functionality to 3rd party clients. Carl Worth expects other mail clients than the default emacs one to integrate notmuch support, and a flurry of scripts and tools is being created surrounding notmuch.

With 3 simple patches that have not made it into the mainline yet (http://thread.gmane.org/gmane.mail.notmuch.general/1822/focus=1836), a libnotmuch.so is build and installed.

I have created python bindings with which it is trivial to make use of notmuch. In order to get a list of all email addresses you've ever send emails to, just do:

 from cnotmuch.notmuch import Database
 msgs = Database().create_query('from:Sebastian@SSpaeth.de').search_messages()
 for msg in msgs: print (msg.get_header('to'))

(install via "sudo easy_install cnotmuch" on decent distributions) Main overview and download links: http://pypi.python.org/pypi/cnotmuch Extensive API documentation is at http://packages.python.org/cnotmuch The issue tracker and source code repo are at http://bitbucket.org/spaetz/cnotmuch


But aside from that, notmuch is really transforming the way, I do emails. I used to be a ferrocious deleter. Besides spam, I haven't deleted a single message in the last few months. Threads tend to become much longer, as they are really a 'discussion place for a topic' and they are easy to pull up again months later and reply to. I seldomly used to reply to months old threads previously. REferences to other emails -very handy for discussions in software development- are much easier, rather than having to search and post a link to some pipermail or gmane web-archive. I press 'ci' in my notmuch emacs window and the current "Message-ID" is copied into the clipboard. People throw mail-IDs around in the notmuch mailing list a lot. Searching those mails (including the thread context) is darn easy.

I think Thunderbird 3 with its use of virtual folders and a mail indexer is finally getting there too, which is good.

Not much of an email review

Posted Mar 26, 2010 17:23 UTC (Fri) by dankamongmen (subscriber, #35141) [Link]

Have you seen sup? http://sup.rubyforge.org/ I keep intending to play with it as a mutt replacement.

Offlineimap?

Posted Mar 29, 2010 17:42 UTC (Mon) by liamh (guest, #4872) [Link] (2 responses)

"Is your editor switching to Notmuch? Not yet. Notmuch requires that all mail be stored locally, but your editor likes having that central IMAP server available. "

Would offlineimap do that job?

Liam

Offlineimap?

Posted Mar 29, 2010 21:06 UTC (Mon) by dlang (guest, #313) [Link] (1 responses)

not always. That still requires all your mail get copied to each system, for someone with a large mailbox this still takes a long time (and for devices you don't frequently use, it can take a while to update them when you try to connect before you can do anything)

In addition, it means that each device you use must have enough storage for all your mail. when people have GB of mail this just won't fit on some smaller devices.

Offlineimap?

Posted Mar 29, 2010 21:16 UTC (Mon) by liamh (guest, #4872) [Link]

I was thinking (for me, not for our editor) of syncing the mail onto an AFS server which I can get to from all my clients. Then sync times should generally be short. I can even cron it subject to having a valid token. I have 500GB quota on the AFS server, and I can send an email to get more. I don't have that much email (yet).

Liam

Not much of an email review

Posted Mar 30, 2010 18:05 UTC (Tue) by Tet (subscriber, #5433) [Link] (1 responses)

There's a reason I'm still using MH. It's not without its problems, but over 20 years on and I still find it better than the alternatives.

re: MH

Posted Apr 6, 2010 15:43 UTC (Tue) by pj (subscriber, #4506) [Link]

Agreed. I'd still be using it if it could talk to IMAP. Instead I had to hack up a workalike (in Python) called MHI, though I'll admit it's not as finished as I'd like. But it's enough that I can use Thunderbird if I have the time/space/attention/ability, or I can use mhi from anywhere.

Can some explain how it compares to mutt?

Posted Apr 1, 2010 18:27 UTC (Thu) by Pc5Y9sbv (guest, #41328) [Link]

I switched to mutt (from mailx) a long time ago, and have found that it only grows more useful as machines and disks get faster, in spite of messages also getting larger. I don't delete messages (except spam) as someone else mentioned above, because of all the mutt features for search, ordering, and limited views. I sometimes delete overweight attachments though, e.g. when I know they are obsolete.

I find myself letting my mailbox grow to quarterly sizes before I shift it off to an older annual archive. I use Maildir for my current working set, but each archive is just an mbox file. Mutt handles 500 MB mbox files with aplomb.

Once in mutt, I tend to use threaded view, but sometimes switch to date of arrival to return to recent stuff I lose track of, for example when it is hanging off of a thread from last month, so nowhere in sight in the last few screens full of messages. And I use the pattern-match search and view filtering very frequently. It's easy for me to do something like "mutt -f mbox.2009" and then limit by sender/subject/body patterns and find the proverbial needle in a hay stack.

The most significant custom setting I used is setting the tab-key to jump to the next unread message in both index and pager views, so I can easily catch up on email that has arrived since my last time looking. I tend to view every message and do triage, rather than defer messages and try to read by topic. If there's a busy topic, the tab key will walk me through in threaded order, since the replies will batch up in between my mail runs. If there's a lone response on an old thread, tab will walk me back to it after processing everything that is nearer in the sort view. If there's something I don't want to reply to or forget, I just use the mutt flagging feature, so I can later come back to handle flagged messages during a more in-depth mail session (again using the search features to good effect, to walk through each message that is flagged in the entire mailbox).


Copyright © 2010, Eklektix, Inc.
This article may be redistributed under the terms of the Creative Commons CC BY-SA 4.0 license
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds