Optimizing Dovecot IMAP IDLE for Real‑Time Email Notifications

Solving the Push Email Latency Problem

Standard IMAP clients typically poll the server at set intervals to check for new mail, which creates a trade‑off between battery drain/server load and notification latency. The IMAP IDLE command (RFC 2177) solves this by allowing the client to tell the server it is waiting for updates. Instead of the client asking "Anything new?" every few minutes, the server pushes an untagged EXISTS response the moment a new message hits the mailbox.

To implement this in Dovecot (version 2.3+), you must ensure the IMAP protocol is configured to notify clients and that the underlying filesystem notifications are efficient enough to handle the concurrent connections without spiking CPU usage.

Mechanism: How Dovecot Handles IDLE

When a client issues the IDLE command, Dovecot puts the connection into a waiting state. Rather than scanning the disk for every connected client, Dovecot leverages inotify (on Linux) or kqueue (on BSD) to watch for filesystem changes. When the mail delivery agent (LDA) writes a new file to the maildir or modifies the mbox, the kernel notifies Dovecot, which then triggers the EXISTS response to all clients currently in the IDLE state for that specific mailbox.

Recommended Configuration

Most Dovecot installations have IDLE enabled by default, but production environments require specific tuning to prevent firewall timeouts and performance degradation. Add or verify these settings in your dovecot.conf or 15-imap.conf:

# Protocol‑specific settings for IMAP
protocol imap {
  # Enables the IDLE command (Default: yes)
  imap_idle_notify = yes

  # How often to check for changes if filesystem notifications fail
  # Default is 30s; lower values increase CPU load
  mailbox_idle_check_interval = 30s

  # Sends a keep‑alive response every 2 minutes to prevent
  # NAT/Firewall TCP timeouts (Default: yes)
  imap_idle_send_untagged = yes
}

# Global performance setting
# Prevents expensive directory scans for every IDLE client
mailbox_list_index = yes

Connection Capacity Planning

Each IDLE connection occupies one client slot. If you have 10,000 users with mobile apps keeping connections open, you must adjust your service limits to avoid rejecting new logins. Configure the service imap block as follows:

service imap {
  # Total number of imap processes
  process_limit = 1024
  # Max clients per process; total capacity = process_limit * client_limit
  client_limit = 1000
}

Verification and Diagnostics

To verify that IDLE is active and functioning, you can manually simulate a client using OpenSSL. Run this command from a terminal with access to the server:

# Connect to the IMAP SSL port (usually 993)
openssl s_client -connect localhost:993 -crlf

Once connected and authenticated, execute these commands sequentially:

1. A001 CAPABILITY — Verify that IDLE appears in the list of supported capabilities.
2. A002 SELECT INBOX — Enter the mailbox you wish to monitor.
3. A003 IDLE — The server should respond with + idling.

While the session is in the + idling state, send an email to that account from another terminal. You should see an untagged response like * 2 EXISTS appear instantly in your OpenSSL session. To exit IDLE mode, send DONE.

Limitations and Common Pitfalls

The "Silent Drop" Problem

The most common failure point for IMAP IDLE is not the Dovecot server, but the network path. Corporate firewalls and NAT gateways often drop TCP connections that have no traffic for 5 to 15 minutes. While imap_idle_send_untagged = yes helps by sending a "Still here" heartbeat, some strict IMAP clients may treat these untagged responses as protocol errors. If clients are disconnecting frequently, check your firewall's tcp_keepalive settings.

Performance Degradation

Disabling mailbox_list_index is a common mistake made by administrators trying to reduce disk I/O. However, without the index, Dovecot must perform a full directory scan of the mailbox every time it checks for updates. In a high‑concurrency IDLE environment, this leads to an exponential increase in CPU and disk wait times.

Infrastructure Constraints

• Proxies: IMAP IDLE requires a persistent TCP stream. It will not work over standard HTTP proxies. If using a load balancer (like HAProxy), it must be configured in mode tcp.
• Filesystem Support: If Dovecot is running on a filesystem that does not support inotify/kqueue (e.g., certain network mounts), it falls back to polling every mailbox_idle_check_interval, which significantly increases resource usage.

Rollback Procedure

If you experience instability or excessive CPU load after enabling these settings, revert the changes in your configuration file and reload the service:

# Restore original values in dovecot.conf, then run:
sudo systemctl reload dovecot