[要約] RFC 5518は、Vouch By Reference（VBR）というメール認証メカニズムに関するものであり、メール送信者の信頼性を確認するために使用されます。このRFCの目的は、メールの送信者の信頼性を向上させ、スパムやフィッシングなどの悪意のあるメールを減らすことです。
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.
Copyright（c）2009 IETF Trustおよび文書著者として特定された人。全著作権所有。
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 Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。
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.
このドキュメントには、2008年11月10日までに公開または公開されたIETFドキュメントまたはIETFの貢献からの資料が含まれている場合があります。IETF標準プロセスの外。そのような資料の著作権を制御する人から適切なライセンスを取得しないと、このドキュメントはIETF標準プロセスの外側に変更されない場合があり、その派生作業は、ITF標準プロセスの外側で作成されない場合があります。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 2番目の部分では、受信者は、受信したメッセージに関連付けられているIDに関する情報を取得するために、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：」を使用して認定証明を提供します。このヘッダーフィールドには、送信者が請求するサービスの名前と、メッセージの特定のタイプのコンテンツが含まれています。「somebank.exampleからのトランザクションメール」や「Anotherbank.exampleからのすべてのメール」など、保証するメッセージコンテンツの種類のリストで、質問したサードパーティのDNSベースの認定サービスが応答できます。
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操作を成功させるための前提条件は、メッセージに関連付けられたIDの検証です。VBRは、識別子としてドメイン名の使用に基づいており、ドメイン名を取得および検証する複数の方法を許可します。検証方法は、以下の「有用なドメイン名の取得」セクションで説明されています。
The sender performs two steps:
送信者は2つのステップを実行します。
1. Adds a VBR-Info header field to its message
1. VBR-INFOヘッダーフィールドをメッセージに追加します
2. Protects the message, as appropriate
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.
受信者がバウチングの結果を使用して着信電子メールでスパムスコアを調整した場合、その受信者はバウチングサービスに多数の運用上の信頼とパワーを配置しています。したがって、受信者はそのようなサービスを注意して選択する必要があります。さらに、そのような受信者は、スパムスコアを設定するための単一の障害を回避するために、複数のバウチングサービスを選択したい場合があります。
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].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[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を使用して、これらの手順に従って認証ステータスを決定します。
1. Extracts the domain to certify and the type of message content
1. 認証するドメインを抽出し、メッセージコンテンツの種類を抽出します
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>;
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.
ここで、<domain>はバウチングが提供されるドメインであり、<type-string>はメッセージのコンテンツタイプであり、<certifier-list>は、送信者がこの特定のものを保証する認定プロバイダーのドメイン名のリストですメッセージ。<certifier-list>の構造は、それぞれの間にコロン（ "："）を持つ1つ以上のドメイン名です。<domain>、<type-string>、および<certifier-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.
たとえば、署名者には、取引の通知を保証することをいとわない2つの会社があると仮定します：Certifier-A.exampleおよびCertifier-b.example。署名者は、その発信メッセージのヘッダーに以下を追加します。
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では、アルファと数字のトークンは[RFC5234]からインポートされ、FWSおよびドメイン名のトークンは[RFC4871]からインポートされます。
vbr-info-header = "VBR-Info:" 1*([FWS] element [FWS] ";")
element = md-element / mc-element / mv-element
md-element = "md=" [FWS] domain-name
md-element = "md =" [fws] domain-name
mc-element = "mc=" [FWS] type-string
type-string = "all" / "list" / "transaction"
mv-element = "mv=" [FWS] certifier-list
certifier-list = domain-name *(":" domain-name)
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):
受信者が認証請求が有効かどうかを確認する場合、メッセージのリストを信頼するサービスのリストと比較します。2つのリストの交差点にある各サービスについて、次のDNSラベルで構成される（左から右）で構成されるドメイン名を検索するドメイン名をマーシャリングします。
o the domain name that asserts it can be certified
o 認定できると主張するドメイン名
o _vouch (a string literal)
o _vouch（文字列リテラル）
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レコードに表示されている場合、認証者はメッセージの有効性を保証しています。もちろん、受信者は信頼していないサービスを無視する必要があります。そうでなければ、悪い俳優は、それがそれ自体を保証できるように設定した権威を追加することができます。
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.
ラベル_vouchの名前が選択されました。なぜなら、ラベルの1つとしてそれを含むドメイン名は有効なホスト名ではないためです。有効なホスト名と偶然のオーバーラップはありません。さらに、_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からの返信がこれらのマーシャリングされたテキストブロックをすべて1つに組み立てる必要があるコードは、構文検証が行われる前に1つに組み立てる必要があります。
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.
Verifiersは、TXTレコードがスペースで区切られた小文字の文字列で構成されていることを確認し、その形式ではないレコードを破棄する必要があります。これは、DNSワイルドカードから統合された誤解された記録と無関係なレコードに対して防御されます。
The VBR record MUST have only one TXT record.
VBRレコードには、1つの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つのタイプの送信者のメール（トランザクションメールなど）を保証する場合がありますが、別のタイプ（広告など）ではありません。誰もその広告メールを認証することができないが、そのトランザクションメールの認証者を持っている送信者は、それをトランザクションと誤って誤解しようと誘惑されるかもしれません。MC =要素は、監査証跡を作成して、証明書者がそのような不正行為をキャッチし、トランザクションメールの認定を削除できるようにします。
Three types of content are defined.
3種類のコンテンツが定義されています。
"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.
「List」は、各メールが同一であるか、他と非常に似ている複数の受信者に送信される電子メールのカテゴリです。
"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）を使用する必要があります（ドメインキー、送信者ポリシーフレームワーク（SPF）、またはsenderIDを使用して）送信者に説明責任のあるIDを提供する必要があります。
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.
DomainKeysは、メール（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.
o DKIMが検証メカニズムである場合、VBRのMD =は、DKIMシグネチャーヘッダーフィールドの1つから取られたドメイン名と一致する必要があります。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ヘッダーフィールドは、DKIMによって保護されたヘッダーフィールドのセットに含めて、悪意のあるパーティーがVBR-INFOヘッダーフィールドの内容を変更したり、偽のVBR-INFOヘッダーフィールドを追加したりするのを防ぐ必要があります。
o The VBR-Info header field SHOULD be added in the header immediately below the corresponding DKIM-Signature header field.
o VBR-INFOヘッダーフィールドは、対応する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.
DomainKeys（DK）、[RFC4870]は、ドメイン名をD = d = tag of the domainkey-signatureヘッダーフィールドに関連付けることにより、説明責任のあるアイデンティティを定義します。これは、協会がパブリックキーベースの認証メカニズムを通じて有効であることを保証します。
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.
o DomainKeysが検証メカニズムである場合、VBRのMD =は、DomainKey-Signature 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ヘッダーフィールドは、DKによって保護されているヘッダーフィールドのセットに含めて、悪意のあるパーティーがVBR-INFOヘッダーフィールドの内容を変更したり、偽のVBR-INFOヘッダーフィールドを追加したりするのを防ぐ必要があります。
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.
Sender Policy Framework（SPF）、[RFC4408]は、既存のメッセージアドレスを使用してDNSを照会してSPF使用に有効かどうかを発見することにより、説明責任のあるIDを定義します。
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メールコマンドの最初のパラメーターである<Reverse-Path>アドレスのドメイン名と同じ値でなければなりません。
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を照会して、送信者IDの使用に有効かどうかを発見します。
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.
ドメインは、送信者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-INFO
Applicable protocol: mail
該当するプロトコル：メール
Status: standard
ステータス：標準
Author/Change controller: IETF
著者/変更コントローラー：IETF
Specification document(s): RFC 5518
仕様文書：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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、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] Crocker、D。およびP. Overell、「構文仕様のためのBNFの増強」、STD 68、RFC 5234、2008年1月。
[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, October 2008.
[RFC5322] Resnick、P.、ed。、「インターネットメッセージ形式」、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] Andrews、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.、Nottingham、M。、およびJ. Mogul、「メッセージヘッダーフィールドの登録手順」、BCP 90、RFC 3864、2004年9月。
[RFC4406] Lyon, J. and M. Wong, "Sender ID: Authenticating E-Mail", RFC 4406, April 2006.
[RFC4406] Lyon、J。およびM. Wong、「送信者ID：認証電子メール」、RFC 4406、2006年4月。
[RFC4407] Lyon, J., "Purported Responsible Address in E-Mail Messages", RFC 4407, April 2006.
[RFC4407] Lyon、J。、「電子メールメッセージの責任ある住所」、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.
[RFC4408] Wong、M。およびW. Schlitt、「送信者ポリシーフレームワーク（SPF）電子メールでのドメインの使用を承認するための、バージョン1」、RFC 4408、2006年4月。
[RFC4870] Delany, M., "Domain-Based Email Authentication Using Public Keys Advertised in the DNS (DomainKeys)", RFC 4870, May 2007.
[RFC4870] Delany、M。、「DNS（domainkeys）で宣伝されているパブリックキーを使用したドメインベースの電子メール認証」、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] Allman、E.、Callas、J.、Delany、M.、Libbey、M.、Fenton、J.、およびM. Thomas、「Domainkeys Idified Mail（DKIM）署名」、RFC 4871、2007年5月。
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.
ドメイン保証評議会の多くのメンバーは、プロトコルの設計とこのドキュメントの文言に貢献しました。さらに、ジム・フェントンとマレー・クチェハウィーから建設的な提案が受けられました。
Authors' Addresses
著者のアドレス
Paul Hoffman Domain Assurance Council
ポールホフマンドメイン保証評議会
EMail: paul.hoffman@domain-assurance.org
John Levine Domain Assurance Council
ジョン・レバイン・ドメイン保証評議会
EMail: john.levine@domain-assurance.org
Arvel Hathcock Alt-N Technologies
Arvel Hathcock Alt-N Technologies
EMail: arvel.hathcock@altn.com