This is a read-only archive. Find the latest Linux articles, documentation, and answers at the new!


Text email clients revisited

By Joe 'Zonker' Brockmeier on January 04, 2007 (8:00:00 AM)

Share    Print    Comments   

Lately, I've been pining for the simplicity of a text email client. Though Sylpheed has been a reliable workhorse, I decided to survey today's text email clients to see if I should go back to reading email in an xterm. I tested Pine, Cone, Mutt, and nmh to see if any of them were up to the task. For my use, Mutt came out on top, but Pine is also a reasonable alternative if you don't mind the licensing.

In compiling my list of test candidates, I tried to be as complete as possible while including packages that are still maintained and require less than heroic efforts to obtain and use. Mail User Agents (MUA) that require exotic dependencies and too much hand-tweaking to compile were out. I left out Elmo because it has not been updated since 2004, its Web site is clearly unmaintained, and I received no response to email I sent to the developers about Elmo's continued development. That's a pity, because Elmo looked like a promising mailer. Elm's development seems questionable as well; I couldn't find packages for any of the distros I use regularly, and the configuration script is arcane and tedious to the point of frustration.


I started off with Pine, since I had experience with it in the past, and I thought I'd see how it stacks up now. Pine was created at the Computing & Communications department at the University of Washington in 1989.

Pine ships with its own editor, Pico, and filesystem browser, Pilot. Pico and Pilot are standalone applications, so you can opt to use them outside of Pine if you wish.

Pine is reasonably easy to use for a text email application. Each of its screens has a helpful menu that sets out the options that you'd want to use. You can configure Pine using setup menus -- which are less intuitive than they could be, but they at least provide a full listing of Pine's configuration options. Other text mode mailers tend to require poking through man pages and online manuals just to figure out what options are available, and tweaking the requisite configuration file with a text editor.

But some things are harder to configure with Pine than with other mailers. Pine works great when you're using it on the same system that you're sending messages from, but setting up SMTP authentication can be non-trivial.

Pine also doesn't offer any obvious way to set up encryption, though I have found a few HOWTOs and addons to provide GnuPG functionality when using Pine.

Because Pine is not available under a "free" license, many Linux distros no longer ship Pine packages. However, compiling Pine isn't difficult, and the license is free enough for many end users -- if not for vendors and projects that have to worry about patches and security updates.

A new Pine-based mailer called Alpine is under development. To get access to the alpha at this time, you have to join the "Alpine-alpha" mailing list. The developers are only posting information about Alpine to the list as far as I can tell, and even the archives are subscriber-only. I tried the first release, which came out on November 29, but was unable to get it to compile on Ubuntu or Debian.

The good news is that Alpine is being released under version 2.0 of the Apache License. I don't see any reason why the university couldn't release Pine itself under the Apache license now, and then release Alpine whenever it's ready. It would be nice for loyal Pine users if Debian, Ubuntu, Fedora, and other distros could ship an Apache-licensed version without having to wait for Alpine to stabilize.


The Console Newsreader and Emailer (Cone) is a text-based client that resembles Pine. Its menu layout and keybindings are similar, though different enough to be frustrating for experienced Pine users. Cone uses the Leaf text editor, which is similar to Pico and Nano.

As text-mode mailers go, Cone is full-featured. It includes IMAP support, built-in support for mail signing and encryption, support for multiple accounts, autosave for mail, mail tags, and a set of tutorials for using the mailer.

Cone's SSL support isn't perfect, though. For instance, when you attempt to connect to IMAP over SSL, Cone complains that you can't initialize the encrypted connection because the root authority certificates are not installed, and gives the option of aborting the connection or appending "/novalidate-cert" to the server name and using the server without validation. It'd be a Good Thing™ if Cone actually gave a useful error message and told the user what would be required to install the root authority certificates.

Cone is another text mailer that you'll probably have to compile from source, as it's not included in most Linux distros. Unlike Pine, its GPL licensing is not objectionable to free distros, but it's not popular enough to make it into Debian, Ubuntu, and other distros.


These days, Mutt is probably the most popular text-based MUA for Linux distributions and *BSD variants. The reasons for its popularity aren't hard to discern. It's GPLed, so there's no licensing issue as with Pine. It's full-featured, and has support for IMAP and POP3, several mailbox formats, control over mail headers, PGP and MIME support, and much more.

Mutt's flexibility also offers a lot for an audience that's likely to want to use a text mode mailer. Mutt's keybindings can be configured via the .muttrc configuration file, and you can create macros to reduce the number of keystrokes it takes to do something (like saving a message or switching between folders) or send messages to external programs such as Bogofilter.

Like Pine, Mutt displays a menu of options at each screen, so you can see the most common options. Mutt lists only a few options on each screen; to see the rest of the contextual options, you can press ?. This screen isn't newbie-friendly, because it throws a gob of options at the user all at once, and sorting through them can be a challenge. However, Mutt does seem to have a lot more options than Pine, which is an upside in the long run.

The downside to Mutt, when compared to Pine or Cone, is that it doesn't offer any internal configuration utilities. If you want to set up an IMAP account or change your From headers, you have to do all the tweaking in the .muttrc file. This means that new Mutt users have some pain in store in the short term, but Mutt can help them be more productive in the long term by customizing the application.

nmh and MH-E

The New Mail Handling System, or nmh, offers an unusual way of managing email. Typical MUAs like Mutt present a single interface, and you fire up the program, read mail, send mail, file messages, and do any other mail management from within that interface.

Nmh, on the other hand, is a collection of programs that perform different tasks. You don't run nmh and receive a mail interface; you use show to display a message, next to display the next message, prev to display the previous message, comp to compose a message, and the list goes on. Nmh has more than 30 individual commands for dealing with mail.

A typical example of using nmh to read mail might be running inc to incorporate mail from the mail spool into your mail folder, then running show to display mail, prev to see a previous message, and then repl to reply to a message. This is all done from within the user's normal shell, rather than from within a mail program.

Nmh assumes that you'll be pulling email in from the local spool, so you'll need to use Fetchmail, Getmail, or another tool to grab mail and deliver it to your local system if you're reading mail from a remote location.

I can't really recommend nmh as a mail client. It's seriously non-intuitive and not likely to appeal to many users who aren't already familiar with the original Message Handling utilities. but if you happen to use another MUA with MH mailboxes, then you might want to look into nmh's utilities for use working with messages in scripts.

If you're an Emacs user, you might try MH-E. MH-E is an Emacs interface to MH, which provides a slightly simpler way to interact with the MH system. I say "slightly," because in my short experiments with MH-E, it seemed almost as unintuitive as using nmh utilities directly.

After test driving all the different MUAs, I decided to stick with Mutt. By configuring Mutt to use the MH-style mailboxen, I can use Mutt and Sylpheed with the same set of mail folders and not have to give up a GUI mailer entirely to also use Mutt.

Share    Print    Comments   


on Text email clients revisited

Note: Comments are owned by the poster. We are not responsible for their content.

Re: Pine

Posted by: Anonymous Coward on January 04, 2007 08:35 PM
My only real complaint with Pine (windows version) was I could only use one email address at a time. I have 4 different email addresses and it is useful to be able to check them all at once and select which one I want to send from when I compose.

Right now, my main email client is Sylpheed for windows.


Re: Pine

Posted by: Administrator on January 05, 2007 07:12 PM
Yes, that was my frustration too.
Also, to make multiple IMAPs work well in Mutt requires setting up Fetchmail and Procmail too, which is... a bit of a hassle.


Re(1): Pine [multiple accounts]

Posted by: Anonymous [ip:] on August 23, 2007 05:29 PM
Accessing multiple IMAP accounts is possible in pine . It requires extra config [in .pinerc] though..

- for incoming accounts - specify them all in 'folder-collections' and 'incoming-folders'

- Now when replying to an e-mail - to use the same e-mail id [and perhaps the corresponding
SMTP server for that account] - specify this in [Menu -> Rules -> Roles]

for eg: If "Partic pattern= user@account" then use "Set From=user@account" etc..

There are bunch of other "if/then" options that can be set in Rules->Roles.

I use this on linux [never tried pine on windows though..]



Posted by: Anonymous Coward on January 04, 2007 08:48 PM
How the heck wasn't Elm available?

For instance, Slackware 11 has it (as it always did):

Elm was my first `smart' MUA, and I even considered PINE to be too `unnecessary fancy'<nobr> <wbr></nobr>:-)

That was back in 1995...



Posted by: Anonymous Coward on January 04, 2007 10:04 PM
Yeah, I used elm for years. Its vi like navigation was awesome. I would put elm at the top of the list.



Posted by: Anonymous Coward on January 04, 2007 08:56 PM
Any comment on the compatibility of these with Emacs/EmacsSpeak?

I've worked with the visually impaired, and i know that setting up pine through emacs/emacsspeak doesn't really work.



Posted by: Administrator on January 05, 2007 07:23 AM
If you are already using Emacs you should take a look at Gnus, VM, or one of the other umpteen million Emacs packages for dealing with email.


Where are the screenshots?

Posted by: Anonymous Coward on January 04, 2007 11:02 PM
Although these are text-based clients, they do have user interfaces! UI matters, please do not leave them out of your review.


Wikipedia articles

Posted by: Anonymous Coward on January 04, 2007 11:44 PM
Beware, Pine is NOT free software!

* <a href="" title=""></a>

* <a href="" title=""></a>


Re:Wikipedia articles

Posted by: Administrator on January 05, 2007 04:08 PM
Pine is not having an OSI-approved license and is not considered free by people who can only thinl in GPL's terms or following DFSG's lines.

More reasonable people are not having problems with that. Kudos to Patrick Volkerding, for I can use PINE in Slackware out of the box!


Fedora Core has Cone. A simple "yum install cone"

Posted by: Anonymous Coward on January 05, 2007 02:50 AM
Cone is in at least one popular distro: Fedora Core

"yum search cone"
"cone.i386 0.66.20060203-1.fc5 extras
Matched from: cone
CONE mail reader
CONE is a simple, text-based E-mail reader and writer.
<a href="" title=""></a>"


Debian has alpine

Posted by: Anonymous Coward on January 05, 2007 05:39 AM
Debian Unstable includes ready-built alpine and alpine-pico packages.


nmh handles POP just fine.

Posted by: Anonymous Coward on January 05, 2007 08:39 AM
The mh tools have handled POP, Kerberized POP, etc. for a long, long time. The GNU mailutils version of inc also handles any mail source its library knows, including IMAP. And you can run GUI tools when you're on a fast connection, Emacs MH mode on a medium-speed connection, or just use the text tools. You quickly learn to love sequences. I'd advise skimming the MH book (<a href="" title=""></a>) before deciding against MH.


Why text based

Posted by: Anonymous Coward on January 05, 2007 11:50 AM
Please explain, what is the benefit of a text based e-mail client over things like gmail or evolution.


Re:Why text based

Posted by: Anonymous Coward on January 05, 2007 12:22 PM
You will understand when all you have is a terminal login to the machine.


Re:Why text based

Posted by: Anonymous Coward on January 06, 2007 03:31 AM
Well, I guess that would rule out Evolution. But almost any computer with internet access have a browser in one way or another. Why not webmail?


Re:Why text based

Posted by: Anonymous Coward on January 06, 2007 04:49 AM
No web interface I've seen provides user comfort of localy run application. It still needs to communicate with server and it's limited by HTML and JavaScript capabilities. Now I use GMail for half a year and I was using several other webmails before (all were worse) and though I quite like it and it has the advantage of providing the same interface from everywhere it definitely isn't as fast, comfortable and configurable as common email clients. I was using several webmails and several email clients both GUI and text-based and all those approaches have some pros and cons.


Re:Why text based

Posted by: Anonymous Coward on January 05, 2007 05:12 PM
I have yet to find a graphical mail client that can do everything that Mutt can.

For example, I find Mutt's support for scoring of e-mail messages (not anti-spam scoring) to be a "must-have", and I can't find any graphical mail clients that have anything like it.


Re:Why text based

Posted by: Anonymous Coward on January 06, 2007 01:54 AM
Email is text. Text based MUA's don't have all the vulnerabilities of the XSS web based mailers, and autoexecute everything nature of GUI MUA's. If I DO want to view HTML or an embedded picture, my mailcap is setup to launch the appropriate viewer / editor.

I also never have to take my hands off the keyboard to use Mutt. It's MUCH MUCH faster to read and manage email with Mutt than any other email client I have ever used (and I have used a lot over the years.) The "hooks" system automates much of what you manually have to do in a typical GUI MUA.

I think the question needs to be asked: what is the advantage of a GUI MUA to manage email which is 99%+ text only content? So far, I haven't seen one in my 20+ years of using email.


Defeated by Mutt

Posted by: Anonymous Coward on January 05, 2007 10:25 PM
I have made several attempts to try Mutt but failed each time for the simple reason that I couldn't use the top menu. The menu's default background color (blue) is so strong that I cannot read the menu items (red). I have experimented modifying the config file but the background color has eluded me so far.


Mutt. rawks.

Posted by: Anonymous Coward on January 06, 2007 01:06 AM

I've used a bazillion email clients: BSD and VMS mail, ccMail, Outlook (95 - XP), Outlook Express, Lotus Notes, Eudora, (OSX), Thunderbird, Netscape mail, elm, pine, and others long forgotten.

Simply nothing but nothing comes close to providing the speed and flexibility of access to thousands or tens of thousands of mails per folder. Filtering, threading, index highlighting, console-mode, and the ability to remotely access my mail via SSH sessions (and screen) simly blow anything else out of the water.

Toss in the flexibility offered by multiple access methods (direct POP/IMAP, or fetchmail + procmail filtering), and the fact that mailbox formats (mbox, mh, mdir, maildir) are all text-based and allow either direct access by other tools, or automated processing and filtering, and you've got a wicked-bad system.

A better means for handling address books (we've got an LDAP directory at work) would be good, but even that I've got workarounds for.

- KMSelf


Re:Emacs/EmacsSpeak - an untastefull giggle

Posted by: Anonymous Coward on January 06, 2007 01:08 AM
I apologize to those who become offended and realize no offense was intended by th eposters. If it helps I am monoculur due to an eye injury however:

first post; "I've worked with the visually impaired"

second post; "you should take a look at"

I'm going to be giggling over that for a few hours at least.


Internal configuration

Posted by: Anonymous Coward on January 07, 2007 07:19 AM
> The downside to Mutt, when compared to Pine or Cone, is that it doesn't offer any internal configuration utilities.

Gosh. Never actually noticed that. I use mutt and quiting is always ok with me. It starts instantly anyway. I never even thought about configuration from inside of mutt itself. It is so<nobr> <wbr></nobr>... natural to vim ~/.muttrc<nobr> <wbr></nobr>;-) Not that I need to reconfigure mutt often.

I use fetchmail to actually get e-mail - so my mail is always local to me. Probably that's why starting mutt is always fast for me.


rmail in emacs

Posted by: Anonymous Coward on January 07, 2007 05:57 PM
What's wrong with M-x rmail in emacs?

Glad I learned emacs early 1982. Still useful, for example for reading emails on remote systems.


mutt &amp; sylpheed together

Posted by: Anonymous Coward on January 11, 2007 12:32 AM
I'd be interested in this setup: how to use those two clients on the same mailfolders. Could you please share your muttrc?


I used to use xmh, MH, exmh, and Mutt

Posted by: Administrator on January 05, 2007 01:47 PM
I found that MH based Email programs were the most flexible, because if I had a method to pull in Email from my server, I could use exmh, a very nice TCL/Tk based Email package developed from the individual MH commands. Then I could use MH from the command line, xmh if I wanted a faster, simpler interface than exmh, or if I was away from a GUI, I could use Emacs' mh-e, Mutt, or even use a shell and cd into the Mail directory and use more or less to type out messages labeled 1, 2, 3, etc.

I found Mutt to be the most flexible out of all of the text based Email packages, and also one of the fastest Email clients. I also used Sylpheed and Sylpheed-Claws from time to time.

These days, I use Thunderbird because it runs on multiple platforms, is easy to obtain and update, has solid features, and I have quite a repository of folders, filtering options, and flexibility, with the cost of having to give up the nice MH based concepts of having numbered files holding messages and directories on the file system containing mail folders.

Compromises, but it has worked well for me. Still, I miss exmh and Mutt. For the hard core text email fans, I think Mutt is the most flexible and powerful Email client, and some may argue that it competes, feature for feature, with the best GUI based Email programs. However, it is also one of the most complicated and challenging Email clients to set up effectively. Worth it if you demand speed and maximum flexibility.


nail anyone?

Posted by: Administrator on January 06, 2007 01:22 AM
Not that I was surprised that mutt wins, but I recently found nail- a full-featured mailx replacement, but still lightweight enough for a text mail client. Actually, a article got me started on it (I don't know the author of the article):

<a href="" title=""><nobr>1<wbr></nobr> /31/1633211</a>

It has some advantages over mutt, let's say, ease of configuration, especially for sending mail. Yes, I know about ssmtp, nullmailer, msmtp and all that stuff now, but it's still a hassle compared to a couple of configuration options. Nail also fetches mail one page at a time (headers, that is). Does anyone know how to do that in mutt? It gets mildly annoying when I'm over a slow connection and try to read my mails from my large IMAP inbox (I don't like to delete them).

It's not a Mutt-killer, but is definitely a decent package. Oh, and it has obviously had Debian and Ubuntu packages for ages (well, it's older than Ubuntu itself, and can be tracked to at least oldstable on Debian).


This story has been archived. Comments can no longer be posted.

Tableless layout Validate XHTML 1.0 Strict Validate CSS Powered by Xaraya