Forum OpenACS Q&A: OT: imap server recommendation

Pop3 sucks.  If you want to access your home email from work or vice
versa, your correspondence becomes painfully splintered since once a
message is "popped" it's no longer on the server.  There are ugly
workarounds to this -- you can have the server save messages for,
say, 10 days, so you can download it to your "cannonical" client, but
then you have to delete unwanted messages multiple times.  Switching
mail programs requires nasty hacks to convert mail formats.  Etc.

Back in the old days, you could access your mail from anywhere by
telnetting into your account and running your favorite mail program.
(Mutt zealots, please stop reading now.)  You can still do that, of
course, but modern GUI mail systems are so much more pleasant to use
it's like going back to cooking without a microwave or something.

Hotmail's OE integration (pretty much a proprietary imap protocol)
allows you access to your mail from any number of clients, anywhere,
but spam is constant and 2 MB of mail is pretty skimpy.  (I have a
six-year-old hotmail account and I get way, way more spam mail than
valid mail, despite having "spam filtering" on the highest setting.)

IMAP to the rescue.  You have an open protocol, so you can run your
own server (and integrate intelligent spam filtering, via tmda for
instance), and it's not brain-damaged like POP.

I tried three imap daemons:

* dkimap (some german guy's homegrown imap server)
* courier imapd
* uwimap (pretty much ye olde reference implementation of imap as I
understand it)

dkimap was a breeze to install but has serious scalability issues.
Past a couple hundred messages in a folder and it really bogs down.
Also there are minor bugs here and there -- resetting a message's
recieved date when moved to another folder, for instance.

I spent an hour on courier imapd and still couldn't configure it
correctly.  Its installation instructions are neither concise nor
comprehensive, and its Makefile conventions are horribly
nonstandard.  Courier bills itself as more efficient than the uw
daemon so if you have thousands of users or you are much smarter/more
patient than I am you could give this a try but I wouldn't recommend
it.

uwimap had even less steps to install than dkimap and I have had no
problems with it so far.  Nothing to say except I like it.

The only other popular imap server that I am aware of is the Cyrus
one, but this is a "Mail Borg" program in the startrek sense of the
word -- it wants to be sendmail, procmail, AND your imapd.  Then
there's the separate authentication module you have to set up.  Word
on the imap newsgroup is installing this beast is NOT for the faint
of heart.  No, thanks -- I just wanted to install an imap server and
leave the rest of my (working very nicely) system well enough alone.

I was leery of uwimap at first because there was nothing on the
website indicating what the "binary package" consisted of, or what to
do with it.  (Probably it is a single executable and all you have to
do put it in /usr/local/bin and tell [x]inetd to invoke it for imap
connections.)  As I mentioned, though, I had no trouble compiling
from scratch.  Highly recommended.

(uwimap is available at http://www.washington.edu/imap/)

We run UW imapd for most users (3500 users per dual PIII server, average 20MB disk per user) and Courier for light virtual hosting.    The deep Courier integration can be useful (all we have to do to create a user is insert one row into a MySQL table) and it does perform well, but the IMAP implementation is very dodgy. Sorting is completely bogus. The author has some very odd ideas about standards compliance. I can't recommend it unless you intend for it to be a mostly webmail box and the webmail is to be Courier's own.    As you said, Cyrus wants to own the server. It's a very well engineered multithreaded app, probably the only game in town if you want to support much more than 10,000 simultaneous users per server, but there's additional (or at least different) management overhead. Also its security model pretty much assumes you're running Kerberos.    I like UW imapd. It's not the sexiest, it's not the fastest, but it works and it's standards-compliant. Its workings are a lot more transparent than Cyrus or Courier so it's easier to back up/restore and easier to fix if it breaks.    You *do* want to modify UW imapd to use mbx-format mailboxes. The default is to use berkeley-format mboxes for backwards compatibility, but UW itself and any serious site with more than a few thousand users changes CREATEPROTO=mbx. mbx performs much better, expecially on mailboxes with > 1000 messages, and allows concurrent read/write access. See http://carumba.com/imap/ and doc/formats.txt from the cource distribution, also posted at http://my.brandeis.edu/bboard/q-and-a-fetch-msg?msg_id=00008N

Let me know what your experience is with TMDA. I've been on
their mailing list for a while, and it seems like a good product,
but perhaps one that will take a lot of tuning before it will work for
a small company. For a personal mail server, it seems ideal,
however. If you don't mind, could you let us know how it goes.

For those of you who don't know what TMDA is, it is a spam-
prevention system that uses whitelists instead of blacklists. This
means if someone you don't know writes you, they get an email
they have to reply to before their original message will get sent to
you. This can almost completely cut out all of your spam. Or at
least that's the idea..

I agree that Courier-IMAP's documentation is lacking, but it does support Maildir and SSL -- do the others?

It took some time, but I got Courier-IMAP-SSL installed and running, and I'm using omail (omail.omnis.ch) for webmail -- it supports Maildir, and it reads e-mail directly off the HDD, not over IMAP.

While my IMAP server isn't under a heavy load (it's just me and my family/friends), Courier has been solid, requiring no intervention.

I don't know if it's php or the horde codebase, but IMP is dog slow.

My experience with IMP was that it fired off probably 5 or 6 connections to the UW imapd when you login.  Imapd is not exactly a lightweight process so it can make your server load go pretty high.  And connections are not persistent, so *every time* you click a link in IMP it fires off and tears down an imapd process...