Managing IMAP

Mission Restriction

If you decide to bring up dedicated IMAP servers, there’s a short list of things you can do to help prepare your host and help focus its activities on the task at hand: IMAP. Primarily, these activities can be grouped together as limiting the number of server processes, eliminating or restricting non-administrative accounts, and reducing non-essential workload on the host.

Reducing Server Processes

Out of the box, your operating system probably supports a variety of services through the inetd superserver. None of those services is essential to the IMAP mission. In most cases, you can reduce your inetd services down to a single line in your configuration file that supports your particular IMAP service. If non-privileged users never log on to your mail host, you are somewhat freer to make assumptions about what kind of client software those users have. For example, assuming that:

• Interactive logins, if allowed, are done via Secure Shell (SSH), and SSH runs as a standalone daemon, and

• The MTA runs as standalone daemon, as does sendmail

then there’s little reason to have anything but a one-line inetd.conf file.

Once you’ve shaved down your inetd.conf file, send a HUP signal to it to refresh the active configuration. Then, use netstat to get a picture of what kinds of “listens” are still active on your machine. Here’s an example from a machine that hasn’t completely reduced its inetd.conf file yet (the output has been trimmed down with some filtering from egrep):

%