Network Working Group P. Hoffman
Request for Comments: 5518 J. Levine
Category: Standards Track Domain Assurance Council
A. Hathcock
Alt-N Technologies
April 2009
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和IETF信托在本文件出版之日生效的与IETF文件有关的法律规定的约束(http://trustee.ietf.org/license-info). 请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。
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标准流程之外修改此类材料的权利。在未从控制此类材料版权的人员处获得充分许可的情况下，不得在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
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.
引用验证（Vouch By Reference，简称VBR）是一种向电子邮件中添加第三方认证的协议。具体而言，VBR允许独立第三方证明与收到的邮件相关的域名的所有者。VBR可以在电子邮件传输路径上的任何位置，由处理服务内的任何功能接收模块或最终用户软件执行。
VBR accomplishes this with a two-part protocol:
VBR通过两部分协议实现这一点：
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 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.translate error, please retry
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的第三方认证服务可以用它将提供担保的消息内容类型列表进行响应，例如“来自某个银行的事务性邮件。示例”和/或“来自另一个银行的所有邮件。示例”。
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:
发送方执行两个步骤：
1. Adds a VBR-Info header field to its message
1. 将VBR信息标题字段添加到其消息中
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].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[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信息标题字段。这意味着，在RFC 5322的术语中，VBR信息是一个“跟踪头字段”，应添加在头字段的顶部。
The content of the VBR-Info header field is a list of three elements:
VBR信息标题字段的内容是由三个元素组成的列表：
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. 使用本文所述的一个或多个身份验证机制验证该域的合法使用
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信息标题字段的格式如下：
VBR-Info: md=<domain>; mc=<type-string>; mv=<certifier-list>;
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>的结构是一个或多个域名，每个域名之间带有冒号（“：”）。<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.
例如，假设签名者有两家公司愿意为其交易通知提供担保：certifier-a.example和certifier-b.example。签名者会将以下内容添加到其传出消息的标题中。
VBR-Info: md=somebank.example; mc=transaction;
mv=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标头中的所有三个标头参数都是必需的。特别是，md=domain没有默认值。
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信息头字段中的大小写字符是等效的，尽管按惯例内容都是小写的。为了向上兼容，验证器必须以任何顺序接受字段，并且应该忽略此处定义的三个字段以外的任何字段。
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
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]域名
mc-element = "mc=" [FWS] type-string
type-string = "all" / "list" / "transaction"
mc-element = "mc=" [FWS] type-string
type-string = "all" / "list" / "transaction"
mv-element = "mv=" [FWS] certifier-list
certifier-list = domain-name *(":" domain-name)
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):
当收件人希望检查认证声明是否有效时，它会将邮件中的列表与其信任的服务列表进行比较。对于两个列表交叉点上的每个服务，它会封送一个域名进行查找，该域名由以下DNS标签组成（从左到右）：
o the domain name that asserts it can be certified
o 声明它可以被认证的域名
o _vouch (a string literal)
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
例如：某某银行，例如：某某银行，例如：某某银行，例如：某某银行，例如：某某银行，例如：某某银行，例如：某某银行，例如：某某银行，例如：某某银行，例如：某某银行，例如：某某银行，例如：某某银行，例如：某某银行，例如：某某银行
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
在上面的示例中，接收者检查两个证明人是否为“交易”邮件提供凭证。这将由以下类型之一表示：“all”或“transaction”（“all”表示认证者为相关域发送的所有消息类型提供担保）。如果这些类型中的任何一种出现在
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的名称是因为将其作为其标签之一的任何域名都不能是有效的主机名。不会与有效主机名发生任何意外重叠。此外，可以安全地创建一个规则，该规则规定来自包含担保标签的域名的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
请注意，mc=元素中的值是自断言的。此元素用于审核。可能会有这样的情况，证明人会证明发件人的邮件是一种类型（如事务性邮件），而不是另一种类型（如广告）。无法让任何人证明其广告邮件，但其交易邮件有证明人的发件人可能会受到欺骗和欺诈的诱惑
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=元素创建一个审计跟踪，以帮助他们的认证者捕获此类欺骗，并允许删除事务邮件的认证。
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）（并且可以使用域密钥、发件人策略框架（SPF）或发件人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 Identified Mail（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签名头字段之一的域名匹配。如果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信息标题字段应添加到标题中，紧靠相应DKIM签名标题字段的下方。
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]通过将域名与DomainKey签名头字段的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.
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签名标头字段的正下方。
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]通过使用现有消息地址并查询DNS以发现其是否适用于SPF使用来定义可问责标识。
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]）的现有消息地址并查询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信息头字段，如下所示：
Header field name: VBR-Info
标题字段名称：VBR信息
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:ABNF”，STD 68，RFC 5234，2008年1月。
[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, October 2008.
[RFC5322]Resnick，P.，Ed.“互联网信息格式”，RFC5222008年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中公布的公钥进行基于域的电子邮件身份验证（域密钥）”，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，“域密钥识别邮件（DKIM）签名”，RFC 48712007年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.
域名保证委员会的许多成员对协议的设计和本文件的措辞做出了贡献。此外，Jim Fenton和Murray Kucherawy还提出了建设性建议。
Authors' Addresses
作者地址
Paul Hoffman Domain Assurance Council
保罗霍夫曼领域保证委员会
EMail: paul.hoffman@domain-assurance.org
EMail: paul.hoffman@domain-assurance.org
John Levine Domain Assurance Council
约翰·莱文领域保证委员会
EMail: john.levine@domain-assurance.org
EMail: john.levine@domain-assurance.org
Arvel Hathcock Alt-N Technologies
Arvel Hatchock Alt-N技术公司
EMail: arvel.hathcock@altn.com
EMail: arvel.hathcock@altn.com