IMAP4 IDLE command
Extracted elements (12)
IMAP4 requires clients to poll for changes; while the spec permits servers to push EXISTS responses asynchronously, clients cannot rely on this behavior. IDLE was introduced to allow the server to transmit updates in real time, benefiting users who want immediate new-mail notification and applications that would otherwise need to poll every few seconds.
Clients using IDLE are advised to terminate the IDLE and re-issue it at least every 29 minutes to avoid being logged off by servers with inactivity timeouts. This still allows immediate mailbox updates while polling at roughly half-hour intervals.
The IDLE command may only be used with IMAP4 server implementations that return 'IDLE' as one of the supported capabilities to the CAPABILITY command; capability advertisement is the gating mechanism for this extension.
After receiving the client's 'DONE' continuation, the server MAY send any remaining queued untagged responses and then MUST immediately send the tagged response to the IDLE command and prepare to process other commands.
If the server does not advertise the IDLE capability in response to the CAPABILITY command, the client MUST NOT use the IDLE command and must poll for mailbox updates instead.
The client MUST continue to be able to accept unsolicited untagged responses to ANY command, as specified in the base IMAP specification, regardless of whether IDLE is in use.
The client MUST NOT send a command while the server is waiting for the DONE continuation, since the server will not be able to distinguish a command from a continuation.
The server MAY consider a client inactive if it has an IDLE command running, and if the server has an inactivity timeout it MAY log the client off implicitly at the end of that timeout period.
The IDLE command is sent from client to server to signal readiness to accept unsolicited mailbox update messages. The server responds with a continuation ('+') response, and the command remains active until the client sends 'DONE'. While active, the server may send untagged EXISTS, EXPUNGE, and other messages at any time.
The RFC explicitly states there are no known security issues with the IDLE extension.
IDLE transitions: client sends 'IDLE' → server sends '+' continuation (IDLE active state, server may push untagged responses) → client sends 'DONE' → server sends queued untagged responses then tagged OK/NO/BAD → command completes and server accepts new commands.
The formal BNF syntax defines 'idle' as the literal string 'IDLE' followed by CRLF and then 'DONE'. IDLE is added to command_auth, making it valid only in Authenticated or Selected state.