Search Site:








Edit - To Do - AllRecentChanges

Recent Changes Printable View Page History Edit Page

This page is part of the EmailServer article.

Setting Up a high performance IMAP server

The aim of this article is to describe how to configure a reliable and high performance email server for up to 200 employees.

The constraint here is not to send/receive millions of messages a day but to allow users to keep their emails on the server and use IMAP to retrieve them from wherever they are, and for however long they want to keep them.

This type of server is particularly suited for companies whose employees deal with a lot of emails, such as an Engineering, Project Management or a Law firm.


The basic objective of this project is to enable authorised users to securely send, retrieve and manage lots of emails from anywhere.

Security is enforced from different angles:

  • Authorized use of email for sending, relaying or retrieving is only allowed for users who have an account on that system: for each operation, authentication is required.
  • Encrypted communications: whether sending, receiving or managing emails through IMAP, communication between the client and the server are encrypted. This is especially important for roaming users who may use unsecured wireless access points for instance.
  • Anti-spam protection to limit the risk of being exposed to phishing scams and to identify good mail from bad.
  • Executable attachment protection to ensure users will not receive potentially dangerous attachments in their emails (most executable attachments are forbidden, if you need to send an executable, zip it first). This attachment protection can be extended to control the type of documents sent through emails, for instance, you could ban avi or jpg files based on their extension.
  • Anti-virus protection to remove email containing viruses as they arrive at the server. Note that it is recommended to keep an additional level of protection in the form of an up-to-date antivirus programme on each client machine.

Additionally, the technical objectives are:

  • enabling users to send any email through the server (with a size limit if you want),
  • enabling roaming users to send email through the server securely from the Internet (using encryption),
  • enabling users to check their email through a secured web interface, wherever they are (using HTTPS),
  • allowing up to hundred of thousands of email messages to be stored in an IMAP folder without noticeable slow down when operating on messages (deleting, reading, getting headers)
  • easily add or remove users from the system while not allowing them to access the server from a terminal.
  • keeping the system, virus database and spam detection up-to-date


For this project, I chose the following implementation:

  • postfix will be the Mail Transport Agent, receiving and sending emails and dropping them in each user mail boxes. saslauthd will enable email to be relayed through the server only for users who have an account on the machine.
  • dovecot will be our POP3/IMAP server, giving users access to their emails.
  • squirrelmail will be our web interface. it uses IMAP to access the local mail boxes.
  • amavisd (Amavisd-New) will be our filtering system, marshalling emails beetween postfix and spamassassin -our spam detector- and clamd, the ClamAV antivirus daemon.


In this document, the FQDN? (Fully Qualified Domain Name) of the server is also its hostname and its domain name is thus

I assume that you have setup a MX DNS record for and that mail sent to will be attempted to be delivered to the server we're setting up.

This setup is meant for a company wanting to host its own email server, so the focus is on single domain only. If you want to manage multiple domains, you will have to adapt this setup.

Note: if you need to setup your domain name and take control of your email, I suggest that you take an account with ZoneEdit: the first 5 zones are free, and extra services are quite cheap. You have total control over you domains, subdomains, and can of course create Mail eXchange records. They also have a service to buffer your email should your server be off-line. when things return to normal, any email they kept will be delivered as usual.

In the whole installation and configuration process, I assume that you are logged in under the root account.


The initial installation process is not critical here. Simply avoid installing too much stuff that you don't need (like X, Gnome or KDE and anything graphical) and limit the number of services that run on the server. It's easy enough to add missing packages afterwards.

Buy your hard-drives in double or triple and mount your partitions as RAID1 or RAID5 arrays: this is quite critical as it means that you won't lose everything if one of the drives fails. I won't discuss backup solutions for this system, but you should have one. In the future, I plan to describe a mail to database solution that could be used as a specific mail backup/archiving/retrieval system.

When deciding your disk partitions, allow a rather large one that you will mount as /mail and format as ext3.
Make it as large as you can. You could also build an LVM on top of that partition if you believe that you could run out of disk space. With LVM, you can easily increase or decrease your available space by simply adding new partitions to the Volume.

During the installation process, make sure that you choose Postfix in the available packages. Fedora defaults to using sendmail, so we'll have to fix that later.

After you've rebooted, use yum to update your system.

Check partition indexes

By default, Fedora Core and RedHat/CentOS systems use indexes when creating ext3 partitions, this is good and is required for the partition where the emails will be saved.

Why are indexes so important you ask?
Well, since we're going to use maildirs, each email will be saved as a file. Without indexes, it will take an increasing amount of time for the kernel to locate a file in a busy mailbox. The kernel limit that issue by building fast indexes so it can easily find the file it needs.

It doesn't hurt to double check that our partition supports indexes. Let's suppose that your /mail partition is /dev/hda3:

tune2fs -l /dev/hda3 | grep features

You should see a reference to dir_index.
If not, then you can modify your partition without losing data:

umount /dev/hda3
tune2fs -O dir_index /dev/hda3
e2fsk -fD /dev/hda3
mount /dev/hda3

If your system complains about not finding tune2fs, get it from yum install e2fsprogs.

This bit was taken from the Dovecot site.

EmailServer | Users >

Leave your comments below
Enter your comment (no links allowed): Author:

Edit Page - Page History - Printable View - Recent Changes - WikiHelp - Search - RSS -
Page last modified on Thursday 04 December 2008, at 03:46 GMT+8 - Viewed 1809 times