Network Working Group M. Stecher
Request for Comments: 4902 Secure Computing
Category: Informational May 2007
Network Working Group M. Stecher
Request for Comments: 4902 Secure Computing
Category: Informational May 2007
Integrity, Privacy, and Security in Open Pluggable Edge Services (OPES) for SMTP
SMTP开放可插拔边缘服务（OPES）的完整性、隐私性和安全性
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) The IETF Trust (2007).
版权所有（C）IETF信托基金（2007年）。
Abstract
摘要
The Open Pluggable Edge Services (OPES) framework is application agnostic. Application-specific adaptations extend that framework. Previous work has focused on HTTP and work for SMTP is in progress. These protocols differ fundamentally in the way data flows, and it turns out that existing OPES requirements and IAB considerations for OPES need to be reviewed with regards to how well they fit for SMTP adaptation. This document analyzes aspects about the integrity of SMTP and mail message adaptation by OPES systems and about privacy and security issues when the OPES framework is adapted to SMTP. It also lists requirements that must be considered when creating the "SMTP adaptation with OPES" document.
开放可插拔边缘服务（OPES）框架与应用程序无关。特定于应用程序的调整扩展了该框架。以前的工作重点是HTTP，SMTP的工作正在进行中。这些协议在数据流的方式上有着根本的不同，事实证明，现有的OPE要求和OPE的IAB考虑因素需要审查，以确定它们是否适合SMTP自适应。本文档分析了有关SMTP完整性和OPES系统邮件消息自适应的各个方面，以及当OPES框架适用于SMTP时的隐私和安全问题。它还列出了在创建“带OPES的SMTP自适应”文档时必须考虑的要求。
The intent of this document is to capture this information before the current OPES working group shuts down. This is to provide input for subsequent working groups or individual contributors that may pick up the OPES/SMTP work at a later date.
本文件的目的是在当前OPES工作组关闭之前获取这些信息。这是为了为后续工作组或个人贡献者提供输入，这些贡献者可能在稍后的日期接收OPES/SMTP工作。
Table of Contents
目录
1. Introduction ....................................................3
1.1. Differences between Unidirectional and
Bidirectional Application Protocols ........................3
1.2. Non-Standardized SMTP Adaptations at SMTP Gateways .........3
1.3. Non-OPES Issues of SMTP ....................................4
1.4. Opportunities of OPES/SMTP to Address Some Issues ..........4
1.5. Limitations of OPES in Regards to Fixing SMTP Issues .......4
2. Terminology .....................................................5
3. Integrity, Privacy, and Security Considerations .................5
3.1. Tracing Information in OPES/SMTP ...........................5
3.2. Bypass in OPES/SMTP ........................................6
3.3. Compatibility with Cryptographic Protection Mechanisms .....7
4. Protocol Requirements for OPES/SMTP .............................8
5. IAB Considerations for OPES/SMTP ................................9
5.1. IAB Consideration (2.1) One-Party Consent ..................9
5.2. IAB Consideration (2.2) IP-Layer Communications ............9
5.3. IAB Consideration (3.1) Notification .......................9
5.4. IAB Consideration (3.2) Notification ......................10
5.5. IAB Consideration (3.3) Non-Blocking ......................10
5.6. IAB Consideration Application Layer Addresses (4.x) .......10
5.7. IAB Consideration (5.1) Privacy ...........................10
5.8. IAB Consideration Encryption ..............................11
6. Security Considerations ........................................11
7. References .....................................................11
7.1. Normative References ......................................11
7.2. Informative References ....................................11
Appendix A. Acknowledgements ......................................13
1. Introduction ....................................................3
1.1. Differences between Unidirectional and
Bidirectional Application Protocols ........................3
1.2. Non-Standardized SMTP Adaptations at SMTP Gateways .........3
1.3. Non-OPES Issues of SMTP ....................................4
1.4. Opportunities of OPES/SMTP to Address Some Issues ..........4
1.5. Limitations of OPES in Regards to Fixing SMTP Issues .......4
2. Terminology .....................................................5
3. Integrity, Privacy, and Security Considerations .................5
3.1. Tracing Information in OPES/SMTP ...........................5
3.2. Bypass in OPES/SMTP ........................................6
3.3. Compatibility with Cryptographic Protection Mechanisms .....7
4. Protocol Requirements for OPES/SMTP .............................8
5. IAB Considerations for OPES/SMTP ................................9
5.1. IAB Consideration (2.1) One-Party Consent ..................9
5.2. IAB Consideration (2.2) IP-Layer Communications ............9
5.3. IAB Consideration (3.1) Notification .......................9
5.4. IAB Consideration (3.2) Notification ......................10
5.5. IAB Consideration (3.3) Non-Blocking ......................10
5.6. IAB Consideration Application Layer Addresses (4.x) .......10
5.7. IAB Consideration (5.1) Privacy ...........................10
5.8. IAB Consideration Encryption ..............................11
6. Security Considerations ........................................11
7. References .....................................................11
7.1. Normative References ......................................11
7.2. Informative References ....................................11
Appendix A. Acknowledgements ......................................13
Because OPES is a protocol that is built over application layer transports, its security may depend on the specifics of the transport. OPES designs are guided by the IAB considerations for OPES document [2], and those considerations are revisited here in the context of the SMTP protocol.
由于OPES是建立在应用层传输之上的协议，其安全性可能取决于传输的具体情况。OPES设计以OPES文件[2]的IAB注意事项为指导，这些注意事项将在SMTP协议的上下文中重新讨论。
Section 3 of the OPES SMTP use cases document [6] maps some email and SMTP elements to OPES names that are used in this document.
OPES SMTP用例文档[6]的第3节将一些电子邮件和SMTP元素映射到本文档中使用的OPES名称。
1.1. Differences between Unidirectional and Bidirectional Application Protocols
1.1. 单向和双向应用程序协议之间的差异
The IAB listed considerations for Open Pluggable Edge Services (OPES) in [2] and OPES treatment of those considerations has been discussed in [3]. Both documents make use of HTTP as an example for the underlying protocol in OPES flows, and focus on web protocols that have requests and responses in the classic form (client sends a request to a server that replies with a response of the same protocol within a single protocol transaction).
IAB在[2]中列出了开放式可插拔边缘服务（OPE）的注意事项，这些注意事项的OPE处理在[3]中进行了讨论。这两个文档都将HTTP用作OPES流中底层协议的示例，并将重点放在具有经典形式的请求和响应的web协议上（客户端向服务器发送请求，该服务器在单个协议事务中使用相同协议的响应进行响应）。
RFC 3914 [3] already indicates that other protocols may not fit in this context, for example in Section 5.3, "Moreover, some application protocols may not have explicit responses...".
RFC 3914[3]已经指出，其他协议可能不适合这种情况，例如在第5.3节中，“此外，一些应用协议可能没有明确的响应……”。
When using SMTP there are still client and server applications, and requests and responses handled within SMTP, but email messages are sent by the data provider to the recipients (data consumers) without a previous request. At that abstraction layer, email delivery via SMTP is a unidirectional process and different from the previously handled web protocols such as HTTP. For example, bypass has been defined for OPES, so far, by the data consumer requesting an OPES bypass by adding information to the application protocol request; the OPES system can then react on the bypass request in both the application request and response. For SMTP, the data consumer (email recipient) cannot request in-band that the OPES bypass handling of his/her messages.
使用SMTP时，仍然存在客户端和服务器应用程序，以及SMTP中处理的请求和响应，但数据提供程序会将电子邮件发送给收件人（数据使用者），而无需事先请求。在该抽象层，通过SMTP的电子邮件传递是一个单向过程，与以前处理的web协议（如HTTP）不同。例如，迄今为止，通过向应用协议请求添加信息来请求OPES旁路的数据消费者已经为OPES定义了旁路；然后，OPES系统可以在应用程序请求和响应中对旁路请求作出反应。对于SMTP，数据使用者（电子邮件收件人）无法请求带内操作员绕过对其邮件的处理。
The IAB considerations need to be revisited and special requirements may be needed for OPES handling of SMTP.
需要重新考虑IAB的考虑因素，并且对于SMTP的OPES处理可能需要特殊要求。
A large number of email filters are deployed at SMTP gateways today. In fact, all use cases listed in "OPES SMTP Use Cases" [6] are already deployed, often in non-standardized ways. This opens a number of integrity, privacy, and security concerns that are not
如今，SMTP网关上部署了大量电子邮件筛选器。事实上，“OPES SMTP用例”[6]中列出的所有用例都已经部署，通常采用非标准化的方式。这带来了许多不可忽视的完整性、隐私和安全问题
addressed, and SMTP itself does not provide effective measures to detect and defend against compromised implementations.
SMTP本身并没有提供有效的措施来检测和防御受损的实现。
OPES will most likely not be able to solve these issues completely, but at least should be able to improve the situation to some extent.
运营商很可能无法完全解决这些问题，但至少应该能够在一定程度上改善情况。
The SMTP specifications [4] require that NDRs (Non-Delivery Reports) be sent to the originator of an undeliverable mail that has been accepted by an SMTP server. But it has become common practice for some sorts of mail (spam, worms) to be silently dropped without sending an NDR, a violation of the MUST statement of SMTP (see Section 3.7 of [4]). While the user of a web protocol notices if a resource cannot be fetched, neither the email sender nor email recipient may notice that an email was not delivered. These kind of issues already exist and are not introduced by OPES.
SMTP规范[4]要求将NDR（未送达报告）发送给SMTP服务器已接受的无法送达邮件的发件人。但是，一些种类的邮件（垃圾邮件、蠕虫）在不发送NDR的情况下被悄悄丢弃已成为一种常见做法，这违反了SMTP的必须声明（见[4]第3.7节）。虽然web协议的用户会注意到资源是否无法获取，但电子邮件发送者和收件人都不会注意到电子邮件未送达。这类问题已经存在，而且不是由运营商提出的。
Adding SMTP adaptations with OPES allows us to define a standardized way for SMTP gateway filtering, to offload filtering services to callout servers and address a number of the integrity, privacy, and security issues. OPES offers methods to add OPES tracing information and to request a bypass of filtering, and by that can make email gateway filtering a more reliable and standardized function. But OPES won't make email delivery via SMTP a reliable communication.
通过在OPES中添加SMTP适配，我们可以定义SMTP网关过滤的标准方式，将过滤服务卸载到调用服务器，并解决许多完整性、隐私和安全问题。OPES提供了添加OPES跟踪信息和请求绕过过滤的方法，从而使电子邮件网关过滤成为更可靠和标准化的功能。但OPES不会让通过SMTP发送电子邮件成为一种可靠的通信方式。
The biggest concerns when adding OPES services to a network flow are that compromised, misconfigured, or faulty OPES systems may change messages in a way that the consumer can no longer read them or that messages are no longer delivered at all.
将OPES服务添加到网络流时，最大的问题是，受损、配置错误或故障的OPES系统可能会改变消息，使消费者无法再阅读它们，或者消息根本无法传递。
Defining a standard way to mark mails that have been handled by OPES systems is fairly simple and does not require new techniques by SMTP gateways; they already today MUST leave tracing information by adding "Received" headers to mails. Therefore, recipients receiving broken mail have a fair chance of finding the compromised OPES system by using the trace information. There is still no guarantee, as the email may have been broken in a way that makes even the tracing information unreadable. But the chance will be even better than with other protocols such as HTTP, because most email clients allow the user to display mail headers, while many browsers have no mechanism to show the HTTP headers that might include tracing info.
定义一种标准方法来标记已由OPES系统处理的邮件相当简单，并且不需要SMTP网关的新技术；如今，他们必须通过在邮件中添加“已接收”标题来留下跟踪信息。因此，通过使用跟踪信息，收到破损邮件的收件人有相当大的机会找到受损的OPES系统。目前还无法保证，因为电子邮件可能已经被破坏，甚至连追踪信息都无法读取。但这种可能性甚至比使用HTTP等其他协议更好，因为大多数电子邮件客户端允许用户显示邮件头，而许多浏览器没有显示可能包含跟踪信息的HTTP头的机制。
Email that cannot be delivered, because a compromised OPES system prevented the delivery of legitimate mail, MUST result in a an NDR to be sent to the originator of the mail according to the SMTP specifications [4]. OPES should not be forced to fix the issue that NDRs are not reliable over SMTP.
由于受损的OPES系统阻止了合法邮件的传递而无法传递的电子邮件，必须根据SMTP规范将NDR发送给邮件的发起人[4]。不应强迫运营商解决NDR在SMTP上不可靠的问题。
The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [1]. When used with the normative meanings, these keywords will be all uppercase. Occurrences of these words in lowercase comprise normal prose usage, with no normative implications.
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[1]中所述进行解释。当和规范含义一起使用时，这些关键字将全部大写。这些单词以小写形式出现，包括正常的散文用法，没有任何规范含义。
Tracing OPES operations is an important requirement for OPES systems. Tracing information added to email should follow a similar syntax and structure to that defined for OPES/HTTP in HTTP Adaptation with Open Pluggable Edge Services [5], and with the same guidelines as the SMTP specifications [4] defined for the "Received" headers. (We do not specify here whether "Received" headers would be used to carry the OPES information, or new trace headers should be defined, such as OPES-System and OPES-Via.)
跟踪OPES操作是OPES系统的一项重要要求。添加到电子邮件中的跟踪信息应遵循与使用开放式可插拔边缘服务[5]的HTTP适配中为OPES/HTTP定义的语法和结构类似的语法和结构，并遵循与为“接收”标头定义的SMTP规范[4]相同的准则。（我们在此不指定是否使用“已接收”头来携带OPES信息，或者应定义新的跟踪头，例如OPES系统和OPES Via。）
OPES/SMTP specifications defining tracing requirements MUST be compliant with the general OPES tracing requirements defined in OPES Entities & End Points Communication [12], but MAY further restrict those. For example, they might require the following: that the OPES processor must add tracing information for the OPES system before calling the first callout server; that it has to augment the tracing information with additional data if necessary after the message returns from each service it is calling; and that it must ensure that the tracing information has not been deleted by an OPES service before it forwards the SMTP message.
定义跟踪要求的OPES/SMTP规范必须符合OPES实体和端点通信[12]中定义的一般OPES跟踪要求，但可能进一步限制这些要求。例如，他们可能要求：OPES处理器必须在调用第一个调用服务器之前为OPES系统添加跟踪信息；在消息从它调用的每个服务返回后，如果需要，它必须使用附加数据来增加跟踪信息；并且它必须确保在转发SMTP消息之前，跟踪信息没有被OPES服务删除。
Trace information can then be seen by mail recipients when the mail message reaches the recipient.
当邮件到达收件人时，邮件收件人可以看到跟踪信息。
Mail that cannot be delivered or that is blocked by the OPES service will either be rejected or cannot be delivered after it has been accepted by an SMTP server. In the latter case, SMTP specifications [4] require that an NDR MUST be sent to the originator; OPES further requires that an NDR generated due to OPES processing MUST also contain information about the OPES system so that the sender gets
SMTP服务已被接收或无法被OPES拒绝后，SMTP服务将被拒绝。在后一种情况下，SMTP规范[4]要求必须向发端人发送NDR；OPES进一步要求，由于OPES处理而生成的NDR还必须包含有关OPES系统的信息，以便发送方获得
informed. If an email is rejected at the SMTP protocol level due to OPES processing, an OPES system MUST also include trace data in the SMTP response so that the originator can find out why and where the mail was rejected.
见多识广的如果由于OPES处理，邮件在SMTP协议级别被拒绝，OPES系统还必须在SMTP响应中包含跟踪数据，以便发起者能够找出邮件被拒绝的原因和位置。
If a mail message was rejected or could not be delivered (and an NDR was sent), the originator of the message may want to bypass the OPES system that blocked the message.
如果邮件被拒绝或无法传递（并且发送了NDR），则邮件的发起人可能希望绕过阻止邮件的OPES系统。
If the recipient of a message receives a mail with OPES trace information, he may want to receive a non-OPES version of the message. Although there is no direct in-band request from the recipient back to the OPES system, the recipient can contact the sender and ask her to send the message again and to add a bypass request for the OPES system. Not all OPES systems will be allowed to fulfill a bypass request according to their policy. For example, malware scanners should not be bypassed. But other OPES services are good candidates for bypass requests, such as language translation of the email message. Translation could be bypassed after the recipient has noticed that the translated result does not meet his/her expectations and that the original message would be preferred.
如果邮件收件人收到带有OPES跟踪信息的邮件，他可能希望收到非OPES版本的邮件。虽然收件人没有直接带内请求返回OPES系统，但收件人可以联系发件人，要求其再次发送邮件，并为OPES系统添加旁路请求。并不是所有的OPES系统都可以根据其政策满足旁路请求。例如，不应绕过恶意软件扫描程序。但其他OPES服务很适合绕过请求，例如电子邮件的语言翻译。在接收者注意到翻译结果不符合其期望，并且首选原始信息后，可以忽略翻译。
An OPES system MAY also define out-of-band methods to request a bypass, for example, a web interface or an email message sent to the server that results in the creation of a white list entry for the sender/recipient pair. Examples for these out-of-band methods are email systems that keep a copy of the original email in a quarantine queue and only send the recipient a block notification, plus either a direct link or a digest notification, with the ability to retrieve the original message from quarantine. These out-of-band methods are typically offered by spam filters today.
OPES系统还可以定义带外方法以请求旁路，例如，发送到服务器的web界面或电子邮件消息，其导致为发送者/接收者对创建白名单条目。这些带外方法的示例是电子邮件系统，该系统将原始电子邮件的副本保留在隔离队列中，仅向收件人发送阻止通知，外加直接链接或摘要通知，并能够从隔离中检索原始邮件。这些带外方法目前通常由垃圾邮件过滤器提供。
OPES MUST implement methods to request a bypass, but there cannot be a guarantee that the bypass request will be approved. The security needs of the receiver or the receiver's network may demand that certain filters must not be bypassed (such as virus scanners). In general, the receiver should be able to configure a client centric OPES system, i.e. the receiver should be able to indicate if he/she wants to receive a non-OPES version if it is available.
运营商必须实施请求旁路的方法，但无法保证旁路请求将获得批准。接收器或接收器网络的安全需求可能要求不得绕过某些过滤器（如病毒扫描仪）。一般来说，接收方应能够配置以客户为中心的OPES系统，即接收方应能够指示是否希望接收非OPES版本（如果可用）。
Bypass requests could be added to the mail message or within the SMTP dialog. Bypass request data added to the mail message cannot bypass OPES services that operate on other SMTP dialog commands, which are sent before the mail message has been received (such as RCPT commands).
可以将绕过请求添加到邮件或SMTP对话框中。添加到邮件中的旁路请求数据无法绕过在其他SMTP对话框命令上运行的OPES服务，这些命令是在收到邮件之前发送的（例如RCPT命令）。
Bypass request data sent using an ESMTP extension as part of the SMTP dialog may not reach the OPES system if intermediate SMTP relays do not support those bypass request commands and don't forward that information.
如果中间SMTP中继不支持这些旁路请求命令且不转发该信息，则作为SMTP对话框一部分使用ESMTP扩展发送的旁路请求数据可能无法到达OPES系统。
Cryptography can be used to assure message privacy, to authenticate the originator of messages, and to detect message modification. There are standard methods for achieving some or all these protections for generic messages ([9], [10], [11]), and these can be used to protect SMTP data without changing the SMTP protocol.
密码学可用于确保消息隐私、验证消息的发起人以及检测消息修改。对于一般邮件（[9]、[10]、[11]），有一些标准方法可以实现部分或全部这些保护，这些方法可以用于保护SMTP数据，而无需更改SMTP协议。
The content of encrypted mail messages cannot be inspected by OPES systems because only the intended recipient has the information necessary for decryption. The IAB and others have suggested that users might want to share that information with OPES systems, thus permitting decryption by intermediates. For most cryptographic systems that are compatible with email, this would require end users to share their most valuable keys, in essence their "identities", with OPES machines. Some key management systems, particularly those which have centralized administrative control of keys, might have trust models in which such sharing would be sensible and secure.
OPES系统无法检查加密邮件的内容，因为只有预期收件人具有解密所需的信息。IAB和其他机构建议，用户可能希望与OPES系统共享该信息，从而允许中间人解密。对于大多数与电子邮件兼容的加密系统，这将要求最终用户与OPES机器共享他们最有价值的密钥，本质上是他们的“身份”。一些密钥管理系统，特别是那些对密钥进行集中管理控制的系统，可能具有信任模型，在这种模型中，这种共享是合理和安全的。
After decrypting the message, an OPES box that modified the content would be faced with the task of re-encrypting it in order to maintain some semblance of "end-to-end" privacy.
解密消息后，修改内容的OPES盒将面临重新加密的任务，以保持某种“端到端”的隐私。
If OPES/SMTP had a way to interact with end users on a per-message basis, it might be possible to communicate cryptographic key information from individual messages to end users, have them compute the message encrypting key for particular message, and to send that back to the OPES box. This would perhaps ameliorate the need to share a user's "master" message decrypting key with the OPES box. This kind of communication has not been defined for OPES.
如果OPES/SMTP能够以每封邮件为基础与最终用户进行交互，则可以将各个邮件的加密密钥信息传递给最终用户，让他们计算特定邮件的邮件加密密钥，并将其发送回OPES邮箱。这可能会改善与OPES盒共享用户“主”消息解密密钥的需要。尚未为运营商定义此类通信。
Message protection systems generally include some message integrity mechanisms by which a recipient can check for a message modification that may have occurred after the sender released the message. This protection can be applied to encrypted or plaintext messages and can be accomplished through either symmetric or asymmetric cryptography. In the case of symmetric cryptography, the key sharing problem is exactly similar to the encryption case discussed previously. If the OPES box modified the content, then the message integrity (or authentication) code would have to be recalculated and included with the modified message.
邮件保护系统通常包括一些邮件完整性机制，通过这些机制，收件人可以检查发件人发布邮件后可能发生的邮件修改。这种保护可以应用于加密或明文消息，并且可以通过对称或非对称加密来实现。在对称加密的情况下，密钥共享问题与前面讨论的加密情况完全相似。如果OPES框修改了内容，则必须重新计算消息完整性（或身份验证）代码，并将其包含在修改的消息中。
For asymmetric cryptography the situation is more complicated. The message integrity is tied to the sender's public key, and although anyone who can get the sender's public key can also check for a message modification, no one but the sender can compute the sender's signature on a modified message. Thus, an OPES system could not modify messages and have them appear to come from the purported sender. The notion of sharing the sender's signing key with the OPES system is unpalatable because few trust models would be compatible with sharing digital identities across organization boundaries. However, if the OPES system doing the modification were under the control of the sender's local administration, the sharing might be sensible (as discussed for decryption, above).
对于非对称加密，情况更为复杂。消息的完整性与发送方的公钥有关，尽管任何可以获得发送方公钥的人也可以检查消息的修改，但除了发送方之外，没有人可以计算修改消息上发送方的签名。因此，OPES系统无法修改消息，并使其看起来来自声称的发送者。与OPES系统共享发送者的签名密钥的概念令人不快，因为很少有信任模型能够兼容跨组织边界共享数字身份。但是，如果进行修改的OPES系统在发送方的本地管理部门的控制下，则共享可能是明智的（如上文关于解密的讨论）。
OPES/SMTP systems could present modified content showing the modified regions in a form that permits the authentication of the original message and authentication of the OPES modifications (assuming the OPES box had a digital signature identity and key). One method for doing this is outlined in [13], but to our knowledge this method is not in any standard.
OPES/SMTP系统可以以允许对原始邮件进行身份验证和对OPES修改进行身份验证的形式呈现显示修改区域的修改内容（假设OPES框具有数字签名标识和密钥）。[13]中概述了一种方法，但据我们所知，该方法不在任何标准中。
There are security risks associated with sharing cryptographic keys that must be addressed by implementers. Because this is not a simple task, it is not a requirement for OPES/SMTP.
与共享加密密钥相关的安全风险必须由实现者解决。因为这不是一项简单的任务，所以它不是OPES/SMTP的要求。
In addition to other documents listing requirements for OPES, the discussion in this document implies specific requirements for designing and implementing SMTP adaptations with OPES:
除了列出运营商要求的其他文件外，本文件中的讨论还暗示了设计和实施运营商SMTP适配的具体要求：
o OPES Systems MUST add tracing headers to mail messages
o OPES系统必须向邮件消息添加跟踪标头
o If an email message that has been accepted by an OPES system cannot be delivered, the non-delivery report MUST include trace information of the OPES system.
o 如果OPES系统已接受的电子邮件无法发送，则未发送报告必须包含OPES系统的跟踪信息。
o The OPES/SMTP specifications MUST define a bypass request option that can be included in mail messages.
o OPES/SMTP规范必须定义可包含在邮件消息中的绕过请求选项。
o The OPES/SMTP specifications MUST define a bypass request option as an extension for SMTP dialogs.
o OPES/SMTP规范必须将旁路请求选项定义为SMTP对话框的扩展。
This section lists the IAB considerations for OPES [2] and summarizes how OPES/SMTP addresses them.
本节列出了OPE[2]的IAB注意事项，并总结了OPE/SMTP如何解决这些问题。
The IAB recommends that all OPES services be explicitly authorized by one of the application-layer end-hosts (that is, either the data consumer application or the data provider application). For OPES/ SMTP, this means consent of either the email message sender or the recipient.
IAB建议所有OPES服务由应用层终端主机之一（即数据使用者应用程序或数据提供者应用程序）明确授权。对于OPES/SMTP，这意味着电子邮件发件人或收件人的同意。
The application agnostic architecture of OPES [7] requires that "OPES processors MUST be consented to by either the data consumer or data provider application" (OPES processor is the email gateway for OPES/ SMTP). This cannot prevent the consent-less introduction of OPES processors by noncompliant OPES entities.
OPES的应用程序无关架构[7]要求“OPES处理器必须得到数据使用者或数据提供者应用程序的同意”（OPES处理器是OPES/SMTP的电子邮件网关）。这不能阻止不合规OPES实体不经同意引入OPES处理器。
The IAB recommends that OPES processors must be explicitly addressed at the IP layer by the end user (data consumer application).
IAB建议最终用户（数据消费者应用程序）必须在IP层明确寻址OPES处理器。
This requirement has been addressed by the architecture requirements in Section 2.1 of [7] and has been further clarified in Section 2.2 of [3].
该要求已在[7]第2.1节的架构（architecture）要求中得到解决，并在[3]第2.2节中得到进一步澄清。
"The overall OPES framework needs to assist content providers in detecting and responding to client-centric actions by OPES intermediaries that are deemed inappropriate by the content provider" [2].
“整个OPES框架需要帮助内容提供商检测并响应内容提供商认为不适当的OPES中介机构以客户为中心的行为”[2]。
For OPES/SMTP this translates into assistance for the email message sender to detect and respond to recipient-centric actions that are deemed inappropriate by the sender.
对于OPES/SMTP，这将转化为帮助电子邮件发件人检测并响应发件人认为不适当的以收件人为中心的操作。
This has been addressed in Section 3.1 and by the second tracing requirements in Section 4. As discussed in Section 1.3, OPES/SMTP cannot fix cases where NDRs are not sent or get blocked before reaching the sender of the original message.
这已在第3.1节和第4节的第二个跟踪要求中说明。如第1.3节所述，OPES/SMTP无法修复NDR未发送或在到达原始邮件的发件人之前被阻止的情况。
"The overall OPES framework should assist end users in detecting the behavior of OPES intermediaries, potentially allowing them to identify imperfect or compromised intermediaries" [2].
“整个OPES框架应帮助最终用户检测OPES中介机构的行为，潜在地允许他们识别不完善或受损的中介机构”[2]。
This is addressed in Section 3.1 and by the first tracing requirement in Section 4. It must be noted that some email systems do not make the email headers available to the end user, although the headers belong to the payload that is transferred via SMTP. Building an OPES architecture with those email systems should be avoided or requires that the tracing information be made available to the end users in a different way.
第3.1节和第4节中的第一个跟踪要求对此进行了说明。必须注意的是，某些电子邮件系统不向最终用户提供电子邮件头，尽管这些头属于通过SMTP传输的有效负载。应避免使用这些电子邮件系统构建OPES体系结构，或者要求以不同的方式向最终用户提供跟踪信息。
"If there exists a "non-OPES" version of content available from the content provider, the OPES architecture must not prevent users from retrieving this "non-OPES" version from the content provider" [2].
“如果内容提供商提供的内容存在“非OPES”版本，则OPES体系结构不得阻止用户从内容提供商检索此“非OPES”版本”[2]。
For OPES/SMTP, this has been discussed in Section 3.2 and is addressed by the two bypass requirements of Section 4.
对于OPE/SMTP，这已在第3.2节中讨论，并在第4节的两个旁路要求中解决。
While "most application layer addressing revolves around URIs" (section 8 of [2]), SMTP uses email addresses, for which the considerations only apply to some degree.
虽然“大多数应用层寻址都围绕URI”（见[2]第8节），但SMTP使用电子邮件地址，这些注意事项仅在一定程度上适用。
The SMTP use cases document [6] includes a use case for Mail Rerouting and Address Rewriting. Alias and email list address resolution are standard functions of an email gateway described in [4].
SMTP用例文档[6]包括邮件重新路由和地址重写的用例。别名和电子邮件列表地址解析是[4]中描述的电子邮件网关的标准功能。
Translating the reference validity consideration regarding inter- and intra-document reference validity to SMTP, OPES services mapping internal to external email addresses MUST ensure the proper mapping of addresses in all affected email headers.
将有关文档间和文档内引用有效性的引用有效性考虑因素转换为SMTP，将内部电子邮件地址映射到外部电子邮件地址的OPES服务必须确保所有受影响的电子邮件头中的地址正确映射。
This consideration recommends that the overall OPES framework must provide for mechanisms for end users to determine the privacy policies that were used by OPES intermediaries.
这一考虑建议，整个OPES框架必须为最终用户提供机制，以确定OPES中介机构使用的隐私政策。
The application agnostic part for OPES has been discussed in Section 10 of [3]. Email-specific trace information that will be added to OPES/SMTP according to the requirements in Section 4 may raise
OPES的应用不可知部分已在[3]的第10节中讨论。根据第4节的要求，将添加到OPES/SMTP的电子邮件特定跟踪信息可能会引发
additional privacy issues that MUST be added to the privacy policy description of the OPES system.
必须添加到OPES系统隐私政策说明中的其他隐私问题。
"If OPES was compatible with end-to-end encryption, this would effectively ensure that OPES boxes would be restricted to ones that are known, trusted, explicitly addressed at the IP layer, and authorized (by the provision of decryption keys) by at least one of the ends" [2].
“如果OPES与端到端加密兼容，这将有效地确保OPES盒仅限于已知的、受信任的、在IP层显式寻址的，并且（通过提供解密密钥）由至少一端授权的”[2]。
This has been discussed in Section 3.3.
第3.3节对此进行了讨论。
The document itself discusses security considerations of OPES/SMTP. General security threats of OPES are described in Security Threats for OPES [8]
文件本身讨论了OPES/SMTP的安全注意事项。石油输出国的一般安全威胁见石油输出国的安全威胁[8]
Section 3.3 ("Compatibility with Cryptographic Protection Mechanisms") mentions that an OPES system could eventually deal with cryptographic keys. This raises security issues (such as availability and storage of cryptographic keys) that must be addressed by the implementer.
第3.3节（“与加密保护机制的兼容性”）提到，OPES系统最终可以处理加密密钥。这会引发安全问题（如加密密钥的可用性和存储），实现者必须解决这些问题。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[2] Floyd, S. and L. Daigle, "IAB Architectural and Policy Considerations for Open Pluggable Edge Services", RFC 3238, January 2002.
[2] Floyd，S.和L.Daigle，“开放可插拔边缘服务的IAB架构和政策考虑”，RFC 3238，2002年1月。
[3] Barbir, A. and A. Rousskov, "Open Pluggable Edge Services (OPES) Treatment of IAB Considerations", RFC 3914, October 2004.
[3] Barbir，A.和A.Rousskov，“开放可插拔边缘服务（OPES）对IAB考虑因素的处理”，RFC 3914，2004年10月。
[4] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April 2001.
[4] 《简单邮件传输协议》，RFC 28212001年4月。
[5] Rousskov, A. and M. Stecher, "HTTP Adaptation with Open Pluggable Edge Services (OPES)", RFC 4236, November 2005.
[5] Rousskov，A.和M.Stecher，“使用开放可插拔边缘服务（OPES）的HTTP适配”，RFC 4236，2005年11月。
[6] Stecher, M. and A. Barbir, "Open Pluggable Edge Services (OPES) SMTP Use Cases", RFC 4496, May 2006.
[6] Stecher，M.和A.Barbir，“开放可插拔边缘服务（OPES）SMTP用例”，RFC 4496，2006年5月。
[7] Barbir, A., Penno, R., Chen, R., Hofmann, M., and H. Orman, "An Architecture for Open Pluggable Edge Services (OPES)", RFC 3835, August 2004.
[7] Barbir，A.，Penno，R.，Chen，R.，Hofmann，M.，和H.Orman，“开放可插拔边缘服务（OPES）的体系结构”，RFC 38352004年8月。
[8] Barbir, A., Batuner, O., Srinivas, B., Hofmann, M., and H. Orman, "Security Threats and Risks for Open Pluggable Edge Services (OPES)", RFC 3837, August 2004.
[8] Barbir，A.，Batuner，O.，Srinivas，B.，Hofmann，M.，和H.Orman，“开放可插拔边缘服务（OPES）的安全威胁和风险”，RFC 3837，2004年8月。
[9] Elkins, M., Del Torto, D., Levien, R., and T. Roessler, "MIME Security with OpenPGP", RFC 3156, August 2001.
[9] Elkins，M.，Del Torto，D.，Levien，R.，和T.Roessler，“OpenPGP的MIME安全性”，RFC 3156，2001年8月。
[10] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 3852, July 2004.
[10] Housley，R.，“加密消息语法（CMS）”，RFC3852，2004年7月。
[11] Eastlake, D., Reagle, J., and D. Solo, "(Extensible Markup Language) XML-Signature Syntax and Processing", RFC 3275, March 2002.
[11] Eastlake，D.，Reagle，J.，和D.Solo，“（可扩展标记语言）XML签名语法和处理”，RFC3275，2002年3月。
[12] Barbir, A., "Open Pluggable Edge Services (OPES) Entities and End Points Communication", RFC 3897, September 2004.
[12] Barbir，A.，“开放可插拔边缘服务（OPES）实体和端点通信”，RFC 38972004年9月。
[13] Orman, H., "Data Integrity for Mildly Active Content", Proceedings of the Third Annual International Workshop on Active Middleware Services, p.73, August 2001.
[13] Orman，H.，“轻度活动内容的数据完整性”，第三届活动中间件服务国际年会论文集，第73页，2001年8月。
Many thanks to everybody who provided input and feedback for this document. Very special thanks to Hilarie Orman for her input and suggestions, especially for the content of Section 3.3 ("Compatibility with Cryptographic Protection Mechanisms").
非常感谢为本文件提供意见和反馈的所有人。非常感谢Hilarie Orman的投入和建议，特别是第3.3节（“与密码保护机制的兼容性”）的内容。
Author's Address
作者地址
Martin Stecher Secure Computing Corporation Vattmannstr. 3 33100 Paderborn Germany
马丁·斯蒂彻安全计算公司Vattmannstr。33100德国帕德伯恩
EMail: martin.stecher@webwasher.com
URI: http://www.securecomputing.com/
EMail: martin.stecher@webwasher.com
URI: http://www.securecomputing.com/
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2007).
版权所有（C）IETF信托基金（2007年）。
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.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。