Network Working Group Curtis King Request for Comments: DRAFT Alexey Melnikov Isode Ltd. Arnt Gulbrandsen Oryx Mail Systems GmbH September 2006 The IMAP NOTIFY Extension draft-gulbrandsen-imap-notify-00.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 will expire in February, 2007. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This document defines an IMAP extgension 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 March 2007 [Page 1] Internet-draft September 2006 1. Conventions Used in This Document The key words "REQUIRED", "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" in this document are to be interpreted as described in "Key words for use in RFCs to Indicate Requirement Levels" [KEYWORDS]. Formal syntax is defined by [ABNF] as modified by [IMAP] and [IMAPABNF]. 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 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- I00-NOTIFY extension. 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 for the specified set of events. Until the NOTIFY command is used for the first time, the server notifies the client about the following events (see section 4 for defintion): NewMessage, ExpungeMessage, FlagChange and (if ANNOTATE is supported) AnnotationChange. The effect of NOTIFY lasts until the next NOTIFY command, or until the IMAP connection is closed. King et al. Expires March 2007 [Page 2] Internet-draft September 2006 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 only while the client remains in idle mode. Open issue: What's the benefit in this extension to IDLE? 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 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. 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 message, the server does not notify the client. (OPEN ISSUE: Should it send a STATUS (HIGHESTMODSEQ)?) 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] is supported and enabled, HIGHESTMODSEQ should be included in the STATUS response. King et al. Expires March 2007 [Page 3] Internet-draft September 2006 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 as usual. If the expunged message(s) is/are in another mailbox, the server sends an unsolicited STATUS (EXISTS) response for the relevant mailbox. If [CONDSTORE] is supported and enabled, HIGHESTMODSEQ should be included in the STATUS response. Open issue: Would it be desirable send the UIDs of the neighbours after the expunge, like this? S: * 100 EXPUNGE S: * 100 EXPUNGE S: * 100 EXPUNGE S: * 100 EXPUNGE S: * 99 FETCH (UID 111) S: * 100 FETCH (UID 444) This would tell the client the UIDs of the expunged messages. Perhaps the client should be able to ask for this using an argument to ExpungeMessage? 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. 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 sends a single LIST response. For RenameMailbox, it sends two. Open issue: Should the server try to tell the client that a rename King et al. Expires March 2007 [Page 4] Internet-draft September 2006 is different from a delete/create pair? How? 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 Open issue. 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. Formal Syntax The following syntax specification uses the Augmented Backus-Naur Form (ABNF) notation as specified in [ABNF]. [IMAP] defines the non- terminals "capability", "command-auth" and "search-key". [IDLE] 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. capability =/ "X-DRAFT-I00-NOTIFY" ;; [[Note to RFC Editor: change the capability ;; name before publication]] command-auth =/ notify notify = "NOTIFY" SP event-groups King et al. Expires March 2007 [Page 5] Internet-draft September 2006 idle =/ "IDLE" SP "(FILTER" event-groups ")" CRLF "DONE" ;; Only if IDLE is also advertised event-groups = "(" 1*event-group ")" event-group = filter-mailboxes SP search-key SP events filter-mailboxes = mbox-or-pat events = "(" event *(SP event) ")" / "*" ;; "*" is used to denote all events. event = message-event / mailbox-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" ;; "FlagChange" is any of "ReadMessages", ;; "TrashMessages", "SetFlags", "ClearFlags". ;; "NewMessage" includes "AppendMessage". 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? event-ext = atom ;; For future extensions 7. Security considerations 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. King et al. Expires March 2007 [Page 6] Internet-draft September 2006 8. IANA considerations The IANA is requested to add NOTIFY to the list of IMAP extensions. 9. Acknowedgements The authors gratefully acknowledge the help of Dave Cridland, Mark Crispin and Abhijit Menon-Sen. This draft builds on one published and two unpublished drafts by the same authors. 10. Normative References [ABNF] Crocker, Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, Brandenburg Internetworking, Demon Internet Ltd, October 2005. [KEYWORDS] Bradner, "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, Harvard University, March 1997. [IMAP] Crispin, "Internet Message Access Protocol - Version 4rev1", RFC 3501, University of Washington, June 2003. [IMAPABNF] Melnikov, Daboo, "Collected Extensions to IMAP4 ABNF", RFC 4466, Isode Ltd., April 2006. [CONDSTORE] 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. [IDLE] Leiba, "IMAP4 IDLE Command", RFC 21788, IBM, June 1997. [MSGEVENT] Newman, "Internet Message Store Events", draft-ietf- lemonade-msgevent-00.txt (work in progress), Sun, June 2006. King et al. Expires March 2007 [Page 7] Internet-draft September 2006 11. Informative References [SIEVE] Showalter, "Sieve: A Mail Filtering Language", RFC 3028, Mirapoint Inc, January 2001. 12. Authors' Addresses Curtis King Isode Ltd 5 Castle Business Village 36 Station Road Hampton, Middlesex TW12 2BX UK Email: Curtis.King@mumbo.ca 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 March 2007 [Page 8] Internet-draft September 2006 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 Internet Society (2006). 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 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 March 2007 [Page 9]