Network Working Group R. Gellens
Request for Comments: 5383 Qualcomm
BCP: 143 October 2008
Category: Best Current Practice
Network Working Group R. Gellens
Request for Comments: 5383 Qualcomm
BCP: 143 October 2008
Category: Best Current Practice
Deployment Considerations for Lemonade-Compliant Mobile Email
柠檬水兼容移动电子邮件的部署注意事项
Status of This Memo
关于下段备忘
This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited.
本文件规定了互联网社区的最佳现行做法，并要求进行讨论和提出改进建议。本备忘录的分发不受限制。
Abstract
摘要
This document discusses deployment issues and describes requirements for successful deployment of mobile email that are implicit in the IETF lemonade documents.
本文档讨论了部署问题，并描述了IETF lemonade文档中隐含的成功部署移动电子邮件的要求。
Table of Contents
目录
1. Introduction ....................................................2
2. Conventions Used in This Document ...............................2
3. Ports ...........................................................2
4. TCP Connections .................................................3
4.1. Lifetime ...................................................4
4.2. Maintenance during Temporary Transport Loss ................5
5. Dormancy ........................................................6
6. Firewalls .......................................................6
6.1. Firewall Traversal .........................................7
7. NATs ............................................................8
8. Security Considerations .........................................8
9. Acknowledgments ................................................10
10. Normative References ..........................................10
11. Informative References ........................................10
1. Introduction ....................................................2
2. Conventions Used in This Document ...............................2
3. Ports ...........................................................2
4. TCP Connections .................................................3
4.1. Lifetime ...................................................4
4.2. Maintenance during Temporary Transport Loss ................5
5. Dormancy ........................................................6
6. Firewalls .......................................................6
6.1. Firewall Traversal .........................................7
7. NATs ............................................................8
8. Security Considerations .........................................8
9. Acknowledgments ................................................10
10. Normative References ..........................................10
11. Informative References ........................................10
The IETF lemonade group has developed a set of extensions to IMAP and Message Submission, along with a profile document that restricts server behavior and describes client usage [PROFILE].
IETF lemonade小组开发了一组IMAP和消息提交的扩展，以及一个限制服务器行为和描述客户端使用的概要文件[profile]。
Successful deployment of lemonade-compliant mobile email requires various functionality that is generally assumed and hence not often covered in email RFCs. This document describes some of these additional considerations, with a focus on those that have been reported to be problematic.
成功部署符合柠檬水标准的移动电子邮件需要各种功能，这些功能通常都是假定的，因此电子邮件RFC中通常不包括这些功能。本文件描述了其中一些额外的注意事项，重点是那些据报告存在问题的注意事项。
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 [KEYWORDS].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[关键词]中所述进行解释。
Both IMAP and Message Submission have been assigned well-known ports [IANA] that MUST be available. IMAP uses port 143. Message Submission uses port 587. It is REQUIRED that the client be able to contact the server on these ports. Hence, the client and server systems, as well as any intermediary systems, MUST allow communication on these ports.
IMAP和邮件提交都分配了必须可用的已知端口[IANA]。IMAP使用端口143。消息提交使用端口587。客户机必须能够通过这些端口与服务器联系。因此，客户机和服务器系统以及任何中间系统都必须允许在这些端口上进行通信。
Historically, Message User Agents (MUAs) have used port 25 for Message Submission, and [SUBMISSION] does accommodate this. However, it has become increasingly common for ISPs and organizations to restrict outbound port 25. Additionally, hotels and other public accommodations sometimes intercept port 25 connections, regardless of the destination host, resulting in users unexpectedly submitting potentially sensitive communications to unknown and untrusted third-party servers. Typically, users are not aware of such interception. (Such interception violates [FIREWALLS] and has many negative consequences.)
从历史上看，消息用户代理（MUA）使用端口25进行消息提交，而[Submission]确实满足了这一要求。然而，ISP和组织限制25号出站端口已变得越来越普遍。此外，酒店和其他公共设施有时会拦截端口25连接，而不管目标主机是什么，导致用户意外地向未知和不受信任的第三方服务器提交可能敏感的通信。通常，用户不知道这种拦截。（这种拦截违反了[防火墙]并产生许多负面后果。）
Due to endemic security vulnerabilities in widely deployed SMTP servers, organizations often employ application-level firewalls that intercept SMTP and permit only a limited subset of the protocol. New extensions are therefore more difficult to deploy on port 25. Since lemonade requires support for several [SUBMISSION] extensions, it is extremely important that lemonade clients use, and lemonade servers listen on, port 587 by default.
由于广泛部署的SMTP服务器中普遍存在安全漏洞，组织通常使用应用程序级防火墙拦截SMTP，并且只允许协议的有限子集。因此，在端口25上部署新的扩展更加困难。由于lemonade需要支持几个[SUBMISSION]扩展，因此lemonade客户端使用默认端口587，lemonade服务器监听端口587是非常重要的。
In addition to communications between the client and server systems, lemonade requires that the Message Submission server be able to establish a TCP connection to the IMAP server (for forward-without-download). This uses port 143 by default.
除了客户端和服务器系统之间的通信之外，lemonade还要求消息提交服务器能够建立到IMAP服务器的TCP连接（用于转发而无需下载）。默认情况下，它使用端口143。
Messaging clients sometimes use protocols to store, retrieve, and update configuration and preference data. Functionality such as setting a new device to use the configuration and preference data of another device, or having a device inherit default configuration data from a user account, an organization, or other source, is likely to be even more useful with small mobile devices. Various protocols can be used for configuration and preference data; most of these protocols have designated ports. It is important that clients be able to contact such servers on the appropriate ports. As an example, one protocol that can be used for this purpose is [ACAP], in which case port 674 needs to be available.
消息传递客户端有时使用协议来存储、检索和更新配置和首选项数据。将新设备设置为使用另一设备的配置和首选项数据，或让设备从用户帐户、组织或其他源继承默认配置数据等功能对于小型移动设备可能更有用。各种协议可用于配置和偏好数据；大多数协议都有指定的端口。客户机能够通过适当的端口与此类服务器联系非常重要。例如，可用于此目的的一个协议是[ACAP]，在这种情况下，端口674需要可用。
Note that systems that do not support application use of [TCP] on arbitrary ports are not full Internet clients. As a result, such systems use gateways to the Internet that necessarily result in data integrity problems.
请注意，不支持在任意端口上应用程序使用[TCP]的系统不是完整的Internet客户端。因此，此类系统使用到互联网的网关，这必然导致数据完整性问题。
Both IMAP and Message Submission use [TCP]. Hence, the client system MUST be able to establish and maintain TCP connections to these servers. The Message Submission server MUST be able to initiate a connection to the IMAP server. Support for application use of [TCP] is REQUIRED of both client and server systems.
IMAP和消息提交都使用[TCP]。因此，客户端系统必须能够建立和维护到这些服务器的TCP连接。邮件提交服务器必须能够启动到IMAP服务器的连接。客户端和服务器系统都需要支持[TCP]的应用程序使用。
The requirements and advice in [HOST-REQUIREMENTS] SHOULD be followed.
应遵守[主机要求]中的要求和建议。
Note that, for environments that do not support application use of [TCP] but do so for HTTP, email can be offered by deploying webmail. Webmail is a common term for email over the web, where a server speaks HTTP to the client and an email protocol (often IMAP) to the mail store. Its functionality is necessarily limited by the capabilities of the web client, the webmail server, the protocols used between the webmail server and the client (HTTP and a markup language such as HTML), and between the webmail server and the mail store. However, if HTTP is all that is available to an application, the environment is by definition limited and thus, functionality offered to the user must also be limited, and can't be lemonade compliant.
请注意，对于不支持应用程序使用[TCP]但支持HTTP的环境，可以通过部署webmail来提供电子邮件。Webmail是web上电子邮件的常用术语，其中服务器向客户端发送HTTP，向邮件存储发送电子邮件协议（通常为IMAP）。它的功能必然受到web客户端、webmail服务器、webmail服务器和客户端之间使用的协议（HTTP和HTML等标记语言）以及webmail服务器和邮件存储之间使用的协议的限制。但是，如果应用程序只能使用HTTP，那么环境就受到定义的限制，因此，提供给用户的功能也必须受到限制，并且不能兼容柠檬水。
In this document, "idle" refers to the idle time, as in the "established connection idle-timeout" of [BEHAVE-TCP], while "duration" refers to the total time that a TCP connection has been established.
在本文档中，“空闲”是指空闲时间，如[BEHAVE-TCP]的“已建立连接空闲超时”，而“持续时间”是指已建立TCP连接的总时间。
The duration of the TCP connections between the client and server systems for both IMAP and Message Submission can be arbitrarily long. The client system, the server, as well as all intermediate systems MUST NOT terminate these TCP connections simply because of their duration (that is, just because of how long they have been open).
IMAP和消息提交的客户端和服务器系统之间的TCP连接的持续时间可以任意长。客户机系统、服务器以及所有中间系统不能仅仅因为这些TCP连接的持续时间（也就是说，仅仅因为它们已经打开了多长时间）而终止它们。
Lemonade depends on idle timers being enforced only at the application level (IMAP and Message Submission): if no data is received within a period of time, either side MAY terminate the connection as permitted by the protocol (see [SUBMISSION] or [IMAP]). Since IMAP permits unsolicited notifications of state changes, it is reasonable for clients to remain connected for extended periods with no data being exchanged. Being forced to send data just to keep the connection alive can prevent or hinder optimizations such as dormancy mode (see Section 5).
Lemonade依赖于仅在应用程序级别强制执行的空闲计时器（IMAP和消息提交）：如果在一段时间内未收到任何数据，任何一方都可以根据协议的允许终止连接（请参阅[Submission]或[IMAP]）。由于IMAP允许未经请求的状态更改通知，因此客户端可以在不交换数据的情况下长时间保持连接。强制发送数据只是为了使连接保持活动状态，这可能会阻止或阻碍诸如休眠模式之类的优化（请参见第5节）。
Two hours is a fairly common configuration timeout at middleboxes. That is, there are a number of sites at which TCP connections are torn down by the network two hours after data was last sent in either direction (for example, REQ-5 in [BEHAVE-TCP]). Thus, lemonade clients and servers SHOULD make sure that, in the absence of a specific configuration setting that specifies a longer maximum idle interval, the TCP connection does not remain idle for two hours. This rule ensures that, by default, lemonade clients and servers operate in environments configured with a two-hour maximum for idle TCP connections. Network and server operators can still permit IMAP connections to remain idle in excess of two hours and thus increase the benefits of dormancy, by configuring lemonade clients and servers, and network equipment, to allow this.
两个小时是中间盒上相当常见的配置超时。也就是说，有许多站点的TCP连接在上次向任一方向发送数据两小时后被网络中断（例如，[BEHAVE-TCP]中的REQ-5）。因此，lemonade客户端和服务器应该确保，在没有指定更长的最大空闲时间间隔的特定配置设置的情况下，TCP连接不会保持空闲两小时。此规则确保默认情况下，lemonade客户端和服务器在配置了最多两小时空闲TCP连接的环境中运行。网络和服务器运营商仍然可以允许IMAP连接保持空闲超过两小时，从而通过配置柠檬水客户端和服务器以及网络设备来增加休眠的好处。
It has been reported that some networks impose duration time restrictions of their own on TCP connections other than HTTP. Such behavior is harmful to email and all other TCP-based protocols. It is unclear how widespread such reported behavior is, or if it is an accidental consequence of an attempt at optimizing for HTTP traffic, implementation limitations in firewalls, NATs, or other devices, or a deliberate choice. In any case, such a barrier to TCP connections is a significant risk to the increasing usage of IETF protocols on such networks. Note that TCP is designed to be more efficient when it is
据报道，有些网络对HTTP以外的TCP连接施加自己的持续时间限制。这种行为对电子邮件和所有其他基于TCP的协议都是有害的。目前尚不清楚这种报告的行为有多普遍，或者它是否是试图优化HTTP流量、防火墙、NAT或其他设备中的实现限制或故意选择的意外结果。在任何情况下，TCP连接的这种障碍对于此类网络上日益增加的IETF协议使用是一个重大风险。请注意，TCP的设计目的是在
used to transfer data over time. Prohibiting such connections thus imposes hidden costs on an operator's network, forcing clients to use TCP in inefficient ways. One way in which carriers can inadvertently force TCP connections closed, resulting in users wasting packets by reopening them, is described in Section 7.
用于随时间传输数据。因此，禁止此类连接会给运营商的网络带来隐藏成本，迫使客户机以低效的方式使用TCP。第7节描述了运营商可能无意中强制关闭TCP连接的一种方式，导致用户通过重新打开数据包而浪费数据包。
Note that systems remain able to terminate TCP connections at any time based on local decisions, for example, to prevent overload during a denial-of-service attack. These mechanisms are permitted to take idle time into consideration and are not affected by these requirements.
请注意，系统仍然能够根据本地决定随时终止TCP连接，例如，在拒绝服务攻击期间防止过载。允许这些机制考虑空闲时间，并且不受这些要求的影响。
TCP is designed to withstand temporary loss of lower-level connectivity. Such transient loss is not uncommon in mobile systems (for example, due to handoffs, fade, etc.). The TCP connection SHOULD be able to survive temporary lower-level loss when the IP address of the client does not change (for example, short-duration loss of the mobile device's traffic channel or periods of high packet loss). Thus, the TCP/IP stack on the client, the server, and all intermediate systems SHOULD maintain the TCP connection during transient loss of connectivity.
TCP设计用于承受较低级别连接的临时丢失。这种瞬时丢失在移动系统中并不少见（例如，由于切换、衰减等）。当客户端的IP地址不变时（例如，移动设备的通信信道短时间丢失或高数据包丢失），TCP连接应该能够经受住暂时的低级别丢失。因此，客户端、服务器和所有中间系统上的TCP/IP堆栈应在连接暂时中断期间保持TCP连接。
In general, applications can choose whether or not to enable TCP keep-alives, but in many cases are unable to affect any other aspect of TCP keep-alive operation, such as time between keep-alive packets, number of packets sent before the connection is aborted, etc. In some environments, these are operating system tuning parameters not under application control. In some cases, operational difficulties have been reported with application use of the TCP keep-alive option, which might be the result of TCP implementation differences or defects specific to a platform. Lemonade client and server systems SHOULD NOT set the TCP keep-alive socket option unless operating in environments where this works correctly and such packets will not be sent more frequently than every two hours. Application-level keep-alives (such as IMAP NOOP) MAY be used instead of the TCP keep-alive option.
通常，应用程序可以选择是否启用TCP keep-alives，但在许多情况下无法影响TCP keep-alive操作的任何其他方面，例如keep-alive数据包之间的时间间隔、连接中止前发送的数据包数等。在某些环境中，这些是不受应用程序控制的操作系统调整参数。在某些情况下，报告了应用程序使用TCP保持活动选项时出现的操作困难，这可能是由于TCP实现差异或特定于平台的缺陷造成的。Lemonade客户端和服务器系统不应设置TCP保持活动套接字选项，除非在正常工作的环境中运行，并且此类数据包的发送频率不会超过每两小时一次。可以使用应用程序级keep-alives（例如IMAP NOOP）代替TCP keep-alive选项。
Client, server, and intermediate systems MUST comply with the "Destination Unreachable -- codes 0, 1, 5" text in Section 4.2.3.9 of [HOST-REQUIREMENTS], which states "Since these Unreachable messages indicate soft error conditions, TCP MUST NOT abort the connection".
客户端、服务器和中间系统必须符合[HOST-REQUIREMENTS]第4.2.3.9节中的“Destination Unreachable--codes 0，1，5”文本，该文本规定“由于这些无法访问的消息表示软错误条件，TCP不得中止连接”。
Cellular data channels are connection-oriented (they are brought up or down to establish or tear down connections); it costs network resources to establish connections. Generally speaking, mobile device battery charges last longer when the traffic channel is used less.
蜂窝数据信道是面向连接的（它们被打开或关闭以建立或断开连接）；建立连接需要花费网络资源。一般来说，当流量通道使用较少时，移动设备电池充电持续时间较长。
Some mobile devices and networks support dormant mode, in which the traffic channel is brought down during idle periods, yet the PPP or equivalent level remains active, and the mobile retains its IP address.
一些移动设备和网络支持休眠模式，在这种模式下，业务信道在空闲期间关闭，但PPP或同等级别保持活动，移动设备保留其IP地址。
Maintenance of TCP connections during dormancy SHOULD be supported by the client, server, and any intermediate systems, as described in Sections 4.1 and 4.2.
如第4.1节和第4.2节所述，客户端、服务器和任何中间系统应支持在休眠期间维护TCP连接。
Sending packets just to keep the session active causes unnecessary channel establishment and timeout; with a long-idle TCP connection, this would periodically bring up the channel and then let it idle until it times out, again and again. However, in the absence of specific configuration information to the contrary, it is necessary to do this to ensure correct operation by default.
发送数据包只是为了保持会话活动，这会导致不必要的通道建立和超时；对于长空闲TCP连接，这将定期启动通道，然后让它空闲，直到它一次又一次超时。但是，如果没有相反的特定配置信息，则有必要这样做，以确保默认情况下的正确操作。
New services must necessarily have their traffic pass through firewalls in order to be usable by corporate employees or organization members connecting externally, such as when using mobile devices. Firewalls exist to block traffic, yet exceptions must be made for services to be used. There is a body of best practices based on long experience in this area. Numerous techniques exist to help organizations balance protecting themselves and providing services to their members, employees, and/or customers. (Describing, or even enumerating, such techniques and practices is beyond the scope of this document, but Section 8 does mention some.)
新服务必须使其流量通过防火墙，以便公司员工或组织成员能够使用外部连接，例如在使用移动设备时。防火墙的存在是为了阻止流量，但要使用的服务必须有例外。在这一领域有大量基于长期经验的最佳实践。有许多技术可以帮助组织平衡自我保护和向其成员、员工和/或客户提供服务。（描述或列举此类技术和实践超出了本文件的范围，但第8节确实提到了一些。）
It is critical that protocol design and architecture permit such practices, and not constrain them. One key way in which the design of a new service can aid its secure deployment is to maintain the one-to-one association of services and port numbers.
协议设计和体系结构允许而不是限制这些实践是至关重要的。新服务的设计可以帮助其安全部署的一个关键方法是维护服务和端口号的一对一关联。
One or more firewalls might exist in the path between the client and server systems, as well as between the Message Submission and IMAP servers. Proper deployment REQUIRES that TCP connections be possible from the client system to the IMAP and Message Submission ports on the servers, as well as from the Message Submission server to the IMAP server. This may require configuring firewalls to permit such usage.
一个或多个防火墙可能存在于客户端和服务器系统之间以及消息提交和IMAP服务器之间的路径中。正确部署要求可以从客户端系统到服务器上的IMAP和消息提交端口，以及从消息提交服务器到IMAP服务器的TCP连接。这可能需要配置防火墙以允许此类使用。
Firewalls deployed in the network path MUST NOT damage protocol traffic. In particular, both Message Submission and IMAP connections from the client MUST be permitted. Firewalls MUST NOT partially block extensions to these protocols, such as by allowing one side of an extension negotiation, as doing so results in the two sides being out of synch, with later failures. See [FIREWALLS] for more discussion.
部署在网络路径中的防火墙不得损坏协议流量。特别是，必须允许来自客户端的消息提交和IMAP连接。防火墙不得部分阻止对这些协议的扩展，例如允许扩展协商的一方，因为这样做会导致双方不同步，随后会出现故障。有关更多讨论，请参阅[防火墙]。
Application proxies, which are not uncommon mechanisms, are discussed in [PROXIES].
应用程序代理是一种常见的机制，在[proxies]中讨论。
An often-heard complaint from those attempting to deploy new services within an organization is that the group responsible for maintaining the firewall is unable or unwilling to open the required ports. The group that owns the firewall, being charged with organizational network security, is often reluctant to open firewall ports without an understanding of the benefits and the security implications of the new service.
试图在组织内部署新服务的人经常听到的抱怨是，负责维护防火墙的组无法或不愿意打开所需的端口。负责组织网络安全的防火墙所有者通常不愿意在不了解新服务的好处和安全含义的情况下打开防火墙端口。
The group wishing to deploy a new service is often tempted to bypass the procedure and internal politics necessary to open the firewall ports. A tempting kludge is to tunnel the new service over an existing service that is already permitted to pass through the firewall, typically HTTP on port 80 or sometimes SMTP on port 25. Some of the downsides to this are discussed in [KLUDGE].
希望部署新服务的组通常会绕过打开防火墙端口所需的过程和内部政治。一个诱人的难题是通过隧道将新服务传输到已被允许通过防火墙的现有服务上，通常是端口80上的HTTP，有时是端口25上的SMTP。[KLUDGE]中讨论了这方面的一些不利因素。
Such a bypass can appear to be immediately successful, since the new service seems to deploy. However, assuming the network security group is competent, when they become aware of the kludge, their response is generally to block the violation of organizational security policy. It is difficult to design an application-level proxy/firewall that can provide such access control without violating the transparency requirements of firewalls, as described in [FIREWALLS]. Collateral damage is common in these circumstances. The new service (which initially appeared to have been successfully deployed) as well as those existing services that were leveraged to tunnel the new service, become subject to arbitrary and unpredictable
由于新服务似乎已经部署完毕，这样的绕过看起来会立即成功。然而，假设网络安全组是有能力的，当他们意识到这个问题时，他们的反应通常是阻止违反组织安全策略。如[firewalls]中所述，很难设计一个能够在不违反防火墙透明度要求的情况下提供此类访问控制的应用程序级代理/防火墙。在这些情况下，附带损害很常见。新服务（最初似乎已成功部署）以及那些利用隧道传输新服务的现有服务都会受到任意和不可预测的影响
failures. This encourages an adversarial relationship between the two groups, which hinders attempts at resolution.
失败。这鼓励了两个团体之间的敌对关系，从而阻碍了解决问题的努力。
Even more serious is what happens if a vulnerability is discovered in the new service. Until the vulnerability is corrected, the network security group must disable both the new service and the (typically mission-critical) existing service on which it is layered.
更严重的是，如果在新服务中发现漏洞，会发生什么情况。在更正漏洞之前，网络安全组必须同时禁用新服务和（通常是关键任务）现有服务（它是分层的）。
An often-repeated truism is that any computer that is connected to a network is insecure. Security and usefulness are both considerations, with organizations making choices about achieving acceptable measures in both areas. Deploying new services typically requires deciding to permit access to the ports used by the service, with appropriate protections. While the delay necessary to review the implications of a new service may be frustrating, in the long run, it is likely to be less expensive than a kludge.
一个经常重复的真理是，任何连接到网络的计算机都是不安全的。安全性和有用性都是考虑因素，组织会选择在这两个领域实现可接受的措施。部署新服务通常需要决定允许访问服务使用的端口，并提供适当的保护。虽然审查一项新服务的影响所需的延迟可能令人沮丧，但从长远来看，它可能比一项杂乱无章的服务更便宜。
Any NAT boxes that are deployed between client and server systems MUST comply with REQ-5 in [BEHAVE-TCP], which requires that "the value of the 'established connection idle-timeout' MUST NOT be less than 2 hours 4 minutes".
在客户端和服务器系统之间部署的任何NAT盒必须符合[BEHAVE-TCP]中的REQ-5，其中要求“已建立连接空闲超时”的值不得小于2小时4分钟”。
See Section 5 for additional information on connection lifetimes.
有关连接寿命的更多信息，请参见第5节。
Note that IMAP and Message Submission clients will automatically re-open TCP connections as needed, but it saves time, packets, and processing to avoid the need to do so. Re-opening IMAP and Message Submission connections generally incurs costs for authentication, Transport Layer Security (TLS) negotiation, and server processing, as well as resetting of TCP behavior, such as windows. It is also wasteful to force clients to send NOOP commands just to maintain NAT state, especially since this can defeat dormancy mode.
请注意，IMAP和消息提交客户端将根据需要自动重新打开TCP连接，但这样可以节省时间、数据包和处理，从而避免这样做。重新打开IMAP和消息提交连接通常会导致身份验证、传输层安全性（TLS）协商、服务器处理以及重新设置TCP行为（如windows）的成本。强制客户端发送NOOP命令只是为了维护NAT状态也是一种浪费，特别是因为这样可以克服休眠模式。
There are numerous security considerations whenever an organization chooses to make any of its services available via the Internet. This includes email from mobile clients.
每当一个组织选择通过互联网提供其任何服务时，都有许多安全方面的考虑。这包括来自移动客户端的电子邮件。
Sites concerned about email security should perform a threat analysis, get relevant protections in place, and then make a conscious decision to open up this service. As discussed in Section 6.1, piggybacking email traffic on the HTTP port in an attempt to avoid making a firewall configuration change to explicitly permit mobile email connections would bypass this important step and reduce the overall security of the system.
关注电子邮件安全的网站应该进行威胁分析，采取相应的保护措施，然后有意识地决定开放这项服务。如第6.1节所述，在HTTP端口上承载电子邮件流量以避免更改防火墙配置以明确允许移动电子邮件连接将绕过这一重要步骤并降低系统的整体安全性。
Organizations deploying a messaging server "on the edge" (that is, accessible from the open Internet) are encouraged to choose one that has been designed to operate in that environment.
鼓励部署“边缘”消息传递服务器（即可从开放Internet访问）的组织选择一个设计用于在该环境中运行的服务器。
This document does not attempt to catalogue either the various risks an organization might face or the numerous techniques that can be used to protect against the risks. However, to help illustrate the deployment considerations, a very small sample of some of the risks and countermeasures appear below.
本文件不试图对组织可能面临的各种风险或可用于防范风险的多种技术进行分类。然而，为了帮助说明部署注意事项，下面给出了一些风险和对策的一个非常小的示例。
Some organizations are concerned that permitting direct access to their mail servers via the Internet increases their vulnerability, since a successful exploit against a mail server can potentially expose all mail and authentication credentials stored on that server, and can serve as an injection point for spam. In addition, there are concerns over eavesdropping or modification of mail data and authentication credentials.
一些组织担心，允许通过Internet直接访问其邮件服务器会增加其漏洞，因为成功利用邮件服务器可能会暴露存储在该服务器上的所有邮件和身份验证凭据，并可作为垃圾邮件的注入点。此外，还存在窃听或修改邮件数据和身份验证凭据的问题。
A large number of approaches exist that can mitigate the risks while allowing access to mail services via mobile clients.
存在大量的方法可以降低风险，同时允许通过移动客户端访问邮件服务。
Placing servers inside one or more DMZs (demilitarized zones, also called perimeter networks) can protect the rest of the network from a compromised server. An additional way to reduce the risk is to store authentication credentials on a system that is not accessible from the Internet and that the servers within the DMZ can access only by sending the credentials as received from the client and receiving an authorized/not authorized response. Such isolation reduces the ability of a compromised server to serve as a base for attacking other network hosts.
将服务器放置在一个或多个DMZ（非军事区域，也称为外围网络）内可以保护网络的其余部分不受受损服务器的影响。降低风险的另一种方法是将身份验证凭据存储在无法从Internet访问的系统上，并且DMZ内的服务器只能通过发送从客户端接收的凭据并接收授权/未授权响应来访问该系统。这种隔离降低了受损服务器作为攻击其他网络主机的基础的能力。
Many additional techniques for further isolation exist, such as having the DMZ IMAP server have no mail store of its own. When a client connects to such a server, the DMZ IMAP server might contact the authentication server and receive a ticket, which it passes to the mail store in order to access the client's mail. In this way, a compromised IMAP server cannot be used to access the mail or credentials for other users.
存在许多用于进一步隔离的附加技术，例如DMZ IMAP服务器没有自己的邮件存储。当客户机连接到这样的服务器时，DMZ IMAP服务器可能会联系身份验证服务器并接收一个票证，它会将该票证传递到邮件存储以访问客户机的邮件。这样，受损的IMAP服务器就不能用于访问其他用户的邮件或凭据。
It is important to realize that simply throwing an extra box in front of the mail servers, such as a gateway that may use HTTP or any of a number of synchronization protocols to communicate with clients, does not itself change the security aspects. By adding such a gateway, the overall security of the system, and the vulnerability of the mail servers, may remain unchanged or may be significantly worsened. Isolation and indirection can be used to protect against specific risks, but to be effective, such steps need to be done after a threat analysis, and with an understanding of the issues involved.
重要的是要认识到，仅仅在邮件服务器前面扔一个额外的盒子，例如可能使用HTTP或任何一种同步协议与客户机通信的网关，本身并不会改变安全方面。通过添加这样一个网关，系统的整体安全性和邮件服务器的漏洞可能会保持不变或显著恶化。隔离和间接可用于防范特定风险，但为了有效，这些步骤需要在威胁分析之后进行，并了解所涉及的问题。
Organizations SHOULD deploy servers that support the use of TLS for all connections and that can be optionally configured to require TLS. When TLS is used, it SHOULD be via the STARTTLS extensions rather than the alternate port method. TLS can be an effective measure to protect against specific threats, including eavesdropping and alteration, of the traffic between the endpoints. However, just because TLS is deployed does not mean the system is "secure".
组织应该部署支持对所有连接使用TLS的服务器，并且可以选择将其配置为需要TLS。使用TLS时，应通过STARTTLS扩展，而不是备用端口方法。TLS是一种有效的措施，可以防止端点之间流量的特定威胁，包括窃听和更改。然而，仅仅因为部署了TLS并不意味着系统是“安全的”。
Attempts at bypassing current firewall policy when deploying new services have serious risks, as discussed in Section 6.1.
如第6.1节所述，在部署新服务时试图绕过当前防火墙策略有严重风险。
It's rare for a new service to not have associated security considerations. Making email available to an organization's members using mobile devices can offer significant benefits.
新服务很少没有相关的安全考虑。使用移动设备向组织成员发送电子邮件可以带来显著的好处。
Chris Newman and Phil Karn suggested very helpful text. Brian Ross and Dave Cridland reviewed drafts and provided excellent suggestions.
Chris Newman和Phil Karn建议了非常有用的文本。Brian Ross和Dave Cridland审查了草案并提供了极好的建议。
[BEHAVE-TCP] Guha, S., Ed., Biswas, K., Ford, B., Sivakumar, S., and P. Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142, RFC 5382, October 2008.
[BEHAVE-TCP]Guha，S.，Ed.，Biswas，K.，Ford，B.，Sivakumar，S.，和P.Srisuresh，“TCP的NAT行为要求”，BCP 142，RFC 5382，2008年10月。
[HOST-REQUIREMENTS] Braden, R., Ed., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989.
[主机要求]Braden，R.，Ed.“互联网主机的要求-通信层”，STD 3，RFC 1122，1989年10月。
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[关键词]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[IANA] IANA Port Number Registry,
<http://www.iana.org/assignments/port-numbers>
[IANA] IANA Port Number Registry,
<http://www.iana.org/assignments/port-numbers>
[TCP] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[TCP]Postel，J.，“传输控制协议”，STD 7，RFC 793，1981年9月。
[ACAP] Newman, C. and J. Myers, "ACAP -- Application Configuration Access Protocol", RFC 2244, November 1997.
[ACAP]Newman，C.和J.Myers，“ACAP——应用程序配置访问协议”，RFC22441997年11月。
[FIREWALLS] Freed, N., "Behavior of and Requirements for Internet Firewalls", RFC 2979, October 2000.
[FIREWALLS]Freed，N.，“互联网防火墙的行为和要求”，RFC 29792000年10月。
[IMAP] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", RFC 3501, March 2003.
[IMAP]Crispin，M.，“互联网消息访问协议-版本4rev1”，RFC 35012003年3月。
[KLUDGE] Moore, K., "On the use of HTTP as a Substrate", BCP 56, RFC 3205, February 2002.
[KLUDGE]Moore，K.，“HTTP作为基板的使用”，BCP 56，RFC 3205，2002年2月。
[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月。
[PROXIES] Chatel, M., "Classical versus Transparent IP Proxies", RFC 1919, March 1996.
[代理]Chatel，M.，“经典与透明IP代理”，RFC 1919，1996年3月。
[SUBMISSION] Gellens, R. and J. Klensin, "Message Submission for Mail", RFC 4409, April 2006.
[提交资料]Gellens，R.和J.Klensin，“邮件信息提交”，RFC 4409，2006年4月。
Author's Address
作者地址
Randall Gellens QUALCOMM Incorporated 5775 Morehouse Drive San Diego, CA 92121
Randall Gellens高通公司，美国加利福尼亚州圣地亚哥Morehouse大道5775号，邮编92121
EMail: randy@qualcomm.com
EMail: randy@qualcomm.com
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2008).
版权所有（C）IETF信托基金（2008年）。
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.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
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.
本文件及其包含的信息以“原样”为基础提供，贡献者、他/她所代表或赞助的组织（如有）、互联网协会、IETF信托基金和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
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.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和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.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为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.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.