The Grumpy Editor reviews Claws Mail

The Grumpy Editor's guide to graphical email clients was published almost exactly four years ago. At that time, your editor was looking for a client which could replace an MH-based setup which, for all its age, provided a degree of speed and flexibility which was hard to match. Your editor gets a lot of mail - even before lists like linux-kernel are factored in - so there is a real need for a mail client which can process messages without adding even a few seconds of overhead. At that time, none of the clients reviewed were up to the task; it seems that developers of graphical clients value a number of features above speed and flexibility.

That review mentioned a client called sylpheed-claws; at that time, this client was being managed as a sort of development branch for sylpheed, with every intent of getting changes back into that system. Since then, sylpheed-claws has evolved into a full fork intended to create an independent application; it's new name is Claws Mail. In 2004, your editor had found sylpheed-claws to be an unstable platform at best; in 2008, it seemed like time to go back and see what the developers had accomplished in the last four years. To that end, Claws Mail 3.4.0 was installed and put through its paces.

The good news is that this client has, indeed, stabilized over time. Your editor was unable to make it crash - always a nice feature in a mail client. Many of the features which were under development four years ago are now stable and supported - and, generally, well documented. Claws Mail has come a long way.

The Claws Mail developers emphasize configurability, so there's a wide variety of options to wander through. The layout of the window is highly configurable, allowing the user to make the best use of the available screen space. Most aspects of the client's behavior can be tweaked. For somebody who is willing to wander through a long series of configuration screens, Claws Mail offers the ability to adapt the client to just about any set of needs.

Dealing with email is a keyboard-intensive activity. One of your editor's biggest complaints with graphical clients has been the need to switch constantly between the keyboard and the mouse - a transition which breaks focus and steals time. Claws Mail has improved things in this regard, in that a wide variety of actions can be handled without the mouse. And, unlike some other graphical clients, changing the keyboard bindings is easily done.

For some simple operations - plowing through a mail folder, reading and deleting messages - Claws Mail can be visibly slow. Working over IMAP does not help, of course, but it is slower than with, for example, Thunderbird. In addition, by default, Claws Mail will not display a message which becomes selected as the result of, say, deleting the message before it. So the cycle of deleting a message and viewing the next one requires two keystrokes or clicks. That particular problem can be configured away, of course. Much of the remaining slowness can be mitigated by turning off the "execute moves and deletes immediately" option - a change which also makes it easier to recover from overzealous "delete finger" reflexes.

One common bit of workflow for your editor involves feeding a message to an external program. As a general rule, graphical mail clients do not make this possible, though this feature is almost universal in non-graphical clients. Claws Mail includes the concept of "actions," which are, essentially, external programs which act on messages. This feature almost solves the problem; actions can be set up with quite a bit of flexibility, and they can be bound to keystrokes. But there is no equivalent to the "|" operation provided by textual clients, meaning that it's not possible to pipe a message into an arbitrary command. Claws Mail only passes through the mail headers which are visible on the screen - and there appears to be no way to configure that behavior.

HTML mail appears to be an unfortunate fact of life on the contemporary net. Claws Mail will render such mail as text by default; there are also a couple of plugins which can render HTML mail as intended by its sender. It warmed your editor's heart to note that Claws Mail (unlike certain other clients) does not send HTML mail by default. In fact, it lacks the ability to send HTML mail at all. These developers seem to have their priorities in the right place.

Offline operation is another nice feature in a mail client. Claws mail has such a feature, but your editor was only able to get it partially working. The client can gather up mail for offline reading, but changes and sending of mail lead to a series of "I can't do this" dialogs. Some more configuration (e.g. setting up a local drafts folder) helps in this regard, but this area looks a bit like a work in progress.

There's no end of other features, of course. Claws mail supports encrypted mail, spelling checking, filtering of messages on arrival (with an optional Perl plugin for those especially complicated filtering jobs), a mail template facility, color-labeling of mail, tagging, scoring, watching of threads, and more. There are plugins which will turn on a laptop LED when mail arrives, strip attachments, view PDF files, track RSS feeds, deal with vCalendar messages, etc. There is a complex search mechanism which can do a lot more than just string matches. It is, in summary, a highly capable tool with more features than just about anybody is likely to use.

So has your editor made the change? Not yet. Ways around some of the speed issues will have to be found, and it may be necessary to write a plugin to make Claws Mail work with some LWN processes. A few other details need to be made to work correctly. But it can be said that Claws Mail has gotten closer than any other graphical mail client that your editor has tried to date.

---

(Log in to post comments)

Just one thing, about Actions: you can indeed pipe a complete mail to an arbitrary command;
using either:

|mycommand

(which sends message body or selection to mycommand's stdin) or

mycommand < %f

to send the full raw file.

For example:
ROT-13 selection or body
|tr a-zA-Z n-za-mN-ZA-M|
(the trailing | sends the result back to the message view)

I think you could construct something like that by creating an action that 
pipes into a shell script that calls kdialog (or a similar tool).  Maybe 
something like this:

#!/bin/sh
exec `kdialog --inputbox "Enter command to pipe into" ""`

Since claws sits on top of an MH mail store, can you not just have a command that reads the
message directly from the filesystem? It's a bit of a hack, I know, but it should at least
work.

(Happy MH user for nearly 20 years now -- I've been thinking about Claws, but so far, I
haven't felt the need to make the switch)

Kmail for a long time has had the ability to pipe messages into external programs. In fact the
"integrated spam filtering" that kmail possesses relies entirely on passing messages to
external spam filtering commands. 

Wow that's some ugly font rendering in that screenshot...It does not seem to be caused by LCD
vs. CRT screenshots.

FWIW, font rendering in the screenshot looks fine here @ 100dpi (1600x1200 
on a 21" CRT, ~16" horizontal viewable).  Even at double magnification, I 
don't see a problem.  @ 400% magnification I can, and reducing from there 
to 300% I can, since I know where and what for to look, but at 200% again, 
I still see no problem, and that's still double my usual magnification.

Are you perhaps stretching to a non-native resolution on an LCD, thus 
introducing artifacts there?  Or maybe you're just running say 640x480 
standard TV resolution on a 40" TV or something?  Or maybe it's simply 
personal preference, but I know I see no issues here, even @ double my 
usual magnification.

I find myself wondering if *any* other mail clients support the expiry 
feature offered by Gnus, whereby you can mark a mail for *later* automatic 
deletion (after a per-group-configurable time), and force immediate 
deletion of all expired mail if you need to.

This is really, really, killingly useful: it's like having a 
multi-day-long perfectly reliable email undeletion facility. I find it 
astonishing that nothing else I've tried has done it (not that I've tried 
anything else with much hope that it'll be able to exceed what Gnus can 
do).

In Claws you can create a processing rule for each folder/group.  For example a rule with the
condition 'age_greater_than 30' and the action 'delete' will delete any message older than 30
days.  Rules are run on startup and when the folder is opened.  You can also specify multiple
conditions to match so you can exempt, say, unread messages, or mail from people in your
address book from deletion.

Using claws myself (and seeing it crash 4 times a day since the last update), I used
latencytop to diagnose one of the performance issues with it... and it's a kernel bug.

Short term solution:
echo 4096 > /sys/block/sda/queue/nr_requests
and suddenly all is happy

longer explenation: claws maildir support causes many inode updates, which in turn causes many
IOs. The block layer does CFQ fairness at a low level, but these IO's don't get there (they
get blocked waiting for requests), and the request layer is not fair... stalling claws for 2+
seconds at a time

Sounds a lot like KMail.  :-)

Except that I wish I could make KMail not auto-display a message after 
deleting the previous one, and I wish I could turn off "execute moves and 
deletes immediately" in KMail like you can in Claws.

And yes, I too miss the ability to pipe a message to an arbitrary 
command....

Fellow KMail user here.

For my email, I find that KMail is the least annoying mail client. The 
font rendering is good, and the layout and icons are decent. It doesn't 
seem to butcher diffs the way other mail clients do.

Two things drive me crazy about KMail. The first is that it does, on rare 
occasions, crash. It's not nearly as bad as Konqueror, which I also use 
because I find it the least annoying... but it does still crash. :(

The other issue is a behavior I've seen when KMail starts juggling a lot 
of messages over IMAP. Eventually, it seems that the cache gets corrupted 
such that the message header list won't match with the actual message 
list. In other words, you end up with surprising behavior in which you go 
to click a header (or key to it) and find that the message KMail has 
loaded is completely different. Generally, the header you click will 
change to match this message as well. The confusion gets even worse when 
you try to use the Search feature to search the message headers...

In these instances, I've found that nuking all of the IMAP cache with 
rm -rf is the only way to fly.

Yes, I've noticed similar behavior, except that the list-cache issue is more likely to give 
me empty messages than wrong messages.

Strangely, it's a much bigger problem on one of my machines than on the other, despite 
them running the same version of Kubuntu (though different kernels).  I eventually got 
tired of nuking the IMAP cache on the one machine, and now use KMail only on the other 
one.  :-/

Konqueror's crashes seem to be most often due to memory overload or (more rarely) 
javascript oddities.  It doesn't leak memory as badly as Firefox does, but it does leak 
memory worse than I'd like.

> Konqueror's crashes seem to be most often
> due to memory overload or (more rarely)
> javascript oddities.  It doesn't leak
> memory as badly as Firefox does, but it
> does leak memory worse than I'd like.

Hmm, maybe that's why I don't tend to see such crashes.  I keep scripting 
off by default and finally have plenty of memory (8 gigs, 64-bit 
environment).

The problem then is that konqueror severely lacks sufficient scripting 
control, similar to noscript on iceweasel.  I can turn scripting on for a 
particular site and often, scripted features I want still won't work, 
because the script is loaded off a different site.  With iceweasel, it's 
simply a matter of checking noscript to see what additional sites the page 
is trying to load scripts from and enabling the ones one wishes (view the 
scripts first using the jsview extention if desired) either temporarily or 
permanently.  With konqueror, I'd have to either view source and check 
manually for scripts loaded from other sites, then load konqueror's 
scripting config and manually type in and enable all the desired sites 
individually (and permanently until deleted, no temporarily enable option 
available), or give up and enable scripting globally, including for sites 
like google analytics (urchin tracker) that I'd normally ban.

That's the big reason I still keep iceweasel around.  If konqueror were to 
get decent with its scripting control, using extensions or built-in, I'd 
likely be able to give up iceweasel entirely.  It's possible there'd still 
be some compatibility issues, but where I've dared to, many of those 
magically disappear if I enable scripting globally in konqueror.

Duncan

My biggest gripe with kmail is read-flag synchronization. I have three machines, A, B, and C.
A and B run kmail, and C runs OS X's Mail.app. When A marks a message read, only C notices
that's read. when B marks a message read, only C notices that it's been read. The result is
that on A and B, I often end up reading the same message twice. Flushing the IMAP cache
doesn't help.

I'm having the same problem between Gnus (my primary client) and a couple of Thunderbirds I'm
having in auxiliary machines, all with imap.  Although I cannot confirm it, I'd say that it is
the Thunderbirds that ignore the read flags from Gnus, or Gnus is not diligent enough to send
them promptly to the imap server.  It is really annoying, but I don't have the time to isolate
who's fault is it.

Anybody else has more details?

Ferran

If 'gnus-verbose' is at least 7, you'll see messages of the form "nnimap: 
Setting marks in %s..." when the read flags are being updated.

It's saved by 'gnus-summary-save-newsrc' (Z s), on group exit, at article 
motion time, and at some other moments: it is *not* saved immediately 
merely because you read an article (that would be much too slow with some 
backends).

I'd be interested in hearing about the reasons for the Editor's decision to investigate MH
alternatives. Clearly it isn't a desire to embrace html mail. And nmh development, at least,
seems to be somewhat active.

your editor and any other may just look onto smtp<>nntp<>news_reader. Yes this is not `apt-get
install foo` stuff, but exim4<>inn<>slrn for private mail or gmane<>slrn for lists is the most
productive, flexible and stable environment i've ever had.

Simple smtp-based e-mail has evolve to what nntp was initially designed for, without ad-hoc
functionality for expirity, indexing, search, storing, etc., etc. and all this for huge
volumes of messages. Oh, man, NIH!

As an IMAP client, does it do basic things right such as IDLE and server side searches?