[要約] RFC 4496は、Open Pluggable Edge Services（OPES）SMTPの使用例に関するものであり、OPESアーキテクチャの適用範囲と利点を示しています。このRFCの目的は、OPESアーキテクチャを使用してSMTPトラフィックを処理するための具体的な使用例を提供することです。
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).
Copyright（c）The Internet Society（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.
Open Pluggable Edge Services（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.
Open Pluggable Edge Services（OPES）アーキテクチャ[1]により、データプロバイダー、データ消費者、およびゼロ以上の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 [8]に基づくOPEのユースケースは[2]で説明されています。この作業では、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プロセッサは、Mail Submission Agent（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.
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「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 [7]から取得したSMTP設計を図1に示します。SMTPクライアントに送信するメッセージがある場合、SMTPサーバーへの双方向伝送チャネルを確立します。SMTPクライアントの責任は、メールメッセージを1つ以上の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メッセージの送信（送信）[10]およびローカルメール転送プロトコル（LMTP）[11]から派生したプロトコルの1つを使用するユースケースに焦点を当てています。
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を介して、[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プロセッサと単一のCalloutサーバーのみがあります。
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：Means Client、S：Means Server）：
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
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つのコマンドが必要です。一緒に、すべてのコマンドと応答は、単一の電子メールメッセージフォーム「ダイアログ」を送信します。メールメッセージ本文は、「データ」コマンドの後に送信されたデータです。OPESプロセッサは、それをコマンドの変更と見なすことができます。
If a callout service wants to adapt the email message body, it is mainly interested in this part of the dialog:
Calloutサービスが電子メールメッセージ本文を適応させたい場合、それは主にダイアログのこの部分に関心があります。
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).
コールアウトサービスは、同じダイアログの以前のコマンドの値を調べる必要がある場合があります。たとえば、コールアウトサービスは、RCPTコマンドの値（「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プロファイル[4]に類似したOCPに対して定義されたプロファイルです。）
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:
これらのフィルターは電子メールメッセージ本文に集中し、通常、電子メールセクションを1つずつフィルタリングします。セキュリティポリシーに違反する電子メールセクション（添付ファイル）（たとえば、ウイルスが含まれているか、不要な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ダイアログの直接パラメーターではないにもかかわらず、SMTPゲートウェイが簡単に計算できる典型的なロギングおよびレポート情報です。Calloutサーバーがそのサイズを計算したいという理由だけで、完全な電子メールメッセージ本文を転送することは、ネットワークリソースの無駄になります。
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ダイアログのコマンドからのメールとRCPTの値で動作します。アクセス制御ポリシーを実行して、送信者が現在特定の受信者にメッセージを送信できるかどうかを判断します。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コマンドの値に対して実行できます。電子メールボディ形式の修正の例は、奇妙な長さのuUencoded行または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).
複数の場所を持つ企業は、すべての従業員のすべての電子メールメッセージを受信し、従業員のメールストレージがどの場所で居住するかを決定する中央ゲートウェイを展開したい場合があります。Callout ServerにはRCPTがコマンド値を必要とし、コーポレートディレクトリサービスの場所を検索します。次に、次のSMTPサーバー（つまり、接続する次のSMTPサーバー）があるOPESプロセッサに、受信者アドレスを書き換えます。最初のケースでは、異なる場所のSMTPサーバーは、中央ゲートウェイと同じドメインの電子メールを受け入れます。2番目のケースでは、他の場所はおそらく元のドメイン（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プロセッサが最終的にメッセージを受け入れる前に、電子メールを拒否したいと考えています。正確なポリシーに応じて、エラー応答は、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コールアウトサーバー内で実装が発生するかどうかに関係なく、対処する必要があるセキュリティ問題（暗号化キーの可用性やストレージなど）を提起します。
[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、「Open Pluggable Edge Services（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.、Burger、E.、Chen、R.、Mchenry、S.、Orman、H。、およびR. Penno、「Open Pluggable Edge Services（OPES）ユースケースと展開シナリオ」、RFC 3752、2004年4月。
[3] Rousskov, A., "Open Pluggable Edge Services (OPES) Callout Protocol (OCP) Core", RFC 4037, March 2005.
[3] Rousskov、A。、「Open Pluggable Edge Services（OPES）Callout Protocol（OCP）Core」、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、「Open Pluggable Edge Services（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、「Open Pluggable Edge Services（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] Klensin、J。、「Simple Mail Transfer Protocol」、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] Fielding、R.、Gettys、J.、Mogul、J.、Frystyk、H.、Masinter、L.、Leach、P。、およびT. Berners-Lee、 "HyperText Transfer Protocol-HTTP/1.1"、RFC 2616、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、「Message Submission」、RFC 2476、1998年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
Martin Stecher Secure Computing Corporation Vattmannnst。3 33100 Paderbornドイツ
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
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（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事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。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）によって提供されます。