What this RFC defines
RFC 2177 defines the IDLE extension for IMAP, which allows a mail client to remain connected to the server and receive immediate notification when new mail arrives, without polling. The client sends an IDLE command; the server holds the connection open and pushes EXISTS or EXPUNGE updates as mailbox state changes.
Where you see it in practice
When your phone’s email app shows a new message notification within seconds of the email arriving, rather than waiting for the next scheduled sync, it is using IMAP IDLE as defined by this RFC. Without IDLE, email clients must periodically poll the server with SELECT or NOOP commands to check for new messages. IDLE eliminates polling overhead and reduces both battery use and server load for real-time email notification.
How it connects to other RFCs
RFC 2177 is an extension to IMAP as defined in RFC 9051 (formerly RFC 3501). It is one of the most widely deployed IMAP extensions and complements RFC 4551 (CONDSTORE) and RFC 6851 (MOVE) as part of the modern IMAP extension set that makes server-side mailbox management efficient.
Current status
RFC 2177 is a current standard, published June 1997. IMAP IDLE is supported by virtually all IMAP servers (Dovecot, Courier, Exchange, Gmail) and clients (Outlook, Thunderbird, iOS Mail, Android). It is the standard mechanism for push email notification in IMAP deployments.
The IDLE command explained
RFC 2177 added the IDLE command to IMAP in June 1997. Before IDLE, an IMAP client had to poll the server periodically to check for new mail, which wasted bandwidth and delayed new-message notifications. IDLE lets a client tell the server “I am waiting, notify me when something changes.” The server holds the connection open and sends untagged responses when new messages arrive or existing messages are modified. The client sends DONE to end the IDLE state and issue further commands.
Why IDLE matters for mobile
Every modern mobile mail client that pushes new mail to a lock screen without a persistent third-party service uses IMAP IDLE. Apple Mail, K-9 Mail, FairEmail, and countless enterprise clients rely on this extension for near-instant notification of new messages. The alternative is polling every few minutes, which drains battery and adds latency. Gmail and Outlook additionally support proprietary push protocols (via ActiveSync or Gmail Push), but IMAP IDLE is the universal open-standard mechanism that works with any IMAP server.
Idle timeout handling
Because IDLE holds a TCP connection open, both client and server must handle timeouts carefully. RFC 2177 recommends that clients terminate and restart the IDLE state at least every 29 minutes to avoid triggering firewalls or NAT tables that drop idle connections after 30 minutes. Servers typically send periodic keepalive responses to detect dead connections. If your IMAP client shows delayed notifications after long inactivity, an IDLE timeout is the likely cause, either on the client side, the server side, or a middlebox in between.
RFC 2177 (June 1997) defines the IMAP IDLE extension: a mechanism for clients to receive server-pushed updates about mailbox changes (new messages, flag changes, expunges) in real time, without polling. Client issues IDLE, server holds the connection and pushes untagged responses as events occur, client cancels by sending DONE. Advertised as IDLE in CAPABILITY response. Foundation for modern mobile push notifications, mail client sync, and real-time inbox updates. Nearly universal on modern IMAP servers.
RFC 2177 at a glance
| Aspect | Detail |
|---|---|
| Purpose | Real-time server-to-client notifications without polling |
| Advertised as | IDLE in IMAP CAPABILITY |
| Client command | IDLE |
| Client cancel | Send DONE line (no tag) |
| Server behavior | Hold connection open; push untagged responses on state changes |
| Recommended IDLE cycle | Refresh every 29 minutes (to avoid NAT/proxy timeouts under 30 min) |
| Published | June 1997 |
IDLE dialogue example
The 29-minute rule
Mobile push notifications and IDLE
| Approach | How it works | Battery/network cost |
|---|---|---|
| IMAP IDLE from the device | Device holds IDLE connection; cellular radio active | High: keeps radio active |
| Server-side push (APNS, FCM) | Cloud service holds IDLE; pushes to device via APNS/FCM when needed | Low: device radio can sleep |
| Polling | Client polls every N minutes | Medium: periodic radio wake |
Common IDLE implementation mistakes
DONE. Sending other commands is a protocol violation; some servers close the connection, others behave unpredictably. To perform other operations, terminate IDLE with DONE first, then issue the desired command, then re-issue IDLE if desired.Related standards and further reading
- RFC 3501: IMAP4rev1 (base protocol)
- RFC 9051: IMAP4rev2 (2021 update; IDLE integrated into base)
- RFC 5465: NOTIFY (extended notification framework)
- RFC 5464: METADATA (mailbox metadata)
- RFC 3501 IMAP Guide: base IMAP protocol
- Email Protocols and Ports Guide: IMAP configuration
Frequently asked questions
What is the difference between IDLE and polling?
Polling: client periodically checks server for new messages. Bandwidth cost per poll (connection setup, CAPABILITY, SELECT, FETCH); delay of up to N seconds between polls. IDLE: client keeps a connection open; server pushes updates as they occur. Near-zero bandwidth in idle state, instant notification. IDLE is vastly better for user experience and infrastructure cost. Every modern IMAP client should use IDLE when supported.
Why do IDLE connections drop?
Intermediate middleboxes (NAT devices, corporate proxies, ISP transparent proxies) often drop TCP connections after 15-30 minutes of no traffic. IDLE has no traffic by design (server holds connection until an event fires). Cycling IDLE every 29 minutes (DONE then re-IDLE) sends brief traffic that resets middlebox timers. Client libraries handle this automatically.
Can I use IDLE from a mobile app?
Technically yes, but battery-hostile. Direct IDLE requires the mobile device to keep its radio active, draining battery quickly. Modern mobile mail apps use platform push (APNS on iOS, FCM on Android) via a server-side IDLE proxy: the proxy holds IDLE at the IMAP server, then pushes notifications to the device via the platform mechanism. The device radio can sleep between notifications.
Do all IMAP servers support IDLE?
Nearly all in 2026. Dovecot, Cyrus, Gmail’s IMAP, Microsoft 365, Yahoo, iCloud, Fastmail all support IDLE. Check CAPABILITY response for the IDLE keyword before attempting. Some legacy or specialized deployments (older on-premises Exchange, custom or minimal servers) may lack support; fall back to polling in those cases.
Is IDLE still separate in IMAP4rev2?
No. RFC 9051 (IMAP4rev2, 2021) folds IDLE into the base protocol; there is no separate CAPABILITY advertisement needed. Servers advertising IMAP4rev2 support IDLE by default. RFC 2177 remains the reference for IDLE semantics for IMAP4rev1 servers, which remain the majority in 2026.
About the Author
Alaa · LinkedIn
Email infrastructure specialist with 8+ years of hands-on experience in SMTP, deliverability, and email verification. I’ve configured and troubleshot mail systems across Postfix, Exchange, and cloud relays, managed IP reputation and warmup campaigns, and built verification pipelines processing millions of addresses. My work spans DNS authentication (SPF, DKIM, DMARC, BIMI), bounce handling, blocklist monitoring, and compliance frameworks including CAN-SPAM and GDPR. I write every article on SMTPedia to give email professionals, developers, and marketers the accurate, RFC-grounded reference they need.
About SMTPedia
SMTPedia is an independent email industry reference covering SMTP, IMAP, POP3, email deliverability, marketing platforms, DNS authentication, and email verification. Every article is researched from official provider documentation, IETF RFCs, and industry best practices. Settings and configurations are verified quarterly.
We are cited as a source by ChatGPT, Microsoft Copilot, and thousands of email professionals worldwide. Learn more about our editorial process.
