[要約] RFC 7073は、電子メール識別子の評判応答セットに関する標準化文書です。その目的は、電子メールの送信元の評判情報を提供し、スパムやフィッシングなどの悪意のあるメールを識別するためのフレームワークを提供することです。
Internet Engineering Task Force (IETF) N. Borenstein
Request for Comments: 7073 Mimecast
Category: Standards Track M. Kucherawy
ISSN: 2070-1721 November 2013
A Reputation Response Set for Email Identifiers
電子メール識別子のレピュテーションレスポンスセット
Abstract
概要
This document defines a response set for describing assertions a reputation service provider can make about email identifiers, for use in generating reputons.
このドキュメントでは、レピュトンの生成に使用するために、レピュテーションサービスプロバイダーが電子メール識別子について作成できるアサーションを説明するための応答セットを定義します。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7073.
このドキュメントの現在のステータス、エラッタ、フィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7073で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2013 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction ....................................................2
2. Terminology and Definitions .....................................2
2.1. Key Words ..................................................2
2.2. Email Definitions ..........................................2
2.3. Other Definitions ..........................................3
3. Discussion ......................................................3
3.1. Assertions .................................................3
3.2. Response Set Extensions ....................................4
3.3. Identifiers ................................................4
3.4. Query Extensions ...........................................5
4. IANA Considerations .............................................5
4.1. Registration of 'email-id' Reputation Application ..........5
5. Security Considerations .........................................6
6. References ......................................................7
6.1. Normative References .......................................7
6.2. Informative References .....................................7
Appendix A. Positive vs. Negative Assertions .......................8
Appendix B. Acknowledgments ........................................8
This document specifies a response set for describing the reputation of an email identifier. A "response set" in this context is defined in [RFC7070] and is used to describe assertions a reputation service provider can make about email identifiers as well as metadata that can be included in such a reply beyond the base set specified there.
このドキュメントでは、電子メール識別子の評判を説明するための応答セットを指定します。このコンテキストの「応答セット」は[RFC7070]で定義されており、レピュテーションサービスプロバイダーが電子メール識別子について作成できるアサーションと、そこで指定された基本セットを超えてそのような応答に含めることができるメタデータを記述するために使用されます。
An atomic reputation response is called a "reputon", defined in [RFC7071]. That document also defines a media type to contain a reputon for transport, and creates a registry for reputation applications and the interesting parameters of each.
アトミックなレピュテーションレスポンスは「レプトン」と呼ばれ、[RFC7071]で定義されています。そのドキュメントは、トランスポートのレピュトンを含むメディアタイプも定義し、レピュテーションアプリケーションとそれぞれの興味深いパラメータのレジストリを作成します。
This section defines terms used in the rest of the document.
このセクションでは、ドキュメントの残りの部分で使用される用語を定義します。
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 [KEYWORDS].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [キーワード]で説明されているように解釈されます。
Commonly used definitions describing entities in the email architecture are defined and discussed in [EMAIL-ARCH].
電子メールアーキテクチャのエンティティを説明する一般的に使用される定義は、[EMAIL-ARCH]で定義および説明されています。
Other terms of importance in this document are defined in [RFC7070], the base document for the reputation services work.
このドキュメントの他の重要な用語は、レピュテーションサービスの基本ドキュメントである[RFC7070]で定義されています。
The expression of reputation about an email identifier requires extensions of the base set defined in [RFC7070]. This document defines and registers some common assertions about an entity found in a piece of [MAIL].
電子メール識別子に関する評判の表現には、[RFC7070]で定義されている基本セットの拡張が必要です。このドキュメントは、[MAIL]の一部にあるエンティティに関するいくつかの一般的なアサーションを定義および登録します。
The "email-id" reputation application recognizes the following assertions:
「email-id」レピュテーションアプリケーションは、次のアサーションを認識します。
abusive: The subject identifier is associated with sending or handling email of a personally abusive, threatening, or otherwise harassing nature
虐待：件名識別子は、個人的に虐待的、脅迫的、または嫌がらせの性質のメールの送信または処理に関連付けられています
fraud: The subject identifier is associated with the sending or handling of fraudulent email, such as "phishing" (some good discussion on this topic can be found in [IODEF-PHISHING])
詐欺：件名識別子は、「フィッシング」などの詐欺的な電子メールの送信または処理に関連付けられています（このトピックに関する適切な説明は、[IODEF-PHISHING]にあります）
invalid-recipients: The subject identifier is associated with delivery attempts to nonexistent recipients
invalid-recipients：サブジェクト識別子は、存在しない受信者への配信試行に関連付けられています
malware: The subject identifier is associated with the sending or handling of malware via email
マルウェア：サブジェクト識別子は、電子メールを介したマルウェアの送信または処理に関連付けられています
spam: The subject identifier is associated with the sending or handling of unwanted bulk email
スパム：件名識別子は、不要なバルクメールの送信または処理に関連付けられています
For all assertions, the "rating" scale is linear: a value of 0.0 means there is no data to support the assertion, a value of 1.0 means all accumulated data support the assertion, and the intervening values have a linear relationship (i.e., a score of "x" is twice as strong of an assertion as a value of "x/2").
すべてのアサーションについて、「評価」スケールは線形です。値0.0はアサーションをサポートするデータがないことを意味し、値1.0はすべての累積データがアサーションをサポートすることを意味し、介在する値は線形関係（つまり、a 「x」のスコアは、「x / 2」の値の2倍のアサーションです。
The "email-id" reputation application recognizes the following OPTIONAL extensions to the basic response set defined in [RFC7071]:
「email-id」レピュテーションアプリケーションは、[RFC7071]で定義されている基本的な応答セットに対する次のオプションの拡張を認識します。
email-id-identity: A token indicating the source of the identifier; that is, where the subject identifier was found in the message. This MUST be one of:
email-id-identity：識別子のソースを示すトークン。つまり、件名識別子がメッセージ内で見つかった場所です。これは次のいずれかでなければなりません：
dkim: The signing domain, i.e., the value of the "d=" tag, found on a valid DomainKeys Identified Mail [DKIM] signature in the message
dkim：メッセージの有効なDomainKeys Identified Mail [DKIM]署名で見つかった署名ドメイン、つまり "d ="タグの値
ipv4: The IPv4 address of the client
ipv4：クライアントのIPv4アドレス
ipv6: The IPv6 address of the client
ipv6：クライアントのIPv6アドレス
rfc5321.helo: The RFC5321.HELO value used by the client (see [SMTP])
rfc5321.helo：クライアントが使用するRFC5321.HELO値（[SMTP]を参照）
rfc5321.mailfrom: The RFC5321.MailFrom value of the envelope of the message (see [SMTP])
rfc5321.mailfrom：メッセージのエンベロープのRFC5321.MailFrom値（[SMTP]を参照）
rfc5322.from: The RFC5322.From field of the message (see [MAIL])
rfc5322.from：メッセージのRFC5322.Fromフィールド（[MAIL]を参照）
spf: The domain name portion of the identifier (RFC5321.MailFrom or RFC5321.HELO) verified by [SPF]
spf：[SPF]によって検証された識別子（RFC5321.MailFromまたはRFC5321.HELO）のドメイン名部分
sources: A token relating a count of the number of sources of data that contributed to the reported reputation. This is in contrast to the "sample-size" parameter, which indicates the total number of reports across all reporting sources.
ソース：報告された評判に貢献したデータのソースの数のカウントに関連するトークン。これは、すべてのレポートソースにわたるレポートの総数を示す「sample-size」パラメーターとは対照的です。
A reply that does not contain the "identity" or "sources" extensions is making a non-specific statement about how the reputation returned was developed. A client can use or ignore such a reply at its discretion.
「identity」または「sources」拡張を含まない応答は、返されたレピュテーションがどのように開発されたかについて、具体的ではない声明を出しています。クライアントは、その裁量でこのような応答を使用または無視できます。
In evaluating an email message on the basis of reputation, there can be more than one identifier in the message needing to be validated. For example, a message may have different email addresses in the RFC5321.MailFrom parameter and the RFC5322.From header field. The RFC5321.Helo identifier will obviously be different. Consequently, the software evaluating the email message may need to query for the reputation of more than one identifier.
レピュテーションに基づいて電子メールメッセージを評価する場合、検証する必要があるメッセージに複数の識別子が含まれる場合があります。たとえば、メッセージのRFC5321.MailFromパラメータとRFC5322.Fromヘッダーフィールドに異なる電子メールアドレスが含まれている場合があります。 RFC5321.Helo識別子は明らかに異なります。したがって、電子メールメッセージを評価するソフトウェアは、複数の識別子の評判を照会する必要がある場合があります。
The purpose of including the identity in the reply is to expose to the client the context in which the identifier was extracted from the message under evaluation. In particular, several of the items listed are extracted verbatim from the message and have not been subjected to any kind of validation, while a domain name present in a valid DKIM signature has some more reliable semantics associated with it. Computing or using reputation information about unauthenticated identifiers has substantially reduced value, but can sometimes be useful when combined. For example, a reply that indicates a message contained one of these low-value identifiers with a high "spam" rating might not be worthy of notice, but a reply that indicates a message contained several of them could be grounds for suspicion.
IDを応答に含める目的は、評価中のメッセージから識別子が抽出されたコンテキストをクライアントに公開することです。特に、リストされている項目のいくつかはメッセージから逐語的に抽出され、いかなる種類の検証も行われていませんが、有効なDKIM署名に存在するドメイン名には、より信頼性の高いセマンティクスが関連付けられています。認証されていない識別子に関するレピュテーション情報を計算または使用すると、値が大幅に減少しますが、組み合わせると役立つ場合があります。たとえば、メッセージに「スパム」の評価が高いこれらの低い値の識別子の1つが含まれていることを示す応答は、注目に値しないかもしれませんが、メッセージのいくつかが含まれていることを示す応答は疑わしい場合があります。
A client interested in checking these weaker identifiers would issue a query about each of them using the same assertion (e.g., "spam"), and then collate the results to determine which ones and how many of them came back with ratings indicating content of concern, and take action accordingly. For stronger identifiers, decisions can typically be made based on a few or even just one of them.
これらの弱い識別子をチェックすることに関心のあるクライアントは、同じアサーション（たとえば、「スパム」）を使用してそれらのそれぞれについてクエリを発行し、結果を照合して、どれがどれか、どれが問題の内容を示す評価で戻ってきたかを判断します。 、それに応じてアクションを実行します。より強力な識別子の場合、通常はいくつかまたは1つだけに基づいて決定を行うことができます。
A query within this application can include the OPTIONAL query parameter "identity" to indicate which specific identity is of interest to the query. Legal values are the same as those listed in Section 3.2.
このアプリケーション内のクエリには、OPTIONALクエリパラメータ "identity"を含めて、クエリの対象となる特定のIDを示すことができます。正当な値は、セクション3.2にリストされているものと同じです。
This memo presents one action for IANA, namely the registration of the reputation application "email-id".
このメモは、IANAの1つのアクション、つまり、レピュテーションアプリケーション「email-id」の登録を示しています。
This section registers the "email-id" reputation application, as per the IANA Considerations section of [RFC7071]. The registration parameters are as follows:
このセクションは、[RFC7071]のIANAの考慮事項セクションに従って、「email-id」レピュテーションアプリケーションを登録します。登録パラメーターは次のとおりです。
o Application symbolic name: email-id
o アプリケーションの記号名：email-id
o Short description: Evaluates DNS domain names or IP addresses found in email identifiers
o 簡単な説明：電子メール識別子で見つかったDNSドメイン名またはIPアドレスを評価します
o Defining document: [RFC7073]
o ドキュメントの定義：[RFC7073]
o Status: current o Subject: A string appropriate to the identifier of interest (see Section 3.2 of this document)
oステータス：現在o件名：対象の識別子に適した文字列（このドキュメントのセクション3.2を参照）
o Application-specific query parameters:
o アプリケーション固有のクエリパラメータ：
identity: (current) as defined in Section 3.4 of this document
アイデンティティ：（現在）このドキュメントのセクション3.4で定義
o Application-specific assertions:
o アプリケーション固有のアサーション：
abusive: (current) as defined in Section 3.1 of this document
abusive：（current）このセクション3.1で定義
fraud: (current) as defined in Section 3.1 of this document
詐欺：（現在）このドキュメントのセクション3.1で定義
invalid-recipients: (current) as defined in Section 3.1 of this document
invalid-recipients：（current）このドキュメントのセクション3.1で定義
malware: (current) as defined in Section 3.1 of this document
マルウェア：（最新）このドキュメントのセクション3.1で定義
spam: (current) as defined in Section 3.1 of this document
スパム：（現在）このドキュメントのセクション3.1で定義
o Application-specific response set extensions:
o アプリケーション固有の応答セット拡張：
identity: (current) as defined in Section 3.2 of this document
アイデンティティ：（現在）このドキュメントのセクション3.2で定義
This document is primarily an IANA action and doesn't describe any protocols or protocol elements that might introduce new security concerns.
このドキュメントは主にIANAアクションであり、新しいセキュリティ上の懸念をもたらす可能性のあるプロトコルやプロトコル要素については説明していません。
Security considerations relevant to email and email authentication can be found in most of the documents listed in the References sections below. Information specific to use of reputation services can be found in [CONSIDERATIONS].
電子メールおよび電子メール認証に関連するセキュリティの考慮事項は、以下の「参照」セクションにリストされているほとんどのドキュメントに記載されています。レピュテーションサービスの使用に固有の情報は、[考慮事項]にあります。
[DKIM] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed., "DomainKeys Identified Mail (DKIM) Signatures", STD 76, RFC 6376, September 2011.
[DKIM] Crocker、D。、編、Hansen、T。、編、M。Kucherawy、編、「DomainKeys Identified Mail（DKIM）Signatures」、STD 76、RFC 6376、2011年9月。
[EMAIL-ARCH] Crocker, D., "Internet Mail Architecture", RFC 5598, July 2009.
[メールアーク]クロッカーD.、「インターネットメールアーキテクチャ」、RFC 5598、2009年7月。
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[キーワード] Bradner、S。、「RFCで使用して要件レベルを示すためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC7070] Borenstein, N., Kucherawy, M., and A. Sullivan, "An Architecture for Reputation Reporting", RFC 7070, November 2013.
[RFC7070] Borenstein、N.、Kucherawy、M.、and A. Sullivan、 "An Architecture for Reputation Reporting"、RFC 7070、2013年11月。
[RFC7071] Borenstein, N. and M. Kucherawy, "A Media Type for Reputation Interchange", RFC 7071, November 2013.
[RFC7071] Borenstein、N。およびM. Kucherawy、「評判交換のためのメディアタイプ」、RFC 7071、2013年11月。
[SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, October 2008.
[SMTP] Klensin、J。、「Simple Mail Transfer Protocol」、RFC 5321、2008年10月。
[SPF] Wong, M. and W. Schlitt, "Sender Policy Framework (SPF) for Authorizing Use of Domains in E-Mail, Version 1", RFC 4408, April 2006.
[SPF] Wong、M.、W。Schlitt、「電子メールでのドメインの使用を許可するための送信者ポリシーフレームワーク（SPF）、バージョン1」、RFC 4408、2006年4月。
[CONSIDERATIONS] Kucherawy, M., "Operational Considerations Regarding Reputation Services", Work in Progress, May 2013.
[考慮事項] Kucherawy、M。、「評判サービスに関する運用上の考慮事項」、進行中の作業、2013年5月。
[IODEF-PHISHING] Cain, P. and D. Jevans, "Extensions to the IODEF-Document Class for Reporting Phishing", RFC 5901, July 2010.
[IODEF-PHISHING] Cain、P。およびD. Jevans、「フィッシングを報告するためのIODEF-Documentクラスの拡張」、RFC 5901、2010年7月。
[MAIL] Resnick, P., Ed., "Internet Message Format", RFC 5322, October 2008.
[メール] Resnick、P。、編、「インターネットメッセージ形式」、RFC 5322、2008年10月。
[CONSIDERATIONS] some current theories about reputation, namely that it will possibly have more impact to develop positive reputations and focus on giving preferential treatment to content or sources that earn those. However, the assertions defined in this document are all clearly negative in nature.
[検討事項]評判に関するいくつかの現在の理論、すなわち、肯定的な評判を開発し、それらを獲得するコンテンツまたはソースを優先的に扱うことに焦点を当てることは、おそらくより大きな影響を与えるであろう。ただし、このドキュメントで定義されているアサーションはすべて、本質的に明らかに否定的です。
In effect, this document is recording current use of reputation and of this framework in particular. It is expected that, in the future, the application being registered here will be augmented, and other applications registered, that focus more on positive assertions rather than negative ones.
実際、このドキュメントは、評判、特にこのフレームワークの現在の使用を記録しています。将来、ここに登録されているアプリケーションが拡張され、他のアプリケーションが登録され、否定的なものではなく肯定的なアサーションに重点が置かれることが予想されます。
The authors wish to acknowledge the contributions of the following to this specification: Scott Hollenbeck, Scott Kitterman, Peter Koch, John Levine, Danny McPherson, S. Moonesamy, Doug Otis, and David F. Skoll.
著者は、この仕様に対する次の貢献を認めたいと考えています。
Authors' Addresses
著者のアドレス
Nathaniel Borenstein Mimecast 203 Crescent St., Suite 303 Waltham, MA 02453 USA
Nathaniel Borenstein Mimecast 203 Crescent St.、Suite 303 Waltham、MA 02453 USA
Phone: +1 781 996 5340
EMail: nsb@guppylake.com
Murray S. Kucherawy 270 Upland Drive San Francisco, CA 94127 USA
マレーS.クチェラウィ270アップランドドライブサンフランシスコ、カリフォルニア94127アメリカ
EMail: superuser@gmail.com