Network Working Group M. Thomas
Request for Comments: 5016 Cisco Systems
Category: Informational October 2007
Requirements for a
DomainKeys Identified Mail (DKIM) Signing Practices Protocol
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.
このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。
Abstract
抽象
DomainKeys Identified Mail (DKIM) provides a cryptographic mechanism for domains to assert responsibility for the messages they handle. A related mechanism will allow an administrator to publish various statements about their DKIM signing practices. This document defines requirements for this mechanism, distinguishing between those that must be satisfied (MUST), and those that are highly desirable (SHOULD).
ドメインは、彼らが扱うメッセージの責任を主張するためにドメインキー・アイデンティファイド・メール（DKIM）は、暗号化メカニズムを提供します。関連するメカニズムは、管理者が自分のDKIM署名慣行に関するさまざまなステートメントを発行することができます。この文書は、（MUST）を満たさなければならないものとを区別、このメカニズムのための要件を定義し、（必要があります）非常に望ましいもの。
Table of Contents
目次
1. Introduction ....................................................2
2. Definitions and Requirements Language ...........................3
3. SSP Problem Scenarios ...........................................4
3.1. Problem Scenario 1: Is All Mail Signed with DKIM? ..........4
3.2. Problem Scenario 2: Illegitimate Domain Name Use ...........5
4. SSP Deployment Considerations ...................................6
4.1. Deployment Consideration 1: Outsourced Signing .............6
4.2. Deployment Consideration 2: Subdomain Coverage .............6
4.3. Deployment Consideration 3: Resent Original Mail ...........7
4.4. Deployment Consideration 4: Incremental Deployment
of Signing .................................................7
4.5. Deployment Consideration 5: Performance and Caching ........8
4.6. Deployment Consideration 6: Human Legibility of Practices ..8
4.7. Deployment Consideration 7: Extensibility ..................8
4.8. Deployment Consideration 8: Security .......................8
5. Requirements ....................................................9
5.1. Discovery Requirements .....................................9
5.2. SSP Transport Requirements ................................10
5.3. Practice and Expectation Requirements .....................10
5.4. Extensibility and Forward Compatibility Requirements ......13
6. Requirements for SSP Security ..................................13
7. Security Considerations ........................................13
8. Acknowledgments ................................................13
9. References .....................................................14
9.1. Normative References ......................................14
DomainKeys Identified Mail [RFC4871] defines a message level signing and verification mechanism for email. While a DKIM signed message speaks for itself, there is ambiguity if a message doesn't have a valid first party signature (i.e., on behalf of the [RFC2822].From address): is this to be expected or not? For email, this is an especially difficult problem since there is no expectation of a priori knowledge of a sending domain's practices. This ambiguity can be used to mount a bid down attack that is inherent with systems like email that allow optional authentication: if a receiver doesn't know otherwise, it should not assume that the lack of a valid signature is exceptional without other information. Thus, an attacker can take advantage of the ambiguity and simply not sign messages. If a protocol could be developed for a domain to publish its DKIM signing practices, a message verifier could take that into account when it receives an unsigned piece of email.
ドメインキー・アイデンティファイド・メール[RFC4871]は、電子メールのメッセージレベルの署名と検証メカニズムを定義します。 DKIMメッセージが自身のために語って署名されている間メッセージ（すなわち、[RFC2822] .Fromアドレスの代わりに）有効な第一当事者の署名を持っていない場合、あいまいさがある：これは予想されるかどうすべきでしょうか？送信ドメインの慣行の事前知識のない期待が存在しないため、電子メールの場合、これは特に難しい問題です。この曖昧さは、オプションの認証を許可する電子メールのようなシステムに固有である攻撃ダウン入札をマウントするために使用することができます：受信機がそう認識していない場合、それは有効な署名の欠如が、他の情報なしで異例であると仮定するべきではありません。このため、攻撃者は曖昧さを利用することができますし、単にメッセージに署名しません。プロトコルがそのDKIM署名プラクティスを公開するドメイン用に開発することができれば、それは電子メールの署名のない部分を受信したときに、メッセージの検証ではこの点を考慮に入れことができます。
This document defines the requirements for a mechanism that permits the publication of Sender Signing Practices (SSP). The document is organized into two main sections: first, a Problem and Deployment Scenario section that describes the problems that SSP is intended to address as well as the deployment issues surrounding the base problems, and the second section is the Requirements that arise because of those scenarios.
この文書では、送信者の署名・プラクティス（SSP）の出版を許可するメカニズムのための要件を定義します。文書は、2つの主要なセクションで構成され：最初、問題とSSPが並びに基地問題を取り巻く展開問題に対処することを意図している問題について説明展開シナリオセクション、及び第二部があるため、それらの発生の要件でありますシナリオ。
o Domain Holder: the entity that controls the contents of the DNS subtree starting at the domain, either directly or by delegation via NS records it controls.
ドメインホルダー○：NS経由で直接または委任により、ドメインから始まるDNSサブツリーの内容を制御エンティティは、それが制御する記録します。
o First Party Address: for DKIM, a first party address is defined to be the [RFC2822].From address in the message header; a first party address is also known as an Author address.
O第一者アドレス：DKIM、第1パーティのアドレスは、メッセージヘッダーの[RFC2822] .Fromアドレスであると定義されます。最初のパーティーアドレスも著者アドレスとして知られています。
o First Party Signature: a first party signature is a valid signature where the signing identity (the d= tag or the more specific identity i= tag) matches the first party address. "Matches" in this context is defined in [RFC4871].
O第一者署名：最初のパーティの署名は、署名ID（D =タグまたは複数の特定のアイデンティティI =タグは）最初のパーティーアドレスと一致する有効な署名があります。この文脈における「一致」は、[RFC4871]で定義されています。
o Third Party Signature: a third party signature is a valid signature that does not qualify as a first party signature. Note that a DKIM third party signature is not required to correspond to a header field address such as the contents of Sender or List-Id, etc.
Oサードパーティの署名：サードパーティの署名が最初のパーティー署名としての資格はありません有効な署名です。 DKIM第三者署名は、送信者またはリストID等のコンテンツとしてヘッダフィールドのアドレスに対応するために必要とされないことに注意してください
o Practice: a statement according to the [RFC2822].From domain holder of externally verifiable behavior in the email messages it sends.
O実践：それが送信する電子メールメッセージでの外部検証動作の[RFC2822] .Fromドメインホルダーによると声明。
o Expectation: an expectation combines with a practice to convey what the domain holder considers the likely survivability of the practice for a receiver, in particular receivers that may be more than one SMTP hop away.
Oの期待：期待は、ドメイン所有者が複数のSMTPホップ離れてもよい特定の受信機で、受信機の実践のための可能性の高い生存性を考えるもの伝えるための練習と結合します。
o DKIM Signing Complete: a practice where the domain holder asserts that all legitimate mail will be sent with a valid first party signature.
O DKIMは、完全な署名：ドメインの所有者がすべて正当なメールが有効な最初のパーティー署名で送信されることを主張する練習を。
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 RFC 2119 [RFC2119].
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はRFC 2119 [RFC2119]に記載されているように解釈されます。
The email world is a diverse place with many deployment considerations. This section outlines expected usage scenarios where DKIM signing/verifying will take place, and how a new protocol might help to clarify the relevance of DKIM-signed mail.
電子メールの世界では、多くの配備配慮した多様な場所です。このセクションでは、DKIM署名/検証が行われ、どのように新しいプロトコルがDKIM署名付きメールの関連性を明確にするために役立つかもしれない、予想される利用シナリオの概要を説明します。
After auditing their outgoing mail and deploying DKIM signing for all of their legitimate outgoing mail, a domain could be said to be DKIM signing complete. That is, the domain has, to the best of its ability, ensured that all legitimate mail purporting to have come from that domain contains a valid DKIM signature.
自分の送信メールを監査し、その正当な送信メールのすべてのためにDKIM署名を展開した後、ドメインは、DKIM署名完了しているといえるでしょう。つまり、ドメインは、その能力を最大限に、そのドメインから来ていると主張するすべての正規のメールが有効なDKIM署名が含まれていることを確実にしました。
A receiver in the general case doesn't know what the practices are for a given domain. Thus, the receiver is at a disadvantage in not knowing whether or not it should expect all mail to be signed from a given domain. This knowledge gap leads to a trivially exploitable bid-down attack where the attacker merely sends unsigned mail; since the receiver doesn't know the practices of the signing domain, it cannot treat the message any more harshly for lack of a valid signature.
一般的なケースでの受信機は、慣行が与えられたドメインのためにあるか知りません。したがって、受信機は、すべてのメールが特定のドメインからの署名が期待すべきか否かを知らないで不利です。この知識のギャップは、攻撃者が単に符号なしのメールを送信自明攻撃可能な入札ダウン攻撃につながります。受信機は署名ドメインの慣行を知っていないので、それは有効な署名の欠如のためにこれ以上厳しくメッセージを処理することはできません。
An information service that allows a receiver to query for the practices and expectations of the first party domain when no valid first party signature is found could be useful in closing this gap. A receiver could use this information to treat such questionable mail with varying degrees of prejudice.
有効な最初のパーティー署名が見つからない場合は、本機が最初のパーティドメインの慣行と期待を照会することを可能にする情報サービスは、このギャップを埋めるのに有用である可能性があります。受信機は、偏見の様々な程度で、このような疑わしいメールを処理するために、この情報を使用することができます。
Note that, for the foreseeable future, unrestricted use patterns of mail (e.g., where users may be members of mailing lists, etc.) will likely suffer occasional, non-malicious signature failure in transit. While probably not a large percentage of total traffic, this kind of breakage may be a significant concern for those usage patterns. This scenario defines where the sender cannot set any expectation as to whether an individual message will arrive intact.
予見可能な将来のために、メールの無制限の使用パターンが（例えば、ユーザーがなど、メーリングリストのメンバーかもしれ場合）可能性が輸送中時折、悪意署名の失敗を被るだろう、ということに注意してください。総トラフィックの大部分はおそらくないが、破損のこの種は、それらの使用パターンのための重要な問題となる場合があります。送信者は、個々のメッセージがそのまま到着するかどうかの任意の期待を設定できない場合、このシナリオでは定義します。
Even without that expectation, a receiver may be able to take advantage of the knowledge that the domain's practice is to sign all mail and bias its filters against unsigned or damaged in transit mail. This information should not be expected to be used in a binary yes/no fashion, but instead as a data point among others in a filtering system.
それさえも期待せずに、受信機は、ドメインの練習は、符号なしまたは輸送メールで破損に対するすべてのメールとバイアスそのフィルタに署名することで知識を利用することができるかもしれません。この情報は、その代わりに、フィルタリングシステムにおいて、とりわけデータポイントとして、バイナリはい/いいえの様式で使用されることが期待されるべきではありません。
The following exchange illustrates problem scenario 1.
以下の交換は、問題のシナリオ1を示しています。
1. Mail with a [RFC2822].From domain Alice is sent to domain Bob with a missing or broken DKIM first party signature from Alice.
アリスは、アリスから欠落または破損DKIM最初のパーティの署名でドメインボブに送信される[RFC2822] .Fromドメインと1メール。
2. Domain Bob would like to know whether that is an expected state of affairs.
2.ドメインボブはそれが事務の予想される状態であるかどうかを知っていただきたいと思います。
3. Domain Alice provides information that it signs all outgoing mail, but places no expectation on whether it will arrive with an intact first party signature.
3.ドメインアリスはそれがすべての送信メールに署名した情報を提供していますが、それがそのまま最初のパーティー署名で到着するかどうかには期待を置きません。
4. Domain Bob could use this information to bias its filters to examine the message with some suspicion.
4.ドメインボブは、いくつかの疑いでメッセージを調べるために、バイアスにそのフィルタを、この情報を使用することができます。
A class of mail typified by transactional mail from high-value domains is currently the target of phishing attacks. In particular, many phishing scams forge the [RFC2822].From address in addition to spoofing much of the content to trick unsuspecting users into revealing sensitive information. Domain holders sending this mail would like the ability to give an enhanced guarantee that mail sent with their domain name should always arrive with the proof that the domain holder consented to its transmission. That is, the message should contain a valid first party signature as defined above.
付加価値の高いドメインからの取引メールに代表される電子メールのクラスは、現在、フィッシング攻撃の対象です。特に、多くのフィッシング詐欺は、機密情報を明らかに疑いを持たないユーザをだましするコンテンツの多くを偽装することに加えて、[RFC2822] .Fromアドレスを偽造します。このメールを送信するドメイン所有者は、そのドメイン名で送信されたメールは、常にドメインの所有者がその送信に同意したことの証明で到着すべき強化の保証を与える能力をしたいと思います。これは、上記で定義されたメッセージは、有効な最初のパーティー署名が含まれている必要があり、です。
From a receiver's standpoint, knowing that a domain not only signs all of its mail, but places a very high value on the receipt of a valid first party signature from that domain is helpful. Hence, a receiver knows that the sending domain signs all its mail, and that the sending domain considers mail from this domain particularly sensitive in some sense, and is asking the receiver to be more suspicious than it otherwise might be of a broken or missing first-party signature. A receiver with the knowledge of the sender's expectations in hand might choose to process messages not conforming to the published practices in a special manner. Note that the ability to state an enhanced guarantee of a valid signature means that senders should expect mail that traverses modifying intermediaries (e.g., mailing lists, etc.) will likely be quarantined or deleted; thus, this scenario is more narrow than problem scenario 1.
受信者の観点から、ドメインはそのメールのすべてに署名したが、そのドメインからの有効な最初のパーティー署名の領収書に非常に高い価値を置いていないだけであることを知っておくと便利です。したがって、受信機は、そのすべてのメールドメインの兆候を送信し、送信ドメインが、ある意味では、このドメインからのメールは特に敏感を考慮し、それはそう壊れたのかもしれませんか、最初の欠落しているよりも多くの不審なことを受信機に求めていることを知っていますパーティの署名。手に送信者の期待の知識を持つ受信機は、特別な方法で公表慣行に準拠していないメッセージを処理することを選択するかもしれません。有効な署名の強化保証を述べる能力は、送信者が（などなど、メーリングリスト、）を変更する仲介を横断メールを期待するべきであることを意味することに注意してください可能性が隔離されたり削除されます。したがって、このシナリオでは、問題シナリオ1よりも狭いです。
Informative Note: a receiving filter may choose to treat scenario 2 much more harshly than scenario 1; where scenario 1 looks odd, scenario 2 looks like something is very wrong.
有益な注意：受信フィルタは、シナリオ1よりもはるかに厳しく、シナリオ2の治療のために選択することができ、シナリオ1が奇数に見えるところ何かが非常に間違っているように、シナリオ2が見えます。
1. Mail with a [RFC2822].From domain Alice is sent to domain Bob with a missing or broken first party DKIM signature from domain Alice.
[RFC2822] .Fromドメインアリス1.メールはドメインアリスから欠落または破損した第一当事者DKIM署名とドメインボブに送られます。
2. Domain Bob would like to know whether that is an expected state of affairs.
2.ドメインボブはそれが事務の予想される状態であるかどうかを知っていただきたいと思います。
3. Domain Alice provides information that it signs all outgoing mail, and furthermore places an expectation that it should arrive with an intact first party signature, and that the receiver should be much more wary if it does not.
3.ドメインアリスはそれがすべての送信メールに署名し、さらにそれがそのまま最初のパーティー署名で到着し、そうでない場合は、受信機がはるかに警戒する必要があることをすべきであるという期待を置くという情報を提供します。
4. Domain Bob could use this information to bias its filters such that it examines the message with great suspicion.
4.ドメインBobはそれは素晴らしい疑いでメッセージを調べるように、そのフィルタバイアスにこの情報を使用することができます。
Given the problems enumerated above for which we'd like SSP to provide information to recipients, there are a number of scenarios that are not related to the problems that are to be solved, per se, but the actual mechanics of implementing/deploying the information service that SSP would provide.
私たちは、SSPが受信者に情報を提供したい対象の上に列挙した問題を考えると、それ自体が、解決される問題に関連していないシナリオの数が、/実装情報を展開する実際の仕組みがありますSSPが提供するサービス。
Many domains do not run their own mail infrastructure, or may outsource parts of it to third parties. It is desirable for a domain holder to have the ability to delegate to other entities the ability to sign for the domain holder. One obvious use scenario is a domain holder from a small domain that needs to have the ability for their outgoing ISP to sign all of their mail on behalf of the domain holder. Other use scenarios include outsourced bulk mail for marketing campaigns, as well as outsourcing various business functions, such as insurance benefits, etc.
多くのドメインは、独自のメールインフラストラクチャを実行しない、または第三者にその一部を外部委託すること。ドメイン所有者が他のエンティティへのドメインの所有者のために署名する権限を委任する能力を有することが望ましいです。 1つの明らかな使用シナリオは、ドメイン所有者に代わって自分のメールのすべてに署名する彼らの発信ISPのための能力を持っている必要があり、小さなドメインからドメインホルダーです。他の利用シナリオは、マーケティングキャンペーンのための外部委託バルクメールが含まれ、ならびに等の保険給付などの様々なビジネス機能を、アウトソーシング
An SSP client will perform lookups on incoming mail streams to provide the information as proposed in the problem scenarios. The domain part of the first address of the [RFC2822].From will form the basis to fetch the published information. A trivial attack to circumvent finding the published information can be mounted by simply using a subdomain of the parent domain that doesn't have published information. This attack is called the subdomain attack: that is, a domain wants to not only publish a policy for a given DNS label it controls, but it would also like to protect all subdomains of that label as well. If this characteristic is not met, an attacker would need only create a possibly fictitious subdomain that was not covered by the SSP's information service. Thus, it would be advantageous for SSP to not only cover a given domain, but all subdomains of that domain as well.
SSPクライアントは、問題のシナリオに提案されているような情報を提供するために、受信メールストリーム上の検索を実行します。 [RFC2822] .Fromの最初のアドレスのドメイン部分は、公開された情報を取得するための基礎を形成します。公開された情報を見つける回避する些細な攻撃は、単に情報を公開していていない親ドメインのサブドメインを使用してマウントすることができます。この攻撃は、サブドメイン攻撃と呼ばれている。つまり、ドメインは、それが制御する特定のDNSラベルのポリシーを公開するだけでなく、それはまた、同様にそのラベルのすべてのサブドメインを保護したいと思いたいです。この特性が満たされない場合、攻撃者はSSPの情報サービスによってカバーされていなかった可能性が架空のサブドメインを作成する必要があります。 SSPは、特定のドメインが、同様にそのドメインのすべてのサブドメインをカバーするだけでなく、ためにこのように、それは有利であろう。
Resent mail is a common occurrence in many scenarios in the email world of today. For example, domain Alice sends a DKIM-signed message with a published practice of signing all messages to domain Bob's mailing list. Bob, being a good net citizen, wants to be able to take his part of the responsibility of the message in question, so he DKIM signs the message, perhaps corresponding to the Sender address.
再送メールは、今日の電子メールの世界では多くのシナリオではよくあることです。たとえば、ドメインアリスは、ドメインボブのメーリングリストへのすべてのメッセージに署名するのに公開練習でDKIM署名付きメッセージを送信します。ボブは、優れたネット市民で、問題のメッセージの責任の彼の部分を取ることができるように望んでいるので、彼はDKIMは、おそらく送信者アドレスに対応し、メッセージに署名します。
Note that this scenario is completely orthogonal to whether Alice's signature survived Bob's mailing list: Bob merely wants to assert his part in the chain of accountability for the benefit of the ultimate receivers. It would be useful for this practice to be encouraged as it gives a more accurate view of who handled the message. It also has the side benefit that remailers that break DKIM first party signatures can be potentially assessed by the receiver based on the receiver's opinion of the signing domains that actually survived.
このシナリオでは、アリスの署名がボブのメーリングリストを生き延びたかどうかに完全に直交していることに注意してください：ボブは単に究極の受信機の利益のために責任の連鎖に彼の部分を主張したいです。それは、メッセージを取り扱う者のより正確なビューを提供し、この習慣が奨励されることが有用であろう。また、DKIM最初のパーティー署名を破るリメイラは、潜在的に、実際に生き残った署名ドメインの受信者の意見に基づいて受信機によって評価することができるという副次的な利点があります。
As a practical matter, it may be difficult for a domain to roll out DKIM signing such that they can publish the DKIM Signing Complete practice given the complexities of the user population, the outsourced vendors sending on its behalf, etc. This leaves open an exploit that high-value mail, such as in Problem Scenario 2, must be classified to the least common denominator of the published practices. It would be desirable to allow a domain holder to publish a list of exceptions that would have a more restrictive practices statement. NB: this consideration has been deemed met by the mechanisms provided by the base DKIM signing mechanism; it is merely documented here as having been an issue.
ドメインは、DKIMは、彼らがなど、ユーザー人口の複雑さ、その代わりに、送信する外部委託ベンダー、これが開いたままAN活用与えられた完全な練習の署名DKIMを公開することができるように署名するロールアウトするための実用的な問題として、それは難しいかもしれませんそのような問題シナリオ2のような高付加価値のメールは、公開練習の最小公倍数に分類されなければなりません。ドメインの所有者がより制限慣行の声明を持つことになり、例外のリストを公開できるようにすることが望ましいであろう。 NB：この考察は、ベースDKIM署名メカニズムによって提供されるメカニズムによって満たさとみなされています。それは単に問題されたものとしてここに記載されています。
For example, bigbank.example.com might be ready to say that statements@bigbank.example.com is always signed, but the rest of the domain, say, is not. Another situation is that the practices of some address local parts in a given domain are not the same as practices of other local parts. Using the same example of statements@bigbank.example.com being a transactional kind of email that would like to publish very strong practices, mixed in with the rest of the user population local parts, which may go through mailing lists, etc., for which a less strong statement is appropriate.
例えば、bigbank.example.comはstatements@bigbank.example.comが常に署名されていることを言って準備ができているかもしれませんが、ドメインの残りの部分、たとえば、ではありません。別の状況は、与えられたドメインでいくつかのアドレスのローカル部分の慣行が他のローカル部分の慣行と同じではないということです。以下のために、statements@bigbank.example.com等メーリングリスト、通過することがユーザー人口ローカル部品の残りの部分と混在非常に強いプラクティスを、公開したいと思い、メールのトランザクションの一種であるのと同じ例を使用してこれはあまり強い声明が適切です。
It should be said that DKIM, through the use of subdomains, can already support this kind of differentiation. That is, in order to publish a strong practice, one only has to segregate those cases into different subdomains. For example: accounts.bigbank.example.com would publish constrained practices, while corporateusers.bigbank.example.com might publish more permissive practices.
DKIMは、サブドメインを使用して、すでに分化のこの種類をサポートできることを指摘しておかなければ。それは、強力な練習を公開するためには、1のみが異なるサブドメインにこれらのケースを分離する必要があります。たとえば：corporateusers.bigbank.example.comはもっと寛容なプラクティスを公開かもしれないがaccounts.bigbank.example.com、拘束されたプラクティスを公開します。
Email service provides an any-any mesh of potential connections: all that is required is the publication of an MX record and an SMTP listener to receive mail. Thus, the use of SSP is likely to fall into two main scenarios, the first of which are large, well-known domains that are in constant contact with one another. In this case, caching of records is essential for performance, including the caching of the non-existence of records (i.e., negative caching).
必要とされるすべてのメールを受信するためのMXレコードとSMTPリスナーの出版物である：電子メールサービスは、潜在的な接続のいずれかの-任意のメッシュを提供します。したがって、SSPの使用は、互いに一定の接触している大規模な、周知ドメインで最初する2つの主なシナリオに陥る可能性があります。この場合には、レコードのキャッシュは、レコードの非存在（即ち、ネガティブキャッシュ）のキャッシングなど、性能のために必須です。
The second main scenario is when a domain exchanges mail with a much smaller volume domain. This scenario can be both perfectly normal as with the case of vanity domains, and unfortunately, a vector for those sending mail for anti-social reasons. In this case, we'd like the message exchange burden to SSP querier to be low, since many of the lookups will not provide a useful answer. Likewise, it would be advantageous to have upstream caching here as well so that, say, a mailing list exploder on a small domain does not result in an explosion of queries back at the root and authoritative server for the small domain.
ドメイン交換がはるかに小さい容積ドメインとメールときに、第2のメインシナリオです。このシナリオでは、残念ながら、反社会的な理由でメールを送信する人のためのベクターバニティドメインの場合と同様に、両方の完全に正常である、とすることができます。検索の多くが有用な答えを提供することはありませんので、この場合、我々は、低いことがSSPクエリアにメッセージ交換の負担をしたいと思います。たとえば、小さなドメイン上のメーリングリストエクスプローダが戻って小さなドメインのルートと権限のあるサーバーで、クエリの爆発を生じない、ように同様に、ここにも上流のキャッシュを持っていることが有利であろう。
While SSP records are likely to be primarily consumed by an automaton, for the foreseeable future they are also likely to be inspected by hand. It would be nice to have the practices stated in a fashion that is also intuitive to the human inspectors.
SSPレコードは、主にオートマトンによって消費される可能性が高いですが、予見可能な将来のために、彼らはまた、手で検査される可能性が高いです。また、人間の検査官への直感的な方法で述べた慣行を持っていいだろう。
While this document pertains only to requirements surrounding DKIM signing practices, it would be beneficial for the protocol to be able to extend to other protocols.
この文書は、DKIM署名プラクティスを周囲の要件にのみ関係している間のプロトコルは他のプロトコルに拡張することができるようにするために、それは有益であろう。
SSP must be able to withstand life in a hostile, open-Internet environment. These include DoS attacks, and especially DoS attacks that leverage themselves through amplification inherent in the protocol. In addition, while a useful protocol may be built without strong source authentication provided by the information service, a path to strong source authentication should be provided by the protocol, or underlying protocols.
SSPは、敵対的、オープンインターネット環境での生活を耐えることができなければなりません。これらは、DoS攻撃が挙げられ、特にDoS攻撃は、プロトコルに固有の増幅を通じてレバレッジ自体を攻撃します。有用なプロトコルは、情報サービスによって提供される強力なソース認証なしで構築することができるしながら加えて、強いソース認証へのパスは、プロトコル、または基礎となるプロトコルによって提供されるべきです。
This section defines the requirements for SSP. As with most requirements documents, these requirements define the MINIMUM requirements that a candidate protocol must provide. It should also be noted that SSP must fulfill all of the requirements.
このセクションでは、SSPのための要件を定義します。ほとんどの要件文書と同じように、これらの要件は、候補プロトコルが提供しなければならない最小要件を定義します。また、SSPは、要件のすべてを満たさなければならないことに留意すべきです。
Receivers need a means of obtaining information about a sender's DKIM practices. This requires a means of discovering where the information is and what it contains.
レシーバは、送信者のDKIM慣行についての情報を得る手段を必要としています。これは、情報があるとそれが含まれている場所を発見する手段を必要とします。
1. The author is the first-party sender of a message, as specified in the [RFC2822].From field. SSP's information is associated with the author's domain name, and is published subordinate to that domain name.
1.著者は、[RFC2822] .Fromフィールドで指定されるように、メッセージの最初のパーティの送信者です。 SSPの情報は、著者のドメイン名に関連付けられており、そのドメイン名の下位に公開されています。
2. In order to limit the cost of its use, any query service supplying SSP's information MUST provide a definitive response within a small, deterministic number of message exchanges under normal operational conditions.
2.その使用のコストを制限するために、SSPの情報を供給する任意のクエリサービスは、通常の動作条件下で、メッセージ交換の小さい、決定論的数以内に決定的な応答を提供しなければなりません。
Informative Note: this, for all intents and purposes is a
prohibition on anything that might produce loops or result in
extended delays and overhead; also though "deterministic"
doesn't specify how many exchanges, the expectation is "few".
Refs: Deployment Considerations, Sections 4.2 and 4.5.
参考文献：展開に関する考慮事項、セクション4.2および4.5。
3. SSP's publishing mechanism MUST be defined such that it does not lead to multiple resource records of the same type for different protocols residing at the same location.
3. SSPの出版メカニズムは、それが同じ場所に存在する異なるプロトコルのための同じタイプの複数のリソースレコードにつながらないように定義されなければなりません。
Informative note: an example is multiple resource record of the
same type within a common DNS leaf. Hence, uniquely defined
leaf names or uniquely defined resource record types will
ensure unambiguous referencing.
Refs: Deployment Consideration, Section 4.2.
参考文献：展開の考慮、セクション4.2。
4. SSP retrieval SHOULD provide coverage for not only a given domain but all of its subdomains as well. It is recognized that there is some reasonable doubt about the feasibility of a widely accepted solution to this requirement. If the working group does not achieve rough consensus on a solution, it MUST document the relevant security considerations in the protocol specification.
4. SSPの検索も同様に指定したドメインが、そのサブドメインのすべてではないだけのカバレッジを提供する必要があります。この要件に広く受け入れられている解決策の実現可能性に関するいくつかの合理的な疑いがあることが認識されています。ワーキンググループは、ソリューションのラフコンセンサスを達成していない場合は、プロトコル仕様に関連するセキュリティ上の考慮事項を文書化しなければなりません。
Refs: Deployment Considerations, Sections 4.2 and 4.5.
参考文献：展開に関する考慮事項、セクション4.2および4.5。
The publication and query mechanism will operate as an internet-based message exchange. There are multiple requirements for this lower-layer service:
出版やクエリメカニズムは、インターネットベースのメッセージ交換として動作します。この下層のサービスのための複数の要件があります。
1. The exchange SHOULD have existing widespread deployment of the transport layer, especially if riding on top of a true transport layer (e.g., TCP, UDP).
1.交換は、真のトランスポート層（例えば、TCP、UDP）の上に乗っている場合は特に、トランスポート層の既存の広範な展開を持っているべきです。
Refs: Deployment Considerations, Sections 4.5 and 4.7.
参考文献：展開に関する考慮事項、セクション4.5および4.7。
2. The query/response in terms of latency time and the number of messages involved MUST be low (less than three message exchanges not counting retransmissions or other exceptional conditions).
2.待ち時間と関係するメッセージの数に関してクエリ/応答は、（以下の3つのメッセージ交換は、再送信または他の例外条件を数えない）低くなければなりません。
Refs: Deployment Consideration, Section 4.5.
参考文献：展開の考慮、セクション4.5。
3. If the infrastructure doesn't provide caching (a la DNS), the records retrieved MUST provide initiators the ability to maintain their own cache. The existing caching infrastructure is, however, highly desirable.
3.インフラは、キャッシング（ラDNS）を提供していない場合は、取得したレコードは、イニシエータが自分のキャッシュを維持する能力を提供しなければなりません。既存のキャッシングインフラストラクチャは、しかし、非常に望ましいです。
Refs: Deployment Consideration, Section 4.5.
参考文献：展開の考慮、セクション4.5。
4. Multiple geographically and topologically diverse servers MUST be supported for high availability.
4.複数の地理的およびトポロジ的に多様なサーバは、高可用性をサポートしなければなりません。
Refs: Deployment Considerations, Sections 4.5 and 4.7.
参考文献：展開に関する考慮事項、セクション4.5および4.7。
As stated in the definitions section, a practice is a statement according to the [RFC2822].From domain holder of externally verifiable behavior in the email messages it sends. As an example, a practice might be defined such that all email messages will contain a DKIM signature corresponding to the [RFC2822].From address. Since there is a possibility of alteration between what a sender sends and a receiver examines, an expectation combines with a practice to convey what the [RFC2822].From domain considers the likely outcome of the survivability of the practice at a receiver. For example, a practice that a valid DKIM for the [RFC2822].From address is present when it is sent from the domain, and an expectation that it will remain present and valid for all receivers whether topologically adjacent or not.
定義の項で述べたように、実際には、それが送信する電子メールメッセージでの外部検証動作の[RFC2822] .Fromドメインホルダーに従って文です。一例として、実際には、すべての電子メールメッセージは、[RFC2822] .Fromアドレスに対応するDKIM署名を含むことになるように定義されるかもしれません。送信者が送信機と受信機は、調べものの間で変化する可能性があるので、期待は[RFC2822] .Fromドメインは受信機で実際の生存の可能性の高い結果を考えるもの伝えるための練習と結合します。例えば、[RFC2822] .Fromアドレスの実際の有効なDKIMそれは、それがドメインから送信されたときに存在し、それは全ての受信機トポロジ的に隣接するかどうかのために存在し、有効なままであろうという期待。
1. SSP MUST be able to make practices and expectation assertions about the domain part of a [RFC2822].From address in the context of DKIM. SSP will not make assertions about other addresses for DKIM at this time.
1. SSPは、DKIMの文脈における[RFC2822] .Fromアドレスのドメイン部分についての慣行と期待アサーションを行うことができなければなりません。 SSPは、この時点でDKIMのために他のアドレスについての主張をすることはありません。
Refs: Problem Scenarios 1 and 2, Sections 3.1 and 3.2.
参考文献：問題シナリオ1と2、セクション3.1および3.2。
2. SSP MUST provide a concise linkage between the [RFC2822].From and the identity in the DKIM i= tag, or its default if it is missing in the signature. That is, SSP MUST precisely define the semantics of what qualifies as a first party signature.
それは署名で欠落している場合2. SSPは、DKIMにI =タグ、又はそのデフォルトを[RFC2822] .Fromと同一の間に簡潔な結合を提供しなければなりません。つまり、SSPは正確に最初のパーティー署名としての資格何の意味を定義しなければなりません。
Refs: Problem Scenarios 1 and 2, Sections 3.1 and 3.2.
参考文献：問題シナリオ1と2、セクション3.1および3.2。
3. SSP MUST be able to publish a practice that the domain's signing behavior is "DKIM Signing Complete". That is, all messages were transmitted with a valid first party signature.
3. SSPは、ドメインの署名行動は「DKIMは完全な署名」されていることを練習を公開できるようにしなければなりません。つまり、すべてのメッセージは、有効な最初のパーティー署名で送信されました。
Refs: Problem Scenario 1, Section 3.1.
参考文献：問題シナリオ1、第3.1節。
4. SSP MUST be able to publish an expectation that a verifiable first party DKIM signature should be expected on receipt of a message.
4. SSPは、検証第一当事者DKIM署名は、メッセージの受信時に期待されるべきであることを期待を公開することができなければなりません。
Refs: Problem Scenario 2, Section 3.2.
参考文献：問題シナリオ2、3.2節。
5. Practices and expectations MUST be presented in SSP syntax using as intuitive a descriptor as possible. For example, p=? would be better represented as p=unknown.
5.プラクティスと期待はできるだけ直感的な記述子を使用してSSP構文で提示されなければなりません。例えば、P =？より良いP =不明として表されます。
Refs: Deployment Consideration, Section 4.6.
参考文献：展開の考慮、セクション4.6。
6. Because DKIM uses DNS to store selectors, there is always the ability for a domain holder to delegate all or parts of the _domainkey subdomain to an affiliated party of the domain holder's choosing. That is, the domain holder may set an NS record for _domainkey.example.com to delegate to an email provider who manages the entire namespace. There is also the ability for the domain holder to partition its namespace into subdomains to further constrain third parties. For example, a domain holder could delegate only _domainkey.benefits.example.com to a third party to constrain the third party to only be able to produce valid signatures in the benefits.example.com subdomain. Last, a domain holder can even use CNAME's to delegate individual leaf nodes. Given the above considerations, SSP need not invent a different means of allowing affiliated parties to sign on a domain's behalf at this time.
6. DKIMは、セレクタを保存するためにDNSを使用しているため、ドメイン所有者の選んだの所属政党に全部または_domainkeyサブドメインの一部を委任するために、ドメイン所有者のための能力が常にあります。つまり、ドメインの所有者は、_domainkey.example.comは、名前空間全体を管理し、電子メールプロバイダーに委譲するためのNSレコードを設定することがあります。さらに第三者を拘束するためにサブドメインに名前空間を分割するには、ドメイン所有者のための能力もあります。たとえば、ドメインの所有者のみがbenefits.example.comサブドメインで有効な署名を生成することができるように第三者を拘束するために第三者にのみ_domainkey.benefits.example.comを委任することができます。最後に、ドメインの所有者であっても、個々のリーフノードを委任するCNAMEのを使用することができます。上記の考察を考えると、SSPは、提携当事者は、この時点でドメインに代わって署名することを可能にするさまざまな手段を発明する必要はありません。
Refs: Deployment Consideration, Section 4.4.
参考文献：展開の考慮、セクション4.4。
7. Practices and expectations MUST be presented as an information service from the signing domain to be consumed as an added factor to the receiver's local policy. In particular, a practice or expectation MUST NOT mandate any disposition stance on the receiver.
7.プラクティスと期待は受信機のローカルポリシーに追加要因として消費される署名ドメインからの情報サービスとして提示されなければなりません。具体的には、練習や期待は受信機の任意の配置姿勢を強制してはなりません。
Refs: Problem Scenarios 1 and 2, Sections 3.1 and 3.2.
参考文献：問題シナリオ1と2、セクション3.1および3.2。
8. There is no requirement that SSP publish practices of any/all third parties that MUST NOT sign on the domain holder's behalf. This should be considered out of scope.
8. SSPは、いずれかの実践/ドメイン保有者に代わって署名してはならないすべての第三者に公開する必要はありません。これは、スコープの外に考慮されるべきです。
INFORMATIVE NOTE: this is essentially saying that the protocol
doesn't have to concern itself with being a blacklist
repository.
Refs: Problem Scenarios 1 and 2, Sections 3.1 and 3.2.
参考文献：問題シナリオ1と2、セクション3.1および3.2。
9. SSP MUST NOT be required to be invoked if a valid first party signature is found.
9. SSPは、有効な最初のパーティー署名が発見された場合に呼び出されるために必要とされてはなりません。
Refs: Deployment Consideration, Section 4.2.
参考文献：展開の考慮、セクション4.2。
10. SSP MUST NOT provide a mechanism that impugns the existence of non-first party signatures in a message. A corollary of this requirement is that the protocol MUST NOT link practices of first party signers with the practices of third party signers.
10. SSPは、メッセージ内の非第一当事者署名の存在をimpugnsメカニズムを提供してはいけません。この要件の帰結は、プロトコルがサードパーティの署名者の慣行に最初のパーティー署名者のプラクティスをリンクしてはならないということです。
INFORMATIVE NOTE: the main thrust of this requirement is that
practices should only be published for that which the publisher
has control, and should not meddle in what is ultimately the
local policy of the receiver.
Refs: Deployment Consideration, Section 4.3.
参考文献：展開の考慮、セクション4.3。
1. SSP MUST NOT extend to any protocol other than DKIM for email at this time. SSP SHOULD be extensible for protocols other than DKIM.
1. SSPは、この時点で電子メールのDKIM以外のプロトコルを拡張してはなりません。 SSPは、DKIM以外のプロトコルのために拡張可能であるべきです。
Refs: Deployment Consideration, Section 4.7.
参考文献：展開の考慮、セクション4.7。
2. SSP MUST be able to add new practices and expectations within the existing discovery/transport/practices in a backward compatible fashion.
2. SSPは、下位互換性の方法で既存の検出/輸送/プラクティス以内に新しいプラクティスと期待を追加することができなければなりません。
Refs: Deployment Consideration, Section 4.7.
参考文献：展開の考慮、セクション4.7。
1. SSP for a high-value domain is potentially a high-value DoS target, especially since the unavailability of SSP's record could make unsigned messages less suspicious.
高価値ドメイン1. SSPは、SSPのレコードが使用できないが、符号なしのメッセージは以下の疑わしい作ることができ、特に以来、潜在的に高い価値のDoS対象です。
2. SSP MUST NOT make highly leveraged amplification or make-work attacks possible. In particular, the work and message exchanges involved MUST be order of a constant.
2. SSPは、レバレッジの高い増幅を行うか、攻撃の可能性、作業してはなりません。具体的には、必要な作業及びメッセージ交換は、一定の順序でなければなりません。
Refs: Deployment Consideration, Section 4.8.
参考文献：展開の考慮、セクション4.8。
3. SSP MUST have the ability for a domain holder to provide SSP's data such that a receiver can determine that it is authentically from the domain holder with a large degree of certainty. SSP may provide means that provide less certainty in trade off for ease of deployment.
3. SSPは、受信機は、それが確実に大きい程度とドメインホルダーから本物であることを決定することができるように、SSPのデータを提供するためにドメイン・ホルダー能力を持たなければなりません。 SSPは、展開を容易にするためにトレードオフが少なく確実性を提供する手段を提供することができます。
Refs: Deployment Consideration, Section 4.8.
参考文献：展開の考慮、セクション4.8。
This document defines requirements for a new protocol and the security related requirements are defined above. Since it is expected that the new protocol will use the DNS as a basis for the published SSP information, most if not all of the threats described in [RFC4686] will be applicable.
この文書は、新しいプロトコルのための要件を定義し、セキュリティ関連の要件は、上記に定義されています。それは新しいプロトコルが公開SSP情報の基礎としてDNSを使用し、ほとんどの場合ありません[RFC4686]で説明された脅威のすべてのことが期待されているので、適用されます。
Dave Crocker and Jim Fenton provided substantial review of this document. Thanks also to Vijay Gurbani and David Harrington for their helpful last call reviews.
デイブ・クロッカーとジム・フェントンは、この文書の実質的な見直しを提供します。彼らの役に立つ最後の呼び出しレビューのためにも、ビジェイGurbaniとデヴィッドハリントンに感謝します。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC2822] Resnick, P., Ed., "Internet Message Format", RFC 2822, April 2001.
[RFC2822]レズニック、P.、エド。、 "インターネットメッセージ形式"、RFC 2822、2001年4月。
[RFC4686] Fenton, J., "Analysis of Threats Motivating DomainKeys Identified Mail (DKIM)", RFC 4686, September 2006.
[RFC4686]フェントン、J.、 "メール（DKIM）を同定DomainKeysのをやる気脅威の分析"、RFC 4686、2006年9月。
[RFC4871] Allman, E., Callas, J., Delany, M., Libbey, M., Fenton, J., and M. Thomas, "DomainKeys Identified Mail (DKIM) Signatures", RFC 4871, May 2007.
[RFC4871]オールマン、E.、カラス、J.、デラニー、M.、リビー、M.、フェントン、J.、およびM.トーマス、 "ドメインキーを識別メール（DKIM）署名"、RFC 4871、2007年5月。
Author's Address
著者のアドレス
Michael Thomas Cisco Systems 606 Sanchez St San Francisco, California 94114 USA
マイケル・トーマスシスコシステムズ606サンチェスセントサンフランシスコ、カリフォルニア94114 USA
Phone: +1-408-525-5386 Fax: +1-408-525-5386 EMail: mat@cisco.com
電話：+ 1-408-525-5386ファックス：+ 1-408-525-5386 Eメール：mat@cisco.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（C）IETFトラスト（2007）。
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, THE IETF TRUST 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が表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
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に情報を記述してください。