The Grumpy Editor's guide to graphical mail clients [LWN.net]

This article is part of the LWN Grumpy Editor series.

This is the second article in a series dedicated to the discovery of the perfect mail client. Those who have not read the introduction to the series may want to do so; it explains much of the motivation behind this search. This article, in particular, looks at the current crop of graphical mail clients. Future articles will look at terminal-oriented and emacs-based clients and other aspects of the mail system.

Your editor, remember, is looking for a mail client which enables the processing of vast amounts of mail in a flexible manner. An LWN editor can spend hours each day dealing with email from various sources; actually getting an LWN Weekly Edition out every week very much depends on the use of an efficient, reliable client. In particular, your editor is looking for:

A powerful and flexible command set which does not require constant use of the mouse.
A high degree of configurability. When a complex tool is being used as a key part of the daily workflow, it is worth spending some time to tweak it to optimal performance. That tweaking should be possible.
The ability to interface with external programs for the disposition of email.
Support for common tasks, such as sending patches.

For this article, your editor spent a significant amount of time working with Balsa, Evolution, KMail, Sylpheed, and Thunderbird. These programs all have a great deal in common; they would appear to have all been built from the same basic template. A tall pane on the left contains the folder hierarchy, usually split between local folders and those found on some remote server. The top right pane gives a folder view, while the bulk of the space, in the bottom right, contains the text of a message itself. Separate windows are used for composition of new messages.

Each client has its own keyboard shortcuts (we will get to that later), but the mouse-oriented interaction is quite similar between all of them. A user familiar with one of these clients could make use of another with little trouble. Could it really be that the optimal model for graphical email clients has already been found, and that no further experimentation is called for at this point? Or could it be that all of these clients are imitating a popular proprietary email offering?

All of the clients have most of the expected features: built-in address books; support for multiple accounts; disconnected operation; secure POP, IMAP, and SMTP access; threading of folders; hierarchical folders; filtering of messages based on various criteria; etc. Most of the common features will not be discussed here.

Balsa

Balsa is a longstanding GNOME client. In recent years it has been somewhat upstaged by Evolution, but development on Balsa continues. The 2.1.3 development release came out in May, 2004, but your editor was unable to make it work on his system; this review, thus, looks at the stable 2.0.17 release.

Balsa lacks the polish of some of the other mail clients we'll look at here, but it has many of the same capabilities. It can deal with remote mailboxes via POP or IMAP, and local mailboxes in mbox, maildir, and MH format. It can only use SMTP for outgoing mail; there is no option for passing a message to a local command.

Balsa has one failing which it shares with a few other clients: it makes the user wait while it talks with the remote SMTP server. It would be nice if this conversation could happen in the background; there is little joy in staring at a "connecting to server" dialog for an indefinite period of time. Yes, one can always set up a local MTA to handle this task, but that should not be necessary.

Balsa can render HTML mail reasonably well, though it cannot create such mail (the lack of this feature does not strike your editor as a problem). Its display of multipart MIME messages is somewhat awkward; it can only show one part at a time, forcing the user to bounce between tabs to see the whole message.

There is a reasonable set of keyboard shortcuts which, happily, do not require extensive use of modifier keys. There is no provision for changing the shortcuts, however.

Balsa's interface can be somewhat annoying; it can, at times (such as when getting a large message from a remote server), become unresponsive to the user, who is left wondering what is really going on. The address book interface looks powerful, but it would be nicer if it started with a default, local book and didn't require the user to dig through the preferences dialog before allowing addresses to be saved.

Balsa has a basic set of filter operations, though less advanced than most other mail clients. One unique filter operation, however, allows matching messages to be automatically sent to the printer. The potential for paper waste and embarrassment is impressive.

All told, Balsa is a reasonably capable mail client. One gets the impression, however, that its time in the limelight has passed. Most of the other clients reviewed here are more capable and smoother to operate.

Evolution

Evolution has the broadest focus of any of the clients reviewed; it merges the email functionality with contact management, task list, and calendaring functions. Your editor, who is looking for an email client rather than a calendar manager (he addressed that problem a few months back), did not look at these other capabilities in any great detail. One can certainly imagine uses where an integrated calendar manager would be useful, but, if one is seeking a focused mail client, calendars and such can be a distraction.

Version 1.5.9.2 (a pre-1.6 development release) was looked at for this review.

Evolution can handle a wider range of email account types than any of the other clients reviewed. Along with the usual forms (IMAP, POP, local mailbox), Evolution can work with Novell GroupWise accounts and folders in maildir or MH format. An attempt to set up an MH directory, however, crashed Evolution and rendered it incapable of launching; such is life when one plays with development releases. Use of Evolution to read netnews groups is also supported. Outgoing mail can be sent via SMTP to a server, or passed to a local application. Evolution has a nice feature where it can query the remote mail server to determine what sorts of authentication and encryption features it supports.

Some basic spam filtering is built into Evolution; users can mark messages as being "junk" and, once the internal filter is properly trained, apply filters to clear the spam out of the way. The filtering appears to be based on SpamAssassin. The documentation mentions an option to have Evolution pass mail to spamd for evaluation, but that option does not yet actually exist in the configuration dialogs.

Evolution provides a set of keyboard shortcuts which allows some actions to be performed without the mouse. There is no evident way of configuring shortcuts, however; if you don't like the defaults, there's little to be done.

Evolution provides full support for HTML mail. Incoming HTML is rendered by default. It can compose mail in HTML format, and a full set of operations is provided enabling the composition of truly gaudy messages. Happily, Evolution defaults to sending plain text mail only; users must explicitly say they want to create HTML messages.

There are some nice features for finding messages within folders. A search bar in the main menu can quickly narrow the view to messages meeting the search criteria. The "vFolder" mechanism is a more advanced feature which enables the creation of custom views which can include messages from multiple folders which meet the search criteria.

KMail

KMail is the KDE mail client, part of the "kdepim" package. In many ways, KMail is the most configurable and flexible of the graphical email clients out there.

KMail can handle incoming mail via POP, IMAP, and local mailboxes in mbox or maildir format. Outgoing mail is transferred via SMTP or handed to a local program. KMail's account setup is, however, a little more confusing than that found in the other mailers. Mail identities, mail sources, and "transports" (ways of sending mail) are all configured separately; they can then be mixed and matched in arbitrary ways. Those who are so inclined can select a different outgoing transport for each message. The system is flexible, but not necessarily straightforward to set up at the outset.

Like Evolution, KMail can query remote mail servers to determine their encryption and authentication capabilities. This is such an obviously good feature that one wonders why all mail clients do not work that way.

KMail has extensive configuration options. Uniquely among the clients reviewed (but standard for KDE applications), KMail provides an easy mechanism for configuring keyboard shortcuts. The defaults also make some sense: "R" for reply, for example. Given that regular, unmodified keystrokes have no intrinsic meaning in the context of a mail client window, why make users lean on the control key to get anything done? One should be able to simply hit "N" to see the next message, and KMail's designers understand that.

The usual filtering operations are available. KMail does not, however, have any sort of internal spam filtering built into it (though some of the available, undocumented options, like "mark as spam," suggest that this capability is coming). Filters can, among other things, change the default identity or outgoing transport which applies to a given message, or rewrite header fields. Like Evolution, KMail supports virtual folders created by searching; there is no search bar in the main window, however.

KMail can render HTML mail quite nicely, but it refuses to do so until the user explicitly requests HMTL rendering for a specific message. It also will not load external images until you get past a configuration screen with dire warnings on it. KMail does not appear to be able to create HTML messages.

As a whole, KMail has a pleasant, responsive interface. It is visually pleasing, and makes relatively good use of the screen space. More than some other clients, it provides feedback on what it is doing at any given time, and does not make the user wait unnecessarily. On the other hand, it has an obnoxious habit of popping up "tool tips" with the message subject when the pointer moves over the subject in the folder view pane; this behavior creates a great deal of distracting flashing while not really giving the user any useful information. Some of the toolbar icons are less than instructive; try to guess what the three shown on the left mean. (They are "get new mail", "reply", and "forward").

In summary: KMail is a capable client; its developers have clearly given some thought to how to make life easier for their users. It is arguably one of the best mail clients available.

Sylpheed

Sylpheed is a GTK+ mail client which advertises itself as fast and lightweight. Like Balsa, Sylpheed feels a little rough in the modern world. This client, however, has some capabilities that the others lack.

At the top of the list of those capabilities might be "actions." Sylpheed includes a mechanism for running external programs on messages; the output of that program can, optionally, replace the original message. Actions can be created with a dialog box (canned actions can also be obtained from the net and added directly to the configuration file); thereafter they show up under the "Tools/Actions" menu. It would be nice if an action could be bound to a keystroke, but...

...Sylpheed does not allow the configuration of keyboard shortcuts. Shortcuts do exist for most operations, but they all require the use of the control key. The font selection available in Sylpheed is also somewhat restrictive; it cannot use the nice anti-aliased fonts the way some of the other mail clients can. If you spend a lot of time staring at a mail client every day, this makes a difference.

Sylpheed tends to hang up at times; when an action is being run, for example. It also makes the user wait for SMTP conversations to complete when sending a message.

This client cannot render HTML mail; it wings it by stripping out the markup and simply displaying the remaining text. This technique works surprisingly well; if you don't get much HTML mail, you may never even notice the lack of proper support.

Sylpheed can work with POP and IMAP mailboxes, or with local mailboxes in the mbox format. It creates local mailboxes using the MH format; it can also be configured to use the MH inc command to incorporate new mail. It has no support for mailboxes in maildir format.

The Sylpheed address book is minimal but functional; there is no LDAP support, however.

For those who find Sylpheed inadequate, but who like the basic platform, the Sylpheed-Claws project may be worth a look. Sylpheed-Claws is an ongoing effort to add vast numbers of features to Sylpheed. Some of these include a plugin mechanism, spell checking (a feature available on most other mail clients), the ability to assign actions to icons on the toolbar, a search bar for narrowing folder views, themes, message scoring, HTML viewing (using an external viewer), better GPG support, LDAP support, and more. The biggest problem with Sylpheed-claws, however, is that it is very much a development release; you editor was able to make it crash in several different ways. Crashing is not a desirable feature in a vital work tool.

Sylpheed is a powerful client which is clearly aimed at serious users. In your editor's not entirely humble opinion, what it could best use at this point is (1) a bit more attention to polish, human factors, and visual appeal, and (2) a concerted effort to move the best, most stable features from Sylpheed-Claws into the mainline client. With some work in that direction, Sylpheed could be a powerful contender for the title as the best graphical client for advanced users.

Thunderbird

Thunderbird is the standalone mail client from the Mozilla project; its most recent release is version 0.7.1. Thunderbird is a slick product; it is visually appealing and, for the most part, easy to use.

Unlike other mail clients, Thunderbird has no provision for local maildrops at all; it can only obtain mail via POP or IMAP. It does maintain local folders, however; they are buried deeply under the user's .thunderbird directory, and appear to be in mbox format. Thunderbird can be used to read netnews from NNTP servers. On the outgoing side, Thunderbird expects to talk to an SMTP server, and it makes you wait while the conversation takes place.

Thunderbird handles HTML mail without trouble; one would expect a Mozilla project to get that part down reasonably well. The client will, by default, execute Javascript contained within HTML mail; your editor is hard put to come up with a reason why one would ever want to leave that option enabled. Thunderbird also sends mail in HTML format and, discouragingly, comes configured to send HTML by default.

Thunderbird is a highly configurable client. The actual configuration can be a bit confusing, however; quite a few options (such as sending HTML mail) are part of the account configuration. A user will look for such options under the "options" menu in vain. Thunderbird also has a powerful extension mechanism, with numerous extensions available on the net.

The default keyboard shortcuts are heavily reliant on the control key, and there is no provision for changing them. The "keyconfig" extension mitigates that problem somewhat, though it is not trivial to use and cannot create shortcuts for all that many operations.

Thunderbird has some strange behavioral glitches. Clicking on a URL in a message, for example, causes Thunderbird to copy the web page to a local file and run a browser on that file; this strange behavior breaks all the images and links, among other things. If, instead, the user drags the URL to a browser window, the right thing happens. Thunderbird is also reluctant to use folders on the remote IMAP server that it didn't create itself; folders created by a different mail client tend to be completely inaccessible.

On the other hand, Thunderbird's composition window is relatively nice and easy to use. The interaction with the address book is easy and transparent, and Thunderbird makes it easy to set various types of headers ("Bcc:", "Reply-To:") without having to dig through menus.

Thunderbird has its own bayesian spam filter built in. Messages which look like spam are prominently marked as such; the user then has the option of correcting things. The toolbar icon toggles between "Junk" and "Not junk," depending on the current marking of the message; the user thus has to actually look at it to see what it will do at any given time. This sort of modal interface is an encouragement to the user to make mistakes. The keyboard shortcuts for marking and unmarking spam, at least, are distinct.

There is a search bar in the main window for quickly narrowing folders. There are no virtual folders for holding search results, however.

Thunderbird is an impressive client; for version 0.7 it is in very good shape. Your editor would like to see some attention paid to the needs of users who want to do nonstandard things, such as adding custom operations to the toolbars. Given that most of the details and polish are already in place, a bit of careful feature work could turn Thunderbird into a truly powerful and useful program.

Other important points

A grumpy editor who posts to lists like linux-kernel lives in fear of two things: (1) sending text in very long lines, and (2) sending patches which have been word-wrapped by the mail client. Committing either faux pas can cause a budding kernel hacker to contemplate a switch to Visual Basic programming. Your editor attempted to get each mailer to send an unmolested patch while performing word wrapping on the accompanying text. Note that some people really want to see patches inline, rather than as attachments, which complicates the situation - any of the mail clients reviewed here can send an attachment without trouble.

Only Sylpheed passed this test in a clear way. If the "wrap on input" option is selected, typed text will be wrapped, but an inserted file will be left alone. KMail sort of works, in that word wrap can be disabled for specific messages. If you use the "external editor" option (which works in a bit of a confusing way; you must type a keystroke in the text area of the composition window to get your editor), whatever the editor produces will not be messed with. Balsa wraps everything, as does Evolution. Thunderbird, interestingly, has no option for inserting a file into an outgoing message; you must cut-and-paste it in (and deal with wrapping problems), or send it as an attachment.

Another important feature, as far as your editor is concerned, is the ability to feed a message to an external program. After all, it just might be possible that users may think of things to do with their mail which, inexplicably, just didn't occur to the implementers of the mail client. Such operations might include feeding a message to sa-learn to better train SpamAssassin's filter, or, in your editor's case, inserting a software announcement into the LWN site.

Support for external programs is poor in most of the clients reviewed. Some of them can invoke an external program while filtering messages (thus, for example, allowing SpamAssassin to be used to clean out junk), but only Sylpheed has a separate mechanism for running programs on specific messages. Even then, only Sylpheed-Claws brings that mechanism to the toolbar, and there is still no way to assign an action to a keystroke. Thunderbird has an "external application" extension, but it is really just an application launcher; it can't be used to process messages. There should be no reason why the right kind of extension couldn't be written; it's just that, as far as your editor can tell, nobody has done it yet.

In general, extensibility is an important feature for a complex application. The original developers will never think of everything, and really should not even try. If the application provides an easy way for others to add capabilities, the result will often be a rich ecosystem of features far beyond the imagination of the application's designers. Among the clients reviewed above, only Thunderbird provides support for first-class extensions - though Sylpheed-Claws is getting there. In the long term, the email client which best supports extensions may well be the one which gathers the largest, happiest user base.

Conclusions

A few other free graphical clients exist, but didn't make it into this review:

Althea looks like a fairly basic GTK-based client. "The design goal was a stable e-mail client with the richness of usability of Microsoft's Outlook, Qualcomm's Eudora, and Cyrusoft's Mulberry."
Mahogany is a feature-rich, highly configurable client; its 0.66 release came out in January, 2004. Mahogany does indeed offer a dizzying variety of configuration options; should those options not suffice, there is also a built-in Python interpreter for extensions. That notwithstanding, Mahogany is said to be a low-bloat application.
Aethera is a client produced by theKompany.com; it claims to do task lists and appointment management; it also comes up with news and weather reports on the side. Unfortunately, source for current releases does not appear to be available from theKompany's download site.

So, with all these options, which would your editor choose? The answer, for the moment, is "none of the above." Your editor is not yet sold on the advantages of a graphical client for this sort of work; these clients do have a number of nice features, but an email client must, above all else, enable quick and efficient processing of mail. Anybody who has tried to exchange email with your editor knows that he can easily get far behind; if the email client adds friction to the process, that problem will get worse.

Some of the clients reviewed look like they could eventually be a part of a workable email system. With luck, future development will take at least one of them in a direction where it is, on the one hand, polished, feature-rich, and usable, while being, on the other hand, easy to integrate into a wider way of doing things. Meanwhile, your editor will proceed to look at some of the current non-graphical offerings (this includes emacs-based clients, which are becoming increasingly graphical in their own right). Stay tuned.

to post comments

There's always Mutt

Posted Jun 29, 2004 20:25 UTC (Tue) by ncm (guest, #165) [Link] (10 responses)

I scanned the article looking for the one feature that I would expect all mailers to offer but rarely find.

I recently installed a plugin to Evolution 1.4 which allows it to use Vim as its composition editor. It works, mostly, although Vim running under Bonobo crashes sometimes. (Thus far I haven't lost any half-composed mail I cared about). My main complaint is in how Evo scrambles copies of messages being replied to.

KMail seems to have some ability to use a preferred editor. Any others?

There's always Mutt

Posted Jun 29, 2004 21:34 UTC (Tue) by dmantione (guest, #4640) [Link] (6 responses)

In the quest for a user friendly Linux desktop there is little room for
well but strange baked cakes from the 70s and 80s. Deal with it.

There's always Mutt

Posted Jun 29, 2004 21:51 UTC (Tue) by hppnq (guest, #14462) [Link]

What is it that makes people think that vi (and 70s friends) and a desktop are mutually exclusive?!

Oh well. Who needs evolution + vim if you can have pine and pico. ;-)

There's always Mutt

Posted Jun 29, 2004 21:53 UTC (Tue) by ncm (guest, #165) [Link]

I do deal with it. I use mail programs that do what I want them to do.

It would seem odd to start by assuming that anything I want is inherently ignorable. Generally, when I want something, somebody else wants it too. Maybe it's "obscure" from a marketing standpoint, and there might not be any profit in providing it, but that's not what Free Software is about, is it?

Maybe doing what people want even though "there's no market" is why Free Software is eating your lunch.

There's always Mutt

Posted Jun 29, 2004 22:49 UTC (Tue) by james (guest, #1325) [Link]

Not the point.

This is a Unix-like system. It should be possible to plug in an external editor, whether it's vi-like, emacs-like, kedit, nano, or whatever. This is especially true when the user has a preferred set of keybindings and "feel" to an editor.

Actually, I'd claim that it would be highly reasonable for an e-mail client to open an external HTML editor if the user really wanted to send HTML mail. (Yes, there are occasions when it's justified). Depending on the situation (which should include knowing which MUA recipients use), this might allow for specialised editors that make it easy to send a particular type of very rich hypertext.

No-one who understands the power of pipelines complains that you shouldn't be able to pipe ls through sed "because sed is a strange-baked cake that has been superceded by Perl". The important thing is being able to plug in an editor, not what that editor is.

James.

(And yes, I do use vi and friends a lot...)

I do deal with it

Posted Jul 1, 2004 1:26 UTC (Thu) by dskoll (subscriber, #1630) [Link] (2 responses)

The lack of proper support for external editors is why I don't use Evolution or the Mozilla mail clients.

This is such an incredibly easy feature for the Evo or Mozilla developers to add that I can only conclude they're actively hostile to the idea.

So much for code reuse.

I do deal with it

Posted Jul 1, 2004 9:06 UTC (Thu) by nix (subscriber, #2304) [Link] (1 responses)

It's also (amazing, but true) a feature that Gnus doesn't support.

(Perhaps the only one. :) )

I do deal with it

Posted Jul 8, 2004 15:29 UTC (Thu) by chmouel (subscriber, #6335) [Link]

Gnus doen't support the filtering to external editor ? And :

gnus-summary-pipe-output

It is bound to | or O p by default

VIM plugin howto?

Posted Jun 29, 2004 22:29 UTC (Tue) by colink (guest, #274) [Link] (1 responses)

I'd heard that it could be done but assumed that you had to manually recompile
Evolution to get it done.

What did you have to do to get it to work?

VIM plugin howto?

Posted Jun 30, 2004 3:33 UTC (Wed) by ncm (guest, #165) [Link]

I apt-got a .deb of a patched Evo from Jason Hildebrand, the author of the plug-in. See http://www.opensky.ca/gnome-vim/ to have all your questions answered.

There's always Mutt

Posted Jul 8, 2004 10:18 UTC (Thu) by job (guest, #670) [Link]

I urge you to try KMail with the kvim editor. It's plain vim but dressed up in KDE clothes and acts as a "component" of the parent program. Just change to editor to "embedded kvim".

The Grumpy Editor's guide to graphical mail clients

Posted Jun 29, 2004 20:53 UTC (Tue) by humberto (subscriber, #70) [Link]

They can take exmh when they pry it from my cold dead fingers (or if the rewrite of MH-E improves the speedbar support a bit more).

It handles MIME, HTML, external commands, external editors, PGP, sequences, searches, and MH folders. Fetchmail and procmail grab and filter my mail.

The real killer is HTML

Posted Jun 29, 2004 21:13 UTC (Tue) by ssavitzky (subscriber, #2855) [Link] (14 responses)

I categorically refuse to use a mail client that renders HTML by default -- why should I let every spammer in the universe know their mail got through? Thank you; I'll stick to gnus

The real killer is HTML

Posted Jun 29, 2004 21:19 UTC (Tue) by nix (subscriber, #2304) [Link] (8 responses)

Nothing wrong with rendering HTML: the problem is rendering images (and other external objects that involve touching the network) in that HTML.

The real killer is HTML

Posted Jun 29, 2004 21:50 UTC (Tue) by bfields (subscriber, #19510) [Link]

> Nothing wrong with rendering HTML: the problem is
> rendering images (and other external objects that
> involve touching the network) in that HTML.

Well, this is a different issue, but I also do worry
about the complexity of the processing that is triggered
when reading a mail (usually from someone I don't trust).
HTML adds a bit more--can you be positive that someone
can't overflow some buffer by, e.g., sending you mail
with some bizarre set of nested tables?

The real killer is HTML

Posted Jun 29, 2004 22:04 UTC (Tue) by Ross (guest, #4065) [Link] (6 responses)

I disagree. HTML is very complicated and there are numerous places for
security problems. Things like Javascript have absolutely no business in
email. Plugins certainly don't belong. Images don't either (they are all
remote... how do you insert an image into HTML?).

In fact there are so many inappropriate features in HTML that I wish Netscape
had standardized a subset which would understood enough to be safe rather
than just force the web into our mailboxes. Actually there would be no point
to stick with HTML (though a markup language would have been best). It
should have been very minimal. No exectable code, remote data, hidden links
or text, or display outside of the message area should have been allowed.
Even comments are suspect in my book. And besides security concerns I wish
blinking text, fonts over 18 points tall, and overly-contrasting colors
had been banned :)

The real killer is HTML

Posted Jun 29, 2004 22:36 UTC (Tue) by bastiaan (guest, #5170) [Link] (3 responses)

FYI, images need not be remote in HTML mail: you can add the images as attachment and refer to them from within the HTML. In fact Evolution has a configuration setting which allows you to either show all, some or no remote images in the mail you receive.

The real killer is HTML

Posted Jun 29, 2004 22:42 UTC (Tue) by Ross (guest, #4065) [Link] (2 responses)

That's interesting. What does an image tag which refers to an attachment
look like?

The real killer is HTML

Posted Jun 29, 2004 22:52 UTC (Tue) by bastiaan (guest, #5170) [Link] (1 responses)

You insert an IMG tag like this:
<IMG SRC="cid:1088549203.3067.4.camel@email.example.com" ALIGN="top" ALT="test" BORDER="0">

And add an attachment to your message with the corresponding content-id:

Content-ID: <1088549203.3067.4.camel@email.example.com>
Content-Disposition: attachment; filename=001_star_butterfly.png
Content-Type: image/png; name=001_star_butterfly.png
Content-Transfer-Encoding: base64

iVBORw0.....

The real killer is HTML

Posted Jul 9, 2004 4:30 UTC (Fri) by xoddam (subscriber, #2322) [Link]

And there's another way: Attachments with a 'Content-Location:' header (which can specify any kind of URI) get priority over the remote resource which would otherwise be fetched from the specified location.

But OTOH it would be easy to omit to implement this part of the MHTML spec and allow your mail client to fetch http: or ftp: URLs despite their being provided as attachments.

The real killer is HTML

Posted Jun 29, 2004 22:47 UTC (Tue) by jwb (guest, #15467) [Link]

Images in HTML mails are not "all remote". You can attach an image in the MIME structure of the mail, and you can reference that image using a url with the cid: scheme.

The real killer is HTML

Posted Jun 30, 2004 15:16 UTC (Wed) by iabervon (subscriber, #722) [Link]

For that matter, executable code, hidden links and text, and display outside of the message area should be prohibited in web browsers as well. Why should the web be any less safe than our mailboxes?

I think HTML really ought to have three levels of functionality: non-interactive documents, documents you interact with in browser-controlled ways (forms), and documents with executable portions (scripts). Only the first of these should count as "text/html", since the others do not fit the definition of "text/*". Probably there ought to be MIME media types added for "form" and "script" (and, while we're at it "style").

HTML isn't really all that complicated if you force documents to be non-interactive, particularly now that experience with XML parsers has elucidated the proper representation for parsed documents. (SGML/HTML being essentially XML damaged in recoverable ways, and parsable by an XML parser that's willing to be not too picky)

The real killer is HTML

Posted Jun 29, 2004 22:13 UTC (Tue) by corbet (editor, #1) [Link] (3 responses)

"I categorically refuse to use a mail client that renders HTML by default -- why should I let every spammer in the universe know their mail got through?"

There are plenty of reasons to stay away from HTML mail, but this is not one of them. Most mailers which interpret HTML also provide an option to disallow the loading of external images, and most of them have that option set by default. So there should be no covert channels back to spammers.

The real killer is HTML

Posted Jul 1, 2004 4:40 UTC (Thu) by ssavitzky (subscriber, #2855) [Link] (2 responses)

"There are plenty of reasons to stay away from HTML mail, but this is not one of them."

I should probably have said something like "among other things..." -- as you say, there are plenty of reasons not to want HTML rendered by default. Yet another reason is spam filtering -- if a message has no text/plain component, or a totally incoherent block of random words, it's almost certain to be spam.

The real killer is HTML

Posted Jul 1, 2004 9:10 UTC (Thu) by nix (subscriber, #2304) [Link] (1 responses)

Hotmail users often send HTML-only mail, I find :(

The real killer is HTML

Posted Jul 1, 2004 15:33 UTC (Thu) by ssavitzky (subscriber, #2855) [Link]

yet another reason :->

Luckily most of the hotmail users I correspond with can be taught how to turn it off. You're out of luck if you have to handle a lot of mail from strangers, of course.

The real killer is HTML

Posted Jul 10, 2004 22:16 UTC (Sat) by chbm (guest, #12065) [Link]

You can build Balsa without HTML support at all. Or you can build HTML support and tell it to prefer text parts.
However, the callback problem you mention doesn't come from HTML itself but from references to external entities on HTML. Balsa is spam-safe in that sense as it never fetches those entities.

The Grumpy Editor's guide to graphical mail clients

Posted Jun 29, 2004 21:42 UTC (Tue) by dlang (guest, #313) [Link] (12 responses)

One item I would like to see a comment on is how well the mail clients deal with large mailboxes. and large numbers of new messages. as an example of one of the worst clients I've seen for this it can take Outlook hours to find new messages if you have been on vacation and have a few thousand new messages waiting when it starts up (and you don't want to think of what it takes when you point it at a IMAP mailbox with a few tens of thousands of messages sitting in it)

the quality of IMAP support is almost worth an article in itself, a mail client with poor IMAP support treats IMAP as just a means to download messages (a direct replacement for POP), but a client that really uses IMAP can potentially be FAR more responsive.

for example an IMAP client can download just the header info for the first screen worth of mail and then download the rest later (while the user is doing useful work instead of waiting for the client to find the messages).

Also since the IMAP server understands MIME the client can delay downloading attachments until the user indicates that they are interested in doing so.

there's quite a bit more that's possible, but I don't want to make this post TOO big

IMAP

Posted Jun 29, 2004 22:13 UTC (Tue) by ccyoung (guest, #16340) [Link] (4 responses)

Maybe you'd be interested in Cone and Courier IMAP

IMAP

Posted Jun 30, 2004 3:49 UTC (Wed) by dlang (guest, #313) [Link] (1 responses)

when given a choice I use Cyrus for the IMAP server not Courier, but that's not the issue here :-)

is cone a mail client? if so can you give more info on it?

Cone

Posted Jul 1, 2004 17:54 UTC (Thu) by bjn (guest, #2179) [Link]

Cone is Sam Varshavchik's Pine-a-like, a good match for Courier environments since it comes
from the same project.

IMAP

Posted Jul 1, 2004 17:51 UTC (Thu) by bjn (guest, #2179) [Link]

Along the lines of dlang's comment, here we started with UW-IMAP until it couldn't handle the
load, and then switched to Courier IMAP until it couldn't handle the load either, and are now
switching to Cyrus. So you can perhaps skip a step. :-)

Cyrus IMAPd

Posted Jul 9, 2004 9:56 UTC (Fri) by ringerc (subscriber, #3071) [Link]

As others have noted, it might be easier and nicer to skip to Cyrus IMAPd
if you're changing mail servers. It's extremely fast even for full-text
mailbox searches ("man squatter" for fulltext indexes used on server-side
SEARCH commands) and very stable. It's also in steady development, and
quite remarkably flexible.

You'll have a hard time getting your head around the authentication
configuration at first, but it's not really that bad and it's well and
truly worth it for such an amazing mail server.

If I had to go back to using an ISP's mail services instead of runing my
own mail server, I'd just fetchmail to a local Cyrus - I'm spoilt by it
now ;-)

The Grumpy Editor's guide to graphical mail clients

Posted Jun 29, 2004 22:54 UTC (Tue) by jwb (guest, #15467) [Link] (4 responses)

I haven't used any of these other clients lately but Evolution works pretty well with huge mailboxes. I have IMAP folders in excess of 100,000 messages and, aside from the initial downloading of the headers, it's surprisingly fast. During the slow operation of downloading headers Evolution does provide status messages, as well.

I've found Evolution can open an IMAP folder much more quickly than mutt can open the same maildir. I don't know if it's evolution that's much better than mutt, or if the efficiency is due to Courier IMAP. Either way it's plenty fast.

The Grumpy Editor's guide to graphical mail clients

Posted Jun 30, 2004 18:41 UTC (Wed) by jzbiciak (guest, #5246) [Link] (1 responses)

If you have 100000 messages in maildir format, it might actually be the<I> kernel </I>slowing you down, reading through that directory. You might google around and look for ext2 performance stats on huge directories. That's what spawned all that dirhash stuff awhile back.

The Grumpy Editor's guide to graphical mail clients

Posted Jun 30, 2004 18:57 UTC (Wed) by jwb (guest, #15467) [Link]

Yes I agree, dirhash is the best. But the point is that it's much faster to read exactly the same maildir using Courier IMAP than it is to read it using mutt.

The Grumpy Editor's guide to graphical mail clients

Posted Jul 1, 2004 16:27 UTC (Thu) by wcooley (guest, #1233) [Link]

If you use Cyrus IMAP, you can also enable the "squatter", which builds full-text indexes of messages in your folder, so even searching a very large folder takes only seconds. A good IMAP client will determine if the IMAP server supports server-side searching. Evolution does; I don't know about any of the others.

The Grumpy Editor's guide to graphical mail clients

Posted Jul 10, 2004 22:21 UTC (Sat) by chbm (guest, #12065) [Link]

Evolution uses index caches, that's why it feels so fast until you have a mailbox that's touched by other MUAs.
In your case IMAP feels much faster cause Courier preopens the mailbox. You're just moving the burn to the server.

The Grumpy Editor's guide to graphical mail clients

Posted Jun 30, 2004 2:46 UTC (Wed) by csamuel (✭ supporter ✭, #2624) [Link]

> One item I would like to see a comment on is how well the mail clients
> deal with large mailboxes. and large numbers of new messages.

My mailbox at home is over 800MB and has lots of messages (probably of
the order of 100,000 - I tend to keep almost everything, just in case).

KMail (from KDE3.0, Mandrake 9.0) handles it well.

Here at work my mailbox is a more modest 334MB and contains only 23639
messages and KMail from KDE 3.2 (Mandrake 10.0) handles that without any
complaints either.

cheers!
Chris

The Grumpy Editor's guide to graphical mail clients

Posted Jul 11, 2004 22:10 UTC (Sun) by eallaud (guest, #22956) [Link]

I would say that you should try balsa-2.2.0 (it is just out) if you can. It really tries to use the server-side of IMAP as much as possible (eg threading and searching/filtering is done via IMAP commands), and only loads the barely necessary infos to build the messages tree, and loads only the message you select on-the-fly.

The Grumpy Editor's guide to graphical mail clients

Posted Jun 29, 2004 21:58 UTC (Tue) by dajobe (guest, #6420) [Link]

I switched to sylpheed-claws from 5+ years of using exmh / mh
and have been happily assigning keystrokes to menu items. Just
select a menu item with the mouse, press the key you want - voila.

I couldn't get mouse-free operation with any of the others I tried.

Also, there's a sylpheed-gtk2 version in testing,
so it doesn't have to look so old-school gnome :)

GPG support

Posted Jun 29, 2004 22:10 UTC (Tue) by pjhacnau (subscriber, #4223) [Link] (2 responses)

You only mention this in passing for Sylpheed, and not at all for the others.
I know what Evolution's support is like; what about the others?

GPG support

Posted Jun 29, 2004 22:15 UTC (Tue) by corbet (editor, #1) [Link] (1 responses)

GPG support is pretty much a given anymore with these clients. I would like to have talked about that a bit more, but this article was getting overly long as it was... Vanilla Sylpheed could use a little work (which Sylpheed-claws provides); the others pretty much handle it at this point.

GPG support

Posted Jul 5, 2004 19:00 UTC (Mon) by mmutz (guest, #5642) [Link]

> GPG support is pretty much a given anymore with these clients.
> [...] the others pretty much handle it at this point.

I tend to disagree. There are vast differences in usability. I, for one
(being not entirely unbiased, of course), couldn't live without KMail's
"Automatically encrypt messages whenever possible" a.k.a. opportunistic
encryption.

Word wrap and Evolution

Posted Jun 29, 2004 22:22 UTC (Tue) by dbg400 (guest, #141) [Link]

It is possible to mix word wrapped text and long lines in Evolution, though it's not immediately obvious. In the Compose window there is a drop-down just above the text area. There are several options, with Normal giving wrapped text and Preformat which leaves it alone (like HTMLs <pre></pre>). Quoted text in a reply or forward gets allocated to Preformat, with any new text getting Normal, but it's selectable. (Note this works with plain text emails - it's not just an HTML option)

I use KMail at home & Evolution at work as I can't settle on one over the other - they just seem to fit better that way for the way I use them.

A couple small remarks

Posted Jun 29, 2004 22:44 UTC (Tue) by bastiaan (guest, #5170) [Link] (1 responses)

Two small remarks about the article:
First, Evolution has support for MS Exchange, enabling shared calendaring, etc. I suspect it is unique in this respect, though I expect that now that Novell has open sourced the code for it, other mail clients will include Exchange support in future releases.
Second, I would have liked to see a comparison of how well the different mail clients support PGP and S/MIME.

Cheers,

Bastiaan

kdepim supports Exchange2000

Posted Jul 2, 2004 18:18 UTC (Fri) by ranger (guest, #6415) [Link]

First, Evolution has support for MS Exchange, enabling shared calendaring, etc. I suspect it is unique in this respect

No. korganizer from kdepim (or kontact if you want something similar to evolution) has Exchange 2000 support out-the-box (well, you just need to enable the plugin in the plugin dialog), and I have seen it in action, works well.

Sylpheed-claws

Posted Jun 29, 2004 22:53 UTC (Tue) by BradReed (subscriber, #5917) [Link]

I'm rather curious how the reviewer crashed Sylpheed-claws. I've been using it for over two years and don't think it has ever crashed. Currently using v0.9.11 very happily.

Mozilla mailnews is very mature

Posted Jun 29, 2004 23:12 UTC (Tue) by ruin8tr (guest, #16593) [Link] (1 responses)

I know that Thunderbird is "the future" but Mozilla's mailnews client is nice, stable and mature and should be considered. A lot of the rough edges of TB don't exist in Mozilla.

Also, I'm not sure about TB but Mozilla can be told how many columns to wrap and if you set it to 0, then it turns line wrapping off. Unfortunately this is a global setting. I agree that it would be cool to be able to turn off wrapping for just a section of text. Even better would be if there was a setting to prompt the user before wrapping text.

Mozilla mailnews is very mature

Posted Jun 30, 2004 16:18 UTC (Wed) by jeremiah (subscriber, #1221) [Link]

that reminds me, there is a drop down in any mail message that you send in evolution, that allows you to adjusting the wraping for a portion of text. I choose preformatted when I want to send code to some one. This kills any wraping, otherwise wrping in the norm.

The Grumpy Editor's guide to graphical mail clients

Posted Jun 29, 2004 23:17 UTC (Tue) by dcoutts (subscriber, #5387) [Link] (2 responses)

Evolution can send code patches without line wrapping. I do it all the time.
It's part of the formatting features, you can select a line/pargraph and from the combobox on the compose window's toolbar select 'preformat', which does just what you'd expect. It can also do a limited amount of other formatting (all in ASCII email mode) like bullet points, enumerated lists, indenting etc.

As for keyboard shortcuts I was under the impression that all gtk+/gnome programs could have menu shortcuts assigned. It was certianly the default in gnome 1.4 era. I believe the ability was turned off by default in gnome 2 (along with detachable menus & toolbars) because new users accidentally messed up their shortcuts and didn't realise how they'd done it. These days it's obviously too well hidden a feature.

Try: gconftool-2 --set /desktop/gnome/interface/can_change_accels --type bool True

The Grumpy Editor's guide to graphical mail clients

Posted Jul 1, 2004 16:35 UTC (Thu) by wcooley (guest, #1233) [Link]

Unfortunately, Evolution doesn't use GTK+ directly for the toolbars; it uses Bonobo, which doesn't work the same way. You have to edit XML files in /usr/share to change the keybindings, but I'm not sure if it actually works, because I tried and failed.

The Grumpy Editor's guide to graphical mail clients

Posted Jul 1, 2004 18:16 UTC (Thu) by dbreakey (guest, #1381) [Link]

GNOME 2.4 and 2.6 are still capable of allowing keyboard shortcuts to be assigned arbitrarily, but it seems to have been globally turned off by default; you can either edit the appropriate GConf key (as indicated in the previous post), or download one of the 'advanced' configuration utilities, such as COnfigurator for Gnome. Incidentally, while the reconfigurability of shortcuts is a standard feature, it is apparently up to individual applications whether to permit it or not; I think that failing to allow it is a violation of the HIG guidelines, but I'm not sure. Then again, a quick review doesn't show anything.

Evolution, on the other hand, was not originally a GNOME application (strange, but apparently true, despite the fact that it used/uses extensive parts of GNOME; of course, I'm pulling this from a memory of a very old post, so I could be wrong). Now that it is being proposed as a standard component, for inclusion in 2.8, this lack of shortcut configurability may change. Or it may not, as I've also heard that the developers refuse to enable it due to the dynamic nature of the interface.

Personally, I hope they figure out how to solve any problems and enable this feature, as there are several shortcuts I'd love to change and/or add…

A plug for kmail....

Posted Jun 29, 2004 23:20 UTC (Tue) by yokem_55 (subscriber, #10498) [Link]

KMAIL has excellent support for piping messages through an external program. In kmail 1.6 in the mail filter setup options, you can choose as an "filter action" to pipe the message through an external program. Personally I use this to pipe all my messagages through bogofilter to do spam handling. This type of thing will be much easier to setup in kmail to be released with kde 3.3. In addition, the upcoming kmail will have support for writing html messages.

The Grumpy Editor's guide to graphical mail clients

Posted Jun 30, 2004 0:15 UTC (Wed) by NCunningham (guest, #6457) [Link] (2 responses)

I recently went on a similar search. I started with Evolution, but wasn't happy with it's interaction with my new Zire, or with having to delete LKML messages once I got more than 10,000 in a folder.

I tried Opera for a while, then Kmail, then Thunderbird. In the end, I returned to Evolution. I thought, too, that Thunderbird looks really promising, but the line wrapping and the PIM support got me in the end.

Transfering email between programs was generally not too hard, but transferring an address book was certainly non trivial. Perhaps a local LDAP server would help there, but it doesn't seem to be trivial to set up either.

Message count in evolution

Posted Jul 1, 2004 15:39 UTC (Thu) by hazelsct (guest, #3659) [Link]

When does Evolution force you to delete messages over 10K in a folder? I have tens of thousands in several of my folders with no problem at all (except slow loading over NFS on 10 Mb/s ethernet :-).

Local LDAP

Posted Jul 9, 2004 10:03 UTC (Fri) by ringerc (subscriber, #3071) [Link]

A local LDAP server isn't too hard to set up, really. The problem is that
most clients utterly lack support for writing to it. Evolution can do it,
but it wants to use a custom LDAP schema that reduces the utility of that
ability somewhat. Mozilla AFAIK still can't write to LDAP (but can export
LDIF, so you can do things that way).

I use an LDAP address book with Evolution and I find it works fairly well.
I'm using OpenLDAP for the server, with the Evo schema installed.

Evolution and avoiding word wrapping of inline patches

Posted Jun 30, 2004 2:21 UTC (Wed) by gdt (subscriber, #6284) [Link]

Balsa wraps everything, as does Evolution.

Not so. To send a non-wordwrapped patch in a word-wrapped e-mail using Evolution:

Type your e-mail. Use "Insert | Text file" or cut-and-paste to include your patch (it will word-wrap). Mark the patch. Select "Format | Heading | Preformat" (shortcut Ctrl-7). Selected patch unwraps. Press "Send" to submit patch to lkml without fear.

"Help | About" says version 1.4.6. I use Fedora Core 2.

kmail

Posted Jun 30, 2004 3:06 UTC (Wed) by captrb (guest, #2291) [Link] (12 responses)

While I use pine for private email, I have used kmail at work for nearly
5 years. I understand and acknowledge the Grumpy Editor's complaints,
but I also have a lengthy list of reasons why I love using Kmail for
email as much as I love using Emacs for programming and vim for
low-bandwidth administrative editing. I'll share my reasons, in case
they might help a new kmail user make better use of it's features. I'm
not sure if all these features are turned on by default.

1. As mentioned, the shortcuts are reasonably powerful. I rarely use the
mouse, except in the few dialogs that I encounter during normal use. I
do use the mouse wheel for scrolling, but that takes little complex
navigation (no aiming for buttons or click and move). There is a
shortcut for nearly every action.

2. Threading: Where my coworkers spend their time writhing through their
inboxes to connect replies that make up a long discussion, kmail presents
a perfect tree of email in newsgroup style. While this saves me a great
deal of time, it can also be a inconvenient when someone responds to a
very old message, as there is no quick way to say "show me the new
messages, regardless of the parent message's date".

3. Great searching: the search dialog, while a little clumsy looking,
enables fairly complex searches. Also, your last search is automatically
saved, in the event you need to revisit what you found after the search
dialog was closed. The search results may also be saved under a new
name, so that the next search doesn't overwrite the results. Someday
there may be the ability to update the saved search results dynamically
as new email arrives, forming a long-term catalog of related email for
quick reference.

4. Attachment warnings: When my message contains terms that insinuate
I've attached a file, but I haven't actually attached any, kmail warns
me. This saves me from having to respond to my own emails, "Sorry,
forgot the attachment!", and looking like an ass.

5. Kontact: I've grown used to Kontact, an Outlook look-alike that wraps
up kmail with the other kdepim apps. Having a todo list, calender, and
contact list all in the same windows saves me screen real estate.
Frankly, I've never used the other applications until they were made
easily accessible.

6. The address autocomplete does a great job of remembering the most
commonly seen email addresses and presents them in a very inconspicuous
way. I go weeks without referencing my address book or completely typing
an email address. Usually the first couple letters of the email or name
is enough to give me the address. This saves me time and better yet,
prevents me from mistyping the address.

Along with the "Hot", there is also the "Not" (or maybe the "Should Be")

* something occasionally slows down the compose window to a frustrating
pace as new characters are entered. I think that it is the spell
checking.

* The antique reply problem, mentioned previously.

* text wrap, especially with urls in the read window. Any yahoo news url
requires cut-n-paste. Yikes. This may be due to the senders email
client, but it would be nice if kmail would detect this and patch up the
URL for a quick click.

kmail

Posted Jun 30, 2004 3:34 UTC (Wed) by stephenjudd (guest, #3227) [Link] (3 responses)

You say you can't reconcile threading with the ability to display the newest messages at the top.

In Evolution, I can have a threaded view of my inbox, and a Vfolder (ie a view) of the same mailbox, which just displays unread messages sorted by their "received" date.

kmail

Posted Jun 30, 2004 8:27 UTC (Wed) by ekj (guest, #1524) [Link]

That's nice. Luckily kmail can do the very same thing. Only it doesn't call the things "vfolders" but instead searches.

When you perform any search, you can give that search a name, and it'll work just like a vfolder. Making a search that, for example, shows all messages with status "New" in ascending order by arrival is trivial.

The feature is underadvertised though.

kmail

Posted Jun 30, 2004 18:37 UTC (Wed) by captrb (guest, #2291) [Link] (1 responses)

That sounds like a great feature. If Kmail gains the ability to
automatically update the saved searches, it will have a similar feature.

I've tried Evolution a few times over the years, to see if it offered
features that were compelling enough for me to switch. Frankly, the
unreliability of the application was too great to consider using it. It
has been awhile since I tried, back when I loaded Redhat 9 for kicks and
giggles, so maybe it is worth another look in the next few months.

kmail

Posted Jul 9, 2004 20:43 UTC (Fri) by brockers (guest, #20000) [Link]

It does automatically update the searches. Saved searches are exactly the same thing as vFolders.

Bobby

kmail

Posted Jun 30, 2004 10:14 UTC (Wed) by petebull (subscriber, #7857) [Link] (3 responses)

> 2. Threading:

Do you search "Settings-> Configure KMail... -> Appearance -> Headers"

(...)
__Message Header Threading Options_______
( )
( )
( )
(x) Open threads that contain new, unread....
_____________________________________________
(...)

Peter

kmail

Posted Jun 30, 2004 18:28 UTC (Wed) by captrb (guest, #2291) [Link] (2 responses)

Yes, I use that option. It is still difficult to find the open thread
when the folder has more than 10,000 messages.

I would prefer the ability to have the window scroll the first unread
message (or a message with a particular status).

kmail

Posted Jul 9, 2004 8:27 UTC (Fri) by spooky_d (guest, #22920) [Link]

This can be done by setting the option "Loop in the current folder when
trying to find unread messages". I read my mails using the DEL and SPACE
key (that makes a page down, then if it's the last message the seeks the
next unread message).

kmail

Posted Jul 10, 2004 22:33 UTC (Sat) by chbm (guest, #12065) [Link]

> I would prefer the ability to have the window scroll the first unread
> message (or a message with a particular status).

Like Balsa does ;) it also has a 'go to next unread'.

kmail

Posted Jun 30, 2004 14:11 UTC (Wed) by nick.leroy (guest, #109) [Link] (3 responses)

> 2. Threading: Where my coworkers spend their time writhing through their
> inboxes to connect replies that make up a long discussion, kmail
> presents a perfect tree of email in newsgroup style. While this saves me
> a great deal of time, it can also be a inconvenient when someone
> responds to a very old message, as there is no quick way to say "show me
> the new messages, regardless of the parent message's date".

I also use kmail, but I have a keyboard shortcut (in my case "ctrl-t") to
turn on threaded / non-threaded views. Thus, when I see that there are
"old" messages that haven't flowed to the bottom, I hit c-t, select the
message, then c-t again to see it in it's threaded context. Works great
for me.

-Nick

kmail

Posted Jun 30, 2004 18:32 UTC (Wed) by captrb (guest, #2291) [Link] (2 responses)

That is a good technique, I didn't know that action was shortcut-able. I
will configure it now.

I don't see a way to sort by status, however. Emails, usually spam, that
arrival with odd dates (between the earliest and latest in the folder)
will still be difficult to find.

Finding unread mail in kmail

Posted Jul 1, 2004 13:40 UTC (Thu) by abredon (guest, #2038) [Link] (1 responses)

To find buried unread messages, I use the + and - keys (navigate to next/previous unread message). I use these keys a lot whenever I need to check a lot of messages at once.

Finding unread mail in kmail

Posted Jul 1, 2004 19:16 UTC (Thu) by captrb (guest, #2291) [Link]

That is exactly what I need. I'm even embarrassed I never saw it before.

I guess when I get used to an application over several years of use, I
don't spend enough time digging around in new versions for new features.

Much appreciated.

The Grumpy Editor's guide to graphical mail clients

Posted Jun 30, 2004 8:21 UTC (Wed) by hp (guest, #5220) [Link]

> Support for common tasks, such as sending patches.

Here is the difference between desktop users and the grumpy editor, I guess ;-)

Mozilla Mail and Patches

Posted Jun 30, 2004 9:56 UTC (Wed) by rmathew (subscriber, #20961) [Link]

If you wish to use Mozilla Mail for sending patches, you might want to consider disabling "format=flowed":

http://gcc.gnu.org/ml/java-patches/2003-q2/msg00315.html

I really wish that the Grumpy Editor had considered Mozilla Mail instead of Thunderbird, even though the latter is supposedly "the future" of the former. Mozilla Mail is far more polished and useful and mostly does the right thing (except for the "format=flowed" idiocy).

Sylpheed

Posted Jun 30, 2004 20:19 UTC (Wed) by xyzzy (guest, #1984) [Link]

If you want nice antialiased fonts, there's a GTK2 version of Sylpheed available these days which seems to work quite well.

The Grumpy Editor's guide to graphical mail clients

Posted Jul 1, 2004 11:51 UTC (Thu) by Klavs (guest, #10563) [Link] (3 responses)

Another feature I greatly miss - is inline PGP-signing.
If you attach the PGP-signing - as is the only evolution 1.2 supports (don't know about newer versions) - it means your mail gets split up into two attachments on Outlook and Notes email clients :(

what programs support this feature - Kmail? Thunderbird?
Perhaps a compiled list of "wanted features" - where the editor could check them on/off - would be a great ressource of info for anyone seeking an email client.
The feature name - would be a link to page explaining it in greater detail - and how to apply it in different mail-clients that support it.

It would be very nice for me :)

Desired Features

Posted Jul 1, 2004 17:08 UTC (Thu) by wcooley (guest, #1233) [Link] (1 responses)

To add to the list:
1. More support for writable LDAP addressbooks. Evolution is the only client I know of that supports it, although setting it up was a little odd, even for someone experienced with LDAP. It's also missing features that would make it a useful business-feature. (See http://nakedape.cc/wiki/WritableLdapAddressBookIdeas for my thoughts.)
2. Support for client SSL/TLS certificates. I know Evo 1.4.6 doesn't have this and suspect Thunderbird does.
3. Ability to manage Sieve scripts. Sieve is a server-side mail filtering language currently in the early RFC stages; implemented only in Cyrus IMAP AFAIK. Sieve scripts are uploaded through a TFTP-like interface. Some webmail clients have plug-ins for managing the filters, but I know of no GUI client that does.
4. Ability to include multiple messages in a reply. It makes the logic for threading ambiguous, but can be very useful at times. I'm sure some mailers support it, but I know Evo doesn't.

Oh, did this just turn into my Evolution wish list? Sorry...

Sieve

Posted Jul 9, 2004 10:07 UTC (Fri) by ringerc (subscriber, #3071) [Link]

Mulberry has a Sieve management interface. It's frequently recommended on
the Cyrus list for that reason. It seems like a nice client in some ways,
but ... it's not for me.

The Grumpy Editor's guide to graphical mail clients

Posted Jul 9, 2004 11:39 UTC (Fri) by mahoutsukai (guest, #22926) [Link]

KMail supports inline PGP-signing.

JavaScript on by default?

Posted Jul 1, 2004 17:13 UTC (Thu) by bjn (guest, #2179) [Link]

"The client will, by default, execute Javascript contained within HTML mail; your editor is hard put
to come up with a reason why one would ever want to leave that option enabled."

I have been testing Thunderbird 0.7.1 for use here. On my Mac OS X iBook I looked in
Preferences... Advanced for a new user, and the "Enable JavaScript in mail messages" box is
unchecked. What platform were you testing on? Are you positive it's on by default?

Why I use Evolution

Posted Jul 2, 2004 1:26 UTC (Fri) by X-Nc (guest, #1661) [Link]

While I am not married to any one particular tool/app/utility for anything I do I have settled on Evolution for email because it's got the best spell checker I've ever seen. My spelling of the English language could be called creative at best. The spell checker that Evolution uses is better than anything that any word processor or even command line tools have. I personally wish there was an easy way to integrate this spell checker into everything I use. Right now I am typing this in a Compose window from Evolution and, once all spelling errors have been fixed, will paste it into the web form for the reply.

There are a number of things that I don't like about Evolution but the spell checking alone keeps me using it. If there was a way to get pine to use the spell checker in Evolution I'd be in heaven.

Some comments on Thunderbird

Posted Jul 2, 2004 18:24 UTC (Fri) by ranger (guest, #6415) [Link]

Thunderbird has some strange behavioral glitches. Clicking on a URL in a message, for example, causes Thunderbird to copy the web page to a local file and run a browser on that file;

I think this depends on which browser it is set up to use. With mozilla-firefox installed (and no mozilla), clicking on a url opens that url in a background tab in the "current" firefox window. With mozilla installed, it opens in a new window or new non-background tab (can't remember, but I couldn't get it to work the way I want - ie as with firefox).

Thunderbird is also reluctant to use folders on the remote IMAP server that it didn't create itself; folders created by a different mail client tend to be completely inaccessible.

No, Thunderbird is doing the right thing in not automatically subscribing you to folders you may not want to see. Please use File->Subscribe.

The toolbar icon toggles between "Junk" and "Not junk," depending on the current marking of the message; the user thus has to actually look at it to see what it will do at any given time.

No, you can add the Junk status column to the folder window, and then just toggle it for a mail without reading it.

Anyway, Mozilla-based mail clients have always worked best for me, just because of the quality of the IMAP support, and that has improved even more recently with support for the IDLE command. Offline folders are also working quite well for me (on folders with 30000+ mails), and (with enigmail installed, as provided in the Mandrake packages) it does all I want ..

Message Actions

Posted Jul 5, 2004 19:21 UTC (Mon) by mmutz (guest, #5642) [Link] (1 responses)

The Grumpy Editor wrote about Sylpheed:
> This client, however, has some capabilities that the others lack.
> At the top of the list of those capabilities might be "actions."
[...]
> thereafter they show up under the "Tools/Actions" menu. It would
> be nice if an action could be bound to a keystroke, but...

You might be interested to learn that KMail has this. They are not yet
ad-hoc, meaning that you can say "pipe this message through..." and get a
dialog where you can enter a command, but you can create a set of filter
actions (by checking "Add this filer to the \"Apply Filter\" menu") that
can be placed in the Message->Apply Filter (singular) submenu. They can be
assigned shortcuts in the normal shortcut dialog and assigned icons in the
filter dialog. Once assigned an icon, you can add the action to the
toolbar, too. This is basically what the new antispam wizard does for you
in the upcoming KMail 1.7 to hook up SA or bogofilter into KMail.

But the feature is there in KMail 1.6 already.

Message Actions

Posted Jul 9, 2004 21:16 UTC (Fri) by brockers (guest, #20000) [Link]

All of the Major complaints from TGE are either already addressed in Kmail (I am surprised he missed the per message filtering option) or are already addressed in the development version of Kmail. Also GPG handling was never something I paid much attention to until I started using it. Now I love it! Kmails support for GPG is spectacular.

Bobby

correction to Aethera comment

Posted Jul 8, 2004 9:22 UTC (Thu) by aethera (guest, #22887) [Link]

Hi,
Aethera sources are available at
http://www.smga3000.com/thekompany/Aethera/aethera-1.1.0-040630.src.rpm
Aethera is an open source project, it has GPL license ... it must have
the sources available :)
The latest release (1.1.0) has come one week ago.
Aethera (PIM application) is not the best email client but it's the only
one from the list which is available for Linux, Windows and Mac OSX and
it includes some powerfull features like groupware support via Kolab
server.
Thanks,
Eug

Piping Evolution e-Mail through a command

Posted Jul 8, 2004 9:46 UTC (Thu) by karora (guest, #17553) [Link]

This is possible (along with a wide variety of other things) in the "Filters". Another nice point in Evolution is that you can filter outgoing e-mail as well as incoming.

Unfortunately I can't see any easy way to assign such an action to a toolbar icon, or a keyboard shortcut. This would definitely be nice, and some form of extensibility / scriptability for Evolution would allow the user community more scope for extending it too.

I tried to drop a mail message on "Tasks" today, with a disappointing lack of results :-(

The Grumpy Editor's guide to graphical mail clients

Posted Jul 8, 2004 11:25 UTC (Thu) by fredds72 (guest, #22890) [Link] (1 responses)

With reference to your search for a mail client, most people seem to dismiss Opera, but I have used it successfully for about five years. Last week I got onto this site,
http://tntluoma.com/opera/lover/7/ , which was written by a guy who has delved into Opera quite deeply. You may be interested in "week three, using M2", which outlines the way Opera mail works, and the very different way it sorts mail.
He has a bit of a rant about microsoft but that can be ignored.

Hope this helps

Pete

The Grumpy Editor's guide to graphical mail clients

Posted Jul 10, 2004 3:15 UTC (Sat) by kundor (guest, #14621) [Link]

Opera is not open source. It's not up for consideration.

Nice feature

Posted Jul 8, 2004 22:33 UTC (Thu) by yem (guest, #1138) [Link] (1 responses)

Is that a tabbed folder interface I see in the Balsa screenshot? That would be very nice to have (I use sylpheed-claws for the most part). Having quick access to a handful of the most oft used folders would be very welcome.

Nice feature

Posted Jul 12, 2004 21:54 UTC (Mon) by chbm (guest, #12065) [Link]

Yes, you can have tabs for each open mailbox in Balsa.

IMAP folders and Thunderbird

Posted Jul 9, 2004 9:49 UTC (Fri) by ringerc (subscriber, #3071) [Link]

The problem you describe with Thunderbird not displaying mail folders
created in other apps on an IMAP connection sounds familiar. I would
advise you to check (a) if the IMAP server has server-side subscription
management, (b) if other mail clients are subscribing you to folders when
they create them, and (c) if Thunderbird is set to "show only subscribed
folders".

Lots of mail clients totally ignore the IMAP subscription system and just
"LIST" instead of "LSUB". This is really annoying when you have a huge
mailbox heirachy and don't usually need most of it - especially when there
are lots of shared mailboxes on your server. Mozilla is not one of them,
but some of the other apps you mentioned may well do this. Because they
don't use the subscription list, they often fail to update it when they
create mailboxes, too.

I know that Thunderbird sees my subscribed mailboxes fine with my Cyrus
IMAPd 2.1.x server (Cyrus rocks to the point where I don't understand why
people run other mail servers). Cyrus has server-side subscription
management, and when I change a subscription in Mozilla then Evolution
picks up the change and vice versa.

KMail features the author missed

Posted Jul 9, 2004 12:03 UTC (Fri) by mahoutsukai (guest, #22926) [Link]

First of all, I wonder why the author did test development versions of
most other clients but not of KMail. Anyway.

The current stable version (1.6.x) already has
- custom message actions (shortcuts can be assigned and they can be put on
the toolbar). For details see the comment of mmutz.

The upcoming version brings
- a quick search bar in the main window
- an anti-spam wizard to help the user setting up KMail for use with an
external spam filtering tool; including internal spam filtering is
nonsense because that we mean re-inventing the wheel (and there are
already loads of suitable wheels (SpamAssassin, bogofilter, ...) out
there)
- basic HTML markup in the composer (font family, size, color, shape, text
alignment, lists), not supported are tables, embedded images or other more
advanced HTML features

About Balsa

Posted Jul 10, 2004 22:08 UTC (Sat) by chbm (guest, #12065) [Link] (1 responses)

Hi, I'm one of balsa's developers. I'll try to rebut some of your comments and hopefully revert some of your critics. We'd be happy to answer your questions and help you getting a newer balsa runing at balsa-list@gnome.org or balsa-maintainer@theochem.kth.se.

First, Balsa does support sendmail as well as SMTP but sendmail support isn't very visible. It's a compile time option as there didn't seem to be user need for both features at the same time. Also, you a trivial source change (the sendmail command string) you can get Balsa to use whatever program you like. This shouldn't be a show stoper for a mh veteran :)
Your Balsa build seems to be unthreaded judging from your comments about UI freeze. What system were you using and where did you get your binary ? non-thread builds are very rare and on the default builds with thread support the anoying problems you experience are not present.
Balsa uses gtkhtml for HTML rendering so its support is up to par with other Gnome apps. Also, Balsa does support changing the keybindings like in any other Gtk/Gnome application. Did you have problems with that ? Granted, non Gnome users might not know offhand how simple and powerfull it is.
Your comment about bouncing back and for to view mail parts was already addressed in 2.1/2.2. There's a new handier list now.
You also didn't touch Balsa's GPG support which is quite extensive.

Balsa 2.2 is to be released shortly. While it doesn't fully pass regression tests on 2.2.0 the new mail backend provides a much smoother UI experience and a smaller memory footprint.

Balsa, cause RFCs aren't just a waste of paper.

About Balsa

Posted Jul 10, 2004 22:30 UTC (Sat) by chbm (guest, #12065) [Link]

Replying to myself just add one more point, Balsa does not wrap everything. There is an option to make Balsa wrap text at n columns. You can also select wrap on the composer if you don't have it on by default. Balsa also supports format=flowed for soft wraping.

sorting to imap folders

Posted Jul 20, 2004 5:52 UTC (Tue) by jaclu (guest, #7280) [Link]

The one feature I really miss in almost all mailclients is the ability to sort mail into imap-folders - im so surprised noone has mentioned this.

Outlook, Evolution and KMail are verry able clients, but they have one (in my opinion) huge short-comming: They can only sort mail into local folders

The only clients I have found that are also reasonable in other aspects are the netscape family and its relatives NS,moz,thunderbird.

This have been true for the latest 10 years, Im so surprised that not one other client has implemented it. Every other year or so I try another client, but they all lack sorting to remote folders.

Of course there is this server side scripting system (sieve?) where you can upload rules to the imap-server, I've tried to use it a few times but never got it to run, and the ns/moz interface is so convinient that I see no reason to learn an arcane scripting language when it can be done interactively in moz.

For me this is essential, since I move around alot and read mail on litterally dozens of difrent workstations in all kinds of operating systems.

For this reason imap or webmail is required, and I really think the webmails Ive tried are inferior when it comes to useability, my current setup is squirrel pointing to my cyrrus-imap server, but I only use that if im really stuck on a public system

Thunderbird and vFolders

Posted Dec 20, 2005 4:16 UTC (Tue) by proski (guest, #104) [Link]

Belated commend for the sake of posterity :-)

Thunderbird actually has vFolders, which are called "Saved Search Folders". They can be created under the File menu. Unfortunately, they are very inflexible compared to Evolution, as of Thunderbird 1.5. There is no built-in mailing list support, custom searches don't work and it's impossible to search for messages that don't have a specific header.