The Ideal Email Client

Recently, I was speaking with my fraternity's academic advisor via email
regarding a post on the fraternity's mailing list. He had made a comment about
how he dislikes it when people top-post. Now, people have been
arguing about the proper way to send emails for as long as emails
have existed (or longer, if you consider email to be an extension of the office
memo), but there are some decent counter-arguments against it now. I have been
using Gmail since it was released, and as a result, never gave much thought to
the arguments made against the way that it formats email. I was ok with top
posting because Gmail grouped replies together. Quoted text was automatically
hidden (trimmed) and your email was always right below the email it was
replying to, which fits with "netiquette". The conversation did make me think
about the things that I did not like about Gmail, however, so I started to look
around at some other email clients.

Now, I have been working in IT for the university for some time, so I am
familiar with most of the main stream email clients. I took a look at some of
the recent developments and I was happy to see that all of them supported some
sort of message threading or conversation view like Gmail does, but they still
didn't quite fit. Seeing that, I thought that I should formalize the
requirements that I was looking for in an email client:

Requirements

Support the label/tag and search method of email sorting.
- This is actually more like 2 requirements: Tagging and good search. I
  prefer this method of email organization because it makes me spend less
  time on organizing and finding and more time on other things.
Syncronize flawlessly with other clients, including the Gmail webclient.
- Because I have a phone on which I read email and have quite a number of
  machines, I need syncronization. Sometimes, though, I will not have
  access to my client, so it needs to work with Gmail's web client as
  well.
Have the ability to specify a maximum line length (or has one set at 70-80
characters).
- 80 characters is a very good line length to be able to read. When you
  have a 24" monitor, lines that fill the whole screen become very hard to
  read.
Handle hyperlinks elegantly.
- I don't really care about most HTML elements, since most email clients
  send out both HTML and plain text versions of their emails, but I want
  to be able to click on a link and have it open in my browser.
Sync with Google Contacts (natively or through a 3rd party program).
- I enter new contacts on my phone mostly, which syncs to Google contacts.
  I understand that this is not a good requirement from a general stand
  point, but it would make my life easier. I could probably live without
  this one since I have a pretty good memory and maintaining two separate
  databases is not really a problem.
Be fast, even in a low resource environment
- This should be a requirement for all software, but there are some
  clients that insist on refreshing each folder whenever it is accessed.
  This makes large folders very slow to access. For Gmail's "All Mail"
  folder, this takes on the order of a minute in some clients.
PGP Support
- I like security and proof of identification. This is not a huge factor
  since Gmail does not have it (and I have thus never used it), but it
  would be nice to have, nonetheless.
Keyboard Shortcuts for everything
- Gmail has keyboard shortcuts for most things, and I use Vim as a text
  editor, so I am definitely a fan of keyboard shortcuts, especially when
  the main part of the activity is typing (which is all that email is).
  This is the problem I see with most clients (Thunderbird and Outlook):
  there are not enough keyboard shortcuts.
Be Customizable
- Email is a highly personal thing so it is going to be really difficult
  to build a tool that is useable by lots of people without allowing for
  lots of options in workflow, layout, and organization. I think since it
  is likely that I will disagree with the creator on at least one point of
  how the program should work, that I should be able to fix it through
  customization. This feature also might help with one of the other
  features.
Be Cross Platform
- I would like this to be a feature of all software, but I know that is
  not to be. Fortunately, most email clients fit this one. I need it in
  particular because I have all kinds of different computers and I would
  want it to be able to run on all of them.

With those requirements in mind, I started looking at some of the email
clients out there that are available. I took a look at and tried several of
the less main stream clients until I ran into something that I thought would
make the program difficult for me to use, or until I felt I got a good feel for
the program and decided that it was not for me. I knew going into it that I
would have a hard time finding one that supported labels as I wanted, so I was
not looking only at clients that supported those, but I was really hoping that
one existed.

Email Clients that I Tried

Test Environment

Before I give a review of any mail clients, I should detail the environment in
which I tested them. I tested all of these clients on my netbook, a 1.6Ghz
machine with 2GB of memory. It runs Linux Mint 11 LXDE Edition. I
am connecting to my personal Gmail account via IMAP, which is enabled in my
account settings.

Claws Mail

Website: http://www.claws-mail.org/

I looked at this one because I had read it being touted as a very useful and
very lightweight client. Ideally, this would mean that it satisfies #6. It is
GTK based (#10) and allows for plug-ins (#9), so I can extend it if I so
choose. Additionally, it supports plaintext emails, so #3 is accounted for.
Links, as I would expect from a GUI program, open correctly in the default
browser (#4). It did not use up much in the way of resources on my machine
(and I was testing it on my netbook) and had a decent interface layout.

There were several problems that I had with it, however. Chiefly among them was
that every time I tried to access one of my folders, it wanted to pull down the
whole folder (or at least all of the headers) from Gmail's IMAP interface.
When I access, say, my "All Mail" folder, this can take quite some time. IMAP
is not known for being particularly speedy and sometimes the wireless
connection on campus gets very saturated. When the program is unusable for on
the order of a minute, that is a serious performance problem. This was the main
dealbreaker for me. Additionally, though, it did not fully use the theme that I
have for my window manager. It took the background color (an dark grey), but
did not use the font color specified. The result was that I had to try to read
black text on a light grey background. As you can imagine, there was not too
much contrast there.

Sup Email

Website: http://sup.rubyforge.org/

The goal of Sup is to become the email client of choice for nerds everywhere.

I was very excited to find this client. I had been searching for a client that
could support labels like Gmail, and I had finally found it. Its philosophy
seemed to match mine as far as email organization went. Sup is a command line
client that is written in Ruby with support for tagging and extremely fast
search. It automatically manages your contacts and provides a the ability to
make add ons via its hook system. It is essentially a console Gmail clone.
Being a CLI client, it also supports quite a number of keyboard commands out
of necesssity. Overall, a very promising client.

Shortly after installing, however, problems start to show up. I was able to
install it fine, but then I ran across this line in the FAQ:

Q: How well does Sup play with other mail clients?

A: Not well at all. If messages have been moved, deleted, or altered
due to some other client, Sup will have to rebuild its index for that message
source. For example, for mbox files, reading a single unread message changes
the offsets of every file on disk. Rather than rescanning every time, Sup
assumes sources don't change except by having new messages added. If that
assumption is violated, you'll have to sync the index.

Obviously, since I would want to use the client from multiple computers and
possibly from the web interface occasionally, this would not do. It also does
not appear as though it will get fixed any time soon, since development on the
client seems to have slowed to a crawl based on its repository. It
appears that the developer has started to put his focus on a server version of
Sup called Heliotrope, which looks promising, albeit not mature enough to use.
You can check out its GitHub repository if you would like
to look at the code.

Alpine

Website: http://www.washington.edu/alpine/

Alpine is a CLI client that was developed by the University of Washington as a
successor to their PINE client. Pine, apparently, is what was installed on a
lot of the large mainframe systems at universities in the late 80s and early
90s, so a lot of people are familiar with it. It is a full client, meaning
that it can send, receive, and read mail. It focuses on being easy to use for
both beginners but flexible enough for power users.

I tried this one because it was recommended to me as being a very powerful and
easy to use client. I liked that it was very fast and featured a lot of
keyboard shortcuts. There are binaries of it available for every OS under the
sun, and it supports IMAP, so it plays nicely with other clients. My main
problems with it were that the keyboard shortcuts did not make sense to me.
They were all labeled well, so I was able to see them all, but they were not
intuitive and focused too much on using the arrow keys. I don't like having to
switch from letter keys to arrow keys and back for everything. Additionally,
it is married to the Nano text editor, which is definitely user friendly, but
I don't particularly like it (uses modifier keys too much).

In the several hours I spent testing it, I could not get the SMTP server
settings correct to send mail, either, despite finding numerous "guides" to
configure it for use with Gmail. While I am sure that I could have eventually
gotten it working, I don't want to spend that amount of time. Don't get me
wrong, I am fine with spending hours configuring a tool, but I don't want to
do that for basic functionality.

Ultimately, I decided against using Alpine.

Mutt

Website: http://www.mutt.org/

"All mail clients suck. This one just sucks less." -me, circa 1995

Mutt is a CLI client that functions as a successor to the much older ELM
client. It supports all the mail protocols that you could want, as well as
having an easy to parse config file and all types of plugins available. Recent
versions of it support sending and receiving mail (it used to be only a
MUA, which meant that it could read mail, but the mail
needed to be fetch by some other program). Being a CLI client, it supports
many keyboard shortcuts as well as being very fast. It is very customizable--
its hooks system allows you to specify many different if-then situations. One
of the things that really set it apart for me was that it supports threading
of conversations, similar to Gmail's conversations, but more robust, since it
actually nests replies rather than just grouping together all emails in the
same subject.

I came to look at Mutt after several hours of looking at and evaluating email
clients. At this point, I was pretty sure that I would not find something that
I wanted to use, but I decided I would give Mutt a try before I called it
quits. The installation was incredibly easy. I installed the package and was
up and running in a few minutes. The config file, muttrc, is very easy to
read. I spent a couple minutes looking over the help file and some Google
pages, and I had it connected to my gmail account sending and receiving
email. The keyboard shortcuts were all pretty much exactly what I expected
them to be and I was able to use Vim as an external editor. It also displayed
all of my emails in their beautiful threaded form. The topping on the cake was
that when I could open links in my web browser from the context menu (although
I think that this is actually a function of the terminal that I am using
rather than Mutt itself). I was sold.

After a bit more searching, I also found a python script that allows Mutt to
search your Google contacts. This fits feature allowed it to fit, I believe,
nine out of my ten requirements, which is pretty good for a program from 1995.

Conclusion

I have been using Mutt for several days now with my personal email account and
I so far have been very satisfied. There have certainly been a few quirks, and
I have found that it does not play completely well with Gmail's web client
(it causes duplicate messages to exist because of the difference between
folders and labels). Once I get its setup more stabilized I will make a post
about how I have it configured.

Know of a client that I missed? Have some ideas on your own requirements for a
client? Leave them in the comments below.