Network Working Group Curtis King Internet-Draft Alexey Melnikov Intended Status: Proposed Standard Isode Ltd. Arnt Gulbrandsen Oryx Mail Systems GmbH February 25, 2008 The IMAP NOTIFY Extension draft-ietf-lemonade-imap-notify-04.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet- Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft expires in July 2008. Copyright Notice Copyright (C) The IETF Trust (2008). Abstract This document defines an IMAP extension which allows a client to request specific kinds of unsolicited notifications for specified mailboxes, such as messages being added to or deleted from mailboxes. King, et al. Expires August 2008 [Page 1] Internet-draft February 2008 [[Add Updates: RFC-CONTEXT to the headers]] 1. Conventions Used in This Document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Formal syntax is defined by [RFC5234] as extended by [RFC3501] and [RFC4466]. The acronym MSN stands for Message Sequence Numbers (see Section 2.3.1.2 of [RFC3501]). Example lines prefaced by "C:" are sent by the client and ones prefaced by "S:" by the server. "[...]" means elision. 2. Overview and rationale The IDLE command (defined in [RFC2177]) provides a way for the client to go into a mode where the IMAP server pushes notifications about IMAP mailstore events for the selected mailbox. However, the IDLE extension doesn't restrict or control which server events can be sent, or what information the server sends in response to each event. Also, IDLE only applies to the selected mailbox, thus requiring an additional TCP connection per mailbox. This document defines an IMAP extension that allows clients to express their preferences about unsolicited events generated by the server. The extension allows clients to only receive events they are interested in, while servers know that they don't need to go into effort of generating certain types of untagged responses. Without the NOTIFY command defined in this document, and IMAP server will only send information about mailstore changes to the client in the following cases: - as the result of a client command (e.g. FETCH responses to a FETCH or STORE command), - unsolicited responses sent just before the end of a command (e.g. EXISTS or EXPUNGE) as the result of changes in other sessions, and - during an IDLE command. The NOTIFY command extends what information may be returned in those last two cases, and also permits and requires the server to send information about updates between command. The NOTIFY command also King, et al. Expires August 2008 [Page 2] Internet-draft February 2008 allows for the client to extend what information is sent unsolicited about the selected mailbox, and to request some update information to be sent regarding other mailboxes. For the new messages delivered to or appended to the selected mailbox, the NOTIFY command can be used to request that a set of attributes be sent to the client in an unsolicited FETCH response. This allows a client to be passive recipient of events and new mail, and be able to maintain full synchronisation without having to issue any subsequent commands except to modify the state of the mailbox on the server. Some mobile clients, however, may want mail "pushed" only for mail that matches a SEARCH pattern. To meet that need [CONTEXT] is augmented by this document to extend the UPDATE return option to specify a list of fetch-atts to be returned when a new message is delivered or appended in another session. [[Should the following be a normative subsection?]] IMAP servers which support this extension advertise the X-DRAFT-W04-NOTIFY extension. A server implementing this extension is not required to implement LIST-EXTENDED [LISTEXT], even though a NOTIFY compliant server must be able to return extended LIST responses defined in [LISTEXT]. [[RFC-Editor: Please delete the following before publication: Comments regarding this draft may be sent either to the lemonade@ietf.org mailing list or to the authors.]] 3. The NOTIFY Command Arguments: "SET" optional STATUS indicator Mailboxes to be watched Events about which to notify the client Or Arguments: "NONE" Responses: Possibly untagged STATUS responses (for SET) Result: OK - The server will notify the client as requested. NO - Unsupported notify event, NOTIFY too complex or expensive, etc. BAD - Command unknown, invalid, unsupported or unknown King, et al. Expires August 2008 [Page 3] Internet-draft February 2008 arguments. The NOTIFY command informs the server that the client listens for event notifications all the time (even when no command is in progress) and requests the server to notify it about the specified set of events. The NOTIFY command has two forms. NOTIFY NONE specifies that the client is not interested in any kind of event happening on the server. NOTIFY SET replaces the current list of interesting events with a new list of events. Until the NOTIFY command is used for the first time, the server only sends notifications while a command is being processed, and notifies the client about these events on the selected mailbox: (see section 5 for definitions): MessageNew, MessageExpunge, FlagChange. It does not notify the client about any events on other mailboxes. The effect of a successful NOTIFY command lasts until the next NOTIFY command, or until the IMAP connection is closed. A successful NOTIFY SET command MUST cause the server to immediately return any accumulated changes to the mailbox (if any), such as flag changes, new or expunged messages. This is equivalent to NOOP command being issued by the client just before the NOTIFY SET command. If the NOTIFY command enables MessageNew, MessageExpunge, AnnotationChange or FlagChange notification for a mailbox, and the client has specified the STATUS indicator parameter, then the server MUST send a STATUS response for that mailbox before NOTIFY's tagged OK. If MessageNew is enabled, the STATUS response MUST contain MESSAGES, UIDNEXT and UIDVALIDITY. If MessageExpunge is enabled, the STATUS response MUST contain MESSAGES. If either AnnotationChange or FlagChange are included, the STATUS response MUST contain UIDVALIDITY and HIGHESTMODSEQ. Absence of the STATUS indicator parameter allows the client to avoid the additional STATUS responses. This might be useful if the client has already retrieved this information before issuing the NOTIFY command. Clients are advised to limit the number of mailboxes used with NOTIFY. Particularly, if a client asks for events for all accessible mailboxes, the server may swamp the client with updates about shared mailboxes. This wastes both server and network resources. For each mailbox specified, the server verifies that the client has access using the following test: - If the name does not refer to an existing mailbox, the server MUST ignore it. - If the name refers to a mailbox which the client can't LIST, the King, et al. Expires August 2008 [Page 4] Internet-draft February 2008 server MUST ignore it. For a server that implements [RFC4314] this means that if the client that doesn't have the 'l' (lookup) right for the name, then the server MUST ignore the mailbox. This behavior prevents dislosure on potentially confidential information to clients which don't have rights to know it. - If the name refers to a mailbox which the client can LIST (e.g. it has the 'l' right from [RFC4314]), but misses another right required for processing of the specified event(s), then the server MUST respond with an untagged extended LIST response containing the \NoAccess name attribute. [[Alexey: Note, the newly defined \NoAccess doesn't mean that the client doesn't have any rights other than 'l'. The \NoAccess is only meaningful in the context of the specified NOTIFY command.]] The server SHOULD return the tagged OK response if the client has access to at least one of the mailboxes specified in the current list of interesting events. The server MAY return the tagged NO response if the client has no access to any of the specified mailboxes and no access can ever be granted in the future (e.g. the client specified an event for 'Subtree Bar/Foo', 'Bar/Foo' doesn't exist and LIST returns \Noinferiors for the parent 'Bar'). If the notification would be prohibitively expensive for the server (e.g. "notify me of all flag changes in all mailboxes"), the server MAY refuse the command with a tagged NO [NOTIFICATIONOVERFLOW] response. If the client requests information for events of an unsupported type, the server MUST refuse the command with a tagged NO response (not a BAD). This response SHOULD contain the BADEVENT response code, which MUST list names of all events supported by the server. Here's an example: S: * OK [CAPABILITY IMAP4REV1 NOTIFY] C: a login bob alice S: a OK Password matched C: b notify set status (selected MessageNew (uid body.peek[header.fields (from to subject)]) MessageExpunge) (subtree Lists MessageNew) S: * STATUS Lists/Lemonade (UIDVALIDITY 4 UIDNEXT 9999 MESSAGES 500) S: [...] S: * STATUS Lists/Im2000 (UIDVALIDITY 901 UIDNEXT 1 MESSAGES 0) S: b OK done C: c select inbox S: [...] (the usual 7-8 responses to SELECT) King, et al. Expires August 2008 [Page 5] Internet-draft February 2008 S: c OK INBOX selected (Time passes. A new message is delivered to mailbox Lists/Lemonade.) S: * STATUS Lists/Lemonade (UIDVALIDITY 4 UIDNEXT 10000 MESSAGES 501) (Time passes. A new message is delivered to inbox.) S: * 127 FETCH (UID 127001 BODY[HEADER.FIELDS (From To Subject)] {75} S: Subject: Re: good morning S: From: alice@example.org S: To: bob@example.org S: S: ) (Time passes. The client decides it wants to know about one more mailbox.) C: d notify set status (selected MessageNew (uid body.peek[header.fields (from to subject)]) MessageExpunge) (subtree Lists MessageNew) (mailboxes misc MessageNew) S: * STATUS misc (UIDVALIDITY 1 UIDNEXT 999) (This command enables notification on one mailbox and otherwise changes nothing, so one STATUS response is sent.[[AM: This is no longer correct.]]) S: d OK done 4. Interaction with the IDLE Command If IDLE (as well as this extension) is supported, while processing IDLE the server MUST send the same events as instructed by the client using the NOTIFY command. NOTIFY makes IDLE unnecessary for some clients. If a client does not use MSNs and '*' in commands, it can request MessageExpunge and MessageNew for the selected mailbox using the NOTIFY command instead of entering IDLE mode. 5. Event Types Only some of the events in [MSGEVENT] can be expressed in IMAP, and for some of them there are several possible ways to express the event. This section specifies the events which an IMAP server can notify an IMAP client, and how. The server SHOULD omit notifying the client if the event is caused by this client. For example, if the client issues CREATE and has King, et al. Expires August 2008 [Page 6] Internet-draft February 2008 requested MailboxName event that would cover the newly created mailbox, the server SHOULD NOT notify the client of the MailboxName change. All event types described in this document require the 'l' and 'r' rights (see [RFC4314]) on all observed mailboxes. Servers that don't implement [RFC4314] should map the above rights to their access control model. Note that MessageNew and MessageExpunge must be specified together. It is not possible to specify one, but not the other. If the client instructs the server not to send MessageNew and MessageExpunge for the selected mailbox, the server MUST still send EXISTS and EXPUNGE responses as required by IMAP (see [RFC3501] section 7). In other words, MessageExpunge instructs the server to notify the client immediately, and the lack of MessageExpunge instructs the server to notify the client during execution of the next command as specified in [RFC3501]. MessageNew is handled similarly by the server. 5.1. FlagChange and AnnotationChange If the flag/annotation change happens in the selected mailbox, the server MUST notify the client by sending an unsolicited FETCH response, which MUST include UID and FLAGS/ANNOTATION FETCH data items. It MAY also send new FLAGS and/or OK [PERMANENTFLAGS ...] responses. If a search context is in effect as specified in [CONTEXT], an ESEARCH ADDTO or ESEARCH REMOVEFROM will also be generated, if appropriate. [[Alexey: I don't think this is needed: In this case, the FETCH response MUST precede the ESEARCH response.]] If the change happens in another mailbox, then the response depends on whether CONDSTORE [RFC4551] is being used. If so, the server sends a STATUS (HIGHESTMODSEQ) response. Note that whenever mailbox UIDVALIDITY changes, the server MUST also include UIDVALIDITY in the STATUS response. If CONDSTORE is not used, the server does not notify the client. FlagChange covers the MessageRead, MessageTrash, FlagsSet and FlagsClear events in [MSGEVENT]. [[Open Issue: Filip Navara requested for STATUS (UNSEEN) to be sent for MessageRead. Arnt considers that unsound, since it involves processing all messages in a mailbox after an event affecting only King, et al. Expires August 2008 [Page 7] Internet-draft February 2008 one message, and since it's not reliable anyway.]] Example in the selected mailbox: S: * 99 FETCH (UID 9999 FLAGS ($Junk)) And in another, with CONDSTORE in use: S: * STATUS Lists/Lemonade (HIGHESTMODSEQ 65666665) 5.2. MessageNew This covers both MessageNew and MessageAppend in [MSGEVENT]. If the new/appended message is in the selected mailbox, the server notifies the client by sending an unsolicited EXISTS response, followed by an unsolicited FETCH response containing the information requested by the client. A FETCH response SHOULD NOT be generated for a new message created by the client on this particular connection, for instance as the result of an APPEND or COPY command to the selected mailbox performed by the client itself. The server MAY also send a RECENT response, if the server marks the message as \Recent. Note that a single EXISTS response can be returned for multiple MessageAppend/MessageNew events. If a search context is in effect as specified in [CONTEXT], an ESEARCH ADDTO will also be generated, if appropriate. In this case, the EXISTS response MUST precede the ESEARCH response. Both the NOTIFY command and the SEARCH and SORT commands (see Section 7) can specify attributes to be returned for new messages. These attributes SHOULD be combined into a single FETCH response. The server SHOULD avoid sending duplicate data. The FETCH response(s) MUST follow any ESEARCH ADDTO responses. If the new/appended message is in another mailbox, the server sends an unsolicited STATUS (UIDNEXT MESSAGES) response for the relevant mailbox. If CONDSTORE (defined in [RFC4551]) is in use, the HIGHESTMODSEQ status data item MUST be included in the STATUS response. The client SHOULD NOT use FETCH attributes that implicitly set the \seen flag, or that presuppose the existence of a given bodypart. UID, MODSEQ, FLAGS, ENVELOPE, BODY.PEEK[HEADER.FIELDS... and BODY/BODYSTRUCTURE may be the most useful attributes. Note that if a client asks to be notified of MessageNew events, the number of messages can increase at any time, and therefore the client cannot refer to a specific message using the MSN/UID '*'. King, et al. Expires August 2008 [Page 8] Internet-draft February 2008 Example in the selected mailbox: S: * 444 EXISTS S: * 444 FETCH (UID 9999) And in another, without CONDSTORE: S: * STATUS Lists/Lemonade (UIDNEXT 10002 MESSAGES 503) 5.3. MessageExpunge If the expunged message(s) is/are in the selected mailbox, the server notifies the client using EXPUNGE (or VANISHED, if [QRESYNC] is being used). If a search context is in effect as specified in [CONTEXT], an ESEARCH REMOVEFROM will also be generated, if appropriate. If the expunged message(s) is/are in another mailbox, the server sends an unsolicited STATUS (UIDNEXT MESSAGES) response for the relevant mailbox. If CONDSTORE is being used, HIGHESTMODSEQ MUST be included in the STATUS response. Note that if a client requests MessageExpunge, the meaning of a MSN can change at any time, so the client cannot use MSNs in commands anymore. For example, such a client cannot use FETCH, but it has to use UID FETCH. The meaning of '*' can also change when messages are added or expunged. A client wishing to keep using MSNs MUST NOT request the MessageExpunge event. The MessageExpunge notification covers both MessageExpunge and MessageExpire events from [MSGEVENT]. Example in the selected mailbox, without QRESYNC: S: * 444 EXPUNGE The same example in the selected mailbox, with QRESYNC: S: * VANISHED 5444 And in another: S: * STATUS misc (UIDNEXT 999 MESSAGES 554) 5.4. MailboxName These notifications are sent if an affected mailbox name was created (with CREATE), deleted (with DELETE) or renamed (with RENAME). If a mailbox is created or deleted, the mailbox itself and its parent are considered to be affected. The server notifies the client by sending an unsolicited LIST King, et al. Expires August 2008 [Page 9] Internet-draft February 2008 response for each affected mailbox name. If the mailbox name does not refer to a mailbox after the event, the \Nonexistent flag MUST be included. For each selectable [[Alexey: is "selectable" important?]] mailbox renamed, the server sends an extended LIST response [LISTEXT] for the new mailbox name, containing the OLDNAME extended data item with the old mailbox name. When a mailbox is renamed, its children are renamed too. No additional MailboxName events are sent for children in this case. When INBOX is renamed, a new INBOX is assumed to be created. No MailboxName event must be sent for INBOX in this case. Example of a newly created mailbox: S: * LIST () "/" "NewMailbox" And a deleted mailbox: S: * LIST (\NonExistent) "/" "INBOX.DeletedMailbox" Example of a renamed mailbox: S: * LIST () "/" "NewMailbox" ("OLDNAME" ("OldMailbox")) 5.5. SubscriptionChange The server notifies the client by sending an unsolicited LIST responses for each affected mailbox name. If and only if the mailbox is subscribed after the event, the \Subscribed attribute (see [LISTEXT]) is included. Example: S: * LIST (\Subscribed) "/" "SubscribedMailbox" 5.6. MailboxMetadataChange The server sends an unsolicited LIST response including METADATA (as per Section 4.3.1 of [METADATA]). If possible, only the changed metadata should be included, but if necessary, all metadata must be included. Example: S: * LIST "/" "INBOX" (METADATA (/comment)) 5.7. ServerMetadataChange The server sends an unsolicited METADATA response (as per Section 4.5.2 of [METADATA]). Only the names of changed metadata entries King, et al. Expires August 2008 [Page 10] Internet-draft February 2008 SHOULD be returned in such METADATA responses. Example: S: * METADATA (/comment) 5.8. Notification Overflow If the server is unable or unwilling to deliver as many notifications as it is being asked to, it may disable notifications for some or all clients. It MUST notify these clients by sending an untagged "OK [NOTIFICATIONOVERFLOW]" response and behave as if a NOTIFY NONE command had just been received. Example: S: * OK [NOTIFICATIONOVERFLOW] ...A comment can go here... 5.9. ACL Changes Even if NOTIFY succeeds, it is still possible to loose access to the mailboxes monitoried at a later time. If this happens, the server MUST silently stop monitoring these mailboxes. If access is later granted, the server MUST restart event monitoring. 6. Mailbox Specification Mailboxes to be monitored can be specified in several different ways. Only 'selected' matches the currently selected mailbox. If the client specifies monitoring of the same mailbox several times, the first specification wins. A common example is asking for events on the selected mailbox and some named mailboxes. In this example, the client asks for MessageExpunge events for all personal mailboxes except the selected mailbox: C: a notify set (selected (MessageNew (uid flags) flagchange)) (personal (MessageNew FlagChange MessageExpunge)) 6.1. Selected Selected refers to the mailbox selected using either SELECT or EXAMINE (see [RFC3501] section 6.3.1 and 6.3.2). When the IMAP connection is not in selected state, selected does not refer to any King, et al. Expires August 2008 [Page 11] Internet-draft February 2008 mailbox. 6.2. Personal Personal refers to all selectable mailboxes in the user's personal namespace(s). 6.3. Inboxes Inboxes refers to all selectable mailboxes in the user's personal namespace(s) to which messages may be delivered by an MDA (see [EMAIL-ARCH], particularly section 4.3.3). If the IMAP server cannot easily compute this set, it MUST treat "inboxes" as equivalent to "personal". 6.4 Subscribed Subscribed refers to all mailboxes subscribed by the user. If the subscription list changes, the server MUST reevaluate the list. 6.5 Subtree Subtree is followed by a mailbox name or list of mailbox names. A subtree refers to all selectable mailboxes which are subordinate to the specified mailbox plus the mailbox itself. 6.6 Mailboxes Mailboxes is followed by a mailbox name or a list of mailbox names. The server MUST NOT do wildcard expansion. This means there is no special treatment for the LIST wildcard characters ('*' and '%') if they are present in mailbox names. 7. Extension to SEARCH and SORT commands If the server that support the NOTIFY extension also supports CONTEXT=SEARCH and/or CONTEXT=SORT as defined in [CONTEXT], the UPDATE return option is extended so that a client can request that FETCH attributes be returned when a new message is added to the King, et al. Expires August 2008 [Page 12] Internet-draft February 2008 context result set. For example: C: a00 SEARCH RETURN (COUNT UPDATE (UID BODY[HEADER.FIELDS (TO FROM SUBJECT)])) FROM "boss" S: * ESEARCH (TAG "a00") (COUNT 17) S: a00 OK [...a new message is delivered...] S: * EXISTS 93 S: * ESEARCH (TAG "a00") ADDTO (0 93) S: * 93 FETCH (UID 127001 BODY[HEADER.FIELDS (FROM TO SUBJECT)] {76} S: Subject: Re: good morning S: From: myboss@example.org S: To: bob@example.org S: S: ) Note that the EXISTS response MUST precede the ESEARCH response, and the FETCH response MUST follow the ESEARCH response. No untagged FETCH response SHOULD be returned if a message becomes a member of UPDATE SEARCH due to flag or annotation changes. 8. Formal Syntax The following syntax specification uses the Augmented Backus-Naur Form (ABNF) notation as specified in [RFC5234]. [RFC3501] defines the non-terminals "capability", "command-auth", "mailbox", "mailbox- data", "resp-text-code" and "search-key". The "modifier-update" non- terminal is defined in [CONTEXT]. Except as noted otherwise, all alphabetic characters are case- insensitive. The use of upper or lower case characters to define token strings is for editorial clarity only. Implementations MUST accept these strings in a case-insensitive fashion. capability =/ "X-DRAFT-W03-NOTIFY" ;; [[Note to RFC Editor: change the capability ;; name before publication]] command-auth =/ notify notify = "NOTIFY" SP (notify-set / notify-none) notify-set = "SET" [status-indicator] SP event-groups ; Replace registered notification events ; with the specified list of events [[Alexey: what about "most specific" event overriding a pattern?]] notify-none = "NONE" King, et al. Expires August 2008 [Page 13] Internet-draft February 2008 ; Cancel all registered notification ; events. The client is not interested ; in receiving any events. status-indicator = SP "STATUS" one-or-more-mailbox = mailbox / many-mailboxes many-mailboxes = "(" mailbox *(SP mailbox) ")" event-groups = event-group *(SP event-group) event-group = "(" filter-mailboxes SP events ")" filter-mailboxes = "selected" / "inboxes" / "personal" / "subscribed" / ( "subtree" SP one-or-more-mailbox ) / ( "mailboxes" SP one-or-more-mailbox ) events = ( "(" event *(SP event) ")" ) / "NONE" ;; As in [MSGEVENT]. ;; "NONE" means that the client does not wish ;; to receive any events for the specified ;; mailboxes. event = message-event / mailbox-event / user-event / event-ext message-match-criteria = "(" search-key ")" message-event = ( "MessageNew" [SP "(" fetch-att *(SP fetch-att) ")" ] ) SP "MessageExpunge" / "FlagChange" SP message-match-criteria / "AnnotationChange" SP message-match-criteria ;; "MessageNew" includes "MessageAppend" from ;; [MSGEVENT]. "FlagChange" is any of ;; "MessageRead", "MessageTrash", "FlagsSet", ;; "FlagsClear" [MSGEVENT]. "MessageExpunge" ;; includes "MessageExpire" [MSGEVENT]. mailbox-event = "MailboxName" / "SubscriptionChange" / "MailboxMetadataChange" ; "SubscriptionChange" includes ; MailboxSubscribe and MailboxUnSubscribe. ; "MailboxName" includes MailboxCreate, ; "MailboxDelete" and "MailboxRename". King, et al. Expires August 2008 [Page 14] Internet-draft February 2008 user-event = "ServerMetadataChange" event-ext = atom ;; For future extensions oldname-extended-item = "OLDNAME" SP "(" mailbox ")" ;; Extended data item (mbox-list-extended-item) ;; returned in a LIST response when a mailbox is ;; renamed. ;; Note 1: the OLDNAME tag can be returned ;; with and without surrounding quotes, as per ;; mbox-list-extended-item-tag production. resp-text-code =/ "NOTIFICATIONOVERFLOW" / unsupported-events-code message-event-name = "MessageNew" / / "MessageExpunge" / "FlagChange" / "AnnotationChange" event-name = message-event-name / mailbox-event / user-event unsupported-events-code = "BADEVENT" SP "(" event-name *(SP event-name) ")" modifier-update = "UPDATE" [ "(" fetch-att *(SP fetch-att) ")" ] 9. Security considerations It is very easy for a client to deny itself service using NOTIFY: Asking for all events on all mailboxes may work on a small server, but with a big server can swamp the client's network connection or processing capability. In the worst case, the server's processing could also degrade the service it offers to other clients. Server authors should be aware that if a client issues requests and does not listen to the resulting responses, the TCP window can easily fill up, and a careless server might block. This problem exists in plain IMAP, however this extension magnifies the problem. This extensions makes it possible to retrieve messages immediately when they are added to the mailbox. This makes it wholly impractical to delete sensitive messages using programs like imapfilter. Using [SIEVE] or similar is much better. King, et al. Expires August 2008 [Page 15] Internet-draft February 2008 10. IANA considerations The IANA is requested to add NOTIFY to the list of IMAP extensions, http://www.iana.org/assignments/imap4-capabilities. 10.1. Initial LIST-EXTENDED extended data item registrations It is requested that the following entry be added to the LIST- EXTENDED extended data item registry [LISTEXT]: To: iana@iana.org Subject: Registration of OLDNAME LIST-EXTENDED extended data item LIST-EXTENDED extended data item tag: OLDNAME LIST-EXTENDED extended data item description: The OLDNAME extended data item describes the old mailbox name for the mailbox identified by the LIST response. Which LIST-EXTENDED option(s) (and their types) causes this extended data item to be returned (if any): none Published specification : RFC XXXX, Section 5.4. Security considerations: none Intended usage: COMMON Person and email address to contact for further information: Alexey Melnikov Owner/Change controller: iesg@ietf.org 11. Acknowedgements The authors gratefully acknowledge the help of Peter Coates, Dave Cridland, Mark Crispin, Cyrus Daboo, Abhijit Menon-Sen and Eric Burger. In particular, Peter Coates contributed lots of text and useful suggestions to this document. Various examples are copied from other RFCs. This document builds on one published and two unpublished drafts by the same authors. 12. Normative References King, et al. Expires August 2008 [Page 16] Internet-draft February 2008 [RFC2119] Bradner, "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, Harvard University, March 1997. [RFC2177] Leiba, "IMAP4 IDLE Command", RFC 2177, IBM, June 1997. [RFC3501] Crispin, "Internet Message Access Protocol - Version 4rev1", RFC 3501, University of Washington, June 2003. [RFC5234] Crocker, Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 5234, Brandenburg Internetworking, THUS plc, January 2008. [RFC4314] Melnikov, "IMAP4 Access Control List (ACL) Extension", RFC 4314, December 2005. [RFC4466] Melnikov, Daboo, "Collected Extensions to IMAP4 ABNF", RFC 4466, Isode Ltd., April 2006. [RFC4551] Melnikov, Hole, "IMAP Extension for Conditional STORE Operation or Quick Flag Changes Resynchronization", RFC 4551, Isode Ltd., June 2006. [LISTEXT] Leiba, Melnikov, "IMAP4 List Command Extensions", draft- ietf-imapext-list-extensions-18 (work in progress), IBM, September 2006. [METADATA] Daboo, "IMAP METADATA Extension", draft-daboo-imap- annotatemore-12 (work in progress), Apple Computer, Inc., December 2007. [MSGEVENT] Newman, C. and R. Gellens, "Internet Message Store Events", draft-ietf-lemonade-msgevent-05.txt (work in progress), Sun, January 2008. [CONTEXT] Cridland, D. and C. King, "Contexts for IMAP4", work in progress, draft-cridland-imap-context-03.txt, Isode, June 2007. 13. Informative References [SIEVE] Guenther, P. and T. Showalter, "Sieve: A Mail Filtering Language", RFC 5228, January 2008. [QRESYNC] Melnikov, Cridland, Wilson, "IMAP4 Extensions for Quick Mailbox Resynchronization", draft-ietf-lemonade-reconnect- client-06.txt (work in progress), September 2007. King, et al. Expires August 2008 [Page 17] Internet-draft February 2008 [EMAIL-ARCH] Crocker, "Internet Mail Architecture", draft-crocker- email-arch-10 (work in progress), February 2008. 14. Authors' Addresses Curtis King Isode Ltd 5 Castle Business Village 36 Station Road Hampton, Middlesex TW12 2BX UK Email: Curtis.King@isode.com Alexey Melnikov Isode Ltd 5 Castle Business Village 36 Station Road Hampton, Middlesex TW12 2BX UK Email: Alexey.Melnikov@isode.com Arnt Gulbrandsen Oryx Mail Systems GmbH Schweppermannstr. 8 D-81671 Muenchen Germany Email: arnt@oryx.com King, et al. Expires August 2008 [Page 18] Internet-draft February 2008 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Full Copyright Statement Copyright (C) The IETF Trust (2008). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. King, et al. Expires August 2008 [Page 19]