Network Working Group E. Burger
Request for Comments: 5442 Consultant
Category: Informational G. Parsons
Nortel Networks
March 2009
Network Working Group E. Burger
Request for Comments: 5442 Consultant
Category: Informational G. Parsons
Nortel Networks
March 2009
LEMONADE Architecture - Supporting Open Mobile Alliance (OMA) Mobile Email (MEM) Using Internet Mail
柠檬水体系结构-支持使用互联网邮件的开放移动联盟（OMA）移动电子邮件（MEM）
Status of This Memo
关于下段备忘
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2009 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
本文件受BCP 78和IETF信托在本文件出版之日生效的与IETF文件有关的法律规定的约束(http://trustee.ietf.org/license-info). 请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
本文件可能包含2008年11月10日之前发布或公开的IETF文件或IETF贡献中的材料。控制某些材料版权的人员可能未授予IETF信托允许在IETF标准流程之外修改此类材料的权利。在未从控制此类材料版权的人员处获得充分许可的情况下，不得在IETF标准流程之外修改本文件，也不得在IETF标准流程之外创建其衍生作品，除了将其格式化以RFC形式发布或将其翻译成英语以外的其他语言。
Abstract
摘要
This document specifies the architecture for mobile email, as described by the Open Mobile Alliance (OMA), using Internet Mail protocols. This architecture was an important consideration for much of the work of the LEMONADE (Enhancements to Internet email to Support Diverse Service Environments) working group in the IETF. This document also describes how the LEMONADE architecture meets OMA's requirements for their Mobile Email (MEM) service.
本文档指定了移动电子邮件的体系结构，如开放移动联盟（OMA）所述，使用Internet邮件协议。该体系结构是IETF中LEMONADE（增强Internet电子邮件以支持多种服务环境）工作组大部分工作的重要考虑因素。本文档还描述了柠檬水体系结构如何满足OMA对其移动电子邮件（MEM）服务的要求。
Table of Contents
目录
1. Introduction ....................................................2
2. OMA Mobile Email (MEM) ..........................................2
2.1. OMA MEM Requirements .......................................2
2.2. OMA MEM Architecture .......................................3
2.2.1. OMA MEM Logical Architecture ........................3
2.2.2. OMA MEM Deployment Issues ...........................4
2.3. OMA MEM Technical Specification ............................6
3. IETF LEMONADE Architecture ......................................6
3.1. Relationship between the OMA MEM and LEMONADE Logical
Architectures ..............................................7
3.2. LEMONADE Realization of OMA MEM with
non-LEMONADE-Compliant Servers .............................9
3.2.1. LEMONADE Realization of OMA MEM with
non-LEMONADE IMAP Servers ...........................9
3.2.2. LEMONADE Realization of OMA MEM with non-IMAP
Servers ............................................10
4. Filters and Server-to-Client Notifications and LEMONADE ........11
5. Security Considerations ........................................13
6. Acknowledgements ...............................................13
7. Informative References .........................................13
1. Introduction ....................................................2
2. OMA Mobile Email (MEM) ..........................................2
2.1. OMA MEM Requirements .......................................2
2.2. OMA MEM Architecture .......................................3
2.2.1. OMA MEM Logical Architecture ........................3
2.2.2. OMA MEM Deployment Issues ...........................4
2.3. OMA MEM Technical Specification ............................6
3. IETF LEMONADE Architecture ......................................6
3.1. Relationship between the OMA MEM and LEMONADE Logical
Architectures ..............................................7
3.2. LEMONADE Realization of OMA MEM with
non-LEMONADE-Compliant Servers .............................9
3.2.1. LEMONADE Realization of OMA MEM with
non-LEMONADE IMAP Servers ...........................9
3.2.2. LEMONADE Realization of OMA MEM with non-IMAP
Servers ............................................10
4. Filters and Server-to-Client Notifications and LEMONADE ........11
5. Security Considerations ........................................13
6. Acknowledgements ...............................................13
7. Informative References .........................................13
This document describes the architecture of OMA Mobile Email (MEM) using Internet Mail protocols defined by the IETF. The LEMONADE working group has enhanced many of these protocols for use in the mobile environment. The LEMONADE profile [PROFILE] and its revision, [PROFILE-bis], summarize such protocols and protocol use. This document shows how the OMA MEM Requirements document [MEM-req], OMA MEM Architecture [MEM-arch], and OMA MEM Technical Specification [MEM-ts] relate to the work of LEMONADE in the IETF.
本文档描述了使用IETF定义的互联网邮件协议的OMA移动电子邮件（MEM）的体系结构。柠檬水工作组已经增强了许多用于移动环境的协议。柠檬水简介[profile]及其修订版[profile bis]总结了此类协议和协议使用。本文件展示了OMA MEM需求文件[MEM req]、OMA MEM架构[MEM arch]和OMA MEM技术规范[MEM ts]与IETF中柠檬水工作的关系。
The OMA Mobile Email (MEM) sub-working group has spent some time studying the requirements and architecture of mobile email. IETF LEMONADE has been liaising with them and has based much of its Internet Mail enhancements on their input. This section summarizes the output of the OMA.
OMA移动电子邮件（MEM）子工作组花了一些时间研究移动电子邮件的需求和体系结构。IETF LEMONADE一直在与他们保持联系，并根据他们的输入对其大部分Internet邮件功能进行了增强。本节总结了OMA的输出。
The OMA MEM activity collected a set of use cases and derived requirements for a Mobile Email (MEM) enabler. The OMA MEM Requirements document [MEM-req] summarizes this work. Some requirements relate to email protocols, some involve other OMA
OMA MEM活动收集了一组移动电子邮件（MEM）启用码的用例和衍生需求。OMA MEM需求文件[MEM req]总结了这项工作。有些要求与电子邮件协议有关，有些要求涉及其他OMA
technologies outside the scope of the IETF, and some relate to implementations and normative interoperability statements for clients and servers.
IETF范围之外的技术，以及一些与客户端和服务器的实现和标准互操作性声明有关的技术。
This section introduces the OMA MEM Architecture.
本节介绍OMA MEM体系结构。
The OMA MEM activity has derived a logical architecture from the requirements and use cases described in [MEM-req]. A simplification for illustrative purposes is shown in Figure 1, where arrows indicate content flows.
OMA MEM活动从[MEM req]中描述的需求和用例中派生出一个逻辑架构。图1显示了用于说明目的的简化，其中箭头表示内容流。
__________
| Other |
+---| Mobile |<--+
| | Enablers | |
| |__________| |
|ME-4 |ME-3
_v____ ___v____ ________
| |ME-1 | | | |
| MEM |-------->| MEM | I2 | Email |
|Client| ME-2| Server |<---->| Server |
|______|<--------|________| |________|
^
|ME-5
|
__________
| Other |
+---| Mobile |<--+
| | Enablers | |
| |__________| |
|ME-4 |ME-3
_v____ ___v____ ________
| |ME-1 | | | |
| MEM |-------->| MEM | I2 | Email |
|Client| ME-2| Server |<---->| Server |
|______|<--------|________| |________|
^
|ME-5
|
Figure 1: Basic OMA MEM Logical Architecture
图1：基本OMA MEM逻辑架构
Figure 1 identifies the following elements:
图1确定了以下要素：
o The MEM client that implements the client-side functionality of the OMA Mobile Email enabler. It is also responsible for providing the mobile email user experience and interface to the user and storing the email and data to be sent to the MEM server when not connected.
o 实现OMA Mobile Email enabler客户端功能的MEM客户端。它还负责向用户提供移动电子邮件用户体验和界面，并存储未连接时发送至MEM服务器的电子邮件和数据。
o The MEM server that implements the server-side functionality of the OMA Mobile Email (MEM) enabler.
o 实现OMA移动电子邮件（MEM）启用码服务器端功能的MEM服务器。
o The MEM protocol between the MEM client and MEM server. It is responsible for all the in-band data exchanges that take place between the MEM client and server in order to update the MEM
o MEM客户端和MEM服务器之间的MEM协议。它负责在MEM客户端和服务器之间进行的所有带内数据交换，以更新MEM
client with email server changes and the email server with changes in the MEM client, and in order to send new email from the email server.
更改了电子邮件服务器的客户端和更改了MEM客户端的电子邮件服务器，以便从电子邮件服务器发送新电子邮件。
o Other OMA enablers that are needed to directly support the Mobile Email enabler. They are out of the scope of the IETF but may include support for:
o 直接支持移动电子邮件启用码所需的其他OMA启用码。它们不在IETF的范围内，但可能包括对以下方面的支持：
* Client provisioning and management for over-the-air installation of the MEM client on the device, provisioning of the client settings, and revocation of client privileges.
* 客户端设置和管理，用于在设备上通过空中安装MEM客户端、设置客户端设置以及撤销客户端权限。
* Messaging enablers for out-of-band notification, where out-of-band notifications that are server-to-client event exchanges are not transported by the MEM protocol but via other channels.
* 用于带外通知的消息传递使能器，其中作为服务器到客户端事件交换的带外通知不是通过MEM协议传输的，而是通过其他通道传输的。
* Billing, charging, and so on.
* 计费、收费等。
OMA identifies different interfaces:
OMA识别不同的接口：
o ME-1: MEM client interface to interact via the MEM protocol with the MEM server.
o ME-1:MEM客户端接口，通过MEM协议与MEM服务器进行交互。
o ME-2: Corresponding interface of the MEM server.
o ME-2：MEM服务器对应的接口。
o ME-3: Out-of-band MEM server interfaces; for example, to support generation of server-to-client notifications.
o ME-3：带外MEM服务器接口；例如，支持生成服务器到客户端的通知。
o ME-4: Out-of-band MEM client interfaces (e.g., to receive server-to-client notifications).
o ME-4：带外MEM客户端接口（例如，接收服务器到客户端的通知）。
o ME-5: Interface for management of MEM enabler server settings, user preferences, and filters, globally and per account.
o ME-5：用于管理MEM enabler服务器设置、用户首选项和过滤器的界面，全局和每个帐户。
The MEM server enables an email server. In a particular implementation, the email server may be packaged with (internal to it) the MEM server or be a separate component. In such cases, interfaces to the email server are out of scope of the OMA MEM specifications. In the present document, we focus on the case where the backend consists of IETF IMAP and SUBMIT servers. However, we also discuss the relationship to other cases. The I2 interface is an OMA notation to designate protocol / interfaces that are not specified by the MEM enabler but may be standardized elsewhere.
MEM服务器启用电子邮件服务器。在特定实现中，电子邮件服务器可以与MEM服务器打包（在其内部），或者是单独的组件。在这种情况下，电子邮件服务器的接口超出OMA MEM规范的范围。在本文档中，我们将重点讨论后端由IETF IMAP和提交服务器组成的情况。然而，我们也讨论了与其他案例的关系。I2接口是一种OMA符号，用于指定MEM enabler未指定但可在其他地方标准化的协议/接口。
The OMA MEM Architecture document [MEM-arch] further identifies deployment models.
OMA MEM体系结构文档[MEM arch]进一步确定了部署模型。
The OMA MEM Architecture document [MEM-arch] identifies OMA MEM server proxies as server components that may be deployed ahead of firewalls to facilitate firewall traversal.
OMA MEM体系结构文档[MEM arch]将OMA MEM服务器代理识别为服务器组件，可在防火墙之前部署这些组件，以促进防火墙穿越。
OMA MEM identifies that each component (MEM client, MEM servers, other enablers, and the email server) may be deployed in different domains, possibly separated by firewalls and other network intermediaries. MEM proxies may be involved in front of a firewall that protects the MEM server domain.
OMA MEM确定每个组件（MEM客户端、MEM服务器、其他使能器和电子邮件服务器）可能部署在不同的域中，可能由防火墙和其他网络中介分隔。MEM代理可能位于保护MEM服务器域的防火墙前面。
OMA MEM targets support of configurations where:
OMA MEM的目标是支持以下配置：
o All components are within the same domain, such as in a mobile operator.
o 所有组件都在同一个域中，例如在移动运营商中。
o The MEM client and other enablers are in the mobile operator domain, there is a MEM proxy, and the MEM server and email server are in the domain of the email service provider.
o MEM客户端和其他启用程序位于移动运营商域中，有一个MEM代理，MEM服务器和电子邮件服务器位于电子邮件服务提供商的域中。
o The MEM client and other enablers as well as a MEM proxy are in the mobile operator domain, and the MEM server and email server are in the domain of the email service provider.
o MEM客户端和其他启用程序以及MEM代理位于移动运营商域中，MEM服务器和电子邮件服务器位于电子邮件服务提供商的域中。
o The MEM client and other enablers are in the mobile operator domain, a MEM proxy is in a third-party service provider domain, and the MEM server and email server are in the domain of the email service provider.
o MEM客户端和其他启用程序位于移动运营商域中，MEM代理位于第三方服务提供商域中，MEM服务器和电子邮件服务器位于电子邮件服务提供商域中。
o The MEM client, other enabler, and MEM server are in the mobile operator domain, and the email server is in the domain of the email service provider.
o MEM客户端、其他启用程序和MEM服务器位于移动运营商域中，电子邮件服务器位于电子邮件服务提供商的域中。
o The MEM client and other enablers are in the mobile operator domain, the MEM server is in a third-party service provider domain, and the email server is in the domain of the email service provider.
o MEM客户端和其他启用程序位于移动运营商域中，MEM服务器位于第三方服务提供商域中，电子邮件服务器位于电子邮件服务提供商域中。
The email service provider can be a third-party service provider, a network service provider, or an enterprise email service.
电子邮件服务提供商可以是第三方服务提供商、网络服务提供商或企业电子邮件服务提供商。
The OMA MEM activity will conclude with a specification for a Mobile Email (MEM) enabler. The ongoing work is in the OMA MEM Technical Specification [MEM-ts]. LEMONADE is a basis for the mechanism. However, some additional details that are outside the scope of the IETF will also be included.
OMA MEM活动将以移动电子邮件（MEM）启用码规范结束。正在进行的工作在OMA MEM技术规范[MEM ts]中。柠檬水是这一机制的基础。然而，IETF范围之外的一些附加细节也将包括在内。
OMA provides ways to perform provisioning via OMA client provisioning and device management. Other provisioning specifications are available (e.g., SMS based).
OMA提供了通过OMA客户端资源调配和设备管理执行资源调配的方法。其他供应规范可用（例如，基于SMS的）。
OMA provides enablers to support out-of-band notification mechanisms, filter specifications (such as XDM), and remote deactivate devices, and to perform other non-Internet activities.
OMA提供了支持带外通知机制、筛选器规范（如XDM）和远程停用设备以及执行其他非Internet活动的启用码。
This section introduces the LEMONADE Architecture.
本节介绍柠檬水体系结构。
The IETF LEMONADE activity has derived a LEMONADE profile [PROFILE-bis] with the logical architecture represented in Figure 2, where arrows indicate content flows.
IETF柠檬水活动已衍生出柠檬水配置文件[profile bis]，其逻辑架构如图2所示，其中箭头表示内容流。
______________
| |
_________| Notification |
| | Mechanism |
| |______________|
|Notif. ^
|Protocol |
| ___|______
| | | _____
__v__ IMAP | LEMONADE | ESMTP | |
| |<----------->| IMAP |<---------------| MTA |
| MUA |- | Store | |_____|
|_____| \ |__________|
\ |
\ |URLAUTH
\SUBMIT |
\ ____v_____
\ | | _____
\ | LEMONADE | ESMTP | |
---->| Submit |--------------->| MTA |
| Server | |_____|
|__________|
______________
| |
_________| Notification |
| | Mechanism |
| |______________|
|Notif. ^
|Protocol |
| ___|______
| | | _____
__v__ IMAP | LEMONADE | ESMTP | |
| |<----------->| IMAP |<---------------| MTA |
| MUA |- | Store | |_____|
|_____| \ |__________|
\ |
\ |URLAUTH
\SUBMIT |
\ ____v_____
\ | | _____
\ | LEMONADE | ESMTP | |
---->| Submit |--------------->| MTA |
| Server | |_____|
|__________|
Figure 2: LEMONADE logical architecture
图2：柠檬水逻辑架构
The LEMONADE profile [PROFILE] assumes:
柠檬水简介[简介]假设：
o IMAP protocol [RFC3501], including LEMONADE profile extensions [PROFILE].
o IMAP协议[RFC3501]，包括柠檬汁配置文件扩展[profile]。
o SUBMIT protocol [RFC4409], including LEMONADE profile extensions.
o 提交协议[RFC4409]，包括柠檬水配置文件扩展。
o LEMONADE profile compliant IMAP store connected to an MTA (Mail Transfer Agent) via the ESMTP [EMAIL].
o 柠檬水配置文件兼容的IMAP存储通过ESMTP[电子邮件]连接到MTA（邮件传输代理）。
o LEMONADE profile compliant submit server connected to an MTA, often via the ESMTP.
o LEMONADE配置文件兼容的提交服务器连接到MTA，通常通过ESMTP。
o Out-of-band server-to-client notifications relying on external notification mechanisms (and notification protocols) that may be out of the scope of the LEMONADE profile.
o 依赖外部通知机制（和通知协议）的带外服务器到客户端通知可能超出LEMONADE概要文件的范围。
o LEMONADE-aware MUA (Mail User Agent). While use of out-of-band notification is described in the LEMONADE profile, support for the underlying notifications mechanisms/protocols is out of the scope of the LEMONADE specifications.
o 柠檬水感知MUA（邮件用户代理）。虽然LEMONADE概要文件中描述了带外通知的使用，但对底层通知机制/协议的支持超出了LEMONADE规范的范围。
Further details on the IETF email protocol stack and architecture can be found in [MAIL].
有关IETF电子邮件协议栈和体系结构的更多详细信息，请参见[MAIL]。
3.1. Relationship between the OMA MEM and LEMONADE Logical Architectures
3.1. OMA MEM和LEMONADE逻辑架构之间的关系
Figure 3 illustrates the mapping of the IETF LEMONADE logical architecture on the OMA MEM logical architecture.
图3说明了IETF柠檬水逻辑架构在OMA MEM逻辑架构上的映射。
_____________________
| Other_Mob. Enablers |
| |--------------| |
_________| Notification | |
| | | Mechanism | |
| | |______________| |
|Notif. |____________^________|
|Protocol ______|__________
ME-4 | | ___|_ME-3_ |
___|____ | | | | _____
| __v__ | IMAP | | LEMONADE | | ESMTP | |
|| |<----------->| IMAP |<-----------| MTA |
|| MUA || ME-2a | | Store | | |_____|
||_____||\ME-1 | |__________| |
| MEM | \ | | |
| Client| \ | |URLAUTH |
|_______| \SUBMIT | |
\ | ____v_____ |
\ | | | | _____
\ | | LEMONADE | | ESMTP | |
---->| Submit |----------->| MTA |
ME-2b | | Server | | |_____|
| |__________| |
|MEM Email |
|Server Server|
|_________________|
^
|ME-5
|
_____________________
| Other_Mob. Enablers |
| |--------------| |
_________| Notification | |
| | | Mechanism | |
| | |______________| |
|Notif. |____________^________|
|Protocol ______|__________
ME-4 | | ___|_ME-3_ |
___|____ | | | | _____
| __v__ | IMAP | | LEMONADE | | ESMTP | |
|| |<----------->| IMAP |<-----------| MTA |
|| MUA || ME-2a | | Store | | |_____|
||_____||\ME-1 | |__________| |
| MEM | \ | | |
| Client| \ | |URLAUTH |
|_______| \SUBMIT | |
\ | ____v_____ |
\ | | | | _____
\ | | LEMONADE | | ESMTP | |
---->| Submit |----------->| MTA |
ME-2b | | Server | | |_____|
| |__________| |
|MEM Email |
|Server Server|
|_________________|
^
|ME-5
|
Figure 3: Mapping of LEMONADE Logical Architecture onto the OMA MEM Logical Architecture
图3：柠檬水逻辑架构到OMA MEM逻辑架构的映射
As described in Section 3, the LEMONADE profile assumes LEMONADE profile compliant IMAP stores and SUBMIT servers. Because the LEMONADE profile extends the IMAP store and the SUBMIT server, the mobile enablement of email provided by the LEMONADE profile is directly provided in these servers. Mapping to the OMA MEM logical architecture for the case considered and specified by the LEMONADE profile, we logically combine the MEM server and email server. However, in LEMONADE we split them logically into a distinct LEMONADE message store and a LEMONADE SUBMIT server. ME-2 consists of two interfaces. ME-2a is IMAP extended according to the LEMONADE profile. ME-2b is SUBMIT extended according to the LEMONADE profile.
如第3节所述，柠檬水配置文件假定柠檬水配置文件符合IMAP存储和提交服务器。因为柠檬水配置文件扩展了IMAP存储和提交服务器，所以柠檬水配置文件提供的电子邮件移动支持直接在这些服务器中提供。映射到OMA MEM逻辑体系结构，对于柠檬汁概要文件所考虑和指定的情况，我们在逻辑上结合了MEM服务器和电子邮件服务器。然而，在LEMONADE中，我们在逻辑上将它们分为一个不同的LEMONADE消息存储和一个LEMONADE提交服务器。ME-2由两个接口组成。ME-2a是根据柠檬水配置文件进行IMAP扩展的。ME-2b根据柠檬水的配置文件进行扩展。
The MUA is part of the MEM client.
MUA是MEM客户机的一部分。
The external notifications mechanism is part of the OMA enablers specified by the OMA.
外部通知机制是OMA指定的OMA启用码的一部分。
3.2. LEMONADE Realization of OMA MEM with non-LEMONADE-Compliant Servers
3.2. 用不兼容柠檬水的服务器实现OMA MEM
The OMA MEM activity is not limited to enabling LEMONADE-compliant servers. It explicitly identifies the need to support other backends. This is, of course, outside the scope of the IETF LEMONADE activity.
OMA MEM活动不限于启用柠檬水兼容的服务器。它明确指出了支持其他后端的需要。当然，这超出了IETF柠檬水活动的范围。
Figure 4 illustrates the case of IMAP servers that are not LEMONADE-compliant. In such case, the I2 interface between the MEM server components and the IMAP store and SUBMIT server are IMAP and SUBMIT without LEMONADE extensions.
图4说明了不符合柠檬水的IMAP服务器的情况。在这种情况下，MEM服务器组件与IMAP存储和提交服务器之间的I2接口是IMAP和提交，没有柠檬水扩展。
It is important to note the realizations are of a schematic nature and do not dictate actual implementation. For example, one could envision collocating the LEMONADE MEM enabler server and the submit server shown in Figure 4 in a single instantiation of the implementation. Likewise, we consciously label the LEMONADE MEM enabler as neither an IMAP proxy nor an IMAP back-to-back user agent. LEMONADE leaves the actual implementation to the developer.
重要的是要注意，实现是示意性的，并不要求实际实现。例如，可以设想在实现的一个实例化中同时配置图4所示的LEMONADE MEM enabler服务器和submit服务器。同样，我们有意识地将LEMONADE MEM enabler标记为既不是IMAP代理也不是IMAP背靠背用户代理。LEMONADE将实际实现留给开发人员。
______________
| |
_________| Notification |
| | Mechanism |
| |______________|
|Notif. ^
|Protocol |
| ___|______ _____________
| | LEMONADE | | | _____
__v__ IMAP | MEM | IMAP |NON-LEMONADE | ESMTP | |
| |<--------->|Enabler |<------>|IMAP |<----->| MTA |
| MUA |\ ME-2a | Server | |Store | |_____|
|_____| \ |__________| |_____________|
\ |
\ |URLAUTH
\SUBMIT |
\ ____v_____ _____________
\ | | | | _____
\ | LEMONADE | SUBMIT |NON-LEMONADE | ESMTP | |
-->| MEM | |Submit | | |
| Enabler |------->|Server |------>| MTA |
ME-2b | Server | | | |_____|
|__________| |_____________|
______________
| |
_________| Notification |
| | Mechanism |
| |______________|
|Notif. ^
|Protocol |
| ___|______ _____________
| | LEMONADE | | | _____
__v__ IMAP | MEM | IMAP |NON-LEMONADE | ESMTP | |
| |<--------->|Enabler |<------>|IMAP |<----->| MTA |
| MUA |\ ME-2a | Server | |Store | |_____|
|_____| \ |__________| |_____________|
\ |
\ |URLAUTH
\SUBMIT |
\ ____v_____ _____________
\ | | | | _____
\ | LEMONADE | SUBMIT |NON-LEMONADE | ESMTP | |
-->| MEM | |Submit | | |
| Enabler |------->|Server |------>| MTA |
ME-2b | Server | | | |_____|
|__________| |_____________|
Figure 4: Architecture to Support Non-LEMONADE IMAP Servers with a LEMONADE Realization of an OMA MEM Enabler
图4：通过OMA MEM Enabler的柠檬水实现来支持非柠檬水IMAP服务器的体系结构
Figure 5 illustrates the cases where the message store and submit servers are not IMAP store or submit servers. They may be Post Office Protocol (POP3) servers or other proprietary message stores.
图5说明了消息存储和提交服务器不是IMAP存储或提交服务器的情况。它们可能是邮局协议（POP3）服务器或其他专有消息存储。
______________
| |
_________| Notification |
| | Mechanism |
| |______________|
|Notif. ^
|Protocol |
| ___|______ _____________
| | LEMONADE | | | _____
__v__ IMAP | MEM | I2 |Proprietary | ESMTP | |
| |<--------->|Enabler |<------>|Message |<----->| MTA |
| MUA |\ ME-2a | Server | |Store | |_____|
|_____| \ |__________| |_____________|
\ |
\ |URLAUTH
\SUBMIT |
\ ____v_____ _____________
\ | | | | _____
\ | LEMONADE | I2 |Proprietary | ESMTP | |
-->| MEM | |Submit | | |
| Enabler |------->|Server |------>| MTA |
ME-2b | Server | | | |_____|
|__________| |_____________|
______________
| |
_________| Notification |
| | Mechanism |
| |______________|
|Notif. ^
|Protocol |
| ___|______ _____________
| | LEMONADE | | | _____
__v__ IMAP | MEM | I2 |Proprietary | ESMTP | |
| |<--------->|Enabler |<------>|Message |<----->| MTA |
| MUA |\ ME-2a | Server | |Store | |_____|
|_____| \ |__________| |_____________|
\ |
\ |URLAUTH
\SUBMIT |
\ ____v_____ _____________
\ | | | | _____
\ | LEMONADE | I2 |Proprietary | ESMTP | |
-->| MEM | |Submit | | |
| Enabler |------->|Server |------>| MTA |
ME-2b | Server | | | |_____|
|__________| |_____________|
Figure 5: Architecture to Support Non-IMAP Servers with a LEMONADE Realization of OMA MEM Enabler
图5：通过OMA MEM Enabler的柠檬水实现支持非IMAP服务器的体系结构
I2 designates proprietary adapters to the backends.
I2为后端指定专有适配器。
OMA MEM Requirements [MEM-req] and Architecture [MEM-arch] emphasize the need to provide mechanisms for server-to-client notifications of email events and filtering. Figure 6 illustrates how notification and filtering works in the LEMONADE profile [PROFILE].
OMA MEM要求[MEM req]和体系结构[MEM arch]强调需要为服务器到客户端的电子邮件事件通知和过滤提供机制。图6说明了柠檬汁配置文件[profile]中通知和过滤的工作原理。
______________
| |
_________| Notification |
| | Mechanism |
| |______________|
|Notif. ^
|Protocol -------\ _|__
| ______| ___\>|NF|____
| | | ---- | _____
__v__| IMAP |__ LEMONADE |___ ESMTP __| |
| |<-------->|VF| IMAP |DF |<--------|AF| MTA |
| MUA |\ ME-2a |-- Store |--- --|_____|
|_____| \ |_____________| ^
\_\_______________|_______|
\ |URLAUTH
\SUBMIT |
\ ____v_____
\ | | _____
\ | LEMONADE | ESMTP | |
---->| Submit |--------------->| MTA |
ME-2b | Server | |_____|
|__________|
______________
| |
_________| Notification |
| | Mechanism |
| |______________|
|Notif. ^
|Protocol -------\ _|__
| ______| ___\>|NF|____
| | | ---- | _____
__v__| IMAP |__ LEMONADE |___ ESMTP __| |
| |<-------->|VF| IMAP |DF |<--------|AF| MTA |
| MUA |\ ME-2a |-- Store |--- --|_____|
|_____| \ |_____________| ^
\_\_______________|_______|
\ |URLAUTH
\SUBMIT |
\ ____v_____
\ | | _____
\ | LEMONADE | ESMTP | |
---->| Submit |--------------->| MTA |
ME-2b | Server | |_____|
|__________|
Figure 6: Filtering Mechanism Defined in LEMONADE Architecture
图6：柠檬水体系结构中定义的过滤机制
In Figure 6, we define four categories of filters:
在图6中，我们定义了四类过滤器：
o AF: Administrative Filters - The email service provider usually sets administrative filters. The user typically does not configure AF. AF applies policies covering content filtering, virus protection, spam filtering, etc.
o AF：管理过滤器-电子邮件服务提供商通常设置管理过滤器。用户通常不配置AF。AF应用覆盖内容过滤、病毒保护、垃圾邮件过滤等的策略。
o DF: Deposit Filters - Filters that are executed on deposit of new emails. They can be defined as SIEVE filters [SIEVE]. They can include vacation notices [RFC5230]. As SIEVE filters, one can administer them using the SIEVE management protocol [MANAGESIEVE].
o DF：存款过滤器-在新电子邮件存款时执行的过滤器。它们可以定义为筛子过滤器[筛子]。它们可以包括假期通知[RFC5230]。作为筛子过滤器，可以使用筛子管理协议[ManageSeeve]对其进行管理。
o VF: View Filters - Filters that define which emails are visible to the MUA. View filters can be performed via IMAP using the facilities described in [NOTIFICATIONS].
o VF：查看筛选器-定义MUA可以看到哪些电子邮件的筛选器。可以使用[通知]中描述的功能通过IMAP执行视图过滤器。
o NF: Notification Filters - Filters that define for what email server event an out-of-band notification is sent to the client, as described in [NOTIFICATIONS].
o NF:Notification Filters—定义带外通知发送到客户端的电子邮件服务器事件的过滤器，如[NOTIFICATIONS]中所述。
Refer to the aforementioned references for implementation and management of the respective filters.
有关各过滤器的实施和管理，请参考上述参考资料。
We note there are security risks associated with:
我们注意到存在与以下相关的安全风险：
o Out-of-band notifications
o 带外通知
o Server configuration by client
o 按客户端的服务器配置
o Client configuration by server
o 按服务器的客户端配置
o Presence of MEM proxy servers
o 存在MEM代理服务器
o Presence of MEM servers as intermediaries
o 存在作为中介的MEM服务器
o Measures to address the need to traverse firewalls
o 解决穿越防火墙需要的措施
We refer the reader to the relevant Internet Mail, IMAP, SUBMIT, and Lemonade documents for how we address these issues.
我们建议读者参考相关的互联网邮件、IMAP、SUBMIT和Lemonade文档，了解我们如何解决这些问题。
The authors acknowledge and appreciate the work and comments of the IETF LEMONADE working group and the OMA MEM working group. We extracted the contents of this document from sections of [PROFILE-bis] by Stephane Maes, Alexey Melnikov, and Dave Cridland, as well as sections of [NOTIFICATIONS] by Stephane Maes and Ray Cromwell.
作者承认并赞赏IETF柠檬水工作组和OMA MEM工作组的工作和评论。我们从Stephane Maes、Alexey Melnikov和Dave Cridland的[PROFILE bis]章节以及Stephane Maes和Ray Cromwell的[Notification]章节中摘录了本文件的内容。
[EMAIL] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, October 2008.
[电子邮件]Klensin，J.，“简单邮件传输协议”，RFC 53212008年10月。
[MAIL] Crocker, D., "Internet Mail Architecture", Work in Progress, October 2008.
[邮件]Crocker，D.，“互联网邮件体系结构”，正在进行的工作，2008年10月。
[MANAGESIEVE] Melnikov, A. and T. Martin, "A Protocol for Remotely Managing Sieve Scripts", Work in Progress, January 2009.
[管理筛]Melnikov，A.和T.Martin，“远程管理筛脚本的协议”，正在进行的工作，2009年1月。
[MEM-arch] Open Mobile Alliance, "Mobile Email Architecture Document", OMA, http://member.openmobilealliance.org/ftp/ public_documents/mwg/MEM/Permanent_documents/ OMA-AD-Mobile_Email-V1_0_0-20070614-D.zip, June 2007.
[MEM arch]开放移动联盟，“移动电子邮件架构文档”，OMA，http://member.openmobilealliance.org/ftp/ public_documents/mwg/MEM/Permanent_documents/OMA-AD-Mobile_Email-V1_0_0-20070614-D.zip，2007年6月。
[MEM-req] Open Mobile Alliance, "Mobile Email Requirements Document", OMA, http://www.openmobilealliance.org/, Oct 2005.
[MEM req]开放移动联盟，“移动电子邮件需求文件”，OMA，http://www.openmobilealliance.org/，2005年10月。
[MEM-ts] Open Mobile Alliance, "Mobile Email Technical Specification", OMA, Work in Progress, http://www.openmobilealliance.org/, Oct 2007.
[MEM ts]开放移动联盟，“移动电子邮件技术规范”，OMA，正在进行的工作，http://www.openmobilealliance.org/，2007年10月。
[NOTIFICATIONS] Gellens, R. and S. Maes, "Lemonade Notifications Architecture", Work in Progress, July 2008.
[通知]Gellens，R.和S.Maes，“柠檬水通知体系结构”，正在进行的工作，2008年7月。
[PROFILE] Maes, S. and A. Melnikov, "Internet Email to Support Diverse Service Environments (Lemonade) Profile", RFC 4550, June 2006.
[简介]Maes，S.和A.Melnikov，“支持多样化服务环境的互联网电子邮件（柠檬水）简介”，RFC 45502006年6月。
[PROFILE-bis] Cridland, D., Melnikov, A., and S. Maes, "The Lemonade Profile", Work in Progress, September 2008.
[简介之二]Cridland，D.，Melnikov，A.，和S.Maes，“柠檬水简介”，正在进行的工作，2008年9月。
[RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", RFC 3501, March 2003.
[RFC3501]Crispin，M.，“互联网消息访问协议-版本4rev1”，RFC 35012003年3月。
[RFC4409] Gellens, R. and J. Klensin, "Message Submission for Mail", RFC 4409, April 2006.
[RFC4409]Gellens，R.和J.Klensin，“邮件邮件提交”，RFC 4409，2006年4月。
[RFC5230] Showalter, T. and N. Freed, "Sieve Email Filtering: Vacation Extension", RFC 5230, January 2008.
[RFC5230]Showalter，T.和N.Freed，“筛选电子邮件过滤：假期延长”，RFC 5230，2008年1月。
[SIEVE] Guenther, P. and T. Showalter, "Seive: An Email Filtering Language", RFC 5228, January 2008.
[SIEVE]Guenther，P.和T.Showalter，“Seive：电子邮件过滤语言”，RFC 52282008年1月。
Authors' Addresses
作者地址
Eric W. Burger Consultant New Hampshire USA
Eric W.Burger咨询公司美国新罕布什尔州
Phone:
Fax: +1 530-267-7447
EMail: eburger@standardstrack.com
URI: http://www.standardstrack.com
Phone:
Fax: +1 530-267-7447
EMail: eburger@standardstrack.com
URI: http://www.standardstrack.com
Glenn Parsons Nortel Networks 3500 Carling Avenue Ottawa, ON K2H 8E9 Canada
加拿大K2H 8E9渥太华卡林大道3500号格伦帕森斯北电网络
Phone: +1 613 763 7582
EMail: gparsons@nortel.com
Phone: +1 613 763 7582
EMail: gparsons@nortel.com