Network Working Group Curtis King Internet-Draft Alexey Melnikov Intended Status: Proposed Standard Isode Ltd. Arnt Gulbrandsen Oryx Mail Systems GmbH November 2006 The IMAP NOTIFY Extension draft-gulbrandsen-imap-notify-03.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 September 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 September 2007 [Page 1] Internet-draft March 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. The five characters [...] means that something has been elided. 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. Depending on client preference, the extension takes effect either during IDLE or always. IMAP servers which support this extension advertise the X-DRAFT- I03-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, King, et al. Expires September 2007 [Page 2] Internet-draft March 2007 FlagChange and (if [ANNOTATE] is supported and enabled) AnnotationChange. It does not notify the client about any events on other mailboxes. The effect of NOTIFY lasts until the next NOTIFY or IDLE command, or until the IMAP connection is closed. 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. Open issue: At present the client can send a wildcard or a list of mailboxes. Should we drop the wildcard? Would that nudge the client developers to use short lists by default? Open issue: Lingyan Wu suggests that for each mailbox where the client requests NewMessage events, the server should send a STATUS (UIDNEXT) when the client sends NOTIFY. Arnt's intuition says "That is either a good idea or a bad idea, but I don't know which". 4. The IDLE Command If IDLE (as well as this extension) is supported, the IDLE command is extended to have the same arguments as NOTIFY, and the server sends notifications about the specified events while the client remains in idle mode. If the client uses IDLE without arguments, the server notifies the client about the same events as before IDLE. If the client uses IDLE with arguments, the supplied arguments override the previous setting, even after the end of IDLE processing. Open issue: What's the benefit in extending IDLE this way? If noone suggests concrete value, we drop it in the next version of the draft. 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. King, et al. Expires September 2007 [Page 3] Internet-draft March 2007 The server MAY omit notifying the client if the event is caused by this session. For example, if the client issues SETACL and has requested AdminMailbox notation, the server MAY NOT notify the client of the AdminMailbox change. Open issue: Should the two MAYs in the previous paragraph be upgraded to SHOULD or MUST? 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 supported and enabled. If so, the server sends a STATUS (HIGHESTMODSEQ) response. If not, the server does not notify the client. FlagChange covers the ReadMessages, TrashMessages, SetFlags and ClearFlags events in [MSGEVENT]. 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 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. 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). King, et al. Expires September 2007 [Page 4] Internet-draft March 2007 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. 5.4. OverQuota, UnderQuota and QuotaChange If the client has permission to perform GETQUOTA, the server sends an unsolicited QUOTA response containing the new quotas. If the server does not support the QUOTA extension, it MUST ignore request for these three events and never send any notifications for them. 5.5. CreateMailbox, DeleteMailbox, RenameMailbox 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. For CreateMailbox and DeleteMailbox, the server usually sends a single LIST response. For RenameMailbox, it usually sends two. 5.6. 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 is included. 5.7. 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. Open Issue: What does it mean for METADATA to be enabled? King, et al. Expires September 2007 [Page 5] Internet-draft March 2007 5.8. AdminMailbox If the user has the right to perform GETACL 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. 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 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 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 and wants notifications on both, 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 authentication-id represent the same client. If the server would notify a client of an event via two or more connections, it SHOULD 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" and "search-key". [RFC2177] defines the non-terminal "idle". [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. King, et al. Expires September 2007 [Page 6] Internet-draft March 2007 capability =/ "X-DRAFT-I02-NOTIFY" ;; [[Note to RFC Editor: change the capability ;; name before publication]] command-auth =/ notify notify = "NOTIFY" SP event-groups idle =/ "IDLE" SP "(FILTER" event-groups ")" CRLF "DONE" ;; Only if IDLE is also advertised event-groups = "(" 1*event-group ")" event-group = filter-mailboxes SP events 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 / event-ext ;; As in draft-ietf-lemonade-msgevent-XX.txt message-event = ( "NewMessage" SP "(" fetch-att *(SP fetch-att) ")" ) / "ExpungeMessage" / "OverQuota" / "UnderQuota" / "FlagChange" / "AnnotationChange" ;; "NewMessage" includes "AppendMessage". ;; "FlagChange" is any of "ReadMessages", ;; "TrashMessages", "SetFlags", "ClearFlags". mailbox-event = "CreateMailbox" / "DeleteMailbox" / "RenameMailbox" / "SubscriptionChange" / "MailboxMetadataChange" / "QuotaChange" / "AdminMailbox" ;; Should "{Create/Delete/Rename}Mailbox" be ;; replaced with a single event? ;; Is "AdminMailbox" (ACL change) needed? ;; Add "LocationChange" - e.g. mailbox ;; migration between servers? user-event = "OverQuota" / "UnderQuota" event-ext = atom ;; For future extensions King, et al. Expires September 2007 [Page 7] Internet-draft March 2007 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, 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 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 [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. King, et al. Expires September 2007 [Page 8] Internet-draft March 2007 [RFC4234] Crocker, Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, Brandenburg Internetworking, Demon Internet Ltd, October 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-00.txt (work in progress), Sun, June 2006. 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-02.txt (work in progress), February 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 King, et al. Expires September 2007 [Page 9] Internet-draft March 2007 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. 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 King, et al. Expires September 2007 [Page 10] Internet-draft March 2007 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 September 2007 [Page 11]