7Network Working Group R. Gellens, Ed.
8Request for Comments: 5551 Qualcomm
9Category: Informational August 2009
12 Lemonade Notifications Architecture
16 Notification and filtering mechanisms can make email more enjoyable
17 on mobile and other constrained devices (such as those with limited
18 screen sizes, memory, data transfer rates, etc.). Notifications make
19 the client aware of significant events (such as the arrival of new
20 mail) so it can react (such as by fetching interesting mail
21 immediately). Filtering reduces the visible mail to a set of
22 messages that meet some criteria for "interesting". This
23 functionality is included in the goals of the Lemonade (Enhancements
24 to Internet email to Support Diverse Service Environments) Working
27 This document also discusses the use of server-to-server
28 notifications, and how server to server notifications fit into an
29 architecture that provides server to client notifications.
33 This memo provides information for the Internet community. It does
34 not specify an Internet standard of any kind. Distribution of this
39 Copyright (c) 2009 IETF Trust and the persons identified as the
40 document authors. All rights reserved.
42 This document is subject to BCP 78 and the IETF Trust's Legal
43 Provisions Relating to IETF Documents in effect on the date of
44 publication of this document (http://trustee.ietf.org/license-info).
45 Please review these documents carefully, as they describe your rights
46 and restrictions with respect to this document.
48 This document may contain material from IETF Documents or IETF
49 Contributions published or made publicly available before November
50 10, 2008. The person(s) controlling the copyright in some of this
51 material may not have granted the IETF Trust the right to allow
52 modifications of such material outside the IETF Standards Process.
53 Without obtaining an adequate license from the person(s) controlling
54 the copyright in such materials, this document may not be modified
58Gellens Informational [Page 1]
60RFC 5551 Lemonade Notifications Architecture August 2009
63 outside the IETF Standards Process, and derivative works of it may
64 not be created outside the IETF Standards Process, except to format
65 it for publication as an RFC or to translate it into languages other
70 1. Introduction ....................................................2
71 1.1. Conventions Used in This Document ..........................2
72 2. Notifications Logical Architecture and LEMONADE Profile .........2
73 3. Event-Based Synchronization .....................................4
74 4. Push Email ......................................................5
75 5. Server-to-Server Notifications Rationale ........................5
76 5.1. Notifications Discussion ...................................6
77 5.2. Server to Server Notifications Scope .......................7
78 5.3. Basic Operation ............................................8
79 5.4. Event Order ...............................................10
80 5.5. Reliability ...............................................10
81 6. Security Considerations ........................................10
82 7. References .....................................................11
83 7.1. Normative References ......................................11
84 7.2. Informative References ....................................11
85 8. Contributors ...................................................12
89 The Lemonade work [LEMONADE-PROFILE] identified a need to provide
90 notification and filtering mechanisms for use with IMAP [IMAP].
92 In addition, external groups that make use of IETF work also
93 expressed such requirements (see, for example, [OMA-LEMONADE-ARCH];
94 Open Mobile Alliance (OMA) requirements for within-IMAP ("inband")
95 and out-of-IMAP ("outband") server to client notifications are listed
981.1. Conventions Used in This Document
100 Within this document, the terms "Lemonade Profile" and "Lemonade"
101 generally refer to the revised Lemonade Profile document, RFC 5550
1042. Notifications Logical Architecture and LEMONADE Profile
106 The target logical architecture for the LEMONADE Profile is described
107 in the revised Lemonade Profile document [LEMONADE-PROFILE].
109 Figure 1 illustrates how notification and filtering fit in the
114Gellens Informational [Page 2]
116RFC 5551 Lemonade Notifications Architecture August 2009
121 +=========| Notification |.NF.
124 ! +--------------+! ! NF is either in
125 Notif-! ! ! Notification
126 ications! Filter Protocol ! ! Server or IMAP
127 Protocol! !======================! ! Store, not both
129 ! ! Filter Protocol ....
130 ! !=====================>. . +---------+
131 ! ! +-----------.NF.---+ | |
133 +-----+ IMAP |.... | LMTP/ |.... |<==SMTP
134 | | <======> |.VF. IMAP ....| SMTP |.AF. |
135 | MUA |\ ME-2a |.... Store .DF.|<=======|.... |
137 +-----+ \ +------------------+ +---------+
143 \ | LEMONADE | SMTP | |==>SMTP
144 ===>| Submit |===============>| MTA |
149 Figure 1: Filtering Mechanism Defined in
150 Lemonade Profile Architecture
152 In Figure 1, four categories of filters are defined:
154 1. AF: Administrative Filters: Created and maintained by mail
155 administration. AF are typically not configured by the user and
156 are used to apply policies, content filtering, virus protection,
159 2. DF: Deposit Filters: Executed on deposit of new mail. Can be
160 defined as Sieve filters [SIEVE].
162 3. VF: View Filters: Define which messages are important to a
163 client. May be implemented as pseudo-virtual mailboxes [CONTEXT].
164 Clients may use this to restrict which messages they synchronize.
170Gellens Informational [Page 3]
172RFC 5551 Lemonade Notifications Architecture August 2009
175 4. NF: Notification Filters: Determine when out-of-IMAP ("outband")
176 notifications are sent to the client. These filters can be
177 implemented either in the message store or in a separate
178 notifications engine.
180 Note that when implementing DF or NF using Sieve, the 'enotify'
181 [SIEVE-NOTIFY] and likely the 'variables' [SIEVE-VARIABLES] Sieve
182 extensions might be needed.
184 The filters are manageable by the client as follows:
186 * NF and DF: When internal to the mail store, these are typically
187 implemented using Sieve; hence, a Sieve management protocol is used
188 for client modifications. See [MANAGE-SIEVE] for more information.
189 Per-mailbox notifications might be implemented using a combination
190 of a primary Sieve script for notifications on delivery into a
191 mailbox (e.g., FILEINTO) and a per-mailbox Sieve script such as
192 [IMAP-SIEVE] for transfers into a mailbox. When the NF is within a
193 notification server, it is out of scope of Lemonade.
195 * VF: via pseudo-virtual mailboxes as defined in [CONTEXT].
197 In Figure 1, the NF are shown both as part of the mail store (for
198 example, using Sieve) and as an external notification server. Either
199 approach can be used.
2013. Event-Based Synchronization
203 +----------------+ +---------------+ +------------+
204 | COMPLETE | (VF) | VIEW | (NF) | PUSH |
205 | REPOSITORY | View | REPOSITORY |Notification| REPOSITORY |
206 | |Filters| | Filters | |
207 | all email | | email to be | | important |
208 | in the account |=======|synched by the |=====<?>====| email / |
209 | | | mobile client | | | events |
210 | | | (CONTEXT) | | | |
211 +----------------+ +---------------+ | +------------+
219 Figure 2: Filters and Repositories
226Gellens Informational [Page 4]
228RFC 5551 Lemonade Notifications Architecture August 2009
231 For in-IMAP ("inband") notifications, the Mail User Agent (MUA)
232 (client) issues IDLE [IDLE], or the successor extension command
233 NOTIFY [NOTIFY]; the LEMONADE IMAP server sends notifications as
234 unsolicited responses to the client.
236 Out-of-IMAP ("outband") notifications are messages sent to the user
237 or client not through IMAP. When directed at the user, they are
238 human-consumable and intended to alert the user. When directed at
239 the client, they are machine-consumable and may be acted upon by the
240 receiver in various ways, for example, fetching data from the mail
241 store or resynchronizing one or more mailboxes, updating internal
242 state information, and alerting the user.
246 A good user experience of "push email" requires that when
247 "interesting" events occur in the mail store, the client is informed
248 so that it can connect and resynchronize. The Lemonade Profile
249 [LEMONADE-PROFILE] contains more information, especially in Section
250 5.4.2, titled "External Notifications".
2525. Server-to-Server Notifications Rationale
254 With server-to-server notifications, a mail system generates event
255 notifications. These notifications describe mailbox state change
256 events such as arrival of a new message, mailbox full, and so forth.
258 See [MSGEVENT] for a list of such events.
260 These state change notifications are sent to a notification system,
261 which may generate alerts or notifications for delivery to one or
262 more clients or the user.
264 Server-to-server notifications allow the mail system to generate end
265 user or client notifications without needing to keep track of
266 notification settings for users or clients; the notification system
267 maintains notification preferences for clients and users.
269 Using server-to-server notifications, the mail system can provide the
270 end user with a unified notification experience (the same look and
271 feel for accounts at all messaging systems, such as email and
272 voicemail), while allowing smooth integration of additional messaging
282Gellens Informational [Page 5]
284RFC 5551 Lemonade Notifications Architecture August 2009
2875.1. Notifications Discussion
289 The POP3 and IMAP4 Internet mail protocols allow mail clients to
290 access and manipulate electronic mail messages on mail systems. By
291 definition and scope, these protocols do not provide off-line methods
292 to notify an end user when the mailbox state changes. Nor does
293 either protocol define a way to aggregate the status within the end
294 user's various mailboxes.
296 The desire for this functionality is obvious. For example, from the
297 very early days of electronic mail, various notifications mechanisms
298 have been used, including login shell checks, and simple hacks such
301 To provide an end user with unified notifications and one centralized
302 Message-Waiting Indicator (MWI), notification mechanisms are needed
303 that aggregate the information of all the events occurring on the end
304 user's different messaging systems.
306 Server-to-server notifications allow the messaging system to send
307 state change events to the notification system when something happens
308 in or to an end user's mailbox.
310 Notification systems can be broadly grouped into three general
311 architectures: external smart clients, intrinsic notification, and
312 separate notification mechanisms.
314 External smart clients are agents independent of the mail system that
315 periodically check mailbox state (or receive notifications, for
316 example, via IMAP IDLE) and inform the user or the user's mail
317 client. Many such systems have been used over the years, including
318 login shells that check the user's mail spool, laptop/desktop tiny
319 clients that periodically poll the user's mail servers, etc.
321 Intrinsic notification is any facility within a mail system that
322 generates notifications, for example, the server component of [BIFF],
323 or, for more modern systems, the recent Sieve extensions for
324 notifications [SIEVE-NOTIFY].
326 Separate notification systems decouple the state change event
327 notification from the end user or client notification, allowing a
328 mail system to do the former, and specialized systems (such as those
329 that handle presence) to be responsible for the latter. This
330 separation is architecturally cleaner, since the mail system only
331 needs to support one additional protocol (for communication to the
332 notification system) instead of multiple notification delivery
333 protocols, and does not need to keep track of which clients and which
334 users are interested in which events. It also allows notifications
338Gellens Informational [Page 6]
340RFC 5551 Lemonade Notifications Architecture August 2009
343 to be generated for any service, not just electronic mail. However,
344 it requires a new service (the notification system) and the mail
345 system needs to support an additional protocol (to communicate with
346 the notification system).
348 In addition to any external notification mechanisms, Sieve can be
349 used for notifications [SIEVE-NOTIFY]. Since many mail systems
350 already provide Sieve support, this can be a fairly easy and quick
351 deployment option to provide a useful form of notifications.
3535.2. Server-to-Server Notifications Scope
355 For the purposes of the Lemonade work, the scope of server-to-server
356 notifications is limited to communications between the mail system
357 and the notification system (the third architectural type described
358 in Section 5.1). Communication between the notification system and
359 the end user or devices (which might use SMS, WAP Push, instant
360 messaging, etc.) is out of scope. Likewise, the scope generally
361 presumes a security relationship between the mail system and the
362 notification system. Thus, the security relationship then becomes
363 the responsibility of the notification system. However, the
364 specifics of security, trust relationships, and related issues depend
365 on the specifics of both server-to-server notifications and
366 notification systems.
368 Figure 3 shows the context of server-to-server notifications; only
369 the left side is in scope for Lemonade:
394Gellens Informational [Page 7]
396RFC 5551 Lemonade Notifications Architecture August 2009
399 +--------+ +--------+
401 Message | Mail | \ |Gateway |
402 -------> |Server 1| \ __| |
403 +--------+ \ / +--------+
406 | \ +--------------+ / | +--------+
407 +--------+ | \ | | / | | MWI |
408 Read | Voice | | -| Notification |/ | |Gateway |
409 Message | Mail |-------->| Server |------->| |
410 -------> | Server | | ^ __| |\ ^ | +--------+
411 +--------+ | | / |(out of scope)| \ | |
413 | / ^ +--------------+ ^ \ |
415 +--------+ / | | \ | | \ +--------+
416 Mailbox | | /| | | \| | |\ | WAP |
417 Full | Mail |/ | | | ^ \ | | \| Push |
418 -------> |Server 2| | | | | |\| | |Gateway |
419 +--------+ | | | | | \ | +--------+
422 | | | | | | |\ +--------+
423 | | | | | | | \| IM |
424 | | | | | | | |Gateway |
426 | | | | | | | +--------+
431 Notifications (out of scope)
434 Figure 3: Scope of Server-to-Server Notifications
438 The mail system sends state change event notifications to the
439 notification system (which in turn might notify a client or end user)
440 for events that occur in the end user's mailboxes. Each such
441 notification, referring to a single mailbox event, is called a state
450Gellens Informational [Page 8]
452RFC 5551 Lemonade Notifications Architecture August 2009
455 The state change event contains data regarding the mailbox event that
456 has occurred. The state change event describes the change, but
457 normally does not specify how or if the end user or client is
458 notified; this allows the end user and client notification
459 preferences to be maintained only within the notification server.
461 From the Lemonade viewpoint, out-of-IMAP (outband) notifications are
462 usually desired only when the client is not connected to the IMAP
463 server (since inband notifications are used when there is an IMAP
464 connection). Thus, it is helpful for the mail system to be able to
465 inform the notification system when the user logs in or out, and
466 which client is used (when this information is available).
468 When Sieve is used, the Sieve engine might have access to this
471 A message is generated by the message store as a result of a state
472 change event. This message may be delivered to the end user, a
473 client, or to an external notification server that might deliver an
474 equivalent message to the user or to a client.
476 Within the context of the Lemonade Profile (Figure 1), the event is
477 filtered by NF. That is, the Notification Filters logically
478 determine which state change events cause notification to the user or
481 Notifications allow for a rich end user experience. This might
482 include conveying mailbox status, new message attributes, etc., to
483 the user or client independent of the client's connection to the mail
486 Notifications also allow for different Message Waiting Indicator
487 (MWI) behaviors (e.g., turn MWI indication off after all the messages
488 in all the end user's mailboxes have been read, should such an
489 unlikely thing occur in the real world).
491 The payload of a notification might include a URL referring to the
492 message that caused the event, possibly using URLAUTH [URLAUTH].
494 As state change events occur in the mail store, they are filtered,
495 which is to say matched against client or user preferences. As a
496 result, a notification may or may not be generated for delivery to
499 In the most general case, the mail system sends bulk state change
500 events to an external notification server, and it is the notification
501 server that filters the events by matching against the user's or
502 client's preferences.
506Gellens Informational [Page 9]
508RFC 5551 Lemonade Notifications Architecture August 2009
511 In the most mail-specific case, the mail system performs the
512 filtering itself, for example, using Sieve.
516 For the Lemonade Profile, the event order is generally not important.
517 By including information such as the modification sequence identifier
518 (called a modseq or mod-sequence) [CONDSTORE] in notifications, the
519 receiving client can quickly and easily determine if it has already
520 processed the triggering event (for example, if a notification
521 arrives out of order, or if the client has resynchronized since the
522 event was generated).
524 For generic server-to-server notifications, the order is likely to
525 matter and the mail system needs to provide notifications to the
526 notification system in the order that they occur.
530 For the Lemonade Profile, lost or delayed notifications to the client
531 are tolerated. A client can resynchronize its state (including that
532 reported by any missing events) when it next connects to the server.
534 For generic server-to-server notifications, it is assumed that the
535 data in a state change event is important, and therefore a high level
536 of reliability is needed between the mail system and any external
537 notification systems.
5396. Security Considerations
541 Notification content (payload) needs to be protected against
542 eavesdropping and alteration when it contains specific information
543 from messages, such as the sender.
545 Even when the content is trivial and does not contain privacy-
546 sensitive information, guarding against denial-of-service attacks may
547 require authentication or verification of the notification sender.
549 Protocols that manipulate filters need mechanisms to protect against
550 modification by, as well as disclosure to, unauthorized entities.
551 For example, a malicious entity might try to delete notifications the
552 user wants, or try to flood the target device with notifications to
553 incur usage charges, or prevent normal use. In addition, the filters
554 themselves might contain sensitive information or reveal
555 interpersonal or inter-organizational relationships, as well as email
562Gellens Informational [Page 10]
564RFC 5551 Lemonade Notifications Architecture August 2009
5697.1. Normative References
571 [IMAP] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL -
572 VERSION 4rev1", RFC 3501, March 2003.
575 Cridland, D., Ed., Melnikov, A., Ed., and S. Maes,
576 Ed., "The Internet Email to Support Diverse Service
577 Environments (Lemonade) Profile", RFC 5550, August
5807.2. Informative References
582 [BIFF] Gellens, R., "Simple New Mail Notification", RFC 4146,
585 [CONTEXT] Cridland, D. and C. King, "Contexts for IMAP4", RFC
588 [CONDSTORE] Melnikov, A. and S. Hole, "IMAP Extension for
589 Conditional STORE Operation or Quick Flag Changes
590 Resynchronization", RFC 4551, June 2006.
592 [IMAP-SIEVE] Leiba, B., "Support for Sieve in Internet Message
593 Access Protocol (IMAP4)", Work in Progress, February
596 [MANAGE-SIEVE] Melnikov, A., Ed., and T. Martin, "A Protocol for
597 Remotely Managing Sieve Scripts", Work in Progress,
600 [MSGEVENT] Gellens, R. and C. Newman, "Internet Message Store
601 Events", RFC 5423, March 2009.
603 [IDLE] Leiba, B., "IMAP4 IDLE command", RFC 2177, June 1997.
605 [NOTIFY] Gulbrandsen, A., King, C., and A. Melnikov, "The IMAP
606 NOTIFY Extension", RFC 5465, February 2009.
609 Burger, E. and G. Parsons, "LEMONADE Architecture -
610 Supporting Open Mobile Alliance (OMA) Mobile Email
611 (MEM) Using Internet Mail", RFC 5442, March 2009.
618Gellens Informational [Page 11]
620RFC 5551 Lemonade Notifications Architecture August 2009
623 [OMA-ME-RD] Open Mobile Alliance Mobile Email Requirement
624 Document, (Work in progress).
625 http://www.openmobilealliance.org/
627 [SIEVE] Guenther, P., Ed., and T. Showalter, Ed., "Sieve: An
628 Email Filtering Language", RFC 5228, January 2008.
630 [SIEVE-NOTIFY] Melnikov, A., Ed., Leiba, B., Ed., Segmuller, W., and
631 T. Martin, "Sieve Email Filtering: Extension for
632 Notifications", RFC 5435, January 2009.
635 Homme, K., "Sieve Email Filtering: Variables
636 Extension", RFC 5229, January 2008.
638 [URLAUTH] Crispin, M., "Internet Message Access Protocol (IMAP)
639 - URLAUTH Extension", RFC 4467, May 2006.
643 The original (and longer and more detailed) version of this document
644 was authored by Stephane H. Maes and Ray Cromwell of Oracle
647 The current and original authors want to thank all who have
648 contributed key insight in notifications and filtering and have
649 authored specifications or documents used in this document.
651 The current and original authors want to thank the authors of the
652 original work on "Server To Server Notification Protocol
653 Requirements", some of whose material has been incorporated in the
654 present document, in particular, Gev Decktor.
658 Randall Gellens, Editor
659 QUALCOMM Incorporated
664 EMail: rg+ietf@qualcomm.com
674Gellens Informational [Page 12]