Recommended IMAP server

I'm planning on setting up an IMAP server on a Debian system in the near
future. We're a small company, with two domains and about 25-30 users.
We currently have a POP3 server running on an old windows server, but
we are outgrowing it and need a bit more functionality.

I'm looking for some recommendations, or links to comparisons - I've
been doing some searching and reading, but could do with a few hints
from experienced users.

We currently have exim4 on the Debian, which passes on emails sent by
the pop3 server (it has a bug causing it to send out duplicates of
certain incoming emails - the exim4 server filters them out). exim is
okay, but I don't have to keep it if the new IMAP server works better
with another MTA.

At the moment, we get some incoming email through a DomainPOP box (i.e.,
an external pop3 mailbox collecting all mail for a domain) which is
split into individual pop3 boxes by the pop3 server. Support for this
arrangement is not critical, as we'll be changing to more standard smtp
before long, and in the mean time I can always use fetchmail to get mail
from the old pop3 server. We get other incoming email from an external
pop3 server, which should all end up on the same IMAP server.

Clients run a variety of Thunderbird, Outlook, Outlook Express, and
probably others. Webmail of some sort would also be useful.

I'm happy enough reading technical manuals, hand-editing config files,
and compiling from source if need be (although I'm guessing ready-made
debs will be available).

Speed is not likely to be an issue, unless the server fails to scale
with large numbers of emails for a few of the users (I guess that means
I need a maildir solution rather than mbox).

The servers I'm looking most at are Courier and Dovecot, but there are
others such as Cyrus and Binc IMAP.

Virtual users support would be an advantage, but not a necessity.

Integration with Spam Assassin (or another spam filter) is essential, as
is an easy way for users to interact with the spam filter.

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).

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.


Many thanks for any ideas, comments or links.

David Brown
Norway.

David Brown <(E-Mail Removed)> wrote:
> I'm planning on setting up an IMAP server on a Debian system in the near
> future. We're a small company, with two domains and about 25-30 users.

Dovecot. Simple, fast, and reliable. The best thing (for me) about
Dovecot is that it leaves your mail files in a readable format, so if
all else fails you can still read/search your emails.


> We currently have exim4 on the Debian [...]

Sounds good. I run exim (3) here, too. (I'm gradually migrating to
exim4.)


> At the moment, we get some incoming email through a DomainPOP box (i.e.,
> an external pop3 mailbox collecting all mail for a domain) which is
> split into individual pop3 boxes by the pop3 server. Support for this
> arrangement is not critical, as we'll be changing to more standard smtp
> before long, and in the mean time I can always use fetchmail to get mail
> from the old pop3 server.

Would definitely recommend fetchmail if you have to collect email from a
POP3/IMAP mailbox. Direct SMTP is to be preferred though.


> Clients run a variety of Thunderbird, Outlook, Outlook Express, and
> probably others. Webmail of some sort would also be useful.

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


> Virtual users support would be an advantage, but not a necessity.

I believe dovecot does virtual users but I've never bothered with that
here as I have only a few users.


> Integration with Spam Assassin (or another spam filter) is essential

Absolutely.


> as is an easy way for users to interact with the spam filter.

Ah. I run spamassassin "inside" exim, so it runs with no knowledge of
users' individual preferences. However, it still seems pretty good: I'm
not aware of failed-but-valid emails and I for one get very few
passed-but-spam mails now.


> 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).

I also use ClamAV here, running "inside" exim.


> 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.


> Many thanks for any ideas, comments or links.

I tried cyrus, but couldn't even get it to work properly. (Why /should/
I have to understand the guts of SASL?) 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.

Chris

> Sounds good. I run exim (3) here, too. (I'm gradually migrating to
> exim4.)

As opposed to postfix?

> 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.

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

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.

> > 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.

> > 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.

> > 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 tried cyrus, but couldn't even get it to work properly. (Why /should/
> I have to understand the guts of SASL?)

No shit, 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.

> 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

In message <aroj53-(E-Mail Removed)>, chris-(E-Mail Removed)
wrote:
>
> I tried cyrus, but couldn't even get it to work properly. (Why /should/
> I have to understand the guts of SASL?) 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.
>
Cyrus is good but I'd hate to have to configure it from scratch again. I've
had to do a couple of re-installs but fortunately it's let me install the
latest version and then restore the old stuff from a backup over the top of
the directories that got installed. I vaguely remember trying one before
Cyrus that wouldn't allow me to have folders containing both folders and
messages (Cyrus does). That might have been the Courier version.
--
Dave
mail da (E-Mail Removed) (without the space)
http://www.llondel.org
So many gadgets, so little time

In the referenced article, "wkearney99" <(E-Mail Removed)> writes:

.....

>> > 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.

With exim4 you'd probably do this by delivering mail using a
transport filter that does the necessary message mangling. You'd
need an external program for this. I've heard good things about
altermime:

http://www.pldaniels.com/altermime/

but I've never tried it or tried to mangle messages this way.
--
Dennis Davis, BUCS, University of Bath, Bath, BA2 7AY, UK
(E-Mail Removed)

chris-(E-Mail Removed) wrote:
> David Brown <(E-Mail Removed)> wrote:
>> I'm planning on setting up an IMAP server on a Debian system in the near
>> future. We're a small company, with two domains and about 25-30 users.
>
> Dovecot. Simple, fast, and reliable. The best thing (for me) about
> Dovecot is that it leaves your mail files in a readable format, so if
> all else fails you can still read/search your emails.
>
>

That sounds good - readable format storage is a big plus. I've had to
try to help with crashed Outlook Express email folders - it's been
mostly a matter of providing a shoulder to cry on. Readable format
emails in a nice directory would also work well with my current backup
system (using rsync to copy all the data over ADSL to a backup system at
home).

Am I correct in thinking that Dovecot and Courier use the same maildir
format?

>> We currently have exim4 on the Debian [...]
>
> Sounds good. I run exim (3) here, too. (I'm gradually migrating to
> exim4.)
>
>
>> At the moment, we get some incoming email through a DomainPOP box (i.e.,
>> an external pop3 mailbox collecting all mail for a domain) which is
>> split into individual pop3 boxes by the pop3 server. Support for this
>> arrangement is not critical, as we'll be changing to more standard smtp
>> before long, and in the mean time I can always use fetchmail to get mail
>> from the old pop3 server.
>
> Would definitely recommend fetchmail if you have to collect email from a
> POP3/IMAP mailbox. Direct SMTP is to be preferred though.
>
>
>> Clients run a variety of Thunderbird, Outlook, Outlook Express, and
>> probably others. Webmail of some sort would also be useful.
>
> Squirrelmail works nicely with dovecot, as do the mail clients you've named.
>
>
>> Virtual users support would be an advantage, but not a necessity.
>
> I believe dovecot does virtual users but I've never bothered with that
> here as I have only a few users.
>

Virtual users as such is not a necessity (most of our email users are
already network file users of the same machine), but we do have users
who need to have two separate IMAP accounts with different email
addresses in different domains (we have two companies in the same
offices, and some people work for both of them).

>
>> Integration with Spam Assassin (or another spam filter) is essential
>
> Absolutely.
>
>
>> as is an easy way for users to interact with the spam filter.
>
> Ah. I run spamassassin "inside" exim, so it runs with no knowledge of
> users' individual preferences. However, it still seems pretty good: I'm
> not aware of failed-but-valid emails and I for one get very few
> passed-but-spam mails now.
>

It's sounding like a single spamassassin setup is the way to go. If
anyone wants more control, they can use thunderbird.

Many thanks for your comments.

David


>
>> 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).
>
> I also use ClamAV here, running "inside" exim.
>
>
>> 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.
>
>
>> Many thanks for any ideas, comments or links.
>
> I tried cyrus, but couldn't even get it to work properly. (Why /should/
> I have to understand the guts of SASL?) 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.
>
> Chris

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 shit, 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

In article <4387680f$(E-Mail Removed)>,
David Brown <(E-Mail Removed)> writes:
> chris-(E-Mail Removed) wrote:
>> David Brown <(E-Mail Removed)> wrote:
>>> I'm planning on setting up an IMAP server on a Debian system in the near
>>> future. We're a small company, with two domains and about 25-30 users.
>>
>> Dovecot. Simple, fast, and reliable. The best thing (for me) about
>> Dovecot is that it leaves your mail files in a readable format, so if
>> all else fails you can still read/search your emails.
>>
>>
>
> That sounds good - readable format storage is a big plus. I've had to
> try to help with crashed Outlook Express email folders - it's been
> mostly a matter of providing a shoulder to cry on. Readable format
> emails in a nice directory would also work well with my current backup
> system (using rsync to copy all the data over ADSL to a backup system at
> home).
>
> Am I correct in thinking that Dovecot and Courier use the same maildir
> format?
>
I have 3 running installations of Dovecot + Postfix, and have been happy
with them. Dovecot and Courier both use maildir. I've seen something
about "maildir+" but haven't bothered to look into it. I understand
that Dovecot can also do virtual users, but again have had no need.

On 2 of my installations I'm also using procmail (-z) in lmtp mode so
that Postfix can be fully chrooted. That's giving me problems on one
system, because it has odd interactions with afs that I've tried
unsuccessfully to work around.

One other thing about Dovecot - Gentoo doesn't have an SELinux policy
for it, though Fedora Core 3 does. I'm trying to get my services moved
to an SELinux machine, and coming up with a Dovecot policy is one work
item.

Dale
>>> We currently have exim4 on the Debian [...]
>>
>> Sounds good. I run exim (3) here, too. (I'm gradually migrating to
>> exim4.)
>>
>>
>>> At the moment, we get some incoming email through a DomainPOP box (i.e.,
>>> an external pop3 mailbox collecting all mail for a domain) which is
>>> split into individual pop3 boxes by the pop3 server. Support for this
>>> arrangement is not critical, as we'll be changing to more standard smtp
>>> before long, and in the mean time I can always use fetchmail to get mail
>>> from the old pop3 server.
>>
>> Would definitely recommend fetchmail if you have to collect email from a
>> POP3/IMAP mailbox. Direct SMTP is to be preferred though.
>>
>>
>>> Clients run a variety of Thunderbird, Outlook, Outlook Express, and
>>> probably others. Webmail of some sort would also be useful.
>>
>> Squirrelmail works nicely with dovecot, as do the mail clients you've named.
>>
>>
>>> Virtual users support would be an advantage, but not a necessity.
>>
>> I believe dovecot does virtual users but I've never bothered with that
>> here as I have only a few users.
>>
>
> Virtual users as such is not a necessity (most of our email users are
> already network file users of the same machine), but we do have users
> who need to have two separate IMAP accounts with different email
> addresses in different domains (we have two companies in the same
> offices, and some people work for both of them).
>
>>
>>> Integration with Spam Assassin (or another spam filter) is essential
>>
>> Absolutely.
>>
>>
>>> as is an easy way for users to interact with the spam filter.
>>
>> Ah. I run spamassassin "inside" exim, so it runs with no knowledge of
>> users' individual preferences. However, it still seems pretty good: I'm
>> not aware of failed-but-valid emails and I for one get very few
>> passed-but-spam mails now.
>>
>
> It's sounding like a single spamassassin setup is the way to go. If
> anyone wants more control, they can use thunderbird.
>
> Many thanks for your comments.
>
> David
>
>
>>
>>> 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).
>>
>> I also use ClamAV here, running "inside" exim.
>>
>>
>>> 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.
>>
>>
>>> Many thanks for any ideas, comments or links.
>>
>> I tried cyrus, but couldn't even get it to work properly. (Why /should/
>> I have to understand the guts of SASL?) 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.
>>
>> Chris

--

On 2005-11-25 08:33:48 -0800, "wkearney99" <(E-Mail Removed)> said:

>> I tried cyrus, but couldn't even get it to work properly. (Why /should/
>> I have to understand the guts of SASL?)
>
> No shit, 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.

Reading this makes me wonder what I'm missing. I mean setting up Cyrus
for me has never involved actually knowing how sasl works other than
where it gets it's passwords from (/etc/passwd via saslauthd or
/usr/local/etc/sasldb2). When you refer to "syntax" in what context do
you mean?

On 2005-11-25 10:37:51 -0800, David Brown
<(E-Mail Removed)> said:

> It's sounding like a single spamassassin setup is the way to go. If
> anyone wants more control, they can use thunderbird.

You might consider using dspam instead of spamassassin. I find that
while it requires significantly more training initially, the load it
puts on the server is much lower (at least with the corporate email
gateways I administer).