Network Working Group P. Hoffman
Request for Comments: 5518 J. Levine
Category: Standards Track Domain Assurance Council
A. Hathcock
Alt-N Technologies
April 2009
Vouch By Reference
Status of This Memo
このメモのステータス
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2009 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
この文書では、BCP 78と、この文書（http://trustee.ietf.org/license-info）の発行日に有効なIETFドキュメントに関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
この材料の一部がIETFトラストにこのような材料の変更を許可する権利を与えられていない可能性がありますにこの文書は、2008年、IETFドキュメントまたは11月10日以前に発行または公開さIETF貢献から著作権を支配する者（複数可）材料を含んでいてもよいですIETF標準化プロセスの外。そのような材料の著作権を管理者（単数または複数）から適切なライセンスを取得することなく、この文書は、IETF標準化過程の外側修正されないかもしれません、そして、それの派生物は、IETF標準化過程の外側に作成されない場合があり、それをフォーマットする以外出版RFCとして、英語以外の言語に翻訳します。
Abstract
抽象
This document describes the Vouch By Reference (VBR) protocol. VBR is a protocol for adding third-party certification to email. It permits independent third parties to certify the owner of a domain name that is associated with received mail.
この文書は、保証することでリファレンス（VBR）プロトコルを記述しています。 VBRは、電子メールに第三者認証を追加するためのプロトコルです。これは、受信したメールに関連付けられているドメイン名の所有者を証明するために、独立した第三者を可能にします。
Table of Contents
目次
1. Introduction ....................................................3
1.1. Definitions ................................................4
2. Use of the VBR-Info Header Field ................................4
3. Validation Process ..............................................4
4. The VBR-Info Header Field .......................................5
4.1. Syntax of VBR-Info Header Fields ...........................5
5. DNS Query .......................................................6
6. Types of Message Content ........................................7
6.1. All ........................................................8
6.2. List .......................................................8
6.3. Transaction ................................................8
7. Obtaining a Useful Domain Name ..................................8
7.1. DKIM .......................................................8
7.2. DomainKeys .................................................9
7.3. SPF ........................................................9
7.4. Sender ID .................................................10
8. Security Considerations ........................................10
9. IANA Considerations ............................................10
10. References ....................................................11
10.1. Normative References .....................................11
10.2. Informative References ...................................11
Appendix A. Acknowledgements .....................................12
Vouch By Reference, or VBR, is a protocol for adding third-party certification to email. Specifically, VBR permits independent third parties to certify the owner of a domain name that is associated with received mail. VBR may be performed anywhere along the email transit path, by any capable receiving module, either within the handling service or by end-user software.
リファレンス、またはVBRでは保証、電子メールへの第三者認証を追加するためのプロトコルです。具体的には、VBRは、受信メールに関連付けられているドメイン名の所有者を証明するために独立した第三者を可能にします。 VBRは、ハンドリングサービス内やエンドユーザソフトウェアのいずれかによって、任意の可能な受信モジュールによって、電子メールの中継経路に沿ってどこにでも行うことができます。
VBR accomplishes this with a two-part protocol:
VBRは、2部構成のプロトコルでこれを達成します：
o In the first part, a sender affixes VBR information to email messages. The VBR information says which domain certification services the sender believes will vouch for email traffic associated with that sender.
O最初の部分では、送信者は、電子メールメッセージにVBR情報を付加します。 VBR情報は、送信者がその送信者に関連付けられた電子メールトラフィックを保証します信じているドメイン認証サービスと言います。
o In the second part, the receiver queries one or more certification services to obtain information about the identity that has been associated with a received message. This latter protocol uses the DNS to distribute the certification information.
O第二部では、受信機は、受信したメッセージに関連付けられている識別情報を取得するために、1つ以上の認証サービスを問い合わせます。この後者のプロトコルは、認証情報を配布するためにDNSを使用します。
A sender provides certification attestations through the use of a new RFC 5322 ([RFC5322]) mail header field, "VBR-Info:". This header field contains the names of services that the sender claims will vouch for it, and the particular type of content of the message. A queried, third-party, DNS-based certification service can respond with a list of the types of message content it will vouch for, such as "transactional mail from somebank.example" and/or "all mail from anotherbank.example".
送信者は、新しいRFC 5322（[RFC5322]）メールヘッダフィールドを使用することによって認証アテステーションを提供する「VBR-INFO：」。このヘッダーフィールドは、送信者の主張は、それを保証するサービスの名前、およびメッセージの特定のタイプのコンテンツが含まれています。照会、サードパーティ、DNSベースの認証サービスは、このような「somebank.exampleから取引メール」および/または「anotherbank.exampleからすべてのメール」として、それがために保証されます、メッセージコンテンツの種類のリストで応答することができます。
A prerequisite for successful VBR operation is validation of the identity associated with the message. VBR is based on the use of domain names as identifiers, and permits multiple methods of obtaining and validating domain names. The validation methods are described in the "Obtaining a Useful Domain Name" section below.
成功したVBR操作のための前提条件は、メッセージに関連付けられているアイデンティティの検証です。 VBRは、識別子として、ドメイン名の使用に基づいて、およびドメイン名を取得し、検証する複数の方法を許可されます。検証方法は、以下の「有用なドメイン名を取得」セクションに記載されています。
The sender performs two steps:
送信者は、2つのステップを実行します。
If a recipient uses the results of vouching to adjust spam scores on incoming email, that recipient is placing a great deal of operational trust and power in the vouching service. Therefore, recipients need to select such services with care. Further, such recipients may want to select more than one vouching service in order to avoid a single point of failure for setting spam scores.
受信者が受信メールにスパムスコアを調整するためにバウチングの結果を使用している場合は、その受信者はバウチングサービスにおける動作の信頼と大量の電力を置いています。そのため、受信者は注意して、このようなサービスを選択する必要があります。さらに、このような受信者は、スパムスコアを設定するためのシングルポイント障害を回避するために、2つ以上のバウチングサービスを選択することもできます。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[RFC2119]に記載されているように解釈されます。
A sender uses VBR to indicate which domain certification services the sender believes will vouch for a particular piece of mail. The certification service uses VBR to state for which signatures it will vouch. This protocol uses the DNS to distribute the certification information.
送信者は送信者がメールの特定の部分を保証します信じているドメイン認証サービスを示すために、VBRを使用しています。認証サービスは、それが保証れるシグネチャする状態にVBRを使用しています。このプロトコルは、認証情報を配布するためにDNSを使用しています。
A message may have multiple VBR-Info header fields. This means that, in the terminology of RFC 5322, VBR-Info is a "trace header field" and SHOULD be added at the top of the header fields.
メッセージは、複数のVBR-Infoヘッダフィールドを有していてもよいです。これは、RFC 5322の用語では、VBR-INFO「は、トレースヘッダフィールド」であり、ヘッダフィールドの先頭に追加されるべきである、ということを意味します。
The content of the VBR-Info header field is a list of three elements:
VBR-Infoヘッダーフィールドの内容は、次の3つの要素のリストであります：
o The accountable domain
責任ドメインO
o The type of content in the message
メッセージのコンテンツの種類O
o A list of domain names of services that the sender expects to vouch for that kind of content
送信者は、コンテンツの種類を保証するために期待していたサービスのドメイン名のリストO
The accountable domain is given as md= followed by a domain name. The content type is given as mc= followed by a string; the defined values of that string are found below. The list of services is given as mv= followed by a colon-separated list of domain names.
責任ドメインは、ドメイン名が続く= MDとして与えられています。コンテンツタイプは、文字列が続く= MCとして与えられます。その文字列の定義された値は以下の発見されました。サービスのリストは、ドメイン名のコロンで区切られたリストが続く= MVとして与えられています。
The formal syntax of the header field is defined in Section 4.
ヘッダフィールドの正式な構文はセクション4で定義されています。
A message receiver uses VBR to determine certification status by following these steps:
メッセージ受信機は、次の手順を実行して、認証ステータスを決定するために、VBRを使用しています。
2. Verifies legitimate use of that domain using one or more authentication mechanisms as described herein
2.本明細書に記載される1つ以上の認証メカニズムを使用して、そのドメインの合法的な使用を検証します
3. Obtains the name of a vouching service that it trusts, either from among the set supplied by the sender or from a locally defined set of preferred vouching services
3.送信者から供給されたセットの中からまたは優先バウチングサービスのローカルに定義された一連のいずれかから、それが信頼バウチングサービスの名前を取得します
4. Queries the vouching service to determine whether the vouching service actually vouches for that type of content for that domain.
4.バウチングサービスが実際にそのドメインのコンテンツの種類を保証するかどうかを判断するためにバウチングサービスを照会します。
The VBR-Info header field has the following format:
VBR-Infoヘッダーフィールドの形式は次のとおりです。
VBR-Info: md=<domain>; mc=<type-string>; mv=<certifier-list>;
VBR-情報：MD = <ドメイン>。 MC = <タイプ文字列>。 MV = <認証者リスト>;
where <domain> is the domain for which vouching is offered, <type-string> is the content type of the message, and <certifier-list> is a list of domain names of certification providers that the sender asserts will vouch for this particular message. The structure of the <certifier-list> is one or more domain names with a colon (":") between each. The elements in the <domain>, <type-string>, and <certifier-list> must not have any white space in them.
ここで、<ドメイン>はバウチングが提供されているドメイン、<タイプ文字列>は、メッセージのコンテンツタイプです、そして<認証者リスト>は、送信者がこの特定を保証しますアサート認証プロバイダのドメイン名のリストですメッセージ。各々の間の<認証者リスト>の構造は、コロン（「」）を有する1人の以上のドメイン名です。 <ドメイン>の要素、<タイプ文字列>、および<認証-list>はそれらの中に空白があってはなりません。
For example, assume that the signer has two companies that are willing to vouch for its transactional notices: certifier-a.example and certifier-b.example. The signer would add the following to the header of its outgoing message.
認証者-a.exampleと認証-b.example：たとえば、署名者は、そのトランザクションの通知を保証して喜んでである2社を持っていることを前提としています。署名者は、発信メッセージのヘッダに以下を追加します。
VBR-Info: md=somebank.example; mc=transaction;
mv=certifier-a.example:certifier-b.example;
All three header parameters in the VBR-Info header are mandatory. In particular, there is no default for the md= domain.
VBR-Infoヘッダーのすべての3つのヘッダパラメータは必須です。特に、MD =ドメインにはデフォルトはありません。
Upper and lowercase characters in a VBR-Info header field are equivalent, although conventionally the contents are all in lower case. For upward compatibility, verifiers MUST accept the fields in any order and SHOULD ignore any fields other than the three defined here.
従来内容は全て小文字であるが、上部およびVBR-Infoヘッダフィールドの小文字は、等価です。上位互換性のために、検証者は、任意の順序でフィールドを受け入れなければならないし、ここで定義された3以外の任意のフィールドを無視します。
If a message has more than one VBR-Info header field, verifiers SHOULD check each in turn or in parallel until either a satisfactory certifier is found or all the header fields have been checked. All of the VBR-Info header fields in a single message MUST have identical mc= values.
メッセージが複数のVBR-Infoヘッダーフィールドを持っている場合、検証者は、満足認証者のいずれかが検出されたか、すべてのヘッダフィールドがチェックされるまで順番にまたは並列にそれぞれチェックする必要があります。単一のメッセージにVBR-Infoヘッダフィールドの全ては、同一のMC =値を持たなければなりません。
In the ABNF below, the ALPHA and DIGIT tokens are imported from [RFC5234], and the FWS and domain-name tokens are imported from [RFC4871].
以下ABNFにおいて、ALPHAとDIGITトークンは[RFC5234]からインポートされ、そしてFWSとドメイン名トークンは[RFC4871]からインポートされています。
vbr-info-header = "VBR-Info:" 1*([FWS] element [FWS] ";") element = md-element / mc-element / mv-element
ハイブリドーマ-情報-ieader = "VBP-Yeap情報" 1 *（[FOS]要素[FOS] "？"）要素= MS-要素/ MK-要素/ MW-要素
md-element = "md=" [FWS] domain-name
MD-要素= "MD =" [FWS]のドメイン名
mc-element = "mc=" [FWS] type-string type-string = "all" / "list" / "transaction"
MC-要素= "MC =" [FWS]タイプ文字列型の列= "すべて" / "リスト" / "取引"
mv-element = "mv=" [FWS] certifier-list certifier-list = domain-name *(":" domain-name)
MV-要素= "MV =" [FWS]認証者リストの認証者リスト=ドメイン名*（ "：" ドメイン名）
When a recipient wants to check whether a certification claim is valid, it compares the list in the message to the list of services it trusts. For each service that is on the intersection of the two lists, it marshals a domain name to look up that consists of the following DNS labels (from left to right):
受信者は、認定請求が有効であるかどうかを確認したい場合は、それが信頼サービスのリストへのメッセージにリストを比較します。二つのリストの交差点にある各サービスについては、次のDNSラベル（左から右へ）で構成されているルックアップするためにドメイン名をマーシャリング：
o the domain name that asserts it can be certified
それは認定することができます主張するドメイン名O
o _vouch (a string literal)
_vouch O（文字列リテラル）
o the host name of the vouching service
バウチングサービスのホスト名O
This domain name is queried for a DNS TXT record. The recipient looks up the domain name in the DNS in the exact same manner it looks up all other domain names.
このドメイン名は、DNS TXTレコードを照会されます。受信者は、それが他のすべてのドメイン名を検索しますまったく同じ方法で、DNSでドメイン名を検索します。
For example, if a message signed by somebank.example contained the VBR-Info header field above, the receiver might look up either or both of the following names, depending on which vouching service it trusts:
somebank.exampleによって署名されたメッセージが上記VBR-Infoヘッダフィールドが含まれている場合、例えば、受信機は、それが信頼バウチングれるサービスに応じて、次の名前のいずれかまたは両方をルックアップすることがあります。
somebank.example._vouch.certifier-b.example somebank.example._vouch.certifier-a.example
somebank.example._vouch.certifier-b.example somebank.example._vouch.certifier-a.example
If the DNS TXT record exists, it contains a space-delimited list of all the types that the service certifies, given as lowercase ASCII. For example, the contents of the TXT record might be:
DNS TXTレコードが存在する場合は、小文字のASCIIとして与えられ、サービスが認定し、すべてのタイプのスペース区切りのリストが含まれています。例えば、TXTレコードの内容は次のようになります。
transaction list
トランザクションリスト
In the example above, the receiver checks whether or not either certifier vouches for "transaction" mail. That would be indicated by either of the following types: "all" or "transaction" ("all" indicates that the certifier vouches for all message types sent by the domain in question). If either of those types appear in either
いずれかの認証者は、「取引」メールを保証する上記の例では、受信機か否かをチェックします。それは、次のタイプのいずれかで示されます：「すべて」または「取引」（「すべては」認証者は、問題のドメインから送信されたすべてのメッセージタイプを保証することを示しています）。これらのタイプのいずれかのどちらかに表示された場合
TXT record, the certifier has vouched for the validity of the message. Of course, the recipient needs to ignore services that it does not trust; otherwise, a bad actor could just add an authority that it has set up so that it can vouch for itself.
TXTレコードは、認証者は、メッセージの有効性のためにvouchedました。もちろん、受信者は、それが信頼していないサービスを無視する必要があります。それは自分自身を保証することができるようにそれ以外の場合は、悪い俳優はちょうどそれが設定した権限を追加することができます。
The name for the label _vouch was chosen because any domain name that includes it as one of its labels cannot be a valid host name. There will never be any accidental overlap with a valid host name. Further, it is safe to create a rule that says that a TXT DNS record that comes from a domain name that includes a _vouch label will always have the structure defined in this document.
そのラベルの1つとして、それを含む任意のドメイン名が有効なホスト名にすることはできませんので、選ばれた_vouchラベルの名前。有効なホスト名を持つ任意の不慮の重複があってはなりません。さらに、_vouchラベルを含むドメイン名から来ているTXT DNSレコードは、常にこの文書で定義された構造を持っているだろうと言うルールを作成しても安全です。
If the RDATA in the TXT record contains multiple character-strings (as defined in Section 3.3 of [RFC1035]), the code handling that reply from DNS MUST assemble all of these marshaled text blocks into a single one before any syntactical verification takes place.
TXTレコード内のRDATAは、複数の文字列を（[RFC1035]の3.3節で定義されている）が含まれている場合いずれかの構文の検証が行われる前に、DNSからその応答を処理コードは、単一の一つにこれらのマーシャリングテキストブロックのすべてを組み立てなければなりません。
Verifiers MUST then check that the TXT record consists of strings of lowercase letters separated by spaces, and discard any records not in that format. This defends against misconfigured records and irrelevant records synthesized from DNS wildcards.
検証者は、TXTレコードは、スペースで区切られた小文字の文字列で構成されていることを確認し、その形式でないすべてのレコードを捨てなければなりません。これは、DNSのワイルドカードから合成誤って設定レコードとは無関係の記録を防御します。
The VBR record MUST have only one TXT record.
VBRレコードは、唯一のTXTレコードを持たなければなりません。
This query method relies on the considerable advantages of existing DNS efficiencies, reliability, and experience. The lookup is very efficient, and certifiers can add and delete client records as quickly as they want. The lookup also leverages the DNS's negative caching ([RFC2308]).
このクエリ方法は、既存のDNS効率、信頼性、および経験のかなりの利点に依存しています。ルックアップは非常に効率的であり、認証機関は、早く彼らが望むように、クライアントのレコードを追加および削除することができます。検索にもDNSのネガティブキャッシュを活用する（[RFC2308]）。
This section describes the types of content for which a certifier can vouch. While the rest of the VBR specification is mostly technical and precise, describing the types of contents in mail messages is inherently open to interpretation. Thus, this section makes distinctions as specifically as possible, but the reader needs to understand that these semantic definitions can be interpreted in very different ways by different people.
このセクションでは、認証者が保証できるため、コンテンツの種類について説明します。 VBR仕様の残りの部分は主に技術的かつ正確ですが、メールメッセージ内のコンテンツの種類を説明することは、解釈に本質的に開かれています。したがって、このセクションでは、できるだけ具体的区別を行いますが、読者は、これらのセマンティックの定義が異なる人々によって非常に異なる方法で解釈することができることを理解する必要があります。
Note that the value in the mc= element is self-asserted. The purpose of this element is for auditing. There will likely be cases where a certifier will vouch for one type of a sender's mail (such as transactional mail) but not another type (such as advertising). A sender who cannot get anyone to certify its advertising mail, but has a certifier for its transactional mail, might be tempted to cheat and mislabel it as transactional. The mc= element creates an the audit trail to help their certifiers catch such cheating and allow the removal of the certification for the transactional mail.
MC =要素の値は、自己表明であることに注意してください。この要素の目的は、監査のためです。おそらく認証者は1つの（例えばトランザクションメールなど）送信者のメールの種類が、（広告など）ではない別のタイプを保証します例があります。誰もがそのダイレクトメールを証明してもらうが、そのトランザクションのメールの認証者を持つことができない送信者は、トランザクションとしてそれをごまかすとmislabelしたくなるかもしれません。 MC =要素は、その認証機関は、このような不正行為をキャッチし、トランザクションのメールの認証の除去を可能に支援するために監査証跡を作成します。
Three types of content are defined.
コンテンツの三つのタイプが定義されています。
"all" means all mail from the sender.
「すべては、」送信者からのすべてのメールを意味します。
"list" is the category for email sent to multiple recipients where each piece of mail is identical or is very similar to the others.
「リストは、」メールの各部分が同一であるか、他の人に非常に似ている複数の受信者に送信される電子メールのためのカテゴリです。
"transaction" is the category for transactional messages. This is a response to a specific action of the user, or a notice about an event in the user's account at the sender.
「トランザクション」はトランザクションメッセージのカテゴリです。これは、ユーザーの特定のアクション、または送信者にユーザーのアカウント内のイベントについての通知に応じています。
VBR relies on having a domain name that specifies a party that is accountable for the message. This requires obtaining the domain name and possessing a strong basis for believing that the use of the domain name is valid, that is, that it has not been spoofed.
VBRは、メッセージのために責任があるパーティーを指定するドメイン名を持つに依存しています。これは、それが詐称されていないこと、つまり、ドメイン名を取得したドメイン名の使用が有効であることを信じるために強固な基盤を持つが必要です。
There are different ways to achieve this and this section discusses the allowed mechanisms. Senders SHOULD use Domain Keys Identified Mail (DKIM) (and MAY use DomainKeys, Sender Policy Framework (SPF), or SenderID) to give an accountable identity for the sender.
そこにこれを達成するためのさまざまな方法があり、このセクションでは、許可されるメカニズムについて説明します。送信者は、ドメインキー認証メール（DKIM）を使用する必要があります（とDomainKeysは、SPF（Sender Policy Framework）を、またはのSenderIDを使用する場合があります）、送信者の責任のアイデンティティを与えます。
DomainKeys Identified Mail (DKIM), [RFC4871], defines an accountable identity by associating a domain name with the message. It provides assurance that the association is valid through a public-key-based authentication mechanism.
ドメインキー・アイデンティファイド・メール（DKIM）、[RFC4871]は、メッセージにドメイン名を関連付けることによって責任アイデンティティを定義します。これは、関連付けは、公開鍵ベースの認証メカニズムを介して有効であることを保証を提供します。
o When DKIM is the validation mechanism, VBR's md= MUST match the domain name taken from one of the DKIM-Signature header fields. If the DKIM signature contains an i= field, the domain name from that field is used; otherwise, the domain name from the DKIM signature d= field is used.
DKIM検証機構、VBRのMDの場合、O = DKIM-Signatureヘッダーフィールドのいずれかから採取されたドメイン名と一致しなければなりません。 DKIM署名がI =フィールドが含まれている場合は、そのフィールドからドメイン名が使用されます。そうでない場合は、DKIM署名D =フィールドからドメイン名が使用されます。
o The VBR-Info header field SHOULD be included in the set of header fields protected by DKIM to prevent a malicious party from changing the contents of the VBR-Info header field or adding bogus VBR-Info header fields.
O VBR-InfoヘッダフィールドはVBR-Infoヘッダフィールドの内容を変更したり、偽のVBR-Infoヘッダフィールドを追加することから悪意のあるパーティを防止するためにDKIMによって保護ヘッダフィールドのセットに含まれるべきです。
o The VBR-Info header field SHOULD be added in the header immediately below the corresponding DKIM-Signature header field.
VBR-InfoヘッダフィールドO直ちに対応DKIM-Signatureヘッダーフィールドの下ヘッダに追加されるべきです。
If the DKIM signature validates, the domain name taken from that signature is valid for use with VBR.
DKIM署名が検証された場合は、その署名から取られたドメイン名はVBRで使用するために有効です。
DomainKeys (DK), [RFC4870], defines an accountable identity by associating a domain name with the message in the d= tag of the DomainKey-Signature header field. It provides assurance that the association is valid through a public-key-based authentication mechanism.
ドメインキー（DK）、[RFC4870]は、DomainKey-SignatureヘッダーフィールドのD =タグ内のメッセージでドメイン名を関連付けることによって責任アイデンティティを定義します。これは、関連付けは、公開鍵ベースの認証メカニズムを介して有効であることを保証を提供します。
o When DomainKeys is the validation mechanism, VBR's md= MUST be the same value as the domain name found in the DomainKey-Signature d= parameter.
DomainKeysの検証機構、VBRのMDの場合、O = DomainKey署名D =パラメーターに見出されるドメイン名と同じ値である必要があります。
o The VBR-Info header field SHOULD be included in the set of header fields protected by DK to prevent a malicious party from changing the contents of the VBR-Info header field or adding bogus VBR-Info header fields.
O VBR-InfoヘッダフィールドはVBR-Infoヘッダフィールドの内容を変更したり、偽のVBR-Infoヘッダフィールドを追加することから悪意のあるパーティを防止するために、DKによって保護ヘッダフィールドのセットに含まれるべきです。
o The VBR-Info header field SHOULD be added immediately below the corresponding DomainKey-Signature header field.
O VBR-Infoヘッダフィールドは、対応するDomainKey-Signatureヘッダーフィールド直下に添加されるべきです。
If the DomainKeys signature validates, the domain in the d= tag is valid for use with VBR.
DomainKeysの署名が検証された場合は、D =タグ内のドメインは、VBRで使用するために有効です。
Sender Policy Framework (SPF), [RFC4408], defines an accountable identity by using an existing message address and querying the DNS to discover whether it is valid for SPF use.
送信者ポリシーフレームワーク（SPF）、[RFC4408]は、既存のメッセージ・アドレスを使用して、SPFを使用するために有効であるかどうかを発見するためにDNSに問い合わせることによって責任アイデンティティを定義します。
When SPF is the validation mechanism, VBR's md= MUST be the same value as the domain name in the <reverse-path> address that is the first parameter to the SMTP MAIL command.
SPFは、検証機構、VBRのMDである場合= SMTPメール・コマンドの最初のパラメータであり、<逆経路>アドレスのドメイン名と同じ値である必要があります。
A domain is valid for use with VBR only when the SPF process produces a "pass" result.
ドメインはSPFのプロセスが「合格」の結果を生じる場合にのみ、VBRで使用するために有効です。
Sender ID, [RFC4406], defines an accountable identity by using an existing message address known as the Purported Responsible Address ([RFC4407]) and querying the DNS to discover whether it is valid for Sender ID use.
送信元ID、[RFC4406]は、主張責任アドレス（[RFC4407]）として知られている既存のメッセージ・アドレスを使用して、送信者IDの使用のために有効であるかどうかを発見するためにDNSに問い合わせることによって責任アイデンティティを定義します。
When Sender ID is the validation mechanism, VBR's md= MUST be the same value as the domain name in the Purported Responsible Address in the message.
送信者IDの検証メカニズム、VBRのMDのとき=メッセージ中主張責任アドレスのドメイン名と同じ値でなければなりません。
A domain is valid for use with VBR only when the Sender ID process produces a "pass" result.
ドメインは、Sender IDのプロセスが「合格」の結果を生じるだけVBRで使用するために有効です。
VBR is used to allow users to trust independent third parties to certify the owner of a domain name that is associated with received mail. The party validating the mail might use that trust relationship to perform actions that affect the security of their system.
VBRは、ユーザーが受信したメールに関連付けられているドメイン名の所有者を証明するために、独立した第三者を信頼できるようにするために使用されます。メールの検証当事者は自分のシステムのセキュリティに影響を与えるアクションを実行するためにその信頼関係を使用する場合があります。
The receiver of a message with a VBR-Info header field MUST ignore certifiers that it does not trust; otherwise, a bad actor could just add an authority that it has set up so that it can vouch for itself.
VBR-Infoヘッダフィールドと、メッセージの受信側は、それが信頼していない認証者を無視しなければなりません。それは自分自身を保証することができるようにそれ以外の場合は、悪い俳優はちょうどそれが設定した権限を追加することができます。
Implementations SHOULD limit the number of VBR-Info header fields they process in a single message in order to protect themselves from a make-work or denial-of-service attack.
実装は、彼らが作る、仕事やサービス拒否攻撃から身を守るために、単一のメッセージで処理VBR-Infoヘッダーフィールドの数を制限する必要があります。
IANA registered the VBR-Info header field in the Message Header Fields Registry ([RFC3864]) as follows:
IANAは、メッセージヘッダフィールドレジストリ（[RFC3864]）は、以下のようにVBR-Infoヘッダフィールドを登録しました：
Header field name: VBR-Info
ヘッダフィールド名：VBR-情報
Applicable protocol: mail
該当するプロトコル：メール
Status: standard
ステータス：標準
Author/Change controller: IETF
著者/変更コントローラ：IETF
Specification document(s): RFC 5518
仕様書（S）：RFC 5518
Related information: none
関連情報：なし
[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月。
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5234]クロッカー、D.、およびP. Overell、 "構文仕様のための増大しているBNF：ABNF"、STD 68、RFC 5234、2008年1月。
[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, October 2008.
[RFC5322]レズニック、P.、エド。、 "インターネットメッセージ形式"、RFC 5322、2008年10月。
[RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.
[RFC1035] Mockapetris、P.、 "ドメイン名 - 実装及び仕様"、STD 13、RFC 1035、1987年11月。
[RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)", RFC 2308, March 1998.
[RFC2308]アンドリュース、M.、 "DNSクエリのネガティブキャッシュ（DNS NCACHE）"、RFC 2308、1998年3月。
[RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration Procedures for Message Header Fields", BCP 90, RFC 3864, September 2004.
[RFC3864] Klyne、G.、ノッティンガム、M.、およびJ.モーグル、BCP 90、RFC 3864、2004年9月 "メッセージヘッダフィールドの登録手順"。
[RFC4406] Lyon, J. and M. Wong, "Sender ID: Authenticating E-Mail", RFC 4406, April 2006.
[RFC4406]リヨン、J.とM.ウォン、 "送信者ID：の認証Eメール"、RFC 4406、2006年4月。
[RFC4407] Lyon, J., "Purported Responsible Address in E-Mail Messages", RFC 4407, April 2006.
[RFC4407]リヨン、J.、 "Eメールメッセージで主張責任アドレス"、RFC 4407、2006年4月。
[RFC4408] Wong, M. and W. Schlitt, "Sender Policy Framework (SPF) for Authorizing Use of Domains in E-Mail, Version 1", RFC 4408, April 2006.
"Eメール、バージョン1でのドメインの認可使用のためのSPF（Sender Policy Framework）を" [RFC4408]ウォン、M.およびW. Schlitt、RFC 4408、2006年4月。
[RFC4870] Delany, M., "Domain-Based Email Authentication Using Public Keys Advertised in the DNS (DomainKeys)", RFC 4870, May 2007.
[RFC4870]デラニー、M.、 "DNS（ドメインキー）で公開鍵アドバタイズを使用したドメインベースの電子メール認証"、RFC 4870、2007年5月。
[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月。
Appendix A. Acknowledgements
付録A.謝辞
Many members of the Domain Assurance Council contributed to the design of the protocol and the wording of this document. In addition, constructive suggestions were received from Jim Fenton and Murray Kucherawy.
ドメイン保証委員会の多くのメンバーは、プロトコルの設計と、この文書の文言に貢献しました。また、建設的な提案は、ジム・フェントンとマレーKucherawyから受け取りました。
Authors' Addresses
著者のアドレス
Paul Hoffman Domain Assurance Council
ポール・ホフマンドメイン保証協議会
EMail: paul.hoffman@domain-assurance.org
メールアドレス：paul.hoffman@domain-assurance.org
John Levine Domain Assurance Council
ジョン・レヴァインドメイン保証協議会
EMail: john.levine@domain-assurance.org
メールアドレス：john.levine@domain-assurance.org
Arvel Hathcock Alt-N Technologies
Arvel HathcockのAlt-N Technologies社
EMail: arvel.hathcock@altn.com
メールアドレス：arvel.hathcock@altn.com