RFC 2177

IMAP4 IDLE command

📅 published June 1997, from ietf

RFC 2177: IMAP4 IDLE command 🎀

okay so this is RFC 2177, and it's giving real-time mail updates for IMAP clients 📬✨

Network Working Group, Request for Comments 2177, written by Barry Leiba from IBM T.J. Watson Research Center. It's a Standards Track doc, dated June 1997. It doesn't list anything it obsoletes or updates 💅

Status of This Memo 📝

bestie, this doc is an Internet standards track protocol for the Internet community, and it's asking for discussion and suggestions for improvements 🫶 For the standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited 🌈

1. Abstract 🌸

so IMAP ([IMAP4]) makes a client keep polling the server to see if anything changed in the selected mailbox, like new mail or deletions 😩 It's way better when the server just pushes updates to the client in real time, so a user can see new mail right away ⚡ This also helps real-time IMAP apps that would otherwise have to poll super often, like every few seconds 💀

Ngl, the spec does technically let a server push EXISTS responses asynchronously, but a client can't count on that behaviour, so it still has to poll 🙈

This doc defines the syntax of an IDLE command, which lets a client tell the server it's ready to accept those real-time updates 🦋

2. Conventions Used in this Document 💜

in the examples, "C:" means lines sent by the client and "S:" means lines sent by the server 💅

The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" in this document are to be interpreted as described in RFC 2060 [IMAP4]. (these are the vibe checks for how strict each rule is 🫶)

3. Specification 🎀

IDLE Command

Arguments:  none

Responses:  continuation data will be requested; the client sends
            the continuation data "DONE" to end the command

Result:     OK - IDLE completed after client sent "DONE"
            NO - failure: the server will not allow the IDLE
                 command at this time
           BAD - command unknown or arguments invalid

okay so the IDLE command works with any IMAP4 server that lists "IDLE" as one of its supported capabilities when asked by the CAPABILITY command ✨ If the server doesn't advertise IDLE, the client MUST NOT use it, and it has to keep polling for mailbox updates 😭 Even so, the client MUST still be able to accept unsolicited untagged responses to ANY command, like the base IMAP spec says 🔥

The client sends IDLE when it's ready to accept unsolicited mailbox update messages 💖 The server asks for a response using the continuation ("+") response. The IDLE command stays active until the client answers that continuation, and while it's active, the server is free to send untagged EXISTS, EXPUNGE, and other messages at any time 🧚

The client ends IDLE by sending a "DONE" continuation, which also satisfies the server's continuation request 🍓 At that point, the server MAY send any leftover queued untagged responses, and then it MUST immediately send the tagged response to the IDLE command and get ready for other commands 😤 Like in the base spec, handling a new command can still lead to unsolicited untagged responses, subject to the ambiguity limitations 🌈 The client MUST NOT send a command while the server is waiting for the DONE, because the server wouldn't be able to tell a command apart from a continuation 💀

Here's the tea 🍵 The server MAY consider a client inactive if it's running an IDLE command. If the server has an inactivity timeout, it MAY log the client off implicitly once that timeout runs out. So clients using IDLE are advised to end the IDLE and re-issue it at least every 29 minutes so they don't get logged off 🙈 Honestly, this still lets a client get immediate mailbox updates, even though it only needs to "poll" every half hour ⭐

Example:

C: A001 SELECT INBOX
S: * FLAGS (Deleted Seen)
S: * 3 EXISTS
S: * 0 RECENT
S: * OK [UIDVALIDITY 1]
S: A001 OK SELECT completed
C: A002 IDLE
S: + idling
...time passes; new mail arrives...
S: * 4 EXISTS
C: DONE
S: A002 OK IDLE terminated
...another client expunges message 2 now...
C: A003 FETCH 4 ALL
S: * 4 FETCH (...)
S: A003 OK FETCH completed
C: A004 IDLE
S: * 2 EXPUNGE
S: * 3 EXISTS
S: + idling
...time passes; another client expunges message 3...
S: * 3 EXPUNGE
S: * 2 EXISTS
...time passes; new mail arrives...
S: * 3 EXISTS
C: DONE
S: A004 OK IDLE terminated
C: A005 FETCH 3 ALL
S: * 3 FETCH (...)
S: A005 OK FETCH completed
C: A006 IDLE

4. Formal Syntax 🧚

this part is the grammar 🤓 It uses the augmented Backus-Naur Form (BNF) notation from [RFC-822], as modified by [IMAP4]. Anything referenced but not defined here is defined by [IMAP4] 💜

command_auth    ::= append / create / delete / examine / list / lsub /
                    rename / select / status / subscribe / unsubscribe
                    / idle
                    ;; Valid only in Authenticated or Selected state

idle            ::= "IDLE" CRLF "DONE"

5. References 📚

[IMAP4] Crispin, M., "Internet Message Access Protocol - Version
4rev1", RFC 2060, December 1996.

6. Security Considerations 🔐

no cap, there are no known security issues with this extension 😌✨ Iconic behaviour, honestly.

7. Author's Address 🎀

Barry Leiba
IBM T.J. Watson Research Center
30 Saw Mill River Road
Hawthorne, NY  10532

Email: leiba@watson.ibm.com
📦 where this page comes from