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
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適応のための準備でOPES SMTPのユースケースと展開シナリオについて説明します。
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
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.
[1]開きプラガブルエッジサービス（OPES）アーキテクチャは、データプロバイダ、データコンシューマ、およびゼロ以上OPESプロセッサ間の連携アプリケーションサービス（OPESサービス）を可能にします。検討中のアプリケーションサービスは、分析し、おそらくデータプロバイダとデータコンシューマの間でやり取りするアプリケーションレベルのメッセージを変換します。 OPESプロセッサは、通信および1つ以上のリモートコールアウトサーバとの連携により、サービス実行の責任を配布することができます。
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.
HTTPに基づくOPESためのユースケースは、[8]の[2]に記載されています。この作業は、SMTPのためOPESに焦点を合わせ[7] [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プロセッサは、メール発信エージェント（MSA）、メール転送エージェント（MTA）、メール配信エージェント（MDA）、およびメールユーザエージェント（MUA）を含むSMTP交換に参加する任意の薬剤であってもよいです。この文書は、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接続が閉じられた後、現在の電子メールフィルタリングシステムは、（MTAのメッセージキューに、例えば）、SMTPの交換中または既に受信されたメッセージを操作のいずれか。
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は、HTTPから変更要求の満足を要求する類似の、SMTPコマンドの修正及びコマンド満足に関与する[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.
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[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.
RFC 2821から取られたSMTP設計は、[7]、SMTPクライアントが送信するメッセージを有する場合、それはSMTPサーバに双方向伝送チャネルを確立し、図1に示されています。 SMTPクライアントの責任は、一つ以上のSMTPサーバーにメールメッセージを転送し、またはこれを行うにはその失敗を報告することです。
+----------+ +----------+
+------+ | | | |
| 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クライアントは、メールメッセージの最終宛先（複数可）を特定します。他の場合には、決定されたドメイン名は、それらのメールメッセージが中継されるべき介して中間宛先を識別する。
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 |
+-------+ +---------+ +---------+ +--------+ +-------+
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プロセッサはMSA、MTA、MDA、及びMUAを含むSMTP交換に参加している任意の薬剤であってもよいです。しかし、この文書は、OPESプロセッサはSMTPプロトコルまたはSMTPメッセージ提出（SUBMIT）[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プロセッサは、それがコールアウトサーバにデータをベクトルすることを可能にする[3]クライアントOCP（OPESコールアウトプロトコル）によって増強されます。フィルタリング機能は、コールアウト・サーバー上にあります。
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を介してであってもよい、[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 |
+----------+ +----------+ +----------+
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プロセッサとメッセージフローの単一コールアウト・サーバを有することになります。
A typical (minimum) SMTP dialog between two OPES SMTP processors (MTA) will consist of the following (C: means client, S: means server):
2つの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サンプルESMTPメールサービス、バージョン：木の準備1.2、2005年1月20日11：24：40 + 0100 C：HELO [192.0.2.138] S：250 mail.example.comこんにちは[192.0。 2.138] C <steve@example.org> S：FROM MAIL 250 2.1.0 steve@example.org ....送信者OK C：RCPT TO：<paul@example.com> S：250 2.1.5ポール@ example.com C：DATA S：354開始メール入力; 。 "CRLF" "CRLF" Cで終了します。From：steve@example.orgのC：TO：sandra@example.com C：件名：テストC：C：こんにちは、これはテストです！ 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" 送達Cのためのキューメール：Sを終了：221 2.0.0 mail.example.comサービス閉鎖伝送チャネル
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
投稿者：steve@example.orgへ：sandra@example.com件名：テスト
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).
コールアウト・サービスは、同じダイアログの以前のコマンドの値を調べる必要があります。例えば、コールアウト・サービスは、RCPTコマンドの値を調べる必要がある「を」目に見えるにおける「sandra@example.com」という電子メールクライアントが表示と違って、（それが「paul@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 / HTTPプロファイルに類似したOCPのために定義されたプロファイル[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ダイアログの要素での作業は必要ありません。この例外は、特定のメッセージのために使用されている異なるセキュリティサブポリシーに電子メールの送信者と受信者をマップする必要があります。セキュリティフィルタは、したがって、それは調べて電子メールメッセージのボディを持つメタデータとしてFROMコマンドRCPT TOとMAILの情報を受信する必要があります。
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ダイアログのコマンドTO FROMとRCPT MAILの値を操作します。彼らは、送信者が現在与えられた受信者にメッセージを送信することが許可されているかどうかを判断するために、アクセス制御ポリシーを実行します。 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 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.
SMTPメッセージは、違法または珍しい形式で送信されてよいです。これは、他の製品の脆弱性を悪用するために、バギーSMTPアプリケーションによって、目的に起こっている可能性があります。正規化フィルタは、電子メールの形式を修正することができます。フォーマット補正は電子メールのボディのためにと他のSMTPコマンドの値のために行うことができます。電子メールの本文の形式の補正のための例は、UUエンコードされた行またはMIMEセクションの珍しい名前の奇妙な長さになります。指令値は、バッファオーバーフロー攻撃に対して分析することができます。リライトは、常にこのような場合にはできません（単に非常に長い電子メールアドレスを書き換えることはできません）が、コールアウトサーバは、このようなコマンドへの応答でエラー応答を送信するために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).
複数の拠点を持つ企業は、すべての従業員のためにすべての電子メールメッセージを受信中央ゲートウェイを展開すると、その後、従業員のメールストレージが存在する場所で決定します。コールアウトサーバは、その値をRCPT TOコマンドが必要になりますし、それが企業のディレクトリサービスの場所を検索します。それは、次のSMTPサーバが（に接続する、すなわち、次のSMTPサーバ）であるか、受信者のアドレスを書き換えるOPESプロセッサのいずれかを告げます。最初のケースでは、異なる場所でSMTPサーバは、中央ゲートウェイが行うのと同じドメインのメールを受け入れます。 （ - > joe@fr.example.org又はjoe@de.example.org joe@example.org）は、第2の場合には、他の位置は、おそらく元のドメインのサブロケーションを使用します。
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.
最初のステップでは、コールアウトサーバは、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.
OPESプロセッサが最終的にメッセージを受け入れ前に、前の例とは異なり、このユースケースは、すなわち、SMTPダイアログがまだアクティブである間、電子メールを拒否するように望んでいます。正確なポリシーに応じて、エラー応答は、その後、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のシナリオの範囲ではなく、コールアウトサーバによって実装される必要があります。
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コールアウトサーバ内に起こるかどうかに対処しなければならない（例えば、暗号鍵の可用性およびストレージとして）セキュリティ上の問題を提起します。
[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.、陳、R.、ホフマン、M.、およびH.オーマン、 "オープン・プラグイン可能なエッジサービスのためのアーキテクチャ（OPES）"、RFC 3835、2004年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.、バーガー、E.、チェン、R.、マクヘンリー、S.、オーマン、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を、 "HTTP適応オープンプラグイン可能なエッジサービス（OPES）と"、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.、スリニバス、B.、ホフマン、M.、およびH.オーマン、 "オープン・プラグイン可能なエッジサービスのセキュリティ脅威とリスク（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]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[7] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April 2001.
[7] Klensin、J.、 "簡易メール転送プロトコル"、RFC 2821、2001年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.、Frystyk、H.、Masinter、L.、リーチ、P.、およびT.バーナーズ - リー、 "ハイパーテキスト転送プロトコル - HTTP / 1.1" 、RFC 2616、1999年6月。
[9] Crocker, D., "Internet Mail Architecture", Work in Progress, March 2005.
[9]クロッカー、D.、 "インターネットメールのアーキテクチャ"、進歩、2005年3月に仕事を。
[10] Gellens, R. and J. Klensin, "Message Submission", RFC 2476, December 1998.
[10] Gellens、R.及びJ. Klensin、 "メッセージ送信"、RFC 2476、1998年12月。
[11] Myers, J., "Local Mail Transfer Protocol", RFC 2033, October 1996.
[11]マイヤーズ、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とマーカス・ホフマンの入力を提供し、みんなに感謝します。また、OPESメーリングリストで与えられた議論とフィードバックをお寄せいただきありがとうございます。
Authors' Addresses
著者のアドレス
Martin Stecher Secure Computing Corporation Vattmannstr. 3 33100 Paderborn Germany
マーティンStecherは、コンピューティング株式会社Vattmannstrを固定します。 3 33100パーダーボルン、ドイツ
EMail: martin.stecher@webwasher.com URI: http://www.securecomputing.com/
電子メール：martin.stecher@webwasher.com URI：http://www.securecomputing.com/
Abbie Barbir Nortel 3500 Carling Avenue Ottawa, Ontario CA
アビーBarbirノーテル3500カーリングアベニューオタワ、オンタリオCA
Phone: +1 613 763 5229 EMail: abbieb@nortel.com
電話：+1 613 763 5229 Eメール：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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンライン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-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFCエディタ機能のための資金は、IETF管理サポート活動（IASA）によって提供されます。