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]