Email Sucks: Why are there no Modern Command Line Clients?

Lately I’ve been trying to experiment with weaning myself off the CPU/Memory expensive GUI clients and instead try living more on the command line. I came to a conclusion that you can’t really go wrong with command line. For one, it gives you an incredible amount of power, but we already talked about that in other posts. Two, it is much, much snappier. My aging work laptop barely notices when I run Pine, Vim and Midnight Commander side by side, but if I launch Thunderbird, Eclipse, Dolphin (KDE File Manager) and a dozen tabs in Chrome it starts to gasp for air every once in a while. Finally it looks ridiculously cool. I’m serious – people get so confused when they watch me work. I love it.

Of course the good reason not to go all command line is because it can be a pain in the ass sometimes. And no – I don’t mean file management and all that stuff. That’s actually when the shell apps and the unix philosophy shines. I’m talking about shit like email.

Let me get this of my chest: email fucking sucks. All email clients blow. All of them. Outlook is a monstrous abomination that I will never even touch. Thunderbird takes about three hours to open and leaks memory like a motherfucker. Kmail which I used extensively for years is an amalgamation of byzantine, buggy and bizarre and like everything it went to shit in the recent KDE releases. In fact the one mail client that I actually kinda enjoy using is the one that lives on my iPad, though the push thing can be wonky sometimes when you have a million IMAP folders and server side filters filing mail to them.

Right now I don’t even use clients on non-mobile platforms. I cut out the middle man and usually go directly to the source – I log into my Gmail for personal crap, and to the corporate Zimbra server for work. And the experience does not suck terribly. The web clients are limited and crippled in just the right ways to make the experience bearable to me. The latency of dealing with dynamic web apps still kills me though.

I mean I shouldn’t have to wait motherfucking seconds to view what 99% of the time is plain text or basic HTML. But when you are using webmail there are page refreshes, ajax spinners, wait times, and etc…

It seems that a logical solution to this annoyance would be to use a blazing fast command line client. Sad part is that these days your choice is usually between Mutt, Pine and Go Fuck Yourself. All of these, except the last one were made in like early Pleistocene (the third one was made by your mom in my bed last night, so there) and so they are not exactly user friendly.

And I don’t mean “steep learning curve” user friendly. I mean, just plain shitty. I am not one to shy away from a little bit of a challenge – I use Vim for fuck’s sake. What I’m saying is that Pine and Mutt are great if all you want to do is to keep all your emails in your inbox and only see a list of subject lines on the screen when you open the client. They provide a very bare-bones, basic email experience, and they tend to be faster than webmail so I guess I can live with that.

But sometimes I wish they could do more. I wish there was a modern day command line email client that would be command line driven (like Pine and Mutt) but actually do some of the things that webmail clients do these days. Among other things I actually look for these sort of features:

  1. Folder list in the sidebar – it should be an expandable tree view in which folders with unread messages should be different color/bolded and should display a number of unread emails next to the name. Most modern email clients and web clients do this. I understand why Pine and Mutt do not have that, but as evidenced by apps like Midnight Commander a two or three pane layouts are completely workable for NCurses apps. I’d love to have something like NERDTree in Vim where I could just key over to my folder tree. Granted, switching folders in Pine is jot horrible but I’m more about the unread mail indicators.
  2. Better attachment management – dealing with attachments in Pine can be a pain. The easiest way to save all the attached files at once to the same folder is to export the entire message there. Attaching multiple files to an email is also a pain. It would be nice to have a robust and easy way to do both.
  3. Email body excerpts – I like to see a short excerpt of the email shown next to the subject. Both Gmail and Zimbra support it, and whenever I use a native client that does not I feel like I’m missing out. Sometimes there is just no reason to open an email when you can at a glance see that the body is just “Thanks” and nothing else. Lack of it is not a deal breaker but it would be something nice.
  4. Some HTML Support – I know, I know – HTML emails suck, blah, blah, blah. Still, I’d like there be an option for me to compose a message in say Markdown like syntax and have the client sent it as a prettified HTML email so that my recipients don’t have to keep telling me my emails look “odd” in their Outlook.

The ability to work with an IMAP server and not completely fuck up would be good too.

So those are some of my wish-list requirements for a command line mail client for geeks and power users. Mutt and Pine are great, very flexible and they work amazingly well in weird conditions – for example over SSH session on a dumb terminal with limited character set. That said, I think there ought to be enough interest for a command line mail client designed specifically to be used in a modern, color terminal. Something that is not encumbered by the need to look good on an 80 character wide display – something with modern sensibilities that still has the power, flexibility and configurability of a mail client from the olden days. My gripes about Pine are mostly about usability and layout – I want a client that looks more modern.

Does a client like that exist out there? If it does, I have never heard of it. If you know it and use it, please let me know because I would love to try it out.

This entry was posted in sysadmin notes. Bookmark the permalink.

17 Responses to Email Sucks: Why are there no Modern Command Line Clients?

  1. astine Mozilla Firefox Windows says:

    I think your best bet might be an Emacs based client. Wanderlust is a pain to setup but it’s flexible enough that you can make it do everything you want and then some. It’ll just take you a week to get there.

    Reply  |  Quote
  2. This is something I look into on occasion, too. Mutt is the client I eye-ball but I’ve not quite made the push, partly for the reasons you cite. I’d love to move to a terminal e-mail client but I think it requires a whole different approach to e-mail than I, and many others, currently follow.

    I didn’t realize it until Paul Graham pointed it out: for most people, an e-mail inbox is a rudimentry todo list. That’s exactly how I’ve been using it for years. Generally things I need to do are associated with an e-mail — an appointment, a task, a bill, etc. — and I leave it in my inbox until I’ve dealt with it.

    These terminal clients were created before this new-ish paradigm and they never changed. They’re not built to be todo lists. They’re designed to be efficient clients for interacting with mailing lists and sending messages. It’s closer to an instant-message client than a modern e-mail client.

    At work, I’m actually right in the middle of a transition to separate my todo list and my e-mail. I think this is similar to how the unix hipsters, who are still using these old e-mail clients, do it. I’ve got Mutt set up to send and receive e-mail, S/MIME included, from any of my computers directly (i.e. no sshing to a master computer to run mutt). For a todo list, I’m using Emacs’ org-mode, versioned with Git so I can keep it in sync between all my machines. If this works out well, I may do this at home too — where I’m just using webmail. What’s taking time is that I’m still learning org-mode and I’m being very careful that I’ve got all my bases covered.

    I’m not using IMAP with Mutt and I don’t want to. I’ll grab the e-mail on the local machine. If it’s a todo item or appointment, I paste the relevant information into a new TODO entry in org-mode and commit it. If any attachments or the e-mail itself is really important, I’ll attach it to the TODO item, freeing it from the e-mail client. Otherwise the e-mail really only lives in Mutt long enough for me to deal with it. No folders to sort or store mail, it’s all just temporary. I don’t store my instant messages, after all. With that, I won’t have some gigantic, centralized e-mail archive to worry about.

    The ultimate goal is to use e-mail as a simple messaging service and leave todo lists to the pros. That’s what the terminal clients were meant to do, I think. That’s why they’re not fancy like you’re expecting.

    Reply  |  Quote
  3. IceBrain PORTUGAL Mozilla Firefox Linux Terminalist says:

    I use ‘Sup, by William Morgan.

    Folder list in the sidebar: No, but pressing ‘L’ does show you the list of Labels* and the number of unread messages in each. It also shows the labels to which new messages were added the last time it polled the server.

    Better attachment management: To save all attachments, you just need to press A and choose the directory. For attaching, you can either use a very basic file manager, or give it a path. The latter takes wildcards and loads all the matching files at once.

    Email body excerpts: Yes, just like GMail (50-100 characters in a single line after the subject).

    HTML support: For viewing, it can load them on a browser (if you use a CLI one like Lynx, it’s just like a normal pane).
    For writing, it just loads the template in your editor of choice and reloads the file after you close it, so supposedly you just need to have a Markdown → HTML converter processing the file before closing it. Something like a shell script that opens the file on an editor and then calls the converter before returning should work fine.

    Why I like it:

    * Uses Labels instead of folders – you can have messages in more than one label, etc.

    * It indexes the email for blazing fast (I’d say faster than Gmail, also due to the bare bones UI) search.

    * It actually knows how to deal with multiple accounts, setting the right From: address when you’re replying to someone, etc.

    * Written in Ruby, which is nice enough (I’m a Python guy) for writing little functions that are called by its hook system and process emails. I use it for writing Turing-complete filters.

    Anyway, enough of a plug, here:

    Reply  |  Quote
  4. Luke Maciak UNITED STATES Mozilla Firefox Windows Terminalist says:

    @ astine:

    Emacs, eh… Well, I might give it a shot. :)

    @ Chris Wellons:

    That’s actually a pretty good philosophy. Though for work, I like to keep archival emails for the “cover your ass” purposes. Plus we are Zimbra based so everything kinda lives on the server.

    @ IceBrain:

    Man, I was actually trying to install sup the other day and it was being a monumental pain in the ass. The gem installation would fail compiling some of the prerequisites and google was like “LOL, IDK, you’re on your own buddy”. I eventually gave up, because I ran out of time I alloted to waste on email client shenanigans.

    Reply  |  Quote
  5. JuEeHa FINLAND Links Linux says:

    Hello again from consoleland. I also kinda gave up on console email clients for mostly the same reasons you listed. Nowadays I just use gmail’s basic html interface (I had set it as my default even before movint to this 12 years old machine because of all the braindamage in the net inteface) in links2. It works pretty well and is bit nicer to use than console email clients.

    Reply  |  Quote
  6. SapientIdiot UNITED STATES Google Chrome Windows says:

    Much as I love doing everything from console, my tablet and phone are pretty much all i use for communications these days, aside from when i really need to type out something long. I’ve been using Kaiten Mail on my android devices for a while. The only downside to not having it on a desktop/laptop is that PGP support on android is horrible, and I happen to use PGP regularly with a handful of the folks i communicate with. Because of that I’m stuck using thunderbird once in a while. I haven’t really had any issues with it, but I’d much rather be using my tablet.

    Reply  |  Quote
  7. I can’t recall which mutt setting I enabled(imap_check_subscribed?), but now I can hit the y key and I get a list of all IMAP folders along with unreads in each. May not scale to your use case P:

    Also I enabled set text_flowed=yes so that line breaks happen more nicely.

    Reply  |  Quote
  8. Hamish AUSTRALIA Mozilla Firefox Linux says:

    Right, let me try and answer this for mutt.

    One by one:

    1) Folder list in the sidebar

    There is a sidebar patch for mutt that is packaged with both debian and ubuntu as part of the “mutt-patched” package. Alternatively – just use the “imap_check_subscribed” as described above.

    2) Better attachment management

    I have not used pine for decades, so I cannot contrast mutt to your described concerns, but with mutt, I get all these features – there is one standard screen for managing attachments, both for sending and recieving and you can tag and save in bulk to a dir.

    3) Email body excerpts

    This seemed like it would be a common request and I was assuming that I could just use the “index_format” setting and add an field for the excerpt. But there is no such field. Even if there was, it would not play well with IMAP, since the Subject line is fetched and renderd as a header and the body text would not be available at that time..

    4) Some HTML Support

    I have this viewing HTML mail working quite well (it is still not perfect, but it is not nearly bad enough for me to build my own renderer)

    Install the ‘lynx’ text mode browser
    In your ~/.mailcap file, ensure you have a line:

    text/html; cat '%s' |perl -pe 's===g' | lynx -assume_charset=utf-8 -dump -stdin; copiousoutput; description=HTML Text; nametemplate=%s.html

    The horrid perl is in the middle there because of some wierd rendering links gave to some code review html emails (patches, converted to html!? who wants that!), but I’m resonably sure that it catches and ‘fixes’ other emails often enough to be generally useful
    Then add “auto_view text/html” to your ~/.muttrc

    Reading your comment again, it looks like you might be more interested in the sending of HTML mail (which I dont do, for all those ‘html mail sucks etc, etc’, reasons) – I’d use a quick wrapper which runs vi, then the markdown commandline tool to do that.

    Reply  |  Quote
  9. Hamish AUSTRALIA Mozilla Firefox Linux says:

    @ Hamish:
    Having read your next post where you mention the mutt IMAP slowness, I thought I should expand a little more.

    I use the mutt header_cache and message_cachedir options to speed up large mailboxes, which means I can open my >6000 message INBOX in under 3 seconds (sometimes, the cache fails, but I think that is more because of the stupid Zimbra IMAP server than anything else).

    I just checked this on a 13000 message folder and it took about 12seconds to open it the
    first time (creating the cache) and under 2 to open it the second time.

    Reply  |  Quote
  10. Ron Mozilla Firefox Linux says:

    Bit late too the punch, but if IMAP is being to slow for you, another option (at the cost of disk space) may be to use offlineimap, to download your email to a maildir.

    Im lookin at this approach as I want to be able to read email, at anytime where I may not have wifi access or it maybe expensive (airports, buses, my mothers who still has dialup).

    It should be pretty portable as I try more clients (mutt, wunderlust, sup being the main ones).

    For markdown email, I would add a transform to the composing (in $EDITOR), this would allow you to also view it in a browser before sending.

    Reply  |  Quote
  11. Ron Mozilla Firefox Linux says:

    Also if its just the latency of gmail, you can set it to default to html-only, which is nice for the most part.

    Its the customizations and new keybindings I tend to miss with gmail, theres probably labs to deal with this thou.

    Reply  |  Quote
  12. MiGri Google Chrome Windows says:

    I like to use cli email clients, too. I used to work with OpenXP but there is not much support left for this good old client and so I switched to cone ( Give it a try…

    Reply  |  Quote
  13. Don’t forget: google and other webmailers are for free (except your data, that’s transfered to NSA etc.) Webmail is financed by comercials, adds etc. If you don’t find a comfortable e-mail-client – learn programming and create an own one. ;-)


    Reply  |  Quote
  14. Oliver GERMANY Mozilla Firefox Ubuntu Linux says:

    There is/was notmuch-vim. And there are also some other tools around notmuch notmuch-fs, alot … so if you are fucked up you can see if you can contribute to these projects and get something you really love…

    Reply  |  Quote
  15. Ian Main CANADA Mozilla Firefox Linux says:

    I guess I’m fucked up.. ;-)

    I got vim-notmuch up and running and it’s awesome! Best email client I’ve ever used. I’m super impressed by the whole paradigm of having searches and tags rather than mailboxes. I have been working on adding support for URI’s and attachments and just general UI improvements.

    Reply  |  Quote
  16. Really now? UNITED STATES Mozilla Firefox Linux says:

    Why not just use elinks / links /lynx and go to

    Reply  |  Quote
  17. TD UNITED KINGDOM Mozilla Firefox Windows says:

    Right folks. It seems to me that a modern CLI email system for a color would have to be developed from scratch.

    At the heart of it would be the ‘editor’, which can do text and HTML the fly, including display images inline. The editor would have to have vi emacs and nano key bindings to accommodate a wide range of personal flavors. And: the viewer needs an attachment integration.

    Very importantly, we ALSO need calendaring and tasks!

    Then, to draw all this together, we need a customizable main window. This should be a frontend for the ‘editor, display calendaring/tasks, as well as email folders in customizable panes.

    So: the existing clients had the various functionalities bolted on over time — or not. But the way forward should be: start with the functions in an integrated way — then put the dedicated frontend on top.

    Reply  |  Quote

Leave a Reply

Your email address will not be published. Required fields are marked *