Current standard
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.
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
Clients that keep a direct IMAP connection open, such as Thunderbird on desktop, Thunderbird for Android (formerly K-9 Mail) and FairEmail, use IDLE to show new mail within seconds. Not every client does: Apple Mail on iPhone offers push only for some account types, such as iCloud and Exchange accounts, and checks ordinary IMAP accounts on a fetch schedule instead. The alternative to IDLE is polling every few minutes, which 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.
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
C: A001 SELECT INBOX
S: * 34 EXISTS
S: * 0 RECENT
S: * OK [UIDVALIDITY 1721600000] UIDs valid
S: * OK [UIDNEXT 12345] Predicted next UID
S: A001 OK [READ-WRITE] SELECT completed
C: A002 IDLE
S: + idling
<<< connection held open >>>
<<< time passes; a new message arrives >>>
S: * 35 EXISTS
S: * 1 RECENT
<<< client decides to act on the new message >>>
C: DONE
S: A002 OK IDLE terminated
C: A003 FETCH 35 (ENVELOPE FLAGS)
S: * 35 FETCH (ENVELOPE (“…” “New message subject” …) FLAGS (Recent))
S: A003 OK FETCH completed
Server can push multiple untagged responses during IDLE:
* N EXISTS New total message count
* N RECENT Newly arrived count
* N EXPUNGE Message N removed
* N FETCH Flag or attribute change on message N
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?
Yes. Android clients such as Thunderbird for Android and FairEmail hold IDLE directly and deliver mail within seconds, at some battery cost. Apps from large providers usually rely on their own servers and the platform push service (APNs on iOS, FCM on Android) instead. On iPhone, background IMAP IDLE is not available to Apple Mail for ordinary IMAP accounts, which are checked on a fetch schedule.
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.
Did this guide save you time?
SMTPedia is free and independent. A coffee helps keep every guide accurate.
Buy SMTPedia a coffeeAbout 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.