Reading Time: 6 minutes
It probably stems from how long I have been using computers, and what my first computer interfaces looked like, but I have been enamored of command line interfaces since, well, forever. There have been the occasional graphics dalliances: the Amiga, NeXTSTEP, the Enlightenment window manager, some aspects of the current OS X GUI. By and large, however, in any environment I can think of, I prefer a command line interface.
The challenge in today’s world is that many operating systems, and an increasing number of network, storage, and other enterprise-level devices, all make it at difficult to use the command line. I do have valid reasons, in my own mind at least, for preferring a text-based interface: I can be more proficient when I do not have to remember where all the little pictures and menus are, and what manner of clickety-clicking I need to perform in order to accomplish regular, mundane, should-be-easy tasks; my brain is hardwired to remember words more than pictures, and as a general rule the command line offers more power and flexibility than does the GUI. Of course, if you’re not accustomed to the command line, or you’re not a luddite, you may scoff at the idea of using an archaic interface method, but I do find that most power users I know—and this is purely anecdotal—prefer a text interface as well: the Unix shell, Windows PowerShell, Cisco IOS, whatever. That said, I do manage to claw my way back into the command-line world where I can, a piece at a time, and the small victories keep me satiated, for the most part.
One area where I find, almost without exception, the GUI completely horrific and lacking is in today’s email clients. The applications seem to be massively bloated, taking much more memory and processing power than their functions would suggest. The layouts of most, while familiar, are only acceptable because we have all become used to them, not because they are useful. The greatest sin, though, is that the searching capabilities are almost universally horrid, ineffectual, and slow. I wanted better, and I finally did something about it: I went to Mutt. Actually, I went to NeoMutt.
Mutt has been around forever as an email client, like the much vaunted Pine—still available, by the way—and NeoMutt is nothing more than Mutt pre-built with several of the most common Mutt patches. Mutt is an infinitely flexible email client that is built in the old vein of clients, and follows the Unix ethos of doing one thing only, and doing that one thing well. While you can set it up to natively handle many things from gathering email, sorting, etc., it works best when you leave those functions to other applications.
The challenge with Mutt, and other support applications in what you might call its ecosystem, is that they aren’t always as intuitive to set up as might be ideal, and less so in today’s complicated climate of proprietary formats (EWS,) cloud-hosted services, IMAP, POP, SNTP, GPG, etc. It took me a while to get my setup dialed in, or at least close to dialed in (there are always tweaks being made), and in the hopes that someone else can use what I have built, I’m putting it all out for public consumption.
I would be remiss if I did not point out that while I created much of what is in these configuration files, other people created much more. As is the tradition in the open source world, I borrowed the best bits from a multitude of people, sites, manuals, DIY guides, my whiskey collection, and random deities to land at what is a fairly serviceable set of files. I would expect nothing less than for the reader to take all of this mess and make it his own. Just contribute back somehow if you find a better way of doing things.
So, without further ado, the configurations are below.
In order to get mail flowing into my system I have to use two programs: davmail, and mbsync. I have three accounts I regularly use, two of which are IMAP, and one which is my corporate Exchange server using EWS. The IMAP accounts are not too difficult to get working, but the Exchange account was a tad challenging at first.
Mbsync is a program that just runs in the background, collecting email from my accounts at a set interval: five minutes at home, one minute on my corporate machine. Just to get it out of the way now, I use cron to keep that program going (I know, I know, deprecated on OS X, but I’ll keep using it until the last possible second it is in the OS.) I hope if you are going down this road you know how to use cron, but if not, just type: crontab –e from a terminal and put the following line in:
The referenced mbsync file below is sanitized, but should give you an idea of what’s going on. The only real caveat here is that you’ll want to pay very close attention to formatting. The mbsync program expects everything to be in a very specific order, and those spaces in the file are a part of that. If in doubt, consult the documentation. Oh, and the “passcmd” I have in there is using PGP to decrypt an encrypted password file I have for each account. That way I don’t have plaintext passwords laying around on my system.
Oh yes, and in this configuration I pulled certificates from my two IMAP accounts using openssl and stored them in an .accounts directory that I created. These are my conventions, by the way, and you are free to pick your own directory structures that make sense to you.
I decided against using the OS X ~/Mail location in my home directory and instead created a ~/.mail folder. There I created one directory for each account, and then created an inbox folder. Everything else will take care of itself once mbsync starts pulling down data. The configuration as I have it creates folders as needed to match the server structure.
Now, because my Exchange administrators do not have IMAP configured for access outside of the corporate network, and I did not want to VPN in every time I needed to check my corporate email, I chose to use a program called davmail. Davmail works by connecting to your Exchange server using native protocols (either EWS or Webdav, depending on the age of the server.) It then exposes a series of local ports that you can connect to using industry standard protocols like IMAP, POP, SMTP, etc. It can be configured to start and run as long as your computer is up, and if you install it via brew, you’ll get a quick little command to run once it’s been installed. The configuration that ended up working for me is below. Note that the ports I’m using are arbitrary, you can use different ones if desired.
The meat of the configuration is the muttrc file itself, and there is far too much in this file to cover everything. I’ll point out just a couple of details, and leave the rest for the reader to modify and cajole as needed. Again, the Google machine is your friend, as is the very good Mutt documentation you can find with just a cursory search.
I have separated my per-account configuration into separate files for two reasons: I like things clean and easy to change, and this way I can switch between accounts in a nice manner. Both of these goals are met with the initial binding of the F1, F2, and F3 keys to source those files. I also source them at the top of the file so that they are pre-populated when I start Mutt.
I have also added some PGP configuration because that is one of the must-have features for me in an email client. I have automatic signing of messages configured, and automatic decrypting of encrypted mail. I still have to tweak the key bindings a bit, but that’s a small task.
I have made some changes in the file to force emails, as much as possible, to come across as text and not HTML, to pull calendar invites out appropriately, and to offer attachments and the HTML version of the email as options. It is not always perfect considering that almost everyone and every email client wants to send large, horribly bloated, HTML-formatted emails willy-nilly, but it does alleviate the problem quite a bit.
I’m going to leave this as an exercise for the reader, but a quick note on searching: Mutt uses regex as its search method of choice, and for those of you who know what this means, let the rejoicing commence. It does have other ways to search and limit, however, so play around with all of the search modalities included, and you’ll find something that works well for you.
Much of this makes sense once you get into the program and get used to the paradigm, but I’d probably just leave this file largely intact until you get a handle on all of Mutt’s functionality. None of this is gospel, and one of the best parts about Mutt is that it really is infinitely flexible. You can make it as much your own as you’d like. It probably makes sense to do a Google images search for Mutt or Neomutt, just to see the myriad different configurations people have put together.
Here is an example of an individual Mutt configuration file. This/these file/files should only include that configuration which is unique to the referenced account. Try not to duplicate functionality here, just put in what you need.
I hope this helps someone out there who may be as in love with the command line as I am. If not, maybe all of this work serves as a warning: there be dragons on the voyage to command line nirvana. In the next chapter of what is likely going to be an ongoing saga in command line shenanigans, I’ll talk a bit about my homegrown command line Twitter client: part utility, part traditional client writ large across the vaunted terminal.