The IMAP NOTIFY Extension
updates
- rfc-5267 — Contexts for IMAP4
Extracted elements (30)
IDLE (RFC 2177) only applies to the selected mailbox and provides no way to restrict which events are sent, requiring an additional TCP connection per monitored mailbox. NOTIFY was designed to let clients express preferences about events across multiple mailboxes on a single connection, reducing unnecessary server processing and network traffic.
The SELECTED-DELAYED specifier was introduced to allow clients that use MSNs (Message Sequence Numbers) and '*' in commands to still benefit from NOTIFY. Without it, unsolicited EXPUNGE notifications would invalidate MSNs mid-operation; SELECTED-DELAYED defers expunge notifications until a safe command boundary.
A server implementing NOTIFY is not required to implement LIST-EXTENDED (RFC 5258), but must be able to return extended LIST responses as defined in RFC 5258, since MailboxName events use extended LIST responses with OLDNAME and attribute data.
A successful NOTIFY SET command MUST cause the server to immediately return any accumulated changes to the currently selected mailbox (if any), such as flag changes and new or expunged messages. A successful NOTIFY SET thus implies an implicit NOOP.
If a client loses access to a monitored mailbox after a successful NOTIFY, the server MUST stop monitoring it. If access is later granted, the server MUST restart event monitoring.
If a client requests events for an unsupported type, the server MUST refuse with a tagged NO response (not BAD). The response SHOULD contain the BADEVENT response code listing all events supported by the server.
If a mailbox name does not refer to an existing mailbox, or refers to a mailbox the client cannot LIST, the server MUST ignore it. This prevents disclosure of confidential information to clients lacking 'l' (lookup) rights.
If FlagChange and/or AnnotationChange events are specified, MessageNew and MessageExpunge MUST also be specified by the client; otherwise the server MUST respond with a tagged BAD. Similarly, if one of MessageNew or MessageExpunge is specified, both MUST be specified.
If NOTIFY enables MessageNew, MessageExpunge, AnnotationChange, or FlagChange for a non-selected mailbox and the client specified the STATUS indicator, the server MUST send a STATUS response for that mailbox before NOTIFY's tagged OK. If MessageNew is enabled, STATUS MUST contain MESSAGES, UIDNEXT, and UIDVALIDITY.
If the IMAP server cannot easily compute the set of MDA-deliverable mailboxes for the 'inboxes' specifier, it MUST treat 'inboxes' as equivalent to 'personal'.
Support for MailboxMetadataChange is OPTIONAL unless the METADATA extension (RFC 5464) is also supported, in which case support is REQUIRED. A deleted metadata item MUST always be included in the METADATA response.
Support for ServerMetadataChange is OPTIONAL unless the METADATA or METADATA-SERVER extension (RFC 5464) is supported, in which case it is REQUIRED. Only the names of changed metadata entries SHOULD be returned; deleted items MUST always be included.
When using the 'Mailboxes' specifier, the server MUST NOT do wildcard expansion; LIST wildcard characters ('*' and '%') have no special treatment in mailbox names.
While processing any IDLE command, the server MUST send exactly the same events as instructed by the client using the NOTIFY command.
Mailbox specifiers include: SELECTED and SELECTED-DELAYED (currently selected mailbox), personal (all selectable personal namespace mailboxes), inboxes (delivery-eligible personal mailboxes), subscribed (all subscribed mailboxes), subtree (mailbox plus descendants), and mailboxes (explicit list, no wildcard expansion).
The FlagChange event covers MessageRead, MessageTrash, FlagsSet, and FlagsClear events from RFC 5423. For the selected mailbox, notification is an unsolicited FETCH response including UID and FLAGS/ANNOTATION items; for other mailboxes, a STATUS response is sent.
The MailboxName event is sent when a mailbox is created, deleted, or renamed (including granting/revoking the 'l' right in ACL-enabled servers). The server sends an unsolicited LIST response for each affected mailbox name; renamed mailboxes get an extended LIST response with the OLDNAME extended data item.
The MessageExpunge event covers both MessageExpunge and MessageExpire from RFC 5423. For the selected mailbox, notification uses EXPUNGE (or VANISHED if QRESYNC is enabled). For other mailboxes, an unsolicited STATUS (UIDNEXT MESSAGES) response is sent.
The MessageNew event covers both MessageNew and MessageAppend from RFC 5423. For the selected mailbox, the server sends an unsolicited EXISTS response followed by an unsolicited FETCH response with client-requested attributes. For other mailboxes, an unsolicited STATUS (UIDNEXT MESSAGES) is sent.
The NotificationOverflow mechanism allows a server unable to deliver all requested notifications to disable them. The server MUST send an untagged 'OK [NOTIFICATIONOVERFLOW]' response and behave as if NOTIFY NONE had been received.
The NOTIFY command allows an IMAP client to request specific unsolicited notifications for specified mailboxes. It has two forms: NOTIFY NONE (cancels all notifications) and NOTIFY SET (replaces the current list of interesting events with a new list).
The SELECTED-DELAYED mailbox specifier requires the server to delay MessageExpunge events until the client issues a command that allows returning information about expunged messages (e.g., NOOP or IDLE). This allows clients using MSNs to avoid MSN invalidation from unsolicited expunge notifications.
The SubscriptionChange event sends an unsolicited LIST response for each affected mailbox name. The \Subscribed attribute is included if and only if the mailbox is subscribed after the event. All mailbox attributes MUST be accurately computed.
The UPDATE return option for SEARCH/SORT (RFC 5267) is extended to allow specifying fetch attributes to be returned when a new message is added to the search context. The EXISTS response MUST precede any FETCH responses, which together MUST precede the ESEARCH response.
IANA added 'NOTIFY' to the list of IMAP extensions. Additionally, the OLDNAME LIST-EXTENDED extended data item was registered in the LIST-EXTENDED response registry (RFC 5258), describing the old mailbox name for a renamed mailbox identified by a LIST response.
A client can deny itself service by requesting all events on all mailboxes, potentially swamping its own network connection or processing capability, and in the worst case degrading the server's service to other clients. Servers may refuse expensive notification requests with a tagged NO [NOTIFICATIONOVERFLOW].
If a client issues NOTIFY requests but does not read responses, the TCP window can fill up and a careless server might block. This problem exists in plain IMAP but is magnified by the NOTIFY extension, which can generate significantly more unsolicited data.
The NOTIFY extension makes it possible to retrieve messages immediately when delivered, making it wholly impractical to delete sensitive messages using programs like imapfilter before the client sees them. Using SIEVE (RFC 5228) for server-side filtering is recommended instead.
The NOTIFY command syntax is: 'NOTIFY SP (notify-set / notify-none)'. NOTIFY SET takes an optional STATUS indicator and event-groups of the form '(' filter-mailboxes SP events ')'. New response codes defined: NOTIFICATIONOVERFLOW and BADEVENT SP '(' event-name+ ')'.
The OLDNAME extended LIST data item is defined as 'OLDNAME SP "(" mailbox ")"' and is returned in a LIST response when a mailbox is renamed, conveying the previous mailbox name. The \NoAccess name attribute is added to mbx-list-oflag.