Ronge

Due to my dissatisfaction with existing mail clients, I’ve been slowly grinding out a simple IMAP client. There was no way I was going to write my own IMAP client, so I scoured the web and came across a few libraries. So I wanted something that was clean, fast and written in C, C++ or Objective-C and ideally thread safe.

C-Client
C-Client was written by the man at the University of Washington who invented IMAP4rev1, so you can be sure it implements the RFC fully. However, the code is downright atrocious, it’s a mess of spaghetti code and undecipherable documentation. There are two programs which are samples to help aide in understanding the library. One of the samples is an old mail program written for NeXt and the other is Pine. If you haven’t looked at the Pine code, I urge you not to, it burns the retinas. So despite C-Client implementing the spec perfectly and being a very fast library, I found myself unable to understand the wild style that the library was written in.

JavaMail
The JavaMail API’s look really clean, but I was leery of implementing a core part of my e-mail app on the Java-ObjC bridge. In a past project, LaserLine at UIUC MacWarriors, I was forced to use the Java-ObjC bridge and was not pleased. I found it a hassle to deal with and a slow alternative to native C code.

Camel
Camel is the mail library that rests under Evolution and it’s designed to access a number of different kinds of data stores. It’s written in plain C and relies on a number of data structures that reside in the underlying Gnome libraries. The libraries that it does rely on are non-graphical so getting them up and running wasn’t a big deal. The code base is massive, with support for an amazing array of data stores. Some people are very leery of the IMAP support inside the library, apparently it works but it’s not exactly thread safe. Camel really is a mountain of source, and the fact that they pretended C is object-oriented when writing the library doesn’t help things. What really made me drop the ball was this:

Even with all of it’s problems, this is the most stable and featureful remote backend in existence. It just isn’t very easy to maintain. I should really add more detail here, but I just don’t care - I barely understand the code either, and I rewrote it anyway. Maybe others can update it. Source

When the guy who created the monster says he doesn’t understand it, I’ll look elsewhere.

Pantomine
Pantomine was the only Cocoa/Objective-C IMAP library that I found, which is a huge plus for this library. But it’s slooooowww and no one has done any work on the project for a number of years. One of the objectives of my mail client is for it to be blazing fast, so Pantomine is a no.

LibEtPan
LibEtPan is the best IMAP library I have found. It’s fast, written in pure C and it doesn’t require really any dependencies. The function names are clear and the data structures are intelligible. There is documentation provided with the library but it’s lacking in a number of respects, but the code is so clean that many times you don’t even need the docs. The implementation is very robust with support for high level access, so that different mail drivers can sit underneath. For example you can use the high level function to talk to either IMAP or POP3 without having to change any code, you just change the driver. The available functions for the high level stuff is limited because it has to be the intersection of both IMAP, POP3 and the other protocols it implements. The lower level stuff is very clean as well, and implementation specific. For example, in my project I am using the lower level IMAP drivers because I don’t intend on supporting any other protocols and I get the niceties of IMAP. This library is in active development and the developer is very responsive to questions, if you’ve got a need for a mail library I highly suggest this one.