RFC4496 日本語訳
4496 Open Pluggable Edge Services (OPES) SMTP Use Cases. M. Stecher,A. Barbir. May 2006. (Format: TXT=27403 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group M. Stecher
Request for Comments: 4496 Secure Computing
Category: Informational A. Barbir
Nortel
May 2006
コメントを求めるワーキンググループM.ステッチャーの要求をネットワークでつないでください: 4496年の安全なコンピューティングカテゴリ: 情報のA.Barbirノーテル2006年5月
Open Pluggable Edge Services (OPES) SMTP Use Cases
開いているPluggable縁のサービス(作品)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)インターネット協会(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.
オープンPluggable Edge Services(作品)フレームワークはアプリケーション不可知論者です。 アプリケーション特有の適合はそのフレームワークを広げています。 このドキュメントはOPES SMTPについて説明します。作品との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
1. 序論…2 2. 用語…2 3. SMTPアーキテクチャの概要に事情を知らせてください…3 3.1. 作品SMTPシステムの操作流動…4 3.1.1. 作品SMTPの例…5 4. 作品/SMTPはケースを使用します…6 4.1. セキュリティフィルタは、メッセージをメールするのに申し込みました…6 4.2. フィルタをばらまいてください…7 4.3. フィルタを登録して、報告します…8 4.4. コントロール・フィルタにアクセスしてください…8 4.5. メールが取り扱いであると機密保護してください…8 4.6. 形式正常化をメールしてください…8 4.7. コースを変更するのとアドレスの書き直しを郵送してください…9 4.8. SMTP対話の間、メールを妨げてください…9 4.9. HTTPリンクへの付属を変換してください…9 5. セキュリティ問題…10 6. 参照…10 6.1. 標準の参照…10 6.2. 有益な参照…10の承認…11
Stecher & Barbir Informational [Page 1] RFC 4496 OPES SMTP Use Cases May 2006
ステッチャーとBarbirの情報[1ページ]のRFC4496作品SMTPは2006年5月にケースを使用します。
1. Introduction
1. 序論
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.
オープンPluggable Edge Services(作品)アーキテクチャ[1]は情報提供業者と、データ消費者と、ゼロの間のアプリケーション・サービス(作品サービス)か、より多くの作品プロセッサを協力して可能にします。 考慮しているアプリケーション・サービスは、情報提供業者とデータ消費者の間で交換されたアプリケーションレベルメッセージを、分析して、ことによると変えます。 作品プロセッサは、1つ以上のリモートcalloutサーバを伝えて、協力することによって、サービス実行の責任を分配できます。
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.
そのようなサービスの実行は作品プロセッサにインストールされた1セットの規則で治められます。 規則評価は作品プロセッサ、または、リモートcalloutサーバの上のローカルのサービスアプリケーションの実行の引き金となることができます。
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]に基礎づけた使用は[2]で説明されます。 SMTP[7]のための作品のこの仕事焦点はケースを使用します。(作品サービスのタイプへのケースと増進が[2]で定義した追加使用はケースによって提供されます)。
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では、作品プロセッサはSMTP交換に参加するどんなエージェントであるかもしれません、メールSubmissionエージェント(MSA)、メール配達エージェント(MTA)メールDeliveryエージェント(MDA)、およびメール・ユーザー・エージェント(MUA)を含んでいて。 このドキュメントは作品プロセッサが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]から変更を要求して、満足を要求するために、類似しています。
2. Terminology
2. 用語
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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[6]で説明されるように本書では解釈されることであるべきですか? 標準の意味と共に使用されると、これらのキーワードはすべて大文字するようになるでしょう。 コネが小文字で印刷するこれらの単語の発生は標準の含意なしで正常な散文用法を包括します。
Stecher & Barbir Informational [Page 2] RFC 4496 OPES SMTP Use Cases May 2006
ステッチャーとBarbirの情報[2ページ]のRFC4496作品SMTPは2006年5月にケースを使用します。
3. Brief Overview of SMTP Architecture
3. SMTPアーキテクチャの簡潔な概要
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.
RFC2821[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
+----------+ +----------+ +------+ | | | | | ユーザ| <-->、|、| SMTP| | +------+ | クライアント|コマンド/回答| サーバ| +------+ | SMTP| <、-、-、-、-、-、-、-、-、-、-、-、-、--、>| SMTP| +------+ | ファイル| <-->、|、| そして、メール| | <-->、| ファイル| |システム| | | | | |システム| +------+ +----------+ +----------+ +------+ SMTPクライアントSMTPサーバ
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]で見つけられるかもしれません。
Stecher & Barbir Informational [Page 3] RFC 4496 OPES SMTP Use Cases May 2006
ステッチャーとBarbirの情報[3ページ]のRFC4496作品SMTPは2006年5月にケースを使用します。
+-------+ +---------+ +---------+ +--------+ +-------+ |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 | +-------+ +---------+ +---------+ +--------+ +-------+
+-------+ +---------+ +---------+ +--------+ +-------+ |メールM| |MはMを郵送します。| SMTP|MはMを郵送します。| SMTP|MはMを郵送します。| |Mメール| |clnt U|--|S srvr T|------|T gway T|------|T srvr D|--|U clnt| | 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]).
この仕事では、作品プロセッサはSMTP交換に参加しているどんなエージェントであるかもしれません、MSA、MTA、MDA、およびMUAを含んでいて。 しかしながら、このドキュメントは作品プロセッサがSMTPプロトコルを使用する場合かプロトコルのひとりがSMTP Message Submission(SUBMIT)[10]とLocalメールTransferプロトコル(LMTP)[11])から引き出した使用に焦点を合わせます。
3.1. Operation Flow of an OPES SMTP System
3.1. 作品SMTPシステムの操作流動
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プロトコルのデータ・ストリームにはある作品プロセッサデバイスです。 作品プロセッサはベクトルの出ているデータにそれを許すOCP(作品calloutは議定書を作る)[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)から始まります。 ユーザは外向的なEメールサーバにメールを送ります。Eメールサーバには、ユーザからメールを受け取るのを待っているMSA(メール服従エージェント)があります。 MSAは、ユーザメールを他のドメインに転送するのに同じサーバの中でMTAを使用します。 (MAPIなどのSMTP、SUBMIT[10]、または他の何かを通してMUAとMSAとのコミュニケーションがあるかもしれません。)
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].
ユーザEメールサーバのMTAは直接受取人のEメールサーバに連絡するか、または他の中間的メールゲートウェイを使用するかもしれません。 通常、送付Eメールサーバとすべての中間ゲートウェイMTAsは、SMTPを使用することで交信します。 LMTP[11]、通常、目的地EメールサーバとのコミュニケーションはSMTPかその派生物を使用します。
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.
目的地Eメールサーバでは、メール配送エージェント(MDA)はメールを受信者のメールボックスに提供するかもしれません。 受取人のメールクライアントプログラムは、メッセージにメールボックスにアクセスして、検索するか、または読むのに、異なったプロトコル(ポストオフィスプロトコルのバージョン3(POP3)かIMAPなどの)を使用するかもしれません。
Stecher & Barbir Informational [Page 4] RFC 4496 OPES SMTP Use Cases May 2006
ステッチャーとBarbirの情報[4ページ]のRFC4496作品SMTPは2006年5月にケースを使用します。
+-------+ +---------+ +---------+ +--------+ +-------+
|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 |
+----------+ +----------+ +----------+
+-------+ +---------+ +---------+ +--------+ +-------+ |メールM| |MはMを郵送します。| SMTP|MはMを郵送します。| SMTP|MはMを郵送します。| |Mメール| |clnt U|--|S srvr T|------|T gway T|------|T srvr D|--|U clnt| | A| |A| |A| |A| |A| +-------+ +---------+ +---------+ +--------+ +-------+ | | | | OCP| OCP| OCP| | | +----------+ +----------+ +----------+ | callout| | callout| | callout| | サーバ| | サーバ| | サーバ| +----------+ +----------+ +----------+
Figure 3: OPES SMTP Flow
図3: 作品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(作品プロセッサ)はEメールサーバ/ゲートウェイの中でメール(ともに)を受け取るか、または送ります。 作品プロセッサは、送付者のSMTPサーバー、目的地SMTPサーバ、またはどんな中間的SMTPゲートウェイであるかもしれません。 (展開によって、どのブロックがどの正式のドメインに属すかは、重要な質問にもかかわらず、異なっています。) この図がMSA、MTA、およびMDAとして異なる役割でメールサーバとゲートウェイの典型的なチェーンにおける複数の作品展開オプションを示すことに注意してください。 しかしながら、作品の一般的なケースに、単一の作品プロセッサとメッセージ流動におけるただ一つのcalloutサーバがあるだけでしょう。
3.1.1. OPES SMTP Example
3.1.1. 作品SMTPの例
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 Sample ESMTPメールService、バージョン: 1.2 木曜日、2005年1月20日の11:24:40+0100Cで準備ができる: HELO、[192.0、.2、.138]、S: 250mail.example.com Hello、[192.0 .2 .138]C: FROM:<steve@example.org に郵送してください、gt;、S: 250 2.1.0 steve@example.org... 。送付者OK C: RCPT TO:<paul@example.com 、gt;、S: 250 2.1.5 paul@example.com C: データS: 354 メール入力を始めてください。 "CRLF" "CRLF"Cと共に終わってください: From: steve@example.org C: To: sandra@example.com C: Subject: テストC: C: こんにちは、これはテストです! C: .
Stecher & Barbir Informational [Page 5] RFC 4496 OPES SMTP Use Cases May 2006
ステッチャーとBarbirの情報[5ページ]のRFC4496作品SMTPは2006年5月にケースを使用します。
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 Serviceが精神を集中します。
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つのコマンドが、メールを送るのに必要です。 単一の電子メールメッセージを送るすべてのコマンドと応答は「対話」を一緒に、形成します。 メール・メッセージ本体は「データ」が命令した後に送られたデータです。 作品プロセッサはコマンド変更であるとそれをみなすかもしれません。
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
From: steve@example.org To: sandra@example.com Subject: テスト
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サービスは、同じ対話の前のコマンドの値を調べる必要があるかもしれません。 例えば、calloutサービスは、メールクライアントが目に見える“To"分野に表示する" sandra@example.com "と異なったRCPTコマンド(それは" paul@example.com "である)の値を調べる必要があります。 それはスパムフィルター(セクション4.2)などのいくつかのフィルタのための重要な事実であるかもしれません。
4. OPES/SMTP Use Cases
4. 作品/SMTPはケースを使用します。
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ゲートウェイで配布されて、明日が定義するすべてが作品calloutフィルタリングにケースを使用します。 OCP/SMTP calloutプロトコルが外でベクトルへのSMTPゲートウェイを可能にする、(離れている、)、ゲートウェイを代表した当時の実行動作であるcalloutサーバへの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.
ここに、異なったろ過面について説明するケースと異なった動作がそれらのフィルタで引き起こした何らかの典型的な使用の収集があります。
4.1. Security Filters Applied to Email Messages
4.1. セキュリティフィルタは、メッセージをメールするのに申し込みました。
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
これらのフィルタは、メールメッセージ本文に集中して、通常、メール部をひとつずつフィルターにかけます。 安全保障政策に違反するセクション(付属)にメールしてください、(例えば、それらはウイルスを含んでいます。
Stecher & Barbir Informational [Page 6] RFC 4496 OPES SMTP Use Cases May 2006
ステッチャーとBarbirの情報[6ページ]のRFC4496作品SMTPは2006年5月にケースを使用します。
or contain an unwanted mime type) define an event that can cause a combination of different actions to be performed:
または、求められていないパントマイムを含んでください。タイプ) 異なった動作の組み合わせを実行できるイベントを定義してください:
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 TOとMAIL FROMコマンドを要求するかもしれません。
4.2. Spam Filter
4.2. スパムフィルター
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.
セキュリティフィルタの横の、今日、スパムフィルターはたぶん最も欲しいフィルタリングアプリケーションです。 スパムフィルターはいくつかのメソッドを使用します。 彼らはメールメッセージ本文に最も集中しますが(また、それはメールヘッダーを含んでいます)、また、これらのフィルタの多くが、分野への目に見えるFrom/と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 メールを送付者に拒絶するか、または返します。
Stecher & Barbir Informational [Page 7] RFC 4496 OPES SMTP Use Cases May 2006
ステッチャーとBarbirの情報[7ページ]のRFC4496作品SMTPは2006年5月にケースを使用します。
4.3. Logging and Reporting Filters
4.3. フィルタを登録して、報告します。
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対話のどんな部分へのアクセスも必要とするかもしれません。 最重要指名手配は、送付者と受取人情報です。 作品プロセッサがメッセージ本体の情報をあらかじめ計算して、移す能力によって、calloutフィルタはメールメッセージ本文自体かまさしくそのメタインフォメーションを見たがっているかもしれません。 例はメールサイズです。 この情報はSMTP対話のダイレクトパラメタではありませんが、計算するSMTPゲートウェイに、簡単な情報を登録して、報告することの典型でしょう。 単にcalloutサーバがサイズについて計算したがっているので完全なメールメッセージ本文を移すのは、ネットワーク資源の浪費でしょう。
4.4. Access Control Filters
4.4. アクセス制御フィルタ
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.
これらのフィルタはMAIL FROMとRCPT TOの値でSMTP対話のコマンドを操作します。 彼らは、送付者が現在与えられた受取人にメッセージを送ることができるかどうか決定するためにアクセス制御方針を実行します。 また、HELO/EHLO、AUTH、およびSTARTTLSコマンドの値は適用されるかもしれません。 このフィルタの結果は作品プロセッサがフィルターにかけることのSMTPコマンドのために同輩に送らなければならないSMTP応答に直接の影響を持っています。
4.5. Secure Email Handling
4.5. 安全なメール取り扱い
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送付者と受取人情報をこれらのフィルタに送るのはミッションクリティカルです。
4.6. Email Format Normalization
4.6. メール形式正常化
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部の珍しい名前でしょう。 コマンド値
Stecher & Barbir Informational [Page 8] RFC 4496 OPES SMTP Use Cases May 2006
ステッチャーとBarbirの情報[8ページ]のRFC4496作品SMTPは2006年5月にケースを使用します。
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.
バッファオーバーフロー功績に対して分析されるかもしれません。 書き直しは、この場合いつも可能であるというわけではありませんが(非常に長いEメールアドレスを絶対に書き直すことができません)、calloutサーバが、そのようなコマンドに対して誤り応答を送るように作品プロセッサに言うのを必要とするでしょう。
4.7. Mail Rerouting and Address Rewriting
4.7. コースを変更するのとアドレスの書き直しを郵送してください。
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コマンド価値を必要とするでしょう、そして、それは法人のディレクトリサービスで位置を見上げるでしょう。 次に、それは、どこで次のSMTPサーバーが(すなわち、接続する次のSMTPサーバー)ですかそれとも受取人アドレスを書き直すかを作品プロセッサに言います。 前者の場合、別の場所のSMTPサーバーは中央のゲートウェイが受け入れるように同じドメインのメールを受け入れます。 2番目の場合に、他の位置がたぶん元のドメインの「副-位置」を使用する、( joe@example.org --、gt;、 joe@fr.example.org か joe@de.example.org )
4.8. Block Email during SMTP Dialog
4.8. SMTP対話の間のブロックメール
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対話が以前まだアクティブである間、メールを否定するために、作品プロセッサは最終的にメッセージを受け入れました。 正確な方針によって、そして、MAIL FROM、RCPT TO、またはDATAコマンドに対して誤り応答を送るべきです。
4.9. Convert Attachments to HTTP Links
4.9. HTTPリンクへの付属を変換してください。
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対話、メールルーティングなどへの影響なしでいかなる他のもメールメッセージ本文を変更します。 より大きいセクション(付属)はメールから取り外されます、そして、内容はウェブサーバーに保存されます。次に、その新しいURLへのリンクはメールクライアントによって表示されそうな最初のセクションのテキストに追加されます。 ウェブサーバーとして付属を保存するのが作品/SMTPシナリオとcalloutサーバによって実装するべき必要性の範囲にありません。
Stecher & Barbir Informational [Page 9] RFC 4496 OPES SMTP Use Cases May 2006
ステッチャーとBarbirの情報[9ページ]のRFC4496作品SMTPは2006年5月にケースを使用します。
5. Security Considerations
5. セキュリティ問題
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.
アプリケーションから独立しているセキュリティ問題はアプリケーション不可知論者作品仕様[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)が特別であるケース「安全なメール取り扱い」個人的な暗号化キーを使用してください。 作品プロトコル仕様の範囲の外に両方があります。 そのようなサービスの実装は実装がMTA以内か作品calloutサーバの中で起こるかどうかにかかわらず扱わなければならない安全保障問題(暗号化キーの有用性やストレージなどの)を提起します。
6. References
6. 参照
6.1. Normative References
6.1. 引用規格
[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.、ペンノ、R.、チェン、R.、ホフマン、M.、およびH.Orman、「開いているPluggable縁のサービスのためのアーキテクチャ(作品)」、RFC3835(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.、Orman、H.、およびR.ペンノ、「開いているPluggable縁のサービス(作品)はケースと展開シナリオを使用します」、RFC3752、2004年4月。
[3] Rousskov, A., "Open Pluggable Edge Services (OPES) Callout
Protocol (OCP) Core", RFC 4037, March 2005.
[3]Rousskov、A.、「開いているPluggable縁のサービス(作品)Calloutプロトコル(OCP)コア」、RFC4037、2005年3月。
[4] Rousskov, A. and M. Stecher, "HTTP Adaptation with Open
Pluggable Edge Services (OPES)", RFC 4236, November 2005.
[4]RousskovとA.とM.ステッチャー、「開いているPluggable縁のサービス(作品)とのHTTP適合」、RFC4236、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.、ホフマン、M.、およびH.Orman、「開いているPluggableのための軍事的脅威とリスクはサービス(作品)を斜めに進みます」、RFC3837、2004年8月。
[6] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[6] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
6.2. Informative References
6.2. 有益な参照
[7] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April
2001.
[7]Klensin、J.、「簡単なメール転送プロトコル」、RFC2821、2001年4月。
Stecher & Barbir Informational [Page 10] RFC 4496 OPES SMTP Use Cases May 2006
ステッチャーとBarbirの情報[10ページ]のRFC4496作品SMTPは2006年5月にケースを使用します。
[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.、Gettys、J.、ムガール人、J.、Frystyk、H.、Masinter、L.、リーチ、P.、およびT.バーナーズ・リー、「HTTP/1.1インチ、RFC2616、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、「メッセージ提案」、RFC2476、1998年12月。
[11] Myers, J., "Local Mail Transfer Protocol", RFC 2033, October
1996.
[11] マイアーズ、J.、「ローカルのメール転送プロトコル」、RFC2033、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、およびマーカスホフマンをありがとうございます。 また、作品メーリングリストでされた議論とフィードバックに感謝してください。
Authors' Addresses
作者のアドレス
Martin Stecher Secure Computing Corporation Vattmannstr. 3 33100 Paderborn Germany
マーチン・ステッチャーSecureのコンピューティング社のVattmannstr。 3 33100パーテルボルンドイツ
EMail: martin.stecher@webwasher.com URI: http://www.securecomputing.com/
メール: martin.stecher@webwasher.com ユリ: http://www.securecomputing.com/
Abbie Barbir Nortel 3500 Carling Avenue Ottawa, Ontario CA
アビーBarbirノーテル3500縦梁Avenueオンタリオオタワ(カリフォルニア)
Phone: +1 613 763 5229 EMail: abbieb@nortel.com
以下に電話をしてください。 +1 5229年の613 763メール: abbieb@nortel.com
Stecher & Barbir Informational [Page 11] RFC 4496 OPES SMTP Use Cases May 2006
ステッチャーとBarbirの情報[11ページ]のRFC4496作品SMTPは2006年5月にケースを使用します。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2006).
Copyright(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
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はどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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 Editor機能のための基金はIETF Administrative Support Activity(IASA)によって提供されます。
Stecher & Barbir Informational [Page 12]
ステッチャーとBarbir情報です。[12ページ]
一覧
スポンサーリンク
