7Network Working Group E. Burger
8Request for Comments: 5442 Consultant
9Category: Informational G. Parsons
14 LEMONADE Architecture - Supporting Open Mobile Alliance (OMA)
15 Mobile Email (MEM) Using Internet Mail
19 This memo provides information for the Internet community. It does
20 not specify an Internet standard of any kind. Distribution of this
25 Copyright (c) 2009 IETF Trust and the persons identified as the
26 document authors. All rights reserved.
28 This document is subject to BCP 78 and the IETF Trust's Legal
29 Provisions Relating to IETF Documents in effect on the date of
30 publication of this document (http://trustee.ietf.org/license-info).
31 Please review these documents carefully, as they describe your rights
32 and restrictions with respect to this document.
34 This document may contain material from IETF Documents or IETF
35 Contributions published or made publicly available before November
36 10, 2008. The person(s) controlling the copyright in some of this
37 material may not have granted the IETF Trust the right to allow
38 modifications of such material outside the IETF Standards Process.
39 Without obtaining an adequate license from the person(s) controlling
40 the copyright in such materials, this document may not be modified
41 outside the IETF Standards Process, and derivative works of it may
42 not be created outside the IETF Standards Process, except to format
43 it for publication as an RFC or to translate it into languages other
48 This document specifies the architecture for mobile email, as
49 described by the Open Mobile Alliance (OMA), using Internet Mail
50 protocols. This architecture was an important consideration for much
51 of the work of the LEMONADE (Enhancements to Internet email to
52 Support Diverse Service Environments) working group in the IETF.
53 This document also describes how the LEMONADE architecture meets
54 OMA's requirements for their Mobile Email (MEM) service.
58Burger & Parsons Informational [Page 1]
60RFC 5442 LEMONADE Architecture March 2009
65 1. Introduction ....................................................2
66 2. OMA Mobile Email (MEM) ..........................................2
67 2.1. OMA MEM Requirements .......................................2
68 2.2. OMA MEM Architecture .......................................3
69 2.2.1. OMA MEM Logical Architecture ........................3
70 2.2.2. OMA MEM Deployment Issues ...........................4
71 2.3. OMA MEM Technical Specification ............................6
72 3. IETF LEMONADE Architecture ......................................6
73 3.1. Relationship between the OMA MEM and LEMONADE Logical
74 Architectures ..............................................7
75 3.2. LEMONADE Realization of OMA MEM with
76 non-LEMONADE-Compliant Servers .............................9
77 3.2.1. LEMONADE Realization of OMA MEM with
78 non-LEMONADE IMAP Servers ...........................9
79 3.2.2. LEMONADE Realization of OMA MEM with non-IMAP
80 Servers ............................................10
81 4. Filters and Server-to-Client Notifications and LEMONADE ........11
82 5. Security Considerations ........................................13
83 6. Acknowledgements ...............................................13
84 7. Informative References .........................................13
88 This document describes the architecture of OMA Mobile Email (MEM)
89 using Internet Mail protocols defined by the IETF. The LEMONADE
90 working group has enhanced many of these protocols for use in the
91 mobile environment. The LEMONADE profile [PROFILE] and its revision,
92 [PROFILE-bis], summarize such protocols and protocol use. This
93 document shows how the OMA MEM Requirements document [MEM-req], OMA
94 MEM Architecture [MEM-arch], and OMA MEM Technical Specification
95 [MEM-ts] relate to the work of LEMONADE in the IETF.
972. OMA Mobile Email (MEM)
99 The OMA Mobile Email (MEM) sub-working group has spent some time
100 studying the requirements and architecture of mobile email. IETF
101 LEMONADE has been liaising with them and has based much of its
102 Internet Mail enhancements on their input. This section summarizes
103 the output of the OMA.
1052.1. OMA MEM Requirements
107 The OMA MEM activity collected a set of use cases and derived
108 requirements for a Mobile Email (MEM) enabler. The OMA MEM
109 Requirements document [MEM-req] summarizes this work. Some
110 requirements relate to email protocols, some involve other OMA
114Burger & Parsons Informational [Page 2]
116RFC 5442 LEMONADE Architecture March 2009
119 technologies outside the scope of the IETF, and some relate to
120 implementations and normative interoperability statements for clients
1232.2. OMA MEM Architecture
125 This section introduces the OMA MEM Architecture.
1272.2.1. OMA MEM Logical Architecture
129 The OMA MEM activity has derived a logical architecture from the
130 requirements and use cases described in [MEM-req]. A simplification
131 for illustrative purposes is shown in Figure 1, where arrows indicate
140 _v____ ___v____ ________
142 | MEM |-------->| MEM | I2 | Email |
143 |Client| ME-2| Server |<---->| Server |
144 |______|<--------|________| |________|
149 Figure 1: Basic OMA MEM Logical Architecture
151 Figure 1 identifies the following elements:
153 o The MEM client that implements the client-side functionality of
154 the OMA Mobile Email enabler. It is also responsible for
155 providing the mobile email user experience and interface to the
156 user and storing the email and data to be sent to the MEM server
159 o The MEM server that implements the server-side functionality of
160 the OMA Mobile Email (MEM) enabler.
162 o The MEM protocol between the MEM client and MEM server. It is
163 responsible for all the in-band data exchanges that take place
164 between the MEM client and server in order to update the MEM
170Burger & Parsons Informational [Page 3]
172RFC 5442 LEMONADE Architecture March 2009
175 client with email server changes and the email server with changes
176 in the MEM client, and in order to send new email from the email
179 o Other OMA enablers that are needed to directly support the Mobile
180 Email enabler. They are out of the scope of the IETF but may
183 * Client provisioning and management for over-the-air
184 installation of the MEM client on the device, provisioning of
185 the client settings, and revocation of client privileges.
187 * Messaging enablers for out-of-band notification, where out-of-
188 band notifications that are server-to-client event exchanges
189 are not transported by the MEM protocol but via other channels.
191 * Billing, charging, and so on.
193 OMA identifies different interfaces:
195 o ME-1: MEM client interface to interact via the MEM protocol with
198 o ME-2: Corresponding interface of the MEM server.
200 o ME-3: Out-of-band MEM server interfaces; for example, to support
201 generation of server-to-client notifications.
203 o ME-4: Out-of-band MEM client interfaces (e.g., to receive server-
204 to-client notifications).
206 o ME-5: Interface for management of MEM enabler server settings,
207 user preferences, and filters, globally and per account.
209 The MEM server enables an email server. In a particular
210 implementation, the email server may be packaged with (internal to
211 it) the MEM server or be a separate component. In such cases,
212 interfaces to the email server are out of scope of the OMA MEM
213 specifications. In the present document, we focus on the case where
214 the backend consists of IETF IMAP and SUBMIT servers. However, we
215 also discuss the relationship to other cases. The I2 interface is an
216 OMA notation to designate protocol / interfaces that are not
217 specified by the MEM enabler but may be standardized elsewhere.
2192.2.2. OMA MEM Deployment Issues
221 The OMA MEM Architecture document [MEM-arch] further identifies
226Burger & Parsons Informational [Page 4]
228RFC 5442 LEMONADE Architecture March 2009
2312.2.2.1. OMA MEM Proxy
233 The OMA MEM Architecture document [MEM-arch] identifies OMA MEM
234 server proxies as server components that may be deployed ahead of
235 firewalls to facilitate firewall traversal.
2372.2.2.2. OMA MEM Deployment Cases
239 OMA MEM identifies that each component (MEM client, MEM servers,
240 other enablers, and the email server) may be deployed in different
241 domains, possibly separated by firewalls and other network
242 intermediaries. MEM proxies may be involved in front of a firewall
243 that protects the MEM server domain.
245 OMA MEM targets support of configurations where:
247 o All components are within the same domain, such as in a mobile
250 o The MEM client and other enablers are in the mobile operator
251 domain, there is a MEM proxy, and the MEM server and email server
252 are in the domain of the email service provider.
254 o The MEM client and other enablers as well as a MEM proxy are in
255 the mobile operator domain, and the MEM server and email server
256 are in the domain of the email service provider.
258 o The MEM client and other enablers are in the mobile operator
259 domain, a MEM proxy is in a third-party service provider domain,
260 and the MEM server and email server are in the domain of the email
263 o The MEM client, other enabler, and MEM server are in the mobile
264 operator domain, and the email server is in the domain of the
265 email service provider.
267 o The MEM client and other enablers are in the mobile operator
268 domain, the MEM server is in a third-party service provider
269 domain, and the email server is in the domain of the email service
272 The email service provider can be a third-party service provider, a
273 network service provider, or an enterprise email service.
282Burger & Parsons Informational [Page 5]
284RFC 5442 LEMONADE Architecture March 2009
2872.3. OMA MEM Technical Specification
289 The OMA MEM activity will conclude with a specification for a Mobile
290 Email (MEM) enabler. The ongoing work is in the OMA MEM Technical
291 Specification [MEM-ts]. LEMONADE is a basis for the mechanism.
292 However, some additional details that are outside the scope of the
293 IETF will also be included.
295 OMA provides ways to perform provisioning via OMA client provisioning
296 and device management. Other provisioning specifications are
297 available (e.g., SMS based).
299 OMA provides enablers to support out-of-band notification mechanisms,
300 filter specifications (such as XDM), and remote deactivate devices,
301 and to perform other non-Internet activities.
3033. IETF LEMONADE Architecture
305 This section introduces the LEMONADE Architecture.
307 The IETF LEMONADE activity has derived a LEMONADE profile
308 [PROFILE-bis] with the logical architecture represented in Figure 2,
309 where arrows indicate content flows.
313 _________| Notification |
320 __v__ IMAP | LEMONADE | ESMTP | |
321 | |<----------->| IMAP |<---------------| MTA |
322 | MUA |- | Store | |_____|
323 |_____| \ |__________|
329 \ | LEMONADE | ESMTP | |
330 ---->| Submit |--------------->| MTA |
334 Figure 2: LEMONADE logical architecture
338Burger & Parsons Informational [Page 6]
340RFC 5442 LEMONADE Architecture March 2009
343 The LEMONADE profile [PROFILE] assumes:
345 o IMAP protocol [RFC3501], including LEMONADE profile extensions
348 o SUBMIT protocol [RFC4409], including LEMONADE profile extensions.
350 o LEMONADE profile compliant IMAP store connected to an MTA (Mail
351 Transfer Agent) via the ESMTP [EMAIL].
353 o LEMONADE profile compliant submit server connected to an MTA,
356 o Out-of-band server-to-client notifications relying on external
357 notification mechanisms (and notification protocols) that may be
358 out of the scope of the LEMONADE profile.
360 o LEMONADE-aware MUA (Mail User Agent). While use of out-of-band
361 notification is described in the LEMONADE profile, support for the
362 underlying notifications mechanisms/protocols is out of the scope
363 of the LEMONADE specifications.
365 Further details on the IETF email protocol stack and architecture can
3683.1. Relationship between the OMA MEM and LEMONADE Logical
371 Figure 3 illustrates the mapping of the IETF LEMONADE logical
372 architecture on the OMA MEM logical architecture.
394Burger & Parsons Informational [Page 7]
396RFC 5442 LEMONADE Architecture March 2009
399 _____________________
400 | Other_Mob. Enablers |
402 _________| Notification | |
404 | | |______________| |
405 |Notif. |____________^________|
406 |Protocol ______|__________
407 ME-4 | | ___|_ME-3_ |
408 ___|____ | | | | _____
409 | __v__ | IMAP | | LEMONADE | | ESMTP | |
410 || |<----------->| IMAP |<-----------| MTA |
411 || MUA || ME-2a | | Store | | |_____|
412 ||_____||\ME-1 | |__________| |
414 | Client| \ | |URLAUTH |
415 |_______| \SUBMIT | |
418 \ | | LEMONADE | | ESMTP | |
419 ---->| Submit |----------->| MTA |
420 ME-2b | | Server | | |_____|
429 Figure 3: Mapping of LEMONADE Logical Architecture
430 onto the OMA MEM Logical Architecture
432 As described in Section 3, the LEMONADE profile assumes LEMONADE
433 profile compliant IMAP stores and SUBMIT servers. Because the
434 LEMONADE profile extends the IMAP store and the SUBMIT server, the
435 mobile enablement of email provided by the LEMONADE profile is
436 directly provided in these servers. Mapping to the OMA MEM logical
437 architecture for the case considered and specified by the LEMONADE
438 profile, we logically combine the MEM server and email server.
439 However, in LEMONADE we split them logically into a distinct LEMONADE
440 message store and a LEMONADE SUBMIT server. ME-2 consists of two
441 interfaces. ME-2a is IMAP extended according to the LEMONADE
442 profile. ME-2b is SUBMIT extended according to the LEMONADE profile.
444 The MUA is part of the MEM client.
450Burger & Parsons Informational [Page 8]
452RFC 5442 LEMONADE Architecture March 2009
455 The external notifications mechanism is part of the OMA enablers
456 specified by the OMA.
4583.2. LEMONADE Realization of OMA MEM with non-LEMONADE-Compliant
461 The OMA MEM activity is not limited to enabling LEMONADE-compliant
462 servers. It explicitly identifies the need to support other
463 backends. This is, of course, outside the scope of the IETF LEMONADE
4663.2.1. LEMONADE Realization of OMA MEM with non-LEMONADE IMAP Servers
468 Figure 4 illustrates the case of IMAP servers that are not LEMONADE-
469 compliant. In such case, the I2 interface between the MEM server
470 components and the IMAP store and SUBMIT server are IMAP and SUBMIT
471 without LEMONADE extensions.
473 It is important to note the realizations are of a schematic nature
474 and do not dictate actual implementation. For example, one could
475 envision collocating the LEMONADE MEM enabler server and the submit
476 server shown in Figure 4 in a single instantiation of the
477 implementation. Likewise, we consciously label the LEMONADE MEM
478 enabler as neither an IMAP proxy nor an IMAP back-to-back user agent.
479 LEMONADE leaves the actual implementation to the developer.
506Burger & Parsons Informational [Page 9]
508RFC 5442 LEMONADE Architecture March 2009
513 _________| Notification |
518 | ___|______ _____________
519 | | LEMONADE | | | _____
520 __v__ IMAP | MEM | IMAP |NON-LEMONADE | ESMTP | |
521 | |<--------->|Enabler |<------>|IMAP |<----->| MTA |
522 | MUA |\ ME-2a | Server | |Store | |_____|
523 |_____| \ |__________| |_____________|
527 \ ____v_____ _____________
529 \ | LEMONADE | SUBMIT |NON-LEMONADE | ESMTP | |
530 -->| MEM | |Submit | | |
531 | Enabler |------->|Server |------>| MTA |
532 ME-2b | Server | | | |_____|
533 |__________| |_____________|
535 Figure 4: Architecture to Support Non-LEMONADE IMAP Servers
536 with a LEMONADE Realization of an OMA MEM Enabler
5383.2.2. LEMONADE Realization of OMA MEM with non-IMAP Servers
540 Figure 5 illustrates the cases where the message store and submit
541 servers are not IMAP store or submit servers. They may be Post
542 Office Protocol (POP3) servers or other proprietary message stores.
562Burger & Parsons Informational [Page 10]
564RFC 5442 LEMONADE Architecture March 2009
569 _________| Notification |
574 | ___|______ _____________
575 | | LEMONADE | | | _____
576 __v__ IMAP | MEM | I2 |Proprietary | ESMTP | |
577 | |<--------->|Enabler |<------>|Message |<----->| MTA |
578 | MUA |\ ME-2a | Server | |Store | |_____|
579 |_____| \ |__________| |_____________|
583 \ ____v_____ _____________
585 \ | LEMONADE | I2 |Proprietary | ESMTP | |
586 -->| MEM | |Submit | | |
587 | Enabler |------->|Server |------>| MTA |
588 ME-2b | Server | | | |_____|
589 |__________| |_____________|
591 Figure 5: Architecture to Support Non-IMAP Servers with a LEMONADE
592 Realization of OMA MEM Enabler
594 I2 designates proprietary adapters to the backends.
5964. Filters and Server-to-Client Notifications and LEMONADE
598 OMA MEM Requirements [MEM-req] and Architecture [MEM-arch] emphasize
599 the need to provide mechanisms for server-to-client notifications of
600 email events and filtering. Figure 6 illustrates how notification
601 and filtering works in the LEMONADE profile [PROFILE].
618Burger & Parsons Informational [Page 11]
620RFC 5442 LEMONADE Architecture March 2009
625 _________| Notification |
629 |Protocol -------\ _|__
630 | ______| ___\>|NF|____
632 __v__| IMAP |__ LEMONADE |___ ESMTP __| |
633 | |<-------->|VF| IMAP |DF |<--------|AF| MTA |
634 | MUA |\ ME-2a |-- Store |--- --|_____|
635 |_____| \ |_____________| ^
636 \_\_______________|_______|
641 \ | LEMONADE | ESMTP | |
642 ---->| Submit |--------------->| MTA |
643 ME-2b | Server | |_____|
646 Figure 6: Filtering Mechanism Defined in LEMONADE Architecture
648 In Figure 6, we define four categories of filters:
650 o AF: Administrative Filters - The email service provider usually
651 sets administrative filters. The user typically does not
652 configure AF. AF applies policies covering content filtering,
653 virus protection, spam filtering, etc.
655 o DF: Deposit Filters - Filters that are executed on deposit of new
656 emails. They can be defined as SIEVE filters [SIEVE]. They can
657 include vacation notices [RFC5230]. As SIEVE filters, one can
658 administer them using the SIEVE management protocol [MANAGESIEVE].
660 o VF: View Filters - Filters that define which emails are visible to
661 the MUA. View filters can be performed via IMAP using the
662 facilities described in [NOTIFICATIONS].
664 o NF: Notification Filters - Filters that define for what email
665 server event an out-of-band notification is sent to the client, as
666 described in [NOTIFICATIONS].
668 Refer to the aforementioned references for implementation and
669 management of the respective filters.
674Burger & Parsons Informational [Page 12]
676RFC 5442 LEMONADE Architecture March 2009
6795. Security Considerations
681 We note there are security risks associated with:
683 o Out-of-band notifications
685 o Server configuration by client
687 o Client configuration by server
689 o Presence of MEM proxy servers
691 o Presence of MEM servers as intermediaries
693 o Measures to address the need to traverse firewalls
695 We refer the reader to the relevant Internet Mail, IMAP, SUBMIT, and
696 Lemonade documents for how we address these issues.
700 The authors acknowledge and appreciate the work and comments of the
701 IETF LEMONADE working group and the OMA MEM working group. We
702 extracted the contents of this document from sections of
703 [PROFILE-bis] by Stephane Maes, Alexey Melnikov, and Dave Cridland,
704 as well as sections of [NOTIFICATIONS] by Stephane Maes and Ray
7077. Informative References
709 [EMAIL] Klensin, J., "Simple Mail Transfer Protocol",
710 RFC 5321, October 2008.
712 [MAIL] Crocker, D., "Internet Mail Architecture", Work
713 in Progress, October 2008.
715 [MANAGESIEVE] Melnikov, A. and T. Martin, "A Protocol for Remotely
716 Managing Sieve Scripts", Work in Progress,
719 [MEM-arch] Open Mobile Alliance, "Mobile Email Architecture
721 http://member.openmobilealliance.org/ftp/
722 public_documents/mwg/MEM/Permanent_documents/
723 OMA-AD-Mobile_Email-V1_0_0-20070614-D.zip,
730Burger & Parsons Informational [Page 13]
732RFC 5442 LEMONADE Architecture March 2009
735 [MEM-req] Open Mobile Alliance, "Mobile Email Requirements
736 Document", OMA, http://www.openmobilealliance.org/,
739 [MEM-ts] Open Mobile Alliance, "Mobile Email Technical
740 Specification", OMA, Work in Progress,
741 http://www.openmobilealliance.org/, Oct 2007.
743 [NOTIFICATIONS] Gellens, R. and S. Maes, "Lemonade Notifications
744 Architecture", Work in Progress, July 2008.
746 [PROFILE] Maes, S. and A. Melnikov, "Internet Email to Support
747 Diverse Service Environments (Lemonade) Profile",
750 [PROFILE-bis] Cridland, D., Melnikov, A., and S. Maes, "The
751 Lemonade Profile", Work in Progress, September 2008.
753 [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL -
754 VERSION 4rev1", RFC 3501, March 2003.
756 [RFC4409] Gellens, R. and J. Klensin, "Message Submission for
757 Mail", RFC 4409, April 2006.
759 [RFC5230] Showalter, T. and N. Freed, "Sieve Email Filtering:
760 Vacation Extension", RFC 5230, January 2008.
762 [SIEVE] Guenther, P. and T. Showalter, "Seive: An Email
763 Filtering Language", RFC 5228, January 2008.
786Burger & Parsons Informational [Page 14]
788RFC 5442 LEMONADE Architecture March 2009
800 EMail: eburger@standardstrack.com
801 URI: http://www.standardstrack.com
810 Phone: +1 613 763 7582
811 EMail: gparsons@nortel.com
842Burger & Parsons Informational [Page 15]