What is Reddit's opinion of notmuch?

From 3.5 billion Reddit comments

I use notmuch. It's not exactly a mail client in the same way that the others are, as most of the heavy lifting is done via C and C++ libraries. But the primary user interface is an Emacs mode. It's also under very active development (the mailing list sees maybe 30-40 messages a day on average).

Think of it a bit like Gmail in Emacs: most of the navigation and manipulation of your mail is done through searching and tagging. It uses Xapian, a full-text search engine written in C++ to provide the search functionality, and most of notmuch is a C library that sits on top of Xapian and provides tagging functionality and the application level search API. The Emacs piece is then the UI, and provides convenient access to your tags, searches, etc. If you like the Gmail style of dealing with email, it's worth a look. Also good: it's very fast. It's fast compared to a normal mail client. Compared to Gnus, it's biblically quick.

The downside is making it play well with others. If you normally read mail via a local spool (i.e., you use fetchmail or something like it to pull mail into a local set of maildirs), then it's a really nice fit. If, like me, you use Gmail and want to have the server reflect all the local changes you've made, it's not as good. I use offlineimap to sync with Gmail, and that works well enough for things like marking mail as read. However, there is no built-in support for having your local tagging update things in a way that offlineimap will update Gmail. It seems most people end up writing shell scripts (or there is an officially blessed python API), but it's a bit of a pain in the ass. It's flexible enough to support about anything you want, but once you start trying to figure out all the syncing behavior you want, it does start to feel like you're writing your own mail client on top of a bare API.

A Google Reader refugee, I switched over to <code>rss2email</code>. I have a cron job that refreshes my feeds once at the start of the day (around 5:30am usually), sending them all to my inbox. By only refreshing that one time, I'm less tempted to keep checking for email feed updates throughout the day.

Benefits include:

• I have the full power of my MUA (either Claws Mail or Mutt) to filter, flag, delete, and sort them into appropriate folders. It allows me to easily filter out sponsored (or otherwise don't-care-about-this) posts or relegate certain feeds to a "skim" folder (where I usually just scan the headlines and open maybe 1% of what comes through). Others get moved to the "read all" folder.

• I can easily forward germane articles to friends/family as easily as I can forward email

• <code>notmuch</code> can index them for easy searching

• mail is already synced via IMAP, so if I read an article on one machine, it's marked read on every machine. Local (non-web-based) solutions have a hard time with this requirement of mine.

• existing solutions for backup of email work to keep my saved feed articles backed up too

• control remains with me and my machine: I'm not handing over my reading habits to some 3rd party news-reader site or depending on their longevity

• I control the pull-rate via cron, meaning I'm not interrupted throughout the day. I do RSS once per day.

I'm a gmail user like you. Still I use notmuch. I use that in conjunction with mbsync. I can switch from notmuch to GMails web interface at will, works nice.

But why do I use an emacs based e-mail solution as well? Mostly because I am in Linux related mailing lists, and they are massive. Also, emacs is much easier to extend, so I added some e-list to copy an Linux kernel patch to /tmp (with a sensible name) by a keystroke.

When it comes to e-mail, I used gnus, Wanderlust, mu4e and notmuch.

Gnus is WAY to complex, also it's news centric. Handling e-mail is just bolted afterwards on it, and that's massive. Simple things need lots of keystrokes.

Wanderlust is not well documented and, as far as I can say, no longer developed. I must admit that I never used it for real.

I used mu4e for some time. Somehow I didn't like it that much. For example it's start screen is something I don't like at all. So I kept experimenting.

The next on my list was notmich. It's indexed in a similar way as mu4e, just better (faster, nicer queries IMHO, but that's taste). It start script was okay, but It was actually easy to customize the startscreen to my liking. E.g. with counts of how many new / total mails I have, the numbers are links so you can press enter over them and get the mails displayed.

Because notmuch's searching and tagging is so fast, I also wrote a script that marks uninteresting e-mails as read. For example, in the linux-arm-kernel mailing list I'm not interested in SOCs from Broadcom, Qualcomm, Renesas, Marvell, so I mark all mails related to that as read. This is something that gnus can do, but it wasn't as (for me, again a question of taste) not as clear as my current solution.

See here what I currently wrote about notmuch: http://www.holgerschurig.de/tags/notmuch/

• Atom/RSS feeds (Elfeed)
• Email (Notmuch)
• General web server (simple-httpd)
• IRC (erc)
• File management (dired)
• Games (built-in)

I recommend notmuch: http://notmuchmail.org/

I use it because sometimes I want to search all my mails for a text string, and since notmuch uses Xapiam, such queries are very fast. Also, it has supports for tags, so it's the closest I have seen in Linux to Gmail.

Plus, I don't have to ever leave my editor (vim), but the main interface is actually emacs.

My previous mail setup with vanilla mutt was fetchmail to grab emails from IMAP and POP3 servers, maildrop to sort them into a MH-style maildir in my home directory and mutt to read the maildir and its subdirectories. Outgoing mail was handled by msmtp and send2-hooks in mutts configuration to select the appropriate outgoing mail server according to the From header of the mail I'm going to send.

My current setup is much the same, except that I use mutt-kz because it has really great notmuch integration and that maildrop uses notmuch to insert emails into the mail database.

Back when sup was dying (seems to be more alive these days), I switched to http://notmuchmail.org/ with its Emacs frontend and enjoyed it a lot more than sup, mostly because it’s faster and not written in ruby (which I dislike).

These days, I’m just using gmail, because I really don’t want to have a single point of failure for my email. With SPOF, I mean: with sup/notmuch/mutt, I’d always SSH into my workstation, so that computer would need to be running 24/7 and be stable.

Interesting, but I'm not sure if couchdb is really a good choice. Storing mail is complicated and Maildir is already a pretty good mailstore.

For indexing, have a look at the folks of notmuch or sup. They're storing stuff in xapian. But, of course, you would have to implement some sort of search feature for the couchdb store, too. And why not use a proven concept.

For notmuch, there is an emacs frontend that's usable.

here is a sample muttrc that uses notmuch virtual mailboxes. I don't think that you can use this with imap accounts, you probably need to use offlineimap or something similar to sync your mails locally.

notmuch sounds like it might fit your needs. Sync with OfflineIMAP to standard maildirs and then index it with notmuch. It handles aggregating and distinguishing accounts pretty elegantly and also does well with very large amounts of mail (that's what it's designed for). It's based on a Xapian database, so queries and indexing are pretty snappy.

I actually use it as the backend for my own email with the frontend alot and msmtp as my MUA and I love it. You probably don't need a frontend if you want to just archive mail, you can query the database directly using the command line client notmuch, which is really easy to use.

EDIT: Oh, if data security is a concern, you can store the maildirs and notmuch index on an encrypted volume. They're just text files and a binary database, so it should be doable especially if you're interested primarily in archival. Another reason this might be useful is that you don't have to have the emails around to query the database. Store the index in one place and keep the mail somewhere with lots of redundancy and strong encryption.