Re: Recommended IMAP server

From: David Brown (david_at_westcontrol.removethisbit.com)
Date: 11/25/05 

Date: 25 Nov 2005 20:41:33 +0200

wkearney99 wrote:
>> Sounds good. I run exim (3) here, too. (I'm gradually migrating to
>> exim4.)
>
> As opposed to postfix?

Is there be any particular reason I should swap? I'll admit that my
initial choice of exim (which has been running now for some time) was
biased by it being a default in Debian, and capable of doing exactly
what I needed at the time (which was to drop any outgoing email that was
not either *to* or *from* a valid user, and thus an unwanted mail sent
by the over-enthusiastic windows pop3 server).

>
>> Would definitely recommend fetchmail if you have to collect email from a
>> POP3/IMAP mailbox. Direct SMTP is to be preferred though.
>
> +1 on fetchmail, it's very convenient for pulling mail from what might be
> more than one remote account all for local reading out of the imap store. I
> use it to pull a bunch of mail from several different accounts and then
> deliver it into local "Inbox-servicename" folders. That way I can still
> tell to which account it was delivered. True, I don't get "you've got new
> mail" on all the separate folders but I can live with that.
>

Yes, fetchmail is pretty much a given for getting email out of other
pop3 mailboxes and passing it on to the imap server. As far as I can
see, it should be reasonably straightforward to set up the required
command files and cron jobs.

>> Squirrelmail works nicely with dovecot, as do the mail clients you've
> named.
>

It looks like I should be talking a close look at dovecot. I've heard
of it being easy to configure and work with, although perhaps a bit
limited compared to Courier. Of course, that's not a problem as long as
it does what I need!

> Take a look at IlohaMail. I find it quite a bit faster than SquirrelMail.
> It's barebones 'just mail' but it works well. Their 0.9.0 development
> version is quite stable.

I'll add that to my list to look at. Speed is not a problem, since the
server is reasonably fast and there will be very low usage. Being easy
to use for the users is more important, and a Norwegian translation
would be nice.

>
>>> Integration with Spam Assassin (or another spam filter) is essential
>> Absolutely.
>
> +1 and then some.
>
>>> as is an easy way for users to interact with the spam filter.
>
> This complicates the setup somewhat but it is possible. There may be
> additional complications with providing per-user spam filter setups for the
> virtual users.
>

If it is complicated, then I'll drop that idea. I think in almost every
case, all the users will agree on what is spam - we have no one
interested in dodgy mortgage deals or bodily enhancements (at least not
during working hours :-). And I get more spam than anyone else (a price
I pay for usenet and mailing lists, I guess), so if I configure the
system to my own satisfaction, the rest should be happy enough.

>>> Integration with ClamAV is essential, as is being able to add my own
>>> filters (for example, I have a policy of stripping all exe files,
>>> including pif, scr, etc., from incoming emails).
>
> Those are generally good rules server-wide. If folks need executables I let
> the server pass zip archives and then scan those.
>

That's exactly what I do at the moment, except that the zip files are
not scanned because it would be difficult to set up on the old system
(should be easy enough with ClamAV). Stripping exe files and all other
dangerous attachments means that viruses can get through to users, but
only in a form that needs several active clicks to activate. I'm
careful about making sure everyone is aware of the rules and precautions
needed (helped by the fact that most virus emails are in English, while
most of our real emails are in Norwegian), and I enforce the rules with
threats with a pair of wire cutters (for the network cable, you
understand). With the new setup, I hope to use scanning and exe stripping.

>>> I also need to be able to sanitise html emails to remove javascript, and
>>> that sort of thing. I realise that's not part of the IMAP server as
>>> such, but I need the server to be able to integrate easily this sort of
>>> filter.
>> No idea.
>
> Trying to strip the HTML mail is quite a bit of a mess. I've found it was
> simpler to switch to a mail client that automatically defaulted to NOT
> showing the message as HTML. Most do this in their latest versions. HTML
> is such a rats nest, along with MIME, that it's truly a difficult to make a
> filter than handles all cases properly.
>

I have certainly read about filters for stripping dangerous html, such
as javascript, from emails, while leaving most of the html intact. I'd
rather not have to fight with the users about their email clients, even
though I will be pushing for thunderbird when we change over. It was
hard enough getting people to stop using internet explorer, and users
tend to be much more attached to email clients. One of the big
advantages of IMAP, however, is that they can try different clients
without losing anything.

>> I tried cyrus, but couldn't even get it to work properly. (Why /should/
>> I have to understand the guts of SASL?)
>
> No ***, it's a unbelievably annoying how poorly documented it is in places.
> Most of the online HOWTO documents are woefully out of date. The syntax
> they suggest just doesn't work on the most recent versions. I've gotten it
> working here but it's taken an inordinately large amount of work.
>

Cyrus appears to me to be a solution designed for very large user bases
(thousands or more), powerful but hard to configure (as is often the
case with powerful and flexible systems). I'm kind of hoping that
Courier or Dovecot will suit the bill.

>> Both it and Courier seem to
>> provide a complete IMAP solution, which is a pain if it doesn't seem to
>> do exactly what you want. On the other hand, it's a right pain running
>> sieve or even exim filters with dovecot - I gave up on that idea.
>
> I wanted server-side filtering with virtual users and that pretty much
> spells out sieve using cyrus-imapd.
>
> -Bill Kearney
>

Many thanks for your (and other posters') time.

David