Network Working Group M. Stecher
Request for Comments: 4496 Secure Computing
Category: Informational A. Barbir
Nortel
May 2006
Network Working Group M. Stecher
Request for Comments: 4496 Secure Computing
Category: Informational A. Barbir
Nortel
May 2006
Open Pluggable Edge Services (OPES) SMTP Use Cases
开放可插拔边缘服务（OPES）SMTP用例
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 Internet Society (2006).
版权所有（C）互联网协会（2006年）。
Abstract
摘要
The Open Pluggable Edge Services (OPES) framework is application agnostic. Application-specific adaptations extend that framework. This document describes OPES SMTP use cases and deployment scenarios in preparation for SMTP adaptation with OPES.
开放可插拔边缘服务（OPES）框架与应用程序无关。特定于应用程序的调整扩展了该框架。本文档描述了OPES SMTP用例和部署场景，以准备SMTP与OPES的适配。
Table of Contents
目录
1. Introduction ....................................................2
2. Terminology .....................................................2
3. Brief Overview of SMTP Architecture .............................3
3.1. Operation Flow of an OPES SMTP System ......................4
3.1.1. OPES SMTP Example ...................................5
4. OPES/SMTP Use Cases .............................................6
4.1. Security Filters Applied to Email Messages .................6
4.2. Spam Filter ................................................7
4.3. Logging and Reporting Filters ..............................8
4.4. Access Control Filters .....................................8
4.5. Secure Email Handling ......................................8
4.6. Email Format Normalization .................................8
4.7. Mail Rerouting and Address Rewriting .......................9
4.8. Block Email during SMTP Dialog .............................9
4.9. Convert Attachments to HTTP Links ..........................9
5. Security Considerations ........................................10
6. References .....................................................10
6.1. Normative References ......................................10
6.2. Informative References ....................................10
Acknowledgements ..................................................11
1. Introduction ....................................................2
2. Terminology .....................................................2
3. Brief Overview of SMTP Architecture .............................3
3.1. Operation Flow of an OPES SMTP System ......................4
3.1.1. OPES SMTP Example ...................................5
4. OPES/SMTP Use Cases .............................................6
4.1. Security Filters Applied to Email Messages .................6
4.2. Spam Filter ................................................7
4.3. Logging and Reporting Filters ..............................8
4.4. Access Control Filters .....................................8
4.5. Secure Email Handling ......................................8
4.6. Email Format Normalization .................................8
4.7. Mail Rerouting and Address Rewriting .......................9
4.8. Block Email during SMTP Dialog .............................9
4.9. Convert Attachments to HTTP Links ..........................9
5. Security Considerations ........................................10
6. References .....................................................10
6.1. Normative References ......................................10
6.2. Informative References ....................................10
Acknowledgements ..................................................11
The Open Pluggable Edge Services (OPES) architecture [1] enables cooperative application services (OPES services) between a data provider, a data consumer, and zero or more OPES processors. The application services under consideration analyze and possibly transform application-level messages exchanged between the data provider and the data consumer. The OPES processor can distribute the responsibility of service execution by communicating and collaborating with one or more remote callout servers.
开放可插拔边缘服务（OPES）体系结构[1]支持数据提供者、数据使用者和零个或多个OPES处理器之间的协作应用程序服务（OPES服务）。考虑中的应用程序服务分析并可能转换数据提供者和数据使用者之间交换的应用程序级消息。OPES处理器可以通过与一个或多个远程调出服务器通信和协作来分配服务执行的责任。
The execution of such services is governed by a set of rules installed on the OPES processor. The rule evaluation can trigger the execution of service applications local to the OPES processor or on a remote callout server.
此类服务的执行由安装在OPES处理器上的一组规则控制。规则评估可触发OPES处理器本地或远程调出服务器上的服务应用程序的执行。
Use cases for OPES based on HTTP [8] are described in [2]. This work focuses on OPES for SMTP [7] use cases, whereby additional use cases and enhancements to the types of OPES services defined in [2] are provided.
[2]中描述了基于HTTP[8]的OPE用例。这项工作的重点是SMTP[7]用例的OPES，其中提供了[2]中定义的OPES服务类型的附加用例和增强。
In SMTP, the OPES processor may be any agent participating in SMTP exchanges, including a Mail Submission Agent (MSA), a Mail Transfer Agent (MTA), a Mail Delivery Agent (MDA), and a Mail User Agent (MUA). This document focuses on use cases in which the OPES processor is a MTA.
在SMTP中，OPES处理器可以是参与SMTP交换的任何代理，包括邮件提交代理（MSA）、邮件传输代理（MTA）、邮件传递代理（MDA）和邮件用户代理（MUA）。本文档重点介绍OPES处理器是MTA的用例。
SMTP is a store-and-forward protocol. Current email filtering systems either operate during the SMTP exchange or on messages that have already been received, after the SMTP connection has been closed (for example, in an MTA's message queue).
SMTP是一种存储转发协议。当前的电子邮件过滤系统要么在SMTP交换期间运行，要么在SMTP连接关闭后（例如，在MTA的邮件队列中）对已收到的邮件运行。
This work focuses on SMTP-based services that want to modify command values or want to block SMTP commands. In order to block a command, the service will provide an error message that the MTA should use in response to the command it received. An OPES MTA will be involved in SMTP command modification and command satisfaction, analogous to request modification and request satisfaction from HTTP [8].
这项工作主要关注基于SMTP的服务，这些服务希望修改命令值或阻止SMTP命令。为了阻止命令，服务将提供一条错误消息，MTA应使用该消息来响应其收到的命令。OPES MTA将参与SMTP命令修改和命令满足，类似于HTTP的请求修改和请求满足[8]。
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 [6]. When used with the normative meanings, these key words will be all uppercase. Occurrences of these words in lowercase comprise normal prose usage, with no normative implications.
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[6]中所述进行解释。当和规范意义一起使用时，这些关键词将全部大写。这些单词以小写形式出现，包括正常的散文用法，没有任何规范含义。
The SMTP design, taken from RFC 2821 [7], is shown in Figure 1. When an SMTP client has a message to transmit, it establishes a two-way transmission channel to an SMTP server. The responsibility of an SMTP client is to transfer mail messages to one or more SMTP servers, or report its failure to do so.
SMTP设计取自RFC2821[7]，如图1所示。当SMTP客户端有消息要传输时，它会建立到SMTP服务器的双向传输通道。SMTP客户端的职责是将邮件消息传输到一个或多个SMTP服务器，或报告其失败。
+----------+ +----------+
+------+ | | | |
| User |<-->| | SMTP | |
+------+ | Client |Commands/Replies| Server |
+------+ | SMTP |<-------------->| SMTP | +------+
| File |<-->| | and Mail | |<-->| File |
|System| | | | | |System|
+------+ +----------+ +----------+ +------+
SMTP client SMTP server
+----------+ +----------+
+------+ | | | |
| User |<-->| | SMTP | |
+------+ | Client |Commands/Replies| Server |
+------+ | SMTP |<-------------->| SMTP | +------+
| File |<-->| | and Mail | |<-->| File |
|System| | | | | |System|
+------+ +----------+ +----------+ +------+
SMTP client SMTP server
Figure 1: SMTP Design
图1:SMTP设计
In some cases, the domain name(s) transferred to, or determined by, an SMTP client will identify the final destination(s) of the mail message. In other cases, the domain name determined will identify an intermediate destination through which those mail messages are to be relayed.
在某些情况下，传输到SMTP客户端或由SMTP客户端确定的域名将标识邮件的最终目的地。在其他情况下，所确定的域名将标识一个中间目的地，这些邮件消息将通过该目的地进行中继。
An SMTP server may be either the ultimate destination or an intermediate "relay" or "gateway" (that is, it may transport the message further using some protocol other than SMTP or using again SMTP and then acting as an SMTP client).
SMTP服务器可以是最终目的地，也可以是中间“中继”或“网关”（也就是说，它可以使用SMTP以外的协议进一步传输邮件，或者再次使用SMTP，然后充当SMTP客户端）。
SMTP commands are generated by the SMTP client and sent to the SMTP server. SMTP responses are sent from the SMTP server to the SMTP client in response to the commands. SMTP message transfer can occur in a single connection between the original SMTP sender and the final SMTP recipient, or it can occur in a series of hops through intermediary systems. SMTP clients and servers exchange commands and responses and eventually the mail message body.
SMTP命令由SMTP客户端生成并发送到SMTP服务器。SMTP响应从SMTP服务器发送到SMTP客户端以响应命令。SMTP邮件传输可以在原始SMTP发件人和最终SMTP收件人之间的单个连接中进行，也可以通过中间系统在一系列跃点中进行。SMTP客户端和服务器交换命令和响应，最终交换邮件正文。
Figure 2 expands on the mail flow in an SMTP system. Further information about the architecture of email in the Internet may be found in [9].
图2扩展了SMTP系统中的邮件流。有关互联网电子邮件体系结构的更多信息，请参见[9]。
+-------+ +---------+ +---------+ +--------+ +-------+
|mail M| |M mail M| SMTP |M mail M| SMTP |M mail M| |M mail |
|clnt U|--|S srvr T|------|T gway T|------|T srvr D|--|U clnt |
| A| |A A| |A A| |A A| |A |
+-------+ +---------+ +---------+ +--------+ +-------+
+-------+ +---------+ +---------+ +--------+ +-------+
|mail M| |M mail M| SMTP |M mail M| SMTP |M mail M| |M mail |
|clnt U|--|S srvr T|------|T gway T|------|T srvr D|--|U clnt |
| A| |A A| |A A| |A A| |A |
+-------+ +---------+ +---------+ +--------+ +-------+
Figure 2: Expanded SMTP Flow
图2：扩展的SMTP流
In this work, the OPES processor may be any agent that is participating in SMTP exchanges, including an MSA, MTA, MDA, and MUA. However, this document focuses on use cases in which the OPES processor uses the SMTP protocol or one of the protocols derived from SMTP Message Submission (SUBMIT) [10] and the Local Mail Transfer Protocol (LMTP) [11]).
在此工作中，OPES处理器可以是参与SMTP交换的任何代理，包括MSA、MTA、MDA和MUA。然而，本文档主要关注OPES处理器使用SMTP协议或从SMTP消息提交（提交）[10]和本地邮件传输协议（LMTP）[11]派生的协议之一的用例。
In this work, an MTA is the OPES processor device that sits in the data stream of the SMTP protocol. The OPES processor gets enhanced by an OCP (OPES callout protocol) [3] client that allows it to vector out data to the callout server. The filtering functionality is on the callout server.
在本文中，MTA是位于SMTP协议数据流中的OPES处理器设备。OPES处理器通过OCP（OPES callout protocol）[3]客户端得到增强，该客户端允许它将数据矢量输出到callout服务器。过滤功能位于callout服务器上。
A client (a mail user) starts with an email client program (MUA). The user sends email to an outgoing email server. In the email server, there is an MSA (mail submission agent) that is waiting to receive email from the user. The MSA uses an MTA within the same server to forward the user email to other domains. (Communication between the MUA and MSA may be via SMTP, SUBMIT [10], or something else such as MAPI).
客户端（邮件用户）从电子邮件客户端程序（MUA）开始。用户将电子邮件发送到传出电子邮件服务器。在电子邮件服务器中，有一个MSA（邮件提交代理）正在等待接收来自用户的电子邮件。MSA使用同一服务器内的MTA将用户电子邮件转发到其他域。（MUA和MSA之间的通信可以通过SMTP、SUBMIT[10]或MAPI等其他方式进行）。
The MTA in the user email server may directly contact the email server of the recipient or may use other intermediate email gateways. The sending email server and all intermediate gateway MTAs usually communicate using SMTP. Communication with the destination email server usually uses SMTP or its derivative, LMTP [11].
用户电子邮件服务器中的MTA可以直接联系收件人的电子邮件服务器，也可以使用其他中间电子邮件网关。发送电子邮件服务器和所有中间网关MTA通常使用SMTP进行通信。与目标电子邮件服务器的通信通常使用SMTP或其衍生物LMTP[11]。
In the destination email server, a mail delivery agent (MDA) may deliver the email to the recipient's mailbox. The email client program of the recipient might use a different protocol (such as the Post Office Protocol version 3 (POP3) or IMAP) to access the mailbox and retrieve/read the messages.
在目标电子邮件服务器中，邮件传递代理（MDA）可以将电子邮件传递到收件人的邮箱。收件人的电子邮件客户端程序可能使用不同的协议（如邮局协议版本3（POP3）或IMAP）来访问邮箱和检索/读取邮件。
+-------+ +---------+ +---------+ +--------+ +-------+
|mail M| |M mail M| SMTP |M mail M| SMTP |M mail M| |M mail |
|clnt U|--|S srvr T|------|T gway T|------|T srvr D|--|U clnt |
| A| |A A| |A A| |A A| |A |
+-------+ +---------+ +---------+ +--------+ +-------+
| | |
| OCP | OCP | OCP
| | |
+----------+ +----------+ +----------+
| callout | | callout | | callout |
| server | | server | | server |
+----------+ +----------+ +----------+
+-------+ +---------+ +---------+ +--------+ +-------+
|mail M| |M mail M| SMTP |M mail M| SMTP |M mail M| |M mail |
|clnt U|--|S srvr T|------|T gway T|------|T srvr D|--|U clnt |
| A| |A A| |A A| |A A| |A |
+-------+ +---------+ +---------+ +--------+ +-------+
| | |
| OCP | OCP | OCP
| | |
+----------+ +----------+ +----------+
| callout | | callout | | callout |
| server | | server | | server |
+----------+ +----------+ +----------+
Figure 3: OPES SMTP Flow
图3:OPES SMTP流
From Figure 3, the MTA (the OPES processor) is either receiving or sending an email (or both) within an email server/gateway. An OPES processor might be the sender's SMTP server, the destination SMTP server, or any intermediate SMTP gateway. (Which building block belongs to which authoritative domain is an important question but different from deployment to deployment.) Note that this figure shows multiple OPES deployment options in a typical chain of mail servers and gateways with different roles as MSA, MTA, and MDA; the OPES standard case, however, will only have a single OPES processor and a single callout server in the message flow.
从图3中可以看出，MTA（OPES处理器）正在电子邮件服务器/网关中接收或发送电子邮件（或同时发送）。OPES处理器可能是发件人的SMTP服务器、目标SMTP服务器或任何中间SMTP网关。（哪个构建块属于哪个权威域是一个重要问题，但不同的部署不同。）请注意，此图显示了具有不同角色（如MSA、MTA和MDA）的典型邮件服务器和网关链中的多个OPES部署选项；然而，OPES标准案例在消息流中只有一个OPES处理器和一个callout服务器。
A typical (minimum) SMTP dialog between two OPES SMTP processors (MTA) will consist of the following (C: means client, S: means server):
两个OPES SMTP处理器（MTA）之间的典型（最小）SMTP对话框将包括以下内容（C:表示客户端，S:表示服务器）：
S: 220 mail.example.com Sample ESMTP MAIL Service, Version: 1.2
ready at Thu, 20 Jan 2005 11:24:40+0100
C: HELO [192.0.2.138]
S: 250 mail.example.com Hello [192.0.2.138]
C: MAIL FROM:<steve@example.org>
S: 250 2.1.0 steve@example.org....Sender OK
C: RCPT TO:<paul@example.com>
S: 250 2.1.5 paul@example.com
C: DATA
S: 354 Start mail input; end with "CRLF"."CRLF"
C: From: steve@example.org
C: To: sandra@example.com
C: Subject: Test
C:
C: Hi, this is a test!
C: .
S: 220 mail.example.com Sample ESMTP MAIL Service, Version: 1.2
ready at Thu, 20 Jan 2005 11:24:40+0100
C: HELO [192.0.2.138]
S: 250 mail.example.com Hello [192.0.2.138]
C: MAIL FROM:<steve@example.org>
S: 250 2.1.0 steve@example.org....Sender OK
C: RCPT TO:<paul@example.com>
S: 250 2.1.5 paul@example.com
C: DATA
S: 354 Start mail input; end with "CRLF"."CRLF"
C: From: steve@example.org
C: To: sandra@example.com
C: Subject: Test
C:
C: Hi, this is a test!
C: .
S: 250 2.6.0 "MAIL0m4b1f@mail.example.com" Queued mail for
delivery
C: QUIT
S: 221 2.0.0 mail.example.com Service closing transmission channel
S: 250 2.6.0 "MAIL0m4b1f@mail.example.com" Queued mail for
delivery
C: QUIT
S: 221 2.0.0 mail.example.com Service closing transmission channel
The client (C:) is issuing SMTP commands and the server (S:) is generating responses. All responses start with a status code and then some text. At minimum, 4 commands are needed to send an email. Together, all commands and responses to send a single email message form "the dialog". The mail message body is the data sent after the "DATA" command. An OPES processor could see that as command modification.
客户端（C:）正在发出SMTP命令，服务器（S:）正在生成响应。所有响应都以状态代码开始，然后是一些文本。发送电子邮件至少需要4个命令。所有发送单个电子邮件的命令和响应一起构成“对话框”。邮件正文是在“data”命令之后发送的数据。OPES处理器可以将其视为命令修改。
If a callout service wants to adapt the email message body, it is mainly interested in this part of the dialog:
如果调出服务想要调整电子邮件正文，它主要感兴趣的是对话框的这一部分：
From: steve@example.org
To: sandra@example.com
Subject: Test
From: steve@example.org
To: sandra@example.com
Subject: Test
Hi, this is a test!
嗨，这是一个测试！
The callout service may need to examine values of previous commands of the same dialog. For example, the callout service needs to examine the value of the RCPT command (it is "paul@example.com"), which is different from the "sandra@example.com" that the email client displays in the visible "To" field. That might be an important fact for some filters such as spam filters (Section 4.2).
详图索引服务可能需要检查同一对话框先前命令的值。例如，callout服务需要检查RCPT命令的值（它是“paul@example.com“”，这与“sandra@example.com电子邮件客户端显示在可见的“收件人”字段中。这可能是一些过滤器（如垃圾邮件过滤器）的一个重要事实（第4.2节）。
In principle, all filtering that is deployed at SMTP gateways today and tomorrow defines use cases for OPES callout filtering. An OCP/SMTP callout protocol will enable an SMTP gateway to vector out (parts of) an SMTP message or parts of the SMTP dialog to a callout server that is then performing actions on behalf of the gateway. (OCP/SMTP would be a profile defined for OCP analogous to the OCP/HTTP profile [4] that has been defined earlier.)
原则上，今天和明天部署在SMTP网关上的所有筛选都定义了OPES调用筛选的用例。OCP/SMTP调出协议将使SMTP网关能够将SMTP邮件或SMTP对话框的一部分矢量输出到调出服务器，然后该服务器将代表网关执行操作。（OCP/SMTP将是为OCP定义的配置文件，类似于前面定义的OCP/HTTP配置文件[4]）
Here is a collection of some typical use cases describing different filtering areas and different actions caused by those filters.
下面是一些典型用例的集合，描述了不同的过滤区域和由这些过滤器引起的不同操作。
These filters concentrate on the email message body and usually filter the email sections one by one. Email sections (attachments) that violate the security policy (e.g., because they contain a virus
这些过滤器集中在电子邮件正文上，通常逐个过滤电子邮件部分。违反安全策略（例如，因为包含病毒）的电子邮件部分（附件）
or contain an unwanted mime type) define an event that can cause a combination of different actions to be performed:
或包含不需要的mime类型）定义可导致执行不同操作组合的事件：
o The attachment is replaced by an error message.
o 附件被错误消息替换。
o The email is marked by inserting a warning into the subject or the email body.
o 通过在主题或电子邮件正文中插入警告来标记电子邮件。
o An additional header is added for post-processing steps.
o 为后处理步骤添加了一个额外的标题。
o The email storage is advised to put the email into quarantine.
o 建议电子邮件存储区将电子邮件隔离。
o Notifications are sent to sender, recipients, and/or administrators.
o 通知将发送给发件人、收件人和/或管理员。
o The incident is reported to other tools such as intrusion detection applications.
o 事件会报告给其他工具，如入侵检测应用程序。
These kinds of filters usually do not require working with elements of the SMTP dialog other than the email message body. An exception to this is the need to map email senders and recipients to different security sub-policies that are used for a particular message. A security filter may therefore require receiving the information of the RCPT TO and MAIL FROM commands as meta data with the email message body it examines.
这些类型的筛选器通常不需要处理SMTP对话框中除电子邮件正文以外的元素。例外情况是需要将电子邮件发件人和收件人映射到用于特定邮件的不同安全子策略。因此，安全过滤器可能需要将RCPT的信息作为元数据与它检查的电子邮件正文一起接收到命令和来自命令的邮件。
Next to security filters, spam filters are probably the most wanted filtering application today. Spam filters use several methods. They concentrate most on the email message body (that also includes the email headers), but many of these filters are also interested in the values of the other SMTP commands in order to compare the SMTP sender/recipients with the visible From/To fields. They may even want to get the source IP of the connected SMTP client as meta information to verify this against lists of open relays, known spammers, etc.
除了安全过滤器，垃圾邮件过滤器可能是当今最受欢迎的过滤应用程序。垃圾邮件过滤器使用多种方法。它们主要集中在电子邮件正文（也包括电子邮件标题）上，但其中许多过滤器也对其他SMTP命令的值感兴趣，以便将SMTP发件人/收件人与可见的发件人/收件人字段进行比较。他们甚至可能希望获得连接的SMTP客户端的源IP作为元信息，以对照开放中继列表、已知垃圾邮件发送者等进行验证。
These are typical actions that could be performed when a message has been classified as spam:
这些是邮件被归类为垃圾邮件时可以执行的典型操作：
o Add a mark to the subject of the email.
o 在电子邮件主题上添加标记。
o Add an additional header for post-processing steps.
o 为后处理步骤添加附加标题。
o The email storage is advised to put the email into a spam queue.
o 建议电子邮件存储将电子邮件放入垃圾邮件队列。
o The email is rejected or returned to the sender.
o 电子邮件被拒绝或返回给发件人。
The nature of these kinds of filters is not to modify the email message. Depending on what is being logged or reported on, the filter may need access to any part of the SMTP dialog. Most wanted is the sender and recipient information. Depending on the ability of the OPES processor to pre-calculate and transfer information about the message body, the callout filter may want to see the email message body itself or just that meta info; an example is the email size. This information would be typical logging and reporting information that is easy for the SMTP gateway to calculate although not a direct parameter of the SMTP dialog. Transferring the complete email message body only because the callout server wants to calculate its size would be a waste of network resources.
这些过滤器的本质不是修改电子邮件。根据记录或报告的内容，筛选器可能需要访问SMTP对话框的任何部分。最需要的是发件人和收件人信息。根据OPES处理器预计算和传输有关邮件正文信息的能力，调出过滤器可能希望查看电子邮件正文本身或仅查看该元信息；电子邮件大小就是一个例子。此信息是SMTP网关易于计算的典型日志记录和报告信息，尽管不是SMTP对话框的直接参数。仅因为调出服务器要计算其大小而传输完整的电子邮件正文将浪费网络资源。
These filters operate on the values of the MAIL FROM and RCPT TO commands of the SMTP dialog. They run an access control policy to determine whether a sender is currently allowed to send a message to the given recipients. The values of HELO/EHLO, AUTH, and STARTTLS commands may also be applied. The result of this filter has a direct influence on the SMTP response that the OPES processor has to send to its peer for the filtered SMTP command.
这些筛选器对SMTP对话框的MAIL FROM和RCPT TO命令的值进行操作。它们运行访问控制策略以确定当前是否允许发件人向给定收件人发送邮件。还可以应用HELO/EHLO、AUTH和STARTTLS命令的值。此筛选器的结果直接影响OPES处理器必须向其对等方发送的SMTP响应，以获取已筛选的SMTP命令。
Filters of this kind can support an email gateway to centrally encode and decode email, and to set and to verify email signatures. They will therefore modify the email message body to encrypt, decrypt, verify, or sign the message, or use an action as specified in the "Security Filter" (Section 4.1) section if the decryption or signature verification fails.
这类过滤器可以支持电子邮件网关来集中编码和解码电子邮件，并设置和验证电子邮件签名。因此，如果解密或签名验证失败，他们将修改电子邮件正文以加密、解密、验证或签名消息，或者使用“安全过滤器”（第4.1节）部分中指定的操作。
Sending the SMTP sender and recipient information as meta data to these filters is mission critical because these filters may not trust the information found in the header section of the email message body.
将SMTP发件人和收件人信息作为元数据发送到这些筛选器是至关重要的，因为这些筛选器可能不信任在电子邮件正文的标题部分中找到的信息。
SMTP messages may be sent with an illegal or uncommon format; this may have happened by a buggy SMTP application or on purpose in order to exploit vulnerabilities of other products. A normalization filter can correct the email format. The format correction can be done for the email body and for the value of other SMTP commands. An example for the email body format correction would be a strange length of UUencoded lines or unusual names of MIME sections. Command values
SMTP邮件可能以非法或不常见的格式发送；这可能是由于错误的SMTP应用程序造成的，也可能是为了利用其他产品的漏洞而故意造成的。规范化筛选器可以更正电子邮件格式。可以对电子邮件正文和其他SMTP命令的值进行格式更正。电子邮件正文格式更正的一个例子是UUencoded行的奇怪长度或MIME节的不寻常名称。命令值
may be analysed against buffer overflow exploits; a rewrite will not always be possible in this case (cannot simply rewrite an email address that is very long) but will require that the callout server tells the OPES processor to send an error response in reply to such a command.
可以针对缓冲区溢出漏洞进行分析；在这种情况下，重写并不总是可能的（不能简单地重写很长的电子邮件地址），但需要调出服务器通知OPES处理器发送错误响应以响应此类命令。
A corporation with multiple locations may want to deploy a central gateway that receives all email messages for all employees and then determines at which location the mail storage of the employee resides. The callout server will then need the RCPT TO command value and it will look up the location in the corporate directory service. It then tells either the OPES processor where the next SMTP server is (i.e., the next SMTP server to connect to) or it rewrites the recipient address; in the first case, the SMTP servers at the different locations accept emails of the same domain as the central gateway does; in the second case, the other locations will probably use the sublocation of the original domain (joe@example.org -> joe@fr.example.org or joe@de.example.org).
具有多个位置的公司可能希望部署一个中央网关，该网关接收所有员工的所有电子邮件，然后确定员工的邮件存储所在的位置。callout服务器随后将需要RCPT TO命令值，并将在公司目录服务中查找位置。然后，它告诉OPES处理器下一个SMTP服务器在哪里（即，要连接的下一个SMTP服务器），或者重写收件人地址；在第一种情况下，不同位置的SMTP服务器接受与中央网关相同域的电子邮件；在第二种情况下，其他位置可能会使用原始域的子位置(joe@example.org -> joe@fr.example.org或joe@de.example.org).
In a first step, the callout server will check the sender and recipient information that was transmitted in the SMTP dialog; that information again maps to a policy that will deny all messages either from that sender or to that recipient, or it checks the body of the email and classifies it (maybe just by looking for some words in the subject or by doing in-depth content analysis), which can then also lead to the decision to deny the message.
在第一步中，callout服务器将检查SMTP对话框中传输的发件人和收件人信息；该信息再次映射到一个策略，该策略将拒绝来自该发件人或收件人的所有邮件，或者它会检查邮件正文并对其进行分类（可能只是通过查找主题中的一些单词或进行深入的内容分析），这也会导致拒绝该邮件的决定。
Unlike previous examples, this use case wants to deny the email while the SMTP dialog is still active, i.e., before the OPES processor finally accepted the message. Depending on the exact policy, the error response should then be sent in reply to the MAIL FROM, RCPT TO, or DATA command.
与前面的示例不同，此用例希望在SMTP对话框仍处于活动状态时，即在OPES处理器最终接受消息之前，拒绝电子邮件。根据具体的策略，错误响应应随后发送，以回复MAIL FROM、RCPT to或DATA命令。
This use case will only modify the email message body without any other influence on the SMTP dialogs, mail routing, etc. Larger sections (attachments) are removed from the email, and the content is stored on a web server. A link to that new URL is then added into the text of a first section that is likely to be displayed by an email client. Storing the attachments onto the web server is not in the scope of the OPES/SMTP scenario and needs to be implemented by the callout server.
此用例将仅修改电子邮件正文，而不会对SMTP对话框、邮件路由等产生任何其他影响。较大的部分（附件）将从电子邮件中删除，并且内容存储在web服务器上。然后，将指向新URL的链接添加到电子邮件客户端可能显示的第一部分的文本中。将附件存储到web服务器不在OPES/SMTP方案的范围内，需要由callout服务器实现。
Application-independent security considerations are documented in application-agnostic OPES specifications [5]. This document contains only use cases and defines no protocol operations. Security considerations for protocols that appear in these use cases are documented in the corresponding protocol specifications.
独立于应用程序的安全注意事项记录在应用程序无关的OPES规范[5]中。本文档仅包含用例，不定义协议操作。这些用例中出现的协议的安全注意事项记录在相应的协议规范中。
Use case "Secure Email Handling" (Section 4.5) is special in this regard because it requires the extension of the end-to-end encryption model and a secure handling of private cryptographic keys when creating digital signatures or when decrypting messages. Both are out of scope of OPES protocol specifications. An implementation of such a service raises security issues (such as availability and storage of cryptographic keys) that must be addressed regardless of whether the implementation happens within an MTA or within an OPES callout server.
用例“安全电子邮件处理”（第4.5节）在这方面很特殊，因为它需要扩展端到端加密模型，并在创建数字签名或解密消息时安全处理私有加密密钥。两者都超出了OPES协议规范的范围。此类服务的实施会引发安全问题（如加密密钥的可用性和存储），无论实施是在MTA内还是在OPES callout服务器内进行，都必须解决这些问题。
[1] Barbir, A., Penno, R., Chen, R., Hofmann, M., and H. Orman, "An Architecture for Open Pluggable Edge Services (OPES)", RFC 3835, August 2004.
[1] Barbir，A.，Penno，R.，Chen，R.，Hofmann，M.，和H.Orman，“开放可插拔边缘服务（OPES）的体系结构”，RFC 38352004年8月。
[2] Barbir, A., Burger, E., Chen, R., McHenry, S., Orman, H., and R. Penno, "Open Pluggable Edge Services (OPES) Use Cases and Deployment Scenarios", RFC 3752, April 2004.
[2] Barbir，A.，Burger，E.，Chen，R.，McHenry，S.，Orman，H.，和R.Penno，“开放可插拔边缘服务（OPES）用例和部署场景”，RFC 3752，2004年4月。
[3] Rousskov, A., "Open Pluggable Edge Services (OPES) Callout Protocol (OCP) Core", RFC 4037, March 2005.
[3] Rousskov，A.，“开放可插拔边缘服务（OPES）呼叫协议（OCP）核心”，RFC 4037，2005年3月。
[4] Rousskov, A. and M. Stecher, "HTTP Adaptation with Open Pluggable Edge Services (OPES)", RFC 4236, November 2005.
[4] Rousskov，A.和M.Stecher，“使用开放可插拔边缘服务（OPES）的HTTP适配”，RFC 4236，2005年11月。
[5] 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.
[5] Barbir，A.，Batuner，O.，Srinivas，B.，Hofmann，M.，和H.Orman，“开放可插拔边缘服务（OPES）的安全威胁和风险”，RFC 3837，2004年8月。
[6] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[6] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[7] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April 2001.
[7] 《简单邮件传输协议》，RFC 28212001年4月。
[8] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[8] 菲尔丁，R.，盖蒂斯，J.，莫卧儿，J.，弗莱斯蒂克，H.，马斯特，L.，利奇，P.，和T.伯纳斯李，“超文本传输协议——HTTP/1.1”，RFC2616，1999年6月。
[9] Crocker, D., "Internet Mail Architecture", Work in Progress, March 2005.
[9] Crocker，D.，“互联网邮件体系结构”，正在进行的工作，2005年3月。
[10] Gellens, R. and J. Klensin, "Message Submission", RFC 2476, December 1998.
[10] Gellens，R.和J.Klensin，“信息提交”，RFC 24761998年12月。
[11] Myers, J., "Local Mail Transfer Protocol", RFC 2033, October 1996.
[11] Myers，J.，“本地邮件传输协议”，RFC 2033，1996年10月。
Acknowledgements
致谢
Many thanks to everybody who provided input for the use case examples, namely, jfc and Markus Hofmann. Thanks also for the discussion and feedback given on the OPES mailing list.
非常感谢为用例示例提供输入的每个人，即jfc和Markus Hofmann。还感谢对OPES邮件列表的讨论和反馈。
Authors' Addresses
作者地址
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/
Abbie Barbir Nortel 3500 Carling Avenue Ottawa, Ontario CA
艾比芭比北电3500卡林大道渥太华，安大略省
Phone: +1 613 763 5229
EMail: abbieb@nortel.com
Phone: +1 613 763 5229
EMail: abbieb@nortel.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（2006年）。
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 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.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
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 provided by the IETF Administrative Support Activity (IASA).
RFC编辑器功能的资金由IETF行政支持活动（IASA）提供。