RFC5016 日本語訳
5016 Requirements for a DomainKeys Identified Mail (DKIM) SigningPractices Protocol. M. Thomas. October 2007. (Format: TXT=33710 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group M. Thomas Request for Comments: 5016 Cisco Systems Category: Informational October 2007
コメントを求めるワーキンググループM.トーマスの要求をネットワークでつないでください: 5016年のシスコシステムズカテゴリ: 情報の2007年10月
Requirements for a
DomainKeys Identified Mail (DKIM) Signing Practices Protocol
DomainKeysが習慣にサインしながらメール(DKIM)を特定したので、要件は議定書を作ります。
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).
ドメインがそれらが扱うメッセージへの責任について断言するように、DomainKeys Identifiedメール(DKIM)は暗号のメカニズムを提供します。 関連するメカニズムで、管理者は習慣にサインするそれらのDKIMに関する様々な声明を発表できるでしょう。 このドキュメントはこのメカニズムのための要件を定義します、満足している(MUST)であるに違いないそれら、および非常に望ましいもの(SHOULD)を見分けて。
Thomas Informational [Page 1] RFC 5016 DKIM-SSP-REQ October 2007
[1ページ]RFC5016DKIM-SSP-REQ2007年10月の情報のトーマス
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
1. 序論…2 2. 定義と要件言語…3 3. SSP問題シナリオ…4 3.1. 問題シナリオ1: すべてのメールがDKIMを契約されますか? ..........4 3.2. 問題シナリオ2: 違法なドメイン名使用…5 4. SSP展開問題…6 4.1. 展開の考慮1: 調印を社外調達します…6 4.2. 展開の考慮2: サブドメイン適用範囲…6 4.3. 展開の考慮3: オリジナルのメールに憤慨してください…7 4.4. 展開の考慮4: 調印の増加の展開…7 4.5. 展開の考慮5: パフォーマンスであってキャッシュすること…8 4.6. 展開の考慮6: 習慣の人間の読みやすさ。8 4.7. 展開の考慮7: 伸展性…8 4.8. 展開の考慮8: セキュリティ…8 5. 要件…9 5.1. 発見要件…9 5.2. SSPは要件を輸送します…10 5.3. 習慣と期待要件…10 5.4. 伸展性と下位互換要件…13 6. SSPセキュリティのための要件…13 7. セキュリティ問題…13 8. 承認…13 9. 参照…14 9.1. 標準の参照…14
1. Introduction
1. 序論
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.
DomainKeys Identifiedメール[RFC4871]はメールのためにメッセージレベル調印と検証メカニズムを定義します。 DKIMはサインしましたが、メッセージは自分の思うことを言って、メッセージに有効な最初のパーティー署名(すなわち、[RFC2822].Fromアドレスを代表した)がないなら、あいまいさがあります: これは、予想されるためのものですか? メールに関しては、送付ドメインの習慣に関する先験的な知識への期待が全くないので、これは特に難しい問題です。 メールのような任意の認証を許すシステムで固有の攻撃の下側に付け値を仕掛けるのにこのあいまいさを使用できます: 受信機が別の方法で知らないなら、それは、有効な署名の不足が他の情報なしで例外的であると仮定するべきではありません。 したがって、攻撃者は、あいまいさを利用して、メッセージに絶対にサインできません。 無記名のメールを受け取るとき、習慣にサインするDKIMを発行するためにドメインにプロトコルを開発できるなら、メッセージ検証はそれを考慮に入れるかもしれないでしょうに。
Thomas Informational [Page 2] RFC 5016 DKIM-SSP-REQ October 2007
[2ページ]RFC5016DKIM-SSP-REQ2007年10月の情報のトーマス
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.
このドキュメントはSender Signing Practices(SSP)の公表を可能にするメカニズムのための要件を定義します。 ドキュメントは2つの主なセクションへまとめられます: 1番目とProblemとSSPが展開と同様にベース問題を囲む問題を記述することを意図して、第2セクションがそれらのシナリオで起こるRequirementsであるという問題について説明するDeployment Scenario部。
2. Definitions and Requirements Language
2. 定義と要件言語
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.
o ドメイン所有者: ドメインでDNS下位木始めのコンテンツを制御する実体、直接かNS記録を通した代表団で、それは制御されます。
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に関しては、最初のパーティーアドレスはメッセージヘッダーの[RFC2822].Fromアドレスになるように定義されます。 また、最初のパーティーアドレスはAuthorアドレスとして知られています。
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 最初のパーティ署名: 最初のパーティー署名は調印のアイデンティティ(d=タグか私=がタグ付けをするより特定のアイデンティティ)が最初のパーティーアドレスに合っているところの有効な署名です。 「マッチ」は[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第三者署名はSenderのコンテンツやList-イドなどのヘッダーフィールドアドレスに相当するのに必要でないことに注意してください。
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 期待: 期待は習慣に結合して、ドメイン所有者が受信機のために習慣のありそうな生存性であると考えるものを伝えます、遠くの1つ以上の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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119[RFC2119]で説明されるように本書では解釈されることであるべきですか?
Thomas Informational [Page 3] RFC 5016 DKIM-SSP-REQ October 2007
[3ページ]RFC5016DKIM-SSP-REQ2007年10月の情報のトーマス
3. SSP Problem Scenarios
3. SSP問題シナリオ
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によってサインされたメールの関連性をはっきりさせるのをどう助けるかもしれないかをこのセクションは概説します。
3.1. Problem Scenario 1: Is All Mail Signed with DKIM?
3.1. 問題シナリオ1: すべてのメールが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署名を含むのをできる限り確実にしました。
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.
その期待がなくても、受信機はドメインの習慣が無記名かトランジットメールで破損に対してすべてのメールにサインして、フィルタに偏ることになっているという知識を利用できるかもしれません。 代わりに特にデータポイントとしてフィルタリング・システムでこの情報によって2進のはい/いいえファッションで使用されないと予想されるべきです。
Thomas Informational [Page 4] RFC 5016 DKIM-SSP-REQ October 2007
[4ページ]RFC5016DKIM-SSP-REQ2007年10月の情報のトーマス
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.
1. なくなったか中断したDKIM最初のパーティー署名と共に[RFC2822].Fromドメインアリスがいるメールをアリスからドメインボブに送ります。
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. Domainボブは、何らかの容疑があるメッセージを調べるためにフィルタに偏るのにこの情報を使用できました。
3.2. Problem Scenario 2: Illegitimate Domain Name Use
3.2. 問題シナリオ2: 違法なドメイン名使用
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は、何か問題が非常にあるように見えます。
Thomas Informational [Page 5] RFC 5016 DKIM-SSP-REQ October 2007
[5ページ]RFC5016DKIM-SSP-REQ2007年10月の情報のトーマス
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.
1. なくなったか中断した最初のパーティーDKIM署名と共に[RFC2822].Fromドメインアリスがいるメールをドメインアリスからドメインボブに送ります。
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. Domainアリスは、すべての送信するメールにサインするという情報を提供して、その上、期待を置きます。完全な最初のパーティー署名と共に到着するべきです、そして、用心深くないなら、受信機ははるかに用心深いはずです。
4. Domain Bob could use this information to bias its filters such
that it examines the message with great suspicion.
4. Domainボブがフィルタに偏るのにこの情報を使用できたので、それはすごい容疑に伴うメッセージを調べます。
4. SSP Deployment Considerations
4. SSP展開問題
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が提供する情報サービスを実行するか、または配備する実際の整備士がいます。
4.1. Deployment Consideration 1: Outsourced Signing
4.1. 展開の考慮1: 社外調達された調印
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.
多くのドメインが、それら自身のメールインフラストラクチャを走らせないか、またはそれの部品を第三者に社外調達するかもしれません。 ドメイン所有者にはドメイン所有者の受取にサインする能力を他の実体へ代表として派遣する能力があるのは、望ましいです。 ある明白な使用、シナリオはそれらの外向的なISPがドメイン所有者を代表してそれらのメールのすべてにサインする能力を必要とする小さいドメインからのドメイン所有者です。 シナリオが保険金などの様々なビジネス機能を社外調達することと同様にキャンペーンを売り出しながら社外調達された料金別納郵便を含む他の使用
4.2. Deployment Consideration 2: Subdomain Coverage
4.2. 展開の考慮2: サブドメイン適用範囲
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
SSPクライアントは、問題シナリオで提案されるように情報を提供するために入って来るメールストリームにルックアップを実行するでしょう。 [RFC2822].Fromの最初のアドレスのドメイン部分は発行された情報をとって来る基礎を形成するでしょう。 発行された情報を取り付けることができるのがわかる回避する些細な攻撃は、単にそれが持っていない親ドメインに関するサブドメインを使用することによって、情報を発表しました。 この攻撃はサブドメイン攻撃と呼ばれます: それはそうであり、ドメインはそれが制御する与えられたDNSラベルのために方針を発行するだけではない必需品です、しかし、また、それがまた、そのラベルに関するすべてのサブドメインを保護したがっています。 この特性が満たされないなら攻撃者、必要性はカバーされていなかったことによると架空のサブドメインを作成するだけでしょう。
Thomas Informational [Page 6] RFC 5016 DKIM-SSP-REQ October 2007
[6ページ]RFC5016DKIM-SSP-REQ2007年10月の情報のトーマス
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の情報サービスで。 したがって、SSPが与えられたドメインだけではなく、また、そのドメインに関するすべてのサブドメインもカバーするのは、有利でしょう。
4.3. Deployment Consideration 3: Resent Original Mail
4.3. 展開の考慮3: オリジナルのメールに憤慨してください。
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はメッセージにサインします、恐らくSenderアドレスに対応しています。
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最初のパーティー署名を壊す「再-郵送者」が潜在的にそうであることができる役得があります。
4.4. Deployment Consideration 4: Incremental Deployment of Signing
4.4. 展開の考慮4: 調印の増加の展開
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 Signing Complete習慣を発行できるようにサインするDKIMを押して伸ばすのは、難しいかもしれません、社外調達された業者が利益などを転送して これは発行のProblem Scenario2などのようにメールを最も最少に分類しなければならない高値の共通点が練習する功績を戸外に発ちます。 ドメイン所有者が、より制限している習慣声明を持っている例外のリストを発表するのを許容するのは望ましいでしょう。 ネブラスカ: これはベース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 に関する同じ例を使用します。
Thomas Informational [Page 7] RFC 5016 DKIM-SSP-REQ October 2007
[7ページ]RFC5016DKIM-SSP-REQ2007年10月の情報のトーマス
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がサブドメインの使用で既にこの種類の分化を支持できると言われているべきです。 すなわち、強い習慣を発行するために、人だけが異なったサブドメインにそれらのケースを隔離しなければなりません。 例えば: accounts.bigbank.example.comは強制的な習慣を発行するでしょうが、corporateusers.bigbank.example.comは、より寛大な習慣を発行するかもしれません。
4.5. Deployment Consideration 5: Performance and Caching
4.5. 展開の考慮5: パフォーマンスとキャッシュ
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つの主なシナリオになりそうです、大きいものの1番目、お互いに常に接触している周知のドメイン。 この場合、性能に、記録のキャッシュは不可欠です、記録(すなわち、否定的キャッシュ)の非存在のキャッシュを含んでいて。
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 querierへの交換処理負担は低くなりたいと思います。 同様に、また、ここに上流のキャッシュを持っているのは有利でしょう、たとえば、したがって、小さいドメインのメーリングリスト発破器が小さいドメインへの根と正式のサーバで質問の爆発をもたらしません。
4.6. Deployment Consideration 6: Human Legibility of Practices
4.6. 展開の考慮6: 習慣の人間の読みやすさ
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記録はオートマトンによって主として消費されそうですが、また、予見できる未来に、それらも手で点検されそうです。 また、人間の検査官にとって、直感的なファッションで習慣を述べさせてうれしいでしょう。
4.7. Deployment Consideration 7: Extensibility
4.7. 展開の考慮7: 伸展性
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を囲む要件だけに関する間、プロトコルが他のプロトコルに達することができるのは、有益でしょう。
4.8. Deployment Consideration 8: Security
4.8. 展開の考慮8: セキュリティ
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
SSPは敵対的で、開いているインターネットの環境における人生に耐えることができなければなりません。 これらはDoS攻撃、および特にプロトコルに固有の増幅で自分たちに投機するDoS攻撃を含んでいます。 役に立つプロトコルなしで建てられるかもしれない間の添加で
Thomas Informational [Page 8] RFC 5016 DKIM-SSP-REQ October 2007
[8ページ]RFC5016DKIM-SSP-REQ2007年10月の情報のトーマス
strong source authentication provided by the information service, a path to strong source authentication should be provided by the protocol, or underlying protocols.
情報サービスによって提供された、強いソース認証、強いソース認証への経路はプロトコルで提供するべきであるか、またはプロトコルの基礎となるべきです。
5. Requirements
5. 要件
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のための要件を定義します。 これらの要件がほとんどの要件ドキュメントで候補プロトコルが提供されなければならないというMINIMUM要件を定義するので。 また、SSPが要件のすべてを実現させなければならないことに注意されるべきです。
5.1. Discovery Requirements
5.1. 発見要件
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.
有益な注意: 例は普通のDNS葉の中の同じタイプに関する複数のリソース記録です。 したがって、唯一定義された葉の名か唯一定義されたリソースレコード種類が明白な参照箇所を確実にするでしょう。
Refs: Deployment Consideration, Section 4.2.
審判: 展開の考慮、セクション4.2。
Thomas Informational [Page 9] RFC 5016 DKIM-SSP-REQ October 2007
[9ページ]RFC5016DKIM-SSP-REQ2007年10月の情報のトーマス
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検索SHOULDは与えられたドメインだけではなく、また、サブドメインのすべてに適用範囲を提供します。 この要件の広く受け入れられた解決策に関する実現の可能性に関していくらかの合理的疑いがあると認められます。 ワーキンググループが解決策に関する荒いコンセンサスを達成しないなら、それはプロトコル仕様に関連セキュリティ問題を記録しなければなりません。
Refs: Deployment Considerations, Sections 4.2 and 4.5.
審判: 展開問題、セクション4.2と4.5。
5.2. SSP Transport Requirements
5.2. SSP輸送要件
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. 交換SHOULDには、特に本当のトランスポート層(例えば、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. インフラストラクチャが(la 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。
5.3. Practice and Expectation Requirements
5.3. 習慣と期待要件
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
定義部で述べられているように、それが送るメールメッセージにおける外部的に証明可能な振舞いの[RFC2822].Fromドメイン所有者に従って、習慣は声明です。 例と、習慣は、すべてのメールメッセージが[RFC2822].Fromアドレスに対応するDKIM署名を含むように、定義されるかもしれません。 以来、送付者が送って、受信機が調べるものの間には、変更の可能性があります、aがあるコンバインが練習する期待
Thomas Informational [Page 10] RFC 5016 DKIM-SSP-REQ October 2007
[10ページ]RFC5016DKIM-SSP-REQ2007年10月の情報のトーマス
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アドレスのための有効なDKIMが習慣ですが、[RFC2822].Fromドメインが受信機で習慣の生存性のありそうな結果であると考えるものを伝えてください。隣接。
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 MUST、習慣と期待主張を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 MUSTが[RFC2822].Fromとアイデンティティの間の簡潔なリンケージをDKIM i=タグに供給するか、またはデフォルトはそれであるなら署名でなくなっています。 すなわち、SSP MUSTは正確に最初のパーティー署名の資格を得ることに関する意味論を定義します。
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 MUST、ドメインのものが振舞いにサインして、「完全な状態でサインする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 MUST、メッセージを受け取り次第期待していた状態で証明可能な最初のパーティー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
6. DKIMがセレクタを収納するのにDNSを使用するので、ドメイン所有者がすべてか_domainkeyサブドメインの部分をドメイン所有者の選ぶことの連携政党へ代表として派遣する能力がいつもあります。 すなわち、ドメイン所有者は_Eメールプロバイダへの代表への全体の名前空間を管理するdomainkey.example.comのためのNS記録を設定するかもしれません。 また、ドメイン所有者がさらに第三者を抑制するために名前空間をサブドメインに仕切る能力があります。 例えば、ドメイン所有者は_domainkey.benefits.example.comしか代表として派遣することができませんでした。
Thomas Informational [Page 11] RFC 5016 DKIM-SSP-REQ October 2007
[11ページ]RFC5016DKIM-SSP-REQ2007年10月の情報のトーマス
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.
第三者が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 MUST NOT、有効な最初のパーティー署名が見つけられるなら、呼び出されるのを必要であってください。
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 MUST NOTはメッセージで非最初にの存在を論難するメカニズムにパーティー署名を供給します。 この要件の推論はプロトコルが第三者署名者の習慣を伴う最初に、パーティー署名者の習慣をリンクしてはいけないということです。
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。
Thomas Informational [Page 12] RFC 5016 DKIM-SSP-REQ October 2007
[12ページ]RFC5016DKIM-SSP-REQ2007年10月の情報のトーマス
5.4. Extensibility and Forward Compatibility Requirements
5.4. 伸展性と下位互換要件
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 MUST NOTはこのとき、メールのためのDKIM以外のどんなプロトコルにも達します。 SSP SHOULD、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 MUST、既存の発見/輸送/習慣の中で後方のコンパチブルファッションで新しい習慣と期待を加えることができてください。
Refs: Deployment Consideration, Section 4.7.
審判: 展開の考慮、セクション4.7。
6. Requirements for SSP Security
6. SSPセキュリティのための要件
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は潜在的に高値のDoS目標です、特に無記名のメッセージがSSPの記録の使用不能で、より疑わしげでなくなるかもしれないので。
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 MUST NOTは非常に投機された増幅か不必要な作業攻撃を可能にします。 かかわった仕事と交換処理は特に、定数の注文であるに違いありません。
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 MUSTには、ドメイン所有者が受信機がそれを決定できるくらいのそのようなものをSSPのデータに提供する能力が大きい度の確実性と共にドメイン所有者からほんとうにあります。 SSPは下に展開の容易さのために、より少ない確実性を貿易に提供する手段を提供するかもしれません。
Refs: Deployment Consideration, Section 4.8.
審判: 展開の考慮、セクション4.8。
7. Security Considerations
7. セキュリティ問題
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.
このドキュメントは新しいプロトコルのための要件を定義します、そして、セキュリティ関連する要件は上で定義されます。 以来、脅威の情報、大部分またはすべてが[RFC4686]で説明した発行されたSSPの基礎が適切になるので新しいプロトコルがDNSを使用すると予想されます。
8. Acknowledgments
8. 承認
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とデヴィッド・ハリントンをありがとうございます。
Thomas Informational [Page 13] RFC 5016 DKIM-SSP-REQ October 2007
[13ページ]RFC5016DKIM-SSP-REQ2007年10月の情報のトーマス
9. References
9. 参照
9.1. Normative References
9.1. 引用規格
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[RFC2822] Resnick, P., Ed., "Internet Message Format", RFC 2822,
April 2001.
[RFC2822] レズニック、P.、エド、「インターネットメッセージ・フォーマット」、RFC2822、4月2001日
[RFC4686] Fenton, J., "Analysis of Threats Motivating DomainKeys
Identified Mail (DKIM)", RFC 4686, September 2006.
[RFC4686] フェントン、J.、「DomainKeysを動機づける脅威の分析はメール(DKIM)を特定した」RFC4686、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.トーマス、「DomainKeysはメール(DKIM)署名を特定しました」、RFC4871、2007年5月。
Author's Address
作者のアドレス
Michael Thomas Cisco Systems 606 Sanchez St San Francisco, California 94114 USA
マイケルトーマスシスコシステムズ606サンチェスStカリフォルニア94114サンフランシスコ(米国)
Phone: +1-408-525-5386 Fax: +1-408-525-5386 EMail: mat@cisco.com
以下に電話をしてください。 +1-408-525-5386 Fax: +1-408-525-5386 メールしてください: mat@cisco.com
Thomas Informational [Page 14] RFC 5016 DKIM-SSP-REQ October 2007
[14ページ]RFC5016DKIM-SSP-REQ2007年10月の情報のトーマス
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2007).
IETFが信じる著作権(C)(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.
このドキュメントは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, 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.
このドキュメントとここに含まれた情報はその人が代理をするか、または(もしあれば)後援される組織、インターネットの振興発展を目的とする組織、「そのままで」という基礎と貢献者の上で提供していて、IETFはそして、インターネット・エンジニアリング・タスク・フォースがすべての保証を放棄すると信じます、急行である、または暗示していて、他を含んでいて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるということであるかいずれが市場性か特定目的への適合性の黙示的な保証です。
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に情報を記述してください。
Thomas Informational [Page 15]
トーマスInformationalです。[15ページ]
一覧
スポンサーリンク
