Network Working Group Curtis King Internet-Draft Alexey Melnikov Intended Status: Proposed Standard Isode Ltd. Arnt Gulbrandsen Oryx Mail Systems GmbH April 2007 The IMAP NOTIFY Extension draft-gulbrandsen-imap-notify-05.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 October 2007. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract This document defines an IMAP extension which allows a client to request specific kinds of unsolicited notifications, such as messages being added to or deleted from mailboxes. King, et al. Expires October 2007 [Page 1] Internet-draft April 2007 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 [RFC4234] as extended by [RFC3501] and [RFC4466]. Example lines prefaced by "C:" are sent by the client and ones prefaced by "S:" by the server. "[...]" means elision. 2. Overview 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. 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. IMAP servers which support this extension advertise the X-DRAFT- I04-NOTIFY extension. Comments regarding this draft may be sent either to the lemonade@ietf.org mailing list or to the authors. 3. The NOTIFY Command 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. Until the NOTIFY command is used for the first time, the server notifies the client about the following events types on the selected mailbox (see section 5 for definitions): NewMessage, ExpungeMessage, FlagChange and (if [ANNOTATE] is supported and enabled) AnnotationChange. It does not notify the client about any events on other mailboxes. The notification about NewMessage events MUST only King, et al. Expires October 2007 [Page 2] Internet-draft April 2007 contain information about the message's UID and flags. The effect of NOTIFY lasts until the next NOTIFY command, or until the IMAP connection is closed. If the NOTIFY command enables NewMessage, ExpungeMessage, AnnotationChange or FlagChange notification for a mailbox, the server MUST send a STATUS response for that mailbox before NOTIFY's tagged OK. If NewMessage is enabled, the STATUS response MUST contain MESSAGES, UIDNEXT and UIDVALIDITY. If ExpungeMessage is enabled, the STATUS response MUST contain MESSAGES. If either AnnotationChange or FlagChange are included, the STATUS response MUST contain UIDVALIDITY and HIGHESTMODSEQ. 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 resources and network traffic, and the client may have to pay for every byte. Here's an example: S: * OK [CAPABILITY IMAP4REV1 NOTIFY] C: a login mel lem S: a OK Password matched C: b notify (inbox Lists/*) (newmessage (uid body.peek[header.fields (from to subject)]) (ALL) expungemessage (ALL)) S: * STATUS INBOX (UIDVALIDITY 1 UIDNEXT 99999 MESSAGES 5) 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 (Time passes. A new message is delivered to mailbox Lists/Lemonade.) S: * STATUS Lists/Lemonade (UIDVALIDITY 4 UIDNEXT 10000 MESSAGES 501) (Time passes. The client decides it wants to know about one more mailbox.) C: c notify (inbox Lists/* misc) (newmessage (uid body.peek[header.fields (from to subject)]) (ALL) expungemessage (ALL)) S: * STATUS misc (UIDVALIDITY 1 UIDNEXT 999) (This command enables notification on one mailbox and otherwise changes nothing, so one STATUS response is sent.) S: c OK done King, et al. Expires October 2007 [Page 3] Internet-draft April 2007 4. The IDLE Command If IDLE (as well as this extension) is supported, the server should send ExpungeMessage while processing IDLE, and otherwise send the same events as the client instructed using NOTIFY. 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 of 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 requested CreateMailbox event that would cover the newly created mailbox, the server SHOULD NOT notify the client of the CreateMailbox change. 5.1. FlagChange and AnnotationChange If the flag/annotation change happens in the selected mailbox, the server notifies the client by sending an unsolicited FETCH response. If the change happens in another mailbox, then the response depends on whether CONDSTORE [RFC4551] is supported and enabled. 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 not, the server does not notify the client. FlagChange covers the ReadMessages, TrashMessages, SetFlags and ClearFlags events in [MSGEVENT]. [[Open Issue: Filip Navara requested for STATUS (UNSEEN) to be sent for ReadMessages.]] 5.2. NewMessage This covers both NewMessage and AppendMessage in [MSGEVENT]. If the new/appended message is in the selected mailbox, the server notifies the client by sending an unsolicited FETCH response King, et al. Expires October 2007 [Page 4] Internet-draft April 2007 containing the information requested by the client. If the new/appended message is in another mailbox, the server sends an unsolicited STATUS (EXISTS) response for the relevant mailbox. If CONDSTORE (defined in [RFC4551]) is supported and enabled, HIGHESTMODSEQ should 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 NewMessage events, the number of messages can increase at any time, and therefore the client cannot refer to a specific message using the MSN/UID '*'. 5.3. ExpungeMessage If the expunged message(s) is/are in the selected mailbox, the server notifies the client using EXPUNGE (or EXPUNGED, if [QRESYNC] is supported and enabled). 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 supported and enabled, HIGHESTMODSEQ should be included in the STATUS response. [[Alexey: Is UIDNEXT needed for ExpungeMessage?]] Note that if a client requests ExpungeMessage, the meaning of an MSN can change at any time, so the client cannot use MSNs in commands any more. For example, such a client cannot use FETCH (it must only use UID FETCH). The meaning of '*' can also change when messages are added or expunged. [[Alexey: Are we allowing EXPUNGE/EXPUNGED to be sent when not allowed without this extension? Arnt: Yes.]] The ExpungeMessage notification covers both ExpungeMessage and ExpireMessage events from [MSGEVENT]. 5.4. OverQuota, UnderQuota and QuotaChange If the client has permission to perform GETQUOTA (defined in [RFC2087]), the server sends an unsolicited QUOTA response containing the new quotas. If the server does not support the QUOTA King, et al. Expires October 2007 [Page 5] Internet-draft April 2007 extension, it MUST ignore request for these three events and never send any notifications for them. These notifications are sent if the client has requested notifications for at least one affected mailbox. 5.5. CreateMailbox and DeleteMailbox The server notifies the client by sending an unsolicited LIST responses for each affected mailbox name. If the mailbox name does not refer to a mailbox after the event, the \Nonexistent flag MUST be included. These notifications are sent if the client has requested notifications for at least one affected mailbox. In the case of CreateMailbox, the mailbox itself and its parent are considered to be affected. In the case of DeleteMailbox, all deleted mailboxes and their parent(s) are considered to be affected. 5.6. RenameMailbox For each selectable mailbox renamed, the server sends a RENAMED response with the old and new name. <> When a mailbox is renamed, its children are renamed too. No additional RenameMailbox events are sent for children in such case. When INBOX is renamed, a new INBOX is assumed to be created. No CreateMailbox event must be sent for INBOX in such case. <> 5.7. 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 [LISTEXT] attribute is included. King, et al. Expires October 2007 [Page 6] Internet-draft April 2007 5.8. MailboxMetadataChange If METADATA (defined in [METADATA]) is supported and enabled (*), the server sends an unsolicited LIST response including METADATA. If possible, only the changed metadata should be included, but if necessary, all metadata must be included. If METADATA is not supported or not enabled, the server does not notify the client. (*) - Note that the METADATA extension is considered enabled once the client issues any of the following commands: SETMETADATA, GETMETADATA, extended LIST command with METADATA selection and/or return option. <> 5.9. AdminMailbox If the user has the right to perform GETACL (see [RFC4314]) after the event, the server notifies the client by sending an unsolicited ACL response with the mailbox' new rights. If the user loses the right to perform GETACL as a result of this event, the server MAY also send the ACL response. In all other cases, the server does not notify the client. 5.10. 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. [[Peter Coates asked: After the server has sent "* OK [NOTIFICATIONOVERFLOW]" is is expected no longer to send notifications? Or is the server merely telling the client that some notifications have been dropped?]] 6. Interaction with the ID Extension The ID extension defined by [RFC2971] defines a way for the client and server to identify themselves. This is meant to be for debugging King, et al. Expires October 2007 [Page 7] Internet-draft April 2007 and statistics purposes. The client can send any number of field/value pairs describing itself, and the server responds similarly. The ID field "instance" is hereby defined as a case-sensitive string containing at least 64 bits of entropy, which is specific to the client instance. If both client and server support ID, and the client opens two or more connections to the server, then it SHOULD send an ID command with a specified instance value. If the server supports both ID and NOTIFY, it MUST assume that all IMAP connections sharing instance and authorization identity [RFC3501] represent the same client. If the server would notify a client of an event via two or more connections, it MAY notify the client via only one. In the case of NewMessage it is best to send the notification on a connection where the relevant mailbox is selected, if possible. 7. Formal Syntax The following syntax specification uses the Augmented Backus-Naur Form (ABNF) notation as specified in RFC 4234. RFC 3501 defines the non-terminals "capability", "command-auth", "mailbox", "mailbox- data", "resp-text-code" and "search-key". [LISTEXT] defines the non- terminal "mbox-or-pat". 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-I05-NOTIFY" ;; [[Note to RFC Editor: change the capability ;; name before publication]] command-auth =/ notify notify = "NOTIFY" SP event-groups event-groups = event-group *(SP event-group) / "NONE" ;; "NONE" specifies that the client does not wish ;;to receive any events event-group = filter-mailboxes SP events King, et al. Expires October 2007 [Page 8] Internet-draft April 2007 filter-mailboxes = mbox-or-pat events = "(" event *(SP event) ")" / "*" ;; "*" is used to denote all events. event = message-event SP "(" search-key ")" / mailbox-event / user-event / "NONE" / event- ext ;; As in draft-ietf-lemonade-msgevent-XX.txt ;; "NONE" specifies that the client does not wish ;;to receive any events for the specified mailboxes message-event = ( "NewMessage" SP "(" fetch-att *(SP fetch-att) ")" ) / "ExpungeMessage" / "FlagChange" / "AnnotationChange" ;; "NewMessage" includes "AppendMessage". ;; "FlagChange" is any of "ReadMessages", ;; "TrashMessages", "SetFlags", "ClearFlags". ;; "ExpungeMessage" includes "ExpireMessage". mailbox-event = "CreateMailbox" / "DeleteMailbox" / "RenameMailbox" / "SubscriptionChange" / "MailboxMetadataChange" / "QuotaChange" / "AdminMailbox" ;; [[Alexey: Should "{Create/Delete/Rename}Mailbox" be ;; replaced with a single event?]] ;; [[Alexey: Add "LocationChange" - e.g. mailbox ;; migration between servers?]] user-event = "OverQuota" / "UnderQuota" event-ext = atom ;; For future extensions mailbox-data =/ "RENAMED" SP mailbox SP mailbox <> resp-text-code =/ "NOTIFICATIONOVERFLOW" 8. 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, King, et al. Expires October 2007 [Page 9] Internet-draft April 2007 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. Servers 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. 9. IANA considerations The IANA is requested to add NOTIFY to the list of IMAP extensions, http://www.iana.org/assignments/imap4-capabilities. 10. Acknowedgements The authors gratefully acknowledge the help of Peter Coates, Dave Cridland, Mark Crispin, Cyrus Daboo and Abhijit Menon-Sen. This document builds on one published and two unpublished drafts by the same authors. 11. Normative References [RFC2087] Myers, "IMAP4 QUOTA extension", RFC 2087, January 1997. [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. [RFC2971] Showalter, "IMAP4 ID extension", RFC 2971, Mirapoint, October 2000. [RFC3501] Crispin, "Internet Message Access Protocol - Version 4rev1", RFC 3501, University of Washington, June 2003. [RFC4234] Crocker, Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, Brandenburg King, et al. Expires October 2007 [Page 10] Internet-draft April 2007 Internetworking, Demon Internet Ltd, October 2005. [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. [ANNOTATE] Gellens, Daboo, "IMAP ANNOTATE Extension", draft-ietf- imapext-annotate-16 (work in progress). [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-11 (work in progress), Apple Computer, Inc., February 2007. [MSGEVENT] Newman, "Internet Message Store Events", draft-ietf- lemonade-msgevent-01.txt (work in progress), Sun, March 2007. 12. Informative References [SIEVE] Showalter, "Sieve: A Mail Filtering Language", RFC 3028, Mirapoint Inc, January 2001. [QRESYNC] Melnikov, Cridland, Wilson, "IMAP4 Extensions for Quick Mailbox Resynchronization", draft-ietf-lemonade- reconnect-client-03.txt (work in progress), February 2007. King, et al. Expires October 2007 [Page 11] Internet-draft April 2007 13. 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 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. King, et al. Expires October 2007 [Page 12] Internet-draft April 2007 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 (2007). 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 October 2007 [Page 13]