idnits 2.17.1 draft-ietf-lemonade-imap-notify-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 18. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1076. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1048. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1055. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1061. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 22 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 23 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (August 18, 2008) is 5723 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'NOTIFICATIONOVERFLOW' is mentioned on line 283, but not defined ** Obsolete normative reference: RFC 3501 (Obsoleted by RFC 9051) ** Obsolete normative reference: RFC 4551 (Obsoleted by RFC 7162) ** Obsolete normative reference: RFC 5162 (ref. 'QRESYNC') (Obsoleted by RFC 7162) == Outdated reference: A later version (-17) exists of draft-daboo-imap-annotatemore-14 == Outdated reference: A later version (-07) exists of draft-ietf-lemonade-msgevent-06 == Outdated reference: A later version (-14) exists of draft-crocker-email-arch-10 Summary: 4 errors (**), 0 flaws (~~), 7 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Alexey Melnikov 3 Internet-Draft Isode Ltd. 4 Intended Status: Proposed Standard Arnt Gulbrandsen 5 Oryx Mail Systems GmbH 6 Curtis King 7 Isode Ltd. 8 August 18, 2008 10 The IMAP NOTIFY Extension 11 draft-ietf-lemonade-imap-notify-07.txt 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six 26 months and may be updated, replaced, or obsoleted by other documents 27 at any time. It is inappropriate to use Internet-Drafts as 28 reference material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet- 32 Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft expires in February 2009. 37 Abstract 39 This document defines an IMAP extension which allows a client to 40 request specific kinds of unsolicited notifications for specified 41 mailboxes, such as messages being added to or deleted from 42 mailboxes. 44 [[Add Updates: RFC-CONTEXT to the headers]] 46 Internet-draft August 2008 48 Table of Contents 50 1. Conventions Used in This Document . . . . . . . . . . . . . . 3 51 2. Overview and rationale . . . . . . . . . . . . . . . . . . . . 3 52 3. The NOTIFY extension . . . . . . . . . . . . . . . . . . . . . 4 53 3.1. The NOTIFY Command . . . . . . . . . . . . . . . . . . . . 4 54 4. Interaction with the IDLE Command . . . . . . . . . . . . . . 8 55 5. Event Types . . . . . . . . . . . . . . . . . . . . . . . . . 8 56 5.1. FlagChange and AnnotationChange . . . . . . . . . . . . . . 9 57 5.2. MessageNew . . . . . . . . . . . . . . . . . . . . . . . . 9 58 5.3. MessageExpunge . . . . . . . . . . . . . . . . . . . . . . 11 59 5.4. MailboxName . . . . . . . . . . . . . . . . . . . . . . . . 11 60 5.5. SubscriptionChange . . . . . . . . . . . . . . . . . . . . 12 61 5.6. MailboxMetadataChange . . . . . . . . . . . . . . . . . . . 12 62 5.7. ServerMetadataChange . . . . . . . . . . . . . . . . . . . 13 63 5.8. Notification Overflow . . . . . . . . . . . . . . . . . . . 13 64 5.9. ACL Changes . . . . . . . . . . . . . . . . . . . . . . . . 13 65 6. Mailbox Specification . . . . . . . . . . . . . . . . . . . . 14 66 6.1. Mailbox specifiers affecting the currently selected mailbox 14 67 6.2. Personal . . . . . . . . . . . . . . . . . . . . . . . . . 15 68 6.3. Inboxes . . . . . . . . . . . . . . . . . . . . . . . . . . 15 69 6.4. Subscribed . . . . . . . . . . . . . . . . . . . . . . . . 15 70 6.5. Subtree . . . . . . . . . . . . . . . . . . . . . . . . . . 15 71 6.6. Mailboxes . . . . . . . . . . . . . . . . . . . . . . . . . 16 72 7. Extension to SEARCH and SORT commands . . . . . . . . . . . . 16 73 8. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 16 74 9. Security considerations . . . . . . . . . . . . . . . . . . . 19 75 10. IANA considerations . . . . . . . . . . . . . . . . . . . . . 19 76 10.1. Initial LIST-EXTENDED extended data item registrations . 19 77 11. Acknowedgements . . . . . . . . . . . . . . . . . . . . . . . 20 78 12. Normative References . . . . . . . . . . . . . . . . . . . . . 20 79 13. Informative References . . . . . . . . . . . . . . . . . . . . 21 80 14. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 22 81 Intellectual Property and Copyright Statements . . . . . . . . . . 23 83 Internet-draft August 2008 85 1. Conventions Used in This Document 87 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 88 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 89 document are to be interpreted as described in [RFC2119]. 91 Formal syntax is defined by [RFC5234] as extended by [RFC3501] and 92 [RFC4466]. 94 The acronym MSN stands for Message Sequence Numbers (see Section 95 2.3.1.2 of [RFC3501]). 97 Example lines prefaced by "C:" are sent by the client and ones 98 prefaced by "S:" by the server. "[...]" means elision. 100 2. Overview and rationale 102 The IDLE command (defined in [RFC2177]) provides a way for the 103 client to go into a mode where the IMAP server pushes 104 notifications about IMAP mailstore events for the selected 105 mailbox. However, the IDLE extension doesn't restrict or 106 control which server events can be sent, or what information 107 the server sends in response to each event. 108 Also, IDLE only applies to the selected mailbox, thus requiring 109 an additional TCP connection per mailbox. 111 This document defines an IMAP extension that allows clients to 112 express their preferences about unsolicited events generated by 113 the server. The extension allows clients to only receive events 114 they are interested in, while servers know that they don't need 115 to go into effort of generating certain types of untagged responses. 117 Without the NOTIFY command defined in this document, an IMAP server 118 will only send information about mailstore changes to the client in 119 the following cases: 120 - as the result of a client command (e.g. FETCH responses to 121 a FETCH or STORE command), 122 - unsolicited responses sent just before the end of a command 123 (e.g. EXISTS or EXPUNGE) as the result of changes in other 124 sessions, and 125 - during an IDLE command. 127 The NOTIFY command extends what information may be returned in those 128 last two cases, and also permits and requires the server to send 129 information about updates between command. The NOTIFY command also 130 allows for the client to extend what information is sent unsolicited 131 about the selected mailbox, and to request some update information 133 Internet-draft August 2008 135 to be sent regarding other mailboxes. 137 For the new messages delivered to or appended to the selected 138 mailbox, the NOTIFY command can be used to request that a set of 139 attributes be sent to the client in an unsolicited FETCH response. 140 This allows a client to be passive recipient of events and new mail, 141 and be able to maintain full synchronisation without having to issue 142 any subsequent commands except to modify the state of the mailbox on 143 the server. 145 Some mobile clients, however, may want mail "pushed" only for mail 146 that matches a SEARCH pattern. To meet that need [CONTEXT] is 147 augmented by this document to extend the UPDATE return option to 148 specify a list of fetch-atts to be returned when a new message is 149 delivered or appended in another session. 151 [[RFC-Editor: Please delete the following before publication: 152 Comments regarding this draft may be sent either to the 153 lemonade@ietf.org mailing list or to the authors.]] 155 3. The NOTIFY extension 157 IMAP servers which support this extension advertise the X-DRAFT- 158 W06-NOTIFY capability. This extension adds the NOTIFY command as 159 defined in Section 5.1. 161 A server implementing this extension is not required to implement 162 LIST-EXTENDED [LISTEXT], even though a NOTIFY compliant server must 163 be able to return extended LIST responses defined in [LISTEXT]. 165 3.1. The NOTIFY Command 167 Arguments: "SET" 168 optional STATUS indicator 169 Mailboxes to be watched 170 Events about which to notify the client 172 Or 173 Arguments: "NONE" 175 Responses: Possibly untagged STATUS responses (for SET) 177 Result: OK - The server will notify the client as requested. 179 Internet-draft August 2008 181 NO - Unsupported notify event, NOTIFY too complex or 182 expensive, etc. 183 BAD - Command unknown, invalid, unsupported or unknown 184 arguments. 186 The NOTIFY command informs the server that the client listens for 187 event notifications all the time (even when no command is in 188 progress) and requests the server to notify it about the specified 189 set of events. The NOTIFY command has two forms. NOTIFY NONE 190 specifies that the client is not interested in any kind of event 191 happening on the server. NOTIFY SET replaces the current list of 192 interesting events with a new list of events. 194 Until the NOTIFY command is used for the first time, the server only 195 sends notifications while a command is being processed, and notifies 196 the client about these events on the selected mailbox: (see section 197 5 for definitions): MessageNew, MessageExpunge, FlagChange. It does 198 not notify the client about any events on other mailboxes. 200 The effect of a successful NOTIFY command lasts until the next 201 NOTIFY command, or until the IMAP connection is closed. 203 A successful NOTIFY SET command MUST cause the server to immediately 204 return any accumulated changes to the currently selected mailbox (if 205 any), such as flag changes, new or expunged messages. This is 206 equivalent to NOOP command being issued by the client just before 207 the NOTIFY SET command. 209 The NOTIFY SET command can request notifications of message related 210 changes to the selected mailbox, whatever it may be at the time the 211 message notifications are being generated. This is done by 212 specifying either the SELECTED or the SELECTED-DELAYED mailbox 213 selector (see Section 6.1) in the NOTIFY SET command. If the 214 SELECTED/SELECTED-DELAYED mailbox selector is not specified in the 215 NOTIFY SET command, this means that the client doesn't want to 216 receive any s for the currently selected mailbox. 217 This is the same as specifying SELECTED NONE. 219 The client can also request notifications on other mailboxes by name 220 or by a limited mailbox pattern match. Message related 221 notifications returned for the currently selected mailbox will be 222 those specified by the SELECTED/SELECTED-DELAYED mailbox specifier, 223 even if the selected mailbox also appears by name (or matches a 224 pattern) in the command. Non message related notifications are 225 controlled by mailbox specifiers other than SELECTED/SELECTED- 226 DELAYED. 228 If the NOTIFY command enables MessageNew, MessageExpunge, 230 Internet-draft August 2008 232 AnnotationChange or FlagChange notification for a mailbox other than 233 the currently selected mailbox, and the client has specified the 234 STATUS indicator parameter, then the server MUST send a STATUS 235 response for that mailbox before NOTIFY's tagged OK. If MessageNew 236 is enabled, the STATUS response MUST contain MESSAGES, UIDNEXT and 237 UIDVALIDITY. If MessageExpunge is enabled, the STATUS response MUST 238 contain MESSAGES. If either AnnotationChange or FlagChange are 239 included and the server also supports CONDSTORE [RFC4551] and/or 240 QRESYNC [QRESYNC] extension, the STATUS response MUST contain 241 UIDVALIDITY and HIGHESTMODSEQ. Absence of the STATUS indicator 242 parameter allows the client to avoid the additional STATUS 243 responses. This might be useful if the client has already retrieved 244 this information before issuing the NOTIFY command. 246 Clients are advised to limit the number of mailboxes used with 247 NOTIFY. Particularly, if a client asks for events for all accessible 248 mailboxes, the server may swamp the client with updates about shared 249 mailboxes. This may reduce client's battery life. Also this wastes 250 both server and network resources. For each mailbox 251 specified, the server verifies that the client has access using the 252 following test: 254 - If the name does not refer to an existing mailbox, the server MUST 255 ignore it. 257 - If the name refers to a mailbox which the client can't LIST, the 258 server MUST ignore it. For a server that implements [RFC4314] this 259 means that if the client that doesn't have the 'l' (lookup) right 260 for the name, then the server MUST ignore the mailbox. This 261 behavior prevents dislosure on potentially confidential 262 information to clients which don't have rights to know it. 264 - If the name refers to a mailbox which the client can LIST (e.g. it 265 has the 'l' right from [RFC4314]), but doesn't have another right 266 required for processing of the specified event(s), then the server 267 MUST respond with an untagged extended LIST response containing 268 the \NoAccess name attribute. 270 The server SHOULD return the tagged OK response if the client has 271 access to at least one of the mailboxes specified in the current 272 list of interesting events. The server MAY return the tagged NO 273 response if the client has no access to any of the specified 274 mailboxes and no access can ever be granted in the future (e.g. the 275 client specified an event for 'Subtree Bar/Foo', 'Bar/Foo' doesn't 276 exist and LIST returns \Noinferiors for the parent 'Bar'). 278 If the notification would be prohibitively expensive for the server 279 (e.g. "notify me of all flag changes in all mailboxes"), the server 281 Internet-draft August 2008 283 MAY refuse the command with a tagged NO [NOTIFICATIONOVERFLOW] 284 response. 286 If the client requests information for events of an unsupported 287 type, the server MUST refuse the command with a tagged NO response 288 (not a BAD). This response SHOULD contain the BADEVENT response 289 code, which MUST list names of all events supported by the server. 291 Here's an example: 293 S: * OK [CAPABILITY IMAP4REV1 NOTIFY] 294 C: a login bob alice 295 S: a OK Password matched 296 C: b notify set status (selected MessageNew (uid 297 body.peek[header.fields (from to subject)]) MessageExpunge) 298 (subtree Lists MessageNew) 299 S: * STATUS Lists/Lemonade (UIDVALIDITY 4 UIDNEXT 9999 MESSAGES 300 500) 301 S: [...] 302 S: * STATUS Lists/Im2000 (UIDVALIDITY 901 UIDNEXT 1 MESSAGES 0) 303 S: b OK done 304 C: c select inbox 305 S: [...] (the usual 7-8 responses to SELECT) 306 S: c OK INBOX selected 307 (Time passes. A new message is delivered to mailbox 308 Lists/Lemonade.) 309 S: * STATUS Lists/Lemonade (UIDVALIDITY 4 UIDNEXT 10000 310 MESSAGES 501) 311 (Time passes. A new message is delivered to inbox.) 312 S: * 127 FETCH (UID 127001 BODY[HEADER.FIELDS (From To 313 Subject)] {75} 314 S: Subject: Re: good morning 315 S: From: alice@example.org 316 S: To: bob@example.org 317 S: 318 S: ) 319 (Time passes. The client decides it wants to know about 320 one more mailbox. As the client already knows 321 necessary STATUS information for all mailboxes below 322 the Lists mailbox and because "notify set status" would 323 cause STATUS responses for *all* mailboxes specified in 324 the NOTIFY command, including the ones for which the 325 client already knows STATUS information, the client 326 issues explicit STATUS request for the mailbox to be 327 added to the watch list, followed by the NOTIFY SET 328 without the STATUS parameter.) 329 C: d STATUS misc (UIDVALIDITY UIDNEXT MESSAGES) 330 S: * STATUS misc (UIDVALIDITY 1 UIDNEXT 999) 332 Internet-draft August 2008 334 S: d STATUS completed 335 C: e notify set (selected MessageNew (uid 336 body.peek[header.fields (from to subject)]) MessageExpunge) 337 (subtree Lists MessageNew) (mailboxes misc MessageNew) 338 S: e OK done 340 4. Interaction with the IDLE Command 342 If IDLE (as well as this extension) is supported, while processing 343 IDLE the server MUST send the same events as instructed by the 344 client using the NOTIFY command. 346 NOTIFY makes IDLE unnecessary for some clients. If a client does not 347 use MSNs and '*' in commands, it can request MessageExpunge and 348 MessageNew for the selected mailbox using the NOTIFY command instead 349 of entering the IDLE mode. 351 A client that uses MSNs and '*' in commands can still use the NOTIFY 352 command if it specifies the SELECTED-DELAYED mailbox specifier in 353 the NOTIFY command. 355 5. Event Types 357 Only some of the events in [MSGEVENT] can be expressed in IMAP, and 358 for some of them there are several possible ways to express the 359 event. 361 This section specifies the events which an IMAP server can notify an 362 IMAP client, and how. 364 The server SHOULD omit notifying the client if the event is caused 365 by this client. For example, if the client issues CREATE and has 366 requested MailboxName event that would cover the newly created 367 mailbox, the server SHOULD NOT notify the client of the MailboxName 368 change. 370 All event types described in this document require the 'l' and 'r' 371 rights (see [RFC4314]) on all observed mailboxes. Servers that 372 don't implement [RFC4314] should map the above rights to their 373 access control model. 375 If FlagChange and/or AnnotationChange event is specified, MessageNew 376 and MessageExpunge MUST also be specified by the client. Otherwise 377 the server MUST respond with the tagged BAD response. 379 If one of MessageNew or MessageExpunge is specified, the both events 381 Internet-draft August 2008 383 MUST be specified. Otherwise the server MUST respond with the 384 tagged BAD response. 386 The client can instruct the server not to send an event by omitting 387 the necessary event from the list of events specified in NOTIFY SET, 388 by using NONE event specifier in the NOTIFY SET or by using NOTIFY 389 NONE. In particular NOTIFY SET ... NONE can be used as a snapshot 390 facility by clients. 392 5.1. FlagChange and AnnotationChange 394 If the flag and/or message annotation change happens in the selected 395 mailbox, the server MUST notify the client by sending an unsolicited 396 FETCH response, which MUST include UID and FLAGS/ANNOTATION FETCH 397 data items. It MAY also send new FLAGS and/or OK [PERMANENTFLAGS 398 ...] responses. 400 If a search context is in effect as specified in [CONTEXT], an 401 ESEARCH ADDTO or ESEARCH REMOVEFROM will also be generated, if 402 appropriate. In this case, the FETCH response MUST precede the 403 ESEARCH response. 405 If the change happens in another mailbox, then the server responds 406 with a STATUS response. The exact content of the STATUS response 407 depends on various factors. If CONDSTORE [RFC4551] and/or QRESYNC 408 [QRESYNC] is enabled by the client, then the server sends a STATUS 409 response that includes at least HIGHESTMODSEQ and UIDVALIDITY status 410 data items. If the number of messages with the \Seen flag changes, 411 the server MAY also include the UNSEEN data item in the STATUS 412 response. If CONDSTORE/QRESYNC is not enabled by the client and the 413 server choses not to include the UNSEEN, the server does not notify 414 the client. When this event is requested the server MUST notify the 415 client about mailbox UIDVALIDITY changes. This is done by sending a 416 STATUS response that includes UIDVALIDITY. 418 FlagChange covers the MessageRead, MessageTrash, FlagsSet and 419 FlagsClear events in [MSGEVENT]. 421 Example in the selected mailbox: 422 S: * 99 FETCH (UID 9999 FLAGS ($Junk)) 424 And in another mailbox, with CONDSTORE in use: 425 S: * STATUS Lists/Lemonade (HIGHESTMODSEQ 65666665 UIDVALIDITY 426 101) 428 5.2. MessageNew 430 Internet-draft August 2008 432 This covers both MessageNew and MessageAppend in [MSGEVENT]. 434 If the new/appended message is in the selected mailbox, the server 435 notifies the client by sending an unsolicited EXISTS response, 436 followed by an unsolicited FETCH response containing the information 437 requested by the client. A FETCH response SHOULD NOT be generated 438 for a new message created by the client on this particular 439 connection, for instance as the result of an APPEND or COPY command 440 to the selected mailbox performed by the client itself. The server 441 MAY also send a RECENT response, if the server marks the message as 442 \Recent. 444 Note that a single EXISTS response can be returned for multiple 445 MessageAppend/MessageNew events. 447 If a search context is in effect as specified in [CONTEXT], an 448 ESEARCH ADDTO will also be generated, if appropriate. In this case, 449 the EXISTS response MUST precede the ESEARCH response. Both the 450 NOTIFY command and the SEARCH and SORT commands (see Section 7) can 451 specify attributes to be returned for new messages. These 452 attributes SHOULD be combined into a single FETCH response. The 453 server SHOULD avoid sending duplicate data. The FETCH response(s) 454 MUST follow any ESEARCH ADDTO responses. 456 If the new/appended message is in another mailbox, the server sends 457 an unsolicited STATUS (UIDNEXT MESSAGES) response for the relevant 458 mailbox. If the CONDSTORE extension [RFC4551] and/or the QRESYNC 459 extension [QRESYNC] is enabled, the HIGHESTMODSEQ status data item 460 MUST be included in the STATUS response. 462 The client SHOULD NOT use FETCH attributes that implicitly set the 463 \seen flag, or that presuppose the existence of a given bodypart. 464 UID, MODSEQ, FLAGS, ENVELOPE, BODY.PEEK[HEADER.FIELDS... and 465 BODY/BODYSTRUCTURE may be the most useful attributes. 467 Note that if a client asks to be notified of MessageNew events with 468 the SELECTED mailbox specifier, the number of messages can increase 469 at any time, and therefore the client cannot refer to a specific 470 message using the MSN/UID '*'. 472 Example in the selected mailbox: 473 S: * 444 EXISTS 474 S: * 444 FETCH (UID 9999) 476 And in another mailbox, without CONDSTORE enabled: 477 S: * STATUS Lists/Lemonade (UIDNEXT 10002 MESSAGES 503) 479 Internet-draft August 2008 481 5.3. MessageExpunge 483 If the expunged message(s) is/are in the selected mailbox, the 484 server notifies the client using EXPUNGE (or VANISHED, if [QRESYNC] 485 is supported by the server and enabled by the client). 487 If a search context is in effect as specified in [CONTEXT], an 488 ESEARCH REMOVEFROM will also be generated, if appropriate. 490 If the expunged message(s) is/are in another mailbox, the server 491 sends an unsolicited STATUS (UIDNEXT MESSAGES) response for the 492 relevant mailbox. If the QRESYNC [QRESYNC] extension is enabled, the 493 HIGHESTMODSEQ data item MUST be included in the STATUS response as 494 well. 496 Note that if a client requests MessageExpunge with the SELECTED 497 mailbox specifier, the meaning of a MSN can change at any time, so 498 the client cannot use MSNs in commands anymore. For example, such a 499 client cannot use FETCH, but it has to use UID FETCH. The meaning of 500 '*' can also change when messages are added or expunged. A client 501 wishing to keep using MSNs can either use the SELECTED-DELAYED 502 mailbox specifier, or can avoid using the MessageExpunge event 503 entirely. 505 The MessageExpunge notification covers both MessageExpunge and 506 MessageExpire events from [MSGEVENT]. 508 Example in the selected mailbox, without QRESYNC: 509 S: * 444 EXPUNGE 510 The same example in the selected mailbox, with QRESYNC: 511 S: * VANISHED 5444 512 And in another mailbox, when QRESYNC is not enabled: 513 S: * STATUS misc (UIDNEXT 999 MESSAGES 554) 515 5.4. MailboxName 517 These notifications are sent if an affected mailbox name was created 518 (with CREATE), deleted (with DELETE) or renamed (with RENAME). For 519 a server that implements [RFC4314] granting or revocation of the 'l' 520 right to the current user on the affected mailbox MUST be considered 521 mailbox creation/deletion respectively. If a mailbox is created or 522 deleted, the mailbox itself and its direct parent (whether it is an 523 existing mailbox or not) are considered to be affected. 525 The server notifies the client by sending an unsolicited LIST 526 response for each affected mailbox name. If, after the event, the 527 mailbox name does not refer to a mailbox accessible to the client, 529 Internet-draft August 2008 531 the \Nonexistent flag MUST be included. 533 For each LISTable mailbox renamed, the server sends an extended LIST 534 response [LISTEXT] for the new mailbox name, containing the OLDNAME 535 extended data item with the old mailbox name. When a mailbox is 536 renamed, its children are renamed too. No additional MailboxName 537 events are sent for children in this case. When INBOX is renamed, a 538 new INBOX is assumed to be created. No MailboxName event is sent 539 for INBOX in this case. 541 If the server automatically subscribes a mailbox when it is created 542 or renamed, then the unsolicited LIST response for each affected 543 subscribed mailbox name MUST include the \Subscribed attribute (see 544 [LISTEXT]). The server SHOULD also include 545 \HasChildren/\HasNoChildren attributes [LISTEXT] as appropriate. 547 Example of a newly created mailbox (or granting of the 'l' right on 548 the mailbox): 549 S: * LIST () "/" "NewMailbox" 551 And a deleted mailbox (or revocation of the 'l' right on the 552 mailbox): 553 S: * LIST (\NonExistent) "." "INBOX.DeletedMailbox" 555 Example of a renamed mailbox: 556 S: * LIST () "/" "NewMailbox" ("OLDNAME" ("OldMailbox")) 558 5.5. SubscriptionChange 560 The server notifies the client by sending an unsolicited LIST 561 responses for each affected mailbox name. If and only if the mailbox 562 is subscribed after the event, the \Subscribed attribute (see 563 [LISTEXT]) is included. Note that in the LIST response, all mailbox 564 attributes MUST be accurately computed (this differs from the 565 behavior of the LSUB command). 567 Example: 568 S: * LIST (\Subscribed) "/" "SubscribedMailbox" 570 5.6. MailboxMetadataChange 572 Support for this event type is OPTIONAL, unless the METADATA 573 extension [METADATA] is also supported by the server, in which case 574 support for this event type is REQUIRED. 576 The server sends an unsolicited METADATA response (as per Section 578 Internet-draft August 2008 580 4.4.2 of [METADATA]). If possible, only the changed metadata SHOULD 581 be included, but if the server can't detect a change to a single 582 metadata item, it MAY include all metadata items set on the mailbox. 584 Example: 585 S: * METADATA "INBOX" /public/comment 587 5.7. ServerMetadataChange 589 Support for this event type is OPTIONAL, unless the METADATA or the 590 METADATA-SERVER extension [METADATA] is also supported by the 591 server, in which case support for this event type is REQUIRED. 593 The server sends an unsolicited METADATA response (as per Section 594 4.4.2 of [METADATA]). Only the names of changed metadata entries 595 SHOULD be returned in such METADATA responses. 597 Example: 598 S: * METADATA "" /public/comment 600 5.8. Notification Overflow 602 If the server is unable or unwilling to deliver as many 603 notifications as it is being asked to, it may disable notifications 604 for some or all clients. It MUST notify these clients by sending an 605 untagged "OK [NOTIFICATIONOVERFLOW]" response and behave as if a 606 NOTIFY NONE command had just been received. 608 Example: 609 S: * OK [NOTIFICATIONOVERFLOW] ...A comment can go here... 611 5.9. ACL Changes 613 Even if NOTIFY succeeds, it is still possible to lose access to the 614 mailboxes monitoried at a later time. If this happens, the server 615 MUST stop monitoring these mailboxes. If access is later granted, 616 the server MUST restart event monitoring. 618 The server SHOULD return the LIST response with the \NoAccess name 619 attribute if and when the mailbox loses the 'l' right. Simalarly, 620 the server SHOULD return the LIST response with no \NoAccess name 621 attribute, if the mailbox was previously reported as having 622 \NoAccess, and later on the 'l' right is granted. 624 Internet-draft August 2008 626 6. Mailbox Specification 628 Mailboxes to be monitored can be specified in several different 629 ways. 631 Only 'SELECTED' and 'SELECTED-DELAYED' (section 6.1) match the 632 currently selected mailbox. All other mailbox specifications affect 633 other (non-selected) mailboxes. 635 Note that multiple s can apply to the same mailbox. 636 The following example demonstrates this. In this example, 637 MessageNew and MessageExpunge events are reported for INBOX due to 638 the first . SubscriptionChange event will also be 639 reported for INBOX due to the second . 641 C: a notify set (mailboxes INBOX (Messagenew messageExpunge)) 642 (personal (SubscriptionChange)) 644 A typical client that supports the NOTIFY extension would ask for 645 events on the selected mailbox and some named mailboxes. 647 In the next example the client asks for FlagChange events for all 648 personal mailboxes except the currently selected mailbox. This is 649 different from the previous example, because SELECTED overrides all 650 other message event definitions for the currently selected mailbox 651 (see Section 3.1). 653 C: a notify set (selected (Messagenew (uid flags) 654 messageExpunge)) (personal (MessageNew FlagChange 655 MessageExpunge)) 657 6.1. Mailbox specifiers affecting the currently selected mailbox 659 Only one of the mailbox specifiers affecting the currently selected 660 mailbox can be specified in any NOTIFY command. The two such mailbox 661 specifiers (SELECTED and SELECTED-DELAYED) are described below. 663 Both refer to the mailbox selected using either SELECT or EXAMINE 664 (see [RFC3501] section 6.3.1 and 6.3.2). When the IMAP connection is 665 not in the selected state, such mailbox specifiers don't refer to 666 any mailbox. 668 The mailbox specifiers only apply to s. It is an 669 error to specify other types of events with either the SELECTED or 670 the SELECTED-DELAYED selector. 672 Internet-draft August 2008 674 6.1.1. Selected 676 The SELECTED mailbox specifier requires the server to send immediate 677 notifications for the currently selected mailbox about all specified 678 s. 680 6.1.2 Selected-delayed 682 The SELECTED-DELAYED mailbox specifier requires the server to delay 683 MessageExpunge event until the client issues a command that allows 684 returning information about expunged messages (see Section 7.4.1 of 685 [RFC3501] for more details), for example till a NOOP or an IDLE 686 command. When SELECTED-DELAYED is specified the server MAY also 687 delay returning other s until the client issues a 688 command specified above, or it MAY return them immediately. 690 6.2. Personal 692 Personal refers to all selectable mailboxes in the user's personal 693 namespace(s), as defined in [NAMESPACE]. 695 6.3. Inboxes 697 Inboxes refers to all selectable mailboxes in the user's personal 698 namespace(s) to which messages may be delivered by an MDA (see 699 [EMAIL-ARCH], particularly section 4.3.3). 701 If the IMAP server cannot easily compute this set, it MUST treat 702 "inboxes" as equivalent to "personal". 704 6.4 Subscribed 706 Subscribed refers to all mailboxes subscribed by the user. 708 If the subscription list changes, the server MUST reevaluate the 709 list. 711 6.5 Subtree 713 Subtree is followed by a mailbox name or list of mailbox names. A 714 subtree refers to all selectable mailboxes which are subordinate to 715 the specified mailbox plus the mailbox itself. 717 Internet-draft August 2008 719 6.6 Mailboxes 721 Mailboxes is followed by a mailbox name or a list of mailbox names. 722 The server MUST NOT do wildcard expansion. This means there is no 723 special treatment for the LIST wildcard characters ('*' and '%') if 724 they are present in mailbox names. 726 7. Extension to SEARCH and SORT commands 728 If the server that support the NOTIFY extension also supports 729 CONTEXT=SEARCH and/or CONTEXT=SORT as defined in [CONTEXT], the 730 UPDATE return option is extended so that a client can request that 731 FETCH attributes be returned when a new message is added to the 732 context result set. 734 For example: 735 C: a00 SEARCH RETURN (COUNT UPDATE (UID BODY[HEADER.FIELDS (TO 736 FROM SUBJECT)])) FROM "boss" 737 S: * ESEARCH (TAG "a00") (COUNT 17) 738 S: a00 OK 739 [...a new message is delivered...] 740 S: * EXISTS 93 741 S: * 93 FETCH (UID 127001 BODY[HEADER.FIELDS (FROM TO 742 SUBJECT)] {76} 743 S: Subject: Re: good morning 744 S: From: myboss@example.org 745 S: To: bob@example.org 746 S: 747 S: ) 748 S: * ESEARCH (TAG "a00") ADDTO (0 93) 750 Note that the EXISTS response MUST precede any FETCH responses, and 751 together they MUST precede the ESEARCH response. 753 No untagged FETCH response SHOULD be returned if a message becomes a 754 member of UPDATE SEARCH due to flag or annotation changes. 756 8. Formal Syntax 758 The following syntax specification uses the Augmented Backus-Naur 759 Form (ABNF) notation as specified in [RFC5234]. [RFC3501] defines 760 the non-terminals "capability", "command-auth", "mailbox", "mailbox- 761 data", "resp-text-code" and "search-key". The "modifier-update" non- 762 terminal is defined in [CONTEXT]. "mbx-list-oflag" is defined in 763 [RFC3501] and updated by [LISTEXT]. 765 Internet-draft August 2008 767 Except as noted otherwise, all alphabetic characters are case- 768 insensitive. The use of upper or lower case characters to define 769 token strings is for editorial clarity only. Implementations MUST 770 accept these strings in a case-insensitive fashion. For example 771 non-terminal value "SELECTED" must be 772 treated in the same way as "Selected" or "selected". 774 capability =/ "X-DRAFT-W06-NOTIFY" 775 ;; [[Note to RFC Editor: change the capability 776 ;; name before publication]] 778 command-auth =/ notify 780 notify = "NOTIFY" SP 781 (notify-set / notify-none) 783 notify-set = "SET" [status-indicator] SP event-groups 784 ; Replace registered notification events 785 ; with the specified list of events 787 notify-none = "NONE" 788 ; Cancel all registered notification 789 ; events. The client is not interested 790 ; in receiving any events. 792 status-indicator = SP "STATUS" 794 one-or-more-mailbox = mailbox / many-mailboxes 796 many-mailboxes = "(" mailbox *(SP mailbox) ")" 798 event-groups = event-group *(SP event-group) 800 event-group = "(" filter-mailboxes SP events ")" 801 ;; Only s are allowed in 802 ;; when is used. 804 filter-mailboxes = filter-mailboxes-selected / 805 filter-mailboxes-other 807 filter-mailboxes-other = "inboxes" / "personal" / "subscribed" / 808 ( "subtree" SP one-or-more-mailbox ) / 809 ( "mailboxes" SP one-or-more-mailbox ) 811 filter-mailboxes-selected = "selected" / "selected-delayed" 812 ;; Apply to the currently selected mailbox only. 813 ;; Only one of them can be specified in a NOTIFY 814 ;; command. 816 Internet-draft August 2008 818 events = ( "(" event *(SP event) ")" ) / "NONE" 819 ;; As in [MSGEVENT]. 820 ;; "NONE" means that the client does not wish 821 ;; to receive any events for the specified 822 ;; mailboxes. 824 event = message-event / 825 mailbox-event / user-event / event-ext 827 message-event = ( "MessageNew" [SP 828 "(" fetch-att *(SP fetch-att) ")" ] ) 829 / "MessageExpunge" 830 / "FlagChange" 831 / "AnnotationChange" 832 ;; "MessageNew" includes "MessageAppend" from 833 ;; [MSGEVENT]. "FlagChange" is any of 834 ;; "MessageRead", "MessageTrash", "FlagsSet", 835 ;; "FlagsClear" [MSGEVENT]. "MessageExpunge" 836 ;; includes "MessageExpire" [MSGEVENT]. 837 ;; MessageNew and MessageExpunge MUST always 838 ;; be specified together. If FlagChange is 839 ;; specified, then MessageNew and MessageExpunge 840 ;; MUST be specified as well. 841 ;; The fett-att list may only be present for the 842 ;; SELECTED/SELECTED-DELAYED mailbox filter 843 ;; (). 845 mailbox-event = "MailboxName" / 846 "SubscriptionChange" / "MailboxMetadataChange" 847 ; "SubscriptionChange" includes 848 ; MailboxSubscribe and MailboxUnSubscribe. 849 ; "MailboxName" includes MailboxCreate, 850 ; "MailboxDelete" and "MailboxRename". 852 user-event = "ServerMetadataChange" 854 event-ext = atom 855 ;; For future extensions 857 oldname-extended-item = "OLDNAME" SP "(" mailbox ")" 858 ;; Extended data item (mbox-list-extended-item) 859 ;; returned in a LIST response when a mailbox is 860 ;; renamed. 861 ;; Note 1: the OLDNAME tag can be returned 862 ;; with and without surrounding quotes, as per 863 ;; mbox-list-extended-item-tag production. 865 resp-text-code =/ "NOTIFICATIONOVERFLOW" / 867 Internet-draft August 2008 869 unsupported-events-code 871 message-event-name = "MessageNew" / 872 "MessageExpunge" / "FlagChange" / 873 "AnnotationChange" 875 event-name = message-event-name / mailbox-event / 876 user-event 878 unsupported-events-code = "BADEVENT" 879 SP "(" event-name *(SP event-name) ")" 881 modifier-update = "UPDATE" 882 [ "(" fetch-att *(SP fetch-att) ")" ] 884 mbx-list-oflag =/ "\NoAccess" 886 9. Security considerations 888 It is very easy for a client to deny itself service using NOTIFY: 889 Asking for all events on all mailboxes may work on a small server, 890 but with a big server can swamp the client's network connection or 891 processing capability. In the worst case, the server's processing 892 could also degrade the service it offers to other clients. 894 Server authors should be aware that if a client issues requests and 895 does not listen to the resulting responses, the TCP window can 896 easily fill up, and a careless server might block. This problem 897 exists in plain IMAP, however this extension magnifies the problem. 899 This extensions makes it possible to retrieve messages immediately 900 when they are added to the mailbox. This makes it wholly impractical 901 to delete sensitive messages using programs like imapfilter. Using 902 [SIEVE] or similar is much better. 904 10. IANA considerations 906 The IANA is requested to add NOTIFY to the list of IMAP extensions, 907 http://www.iana.org/assignments/imap4-capabilities. 909 10.1. Initial LIST-EXTENDED extended data item registrations 911 It is requested that the following entry be added to the IMAP4 List 912 Extended registry [LISTEXT]: 914 Internet-draft August 2008 916 To: iana@iana.org Subject: Registration of OLDNAME LIST-EXTENDED 917 extended data item 919 LIST-EXTENDED extended data item tag: OLDNAME 921 LIST-EXTENDED extended data item description: The OLDNAME extended 922 data item describes the old mailbox name for the mailbox identified 923 by the LIST response. 925 Which LIST-EXTENDED option(s) (and their types) causes this extended 926 data item to be returned (if any): none 928 Published specification : RFC XXXX, Section 5.4. 930 Security considerations: none 932 Intended usage: COMMON 934 Person and email address to contact for further information: 935 Alexey Melnikov 937 Owner/Change controller: iesg@ietf.org 939 11. Acknowedgements 941 The authors gratefully acknowledge the help of Peter Coates, Dave 942 Cridland, Mark Crispin, Cyrus Daboo, Abhijit Menon-Sen, Timo 943 Sirainen and Eric Burger. In particular, Peter Coates contributed 944 lots of text and useful suggestions to this document. 946 Various examples are copied from other RFCs. 948 This document builds on one published and two unpublished drafts by 949 the same authors. 951 12. Normative References 953 [RFC2119] Bradner, "Key words for use in RFCs to Indicate 954 Requirement Levels", RFC 2119, Harvard University, March 955 1997. 957 [RFC2177] Leiba, "IMAP4 IDLE Command", RFC 2177, IBM, June 1997. 959 [RFC3501] Crispin, "Internet Message Access Protocol - Version 960 4rev1", RFC 3501, University of Washington, June 2003. 962 Internet-draft August 2008 964 [RFC5234] Crocker, Overell, "Augmented BNF for Syntax 965 Specifications: ABNF", RFC 5234, Brandenburg 966 Internetworking, THUS plc, January 2008. 968 [RFC4314] Melnikov, "IMAP4 Access Control List (ACL) Extension", 969 RFC 4314, December 2005. 971 [RFC4466] Melnikov, Daboo, "Collected Extensions to IMAP4 ABNF", 972 RFC 4466, Isode Ltd., April 2006. 974 [RFC4551] Melnikov, Hole, "IMAP Extension for Conditional STORE 975 Operation or Quick Flag Changes Resynchronization", RFC 976 4551, Isode Ltd., June 2006. 978 [QRESYNC] Melnikov, A., Cridland, D. and C. Wilson, "IMAP4 979 Extensions for Quick Mailbox Resynchronization", RFC 980 5162, March 2008. 982 [LISTEXT] Leiba, Melnikov, "IMAP4 List Command Extensions", RFC 983 5258, June 2008. 985 [METADATA] Daboo, "IMAP METADATA Extension", draft-daboo-imap- 986 annotatemore-14 (work in progress), Apple Computer, Inc., 987 July 2008. 989 [MSGEVENT] Newman, C. and R. Gellens, "Internet Message Store 990 Events", draft-ietf-lemonade-msgevent-06.txt (work in 991 progress), July 2008. 993 [CONTEXT] Cridland, D. and C. King, "Contexts for IMAP4", RFC 5267, 994 July 2008. 996 [NAMESPACE] Gahrns, M. and C. Newman, "IMAP4 Namespace", RFC 2342, 997 May 1998. 999 13. Informative References 1001 [SIEVE] Guenther, P. and T. Showalter, "Sieve: A Mail Filtering 1002 Language", RFC 5228, January 2008. 1004 [EMAIL-ARCH] Crocker, "Internet Mail Architecture", draft-crocker- 1005 email-arch-10 (work in progress), February 2008. 1007 Internet-draft August 2008 1009 14. Authors' Addresses 1011 Curtis King 1012 Isode Ltd 1013 5 Castle Business Village 1014 36 Station Road 1015 Hampton, Middlesex TW12 2BX 1016 UK 1018 Email: Curtis.King@isode.com 1020 Alexey Melnikov 1021 Isode Ltd 1022 5 Castle Business Village 1023 36 Station Road 1024 Hampton, Middlesex TW12 2BX 1025 UK 1027 Email: Alexey.Melnikov@isode.com 1029 Arnt Gulbrandsen 1030 Oryx Mail Systems GmbH 1031 Schweppermannstr. 8 1032 D-81671 Muenchen 1033 Germany 1035 Email: arnt@oryx.com 1037 Internet-draft August 2008 1039 Intellectual Property Statement 1041 The IETF takes no position regarding the validity or scope of any 1042 Intellectual Property Rights or other rights that might be claimed 1043 to pertain to the implementation or use of the technology described 1044 in this document or the extent to which any license under such 1045 rights might or might not be available; nor does it represent that 1046 it has made any independent effort to identify any such rights. 1047 Information on the procedures with respect to rights in RFC 1048 documents can be found in BCP 78 and BCP 79. 1050 Copies of IPR disclosures made to the IETF Secretariat and any 1051 assurances of licenses to be made available, or the result of an 1052 attempt made to obtain a general license or permission for the use 1053 of such proprietary rights by implementers or users of this 1054 specification can be obtained from the IETF on-line IPR repository 1055 at http://www.ietf.org/ipr. 1057 The IETF invites any interested party to bring to its attention any 1058 copyrights, patents or patent applications, or other proprietary 1059 rights that may cover technology that may be required to implement 1060 this standard. Please address the information to the IETF at 1061 ietf-ipr@ietf.org. 1063 Full Copyright Statement 1065 Copyright (C) The IETF Trust (2008). This document is subject to 1066 the rights, licenses and restrictions contained in BCP 78, and 1067 except as set forth therein, the authors retain all their rights. 1069 This document and the information contained herein are provided on 1070 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 1071 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 1072 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 1073 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 1074 WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE 1075 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 1076 FOR A PARTICULAR PURPOSE. 1078 Acknowledgment 1080 Funding for the RFC Editor function is currently provided by the 1081 Internet Society.