Network Working Group J. Lyon
Request for Comments: 4406 Microsoft Corp.
Category: Experimental M. Wong
pobox.com
April 2006
Network Working Group J. Lyon
Request for Comments: 4406 Microsoft Corp.
Category: Experimental M. Wong
pobox.com
April 2006
Sender ID: Authenticating E-Mail
发件人ID:正在验证电子邮件
Status of This Memo
关于下段备忘
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
这份备忘录为互联网社区定义了一个实验性协议。它没有规定任何类型的互联网标准。要求进行讨论并提出改进建议。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（2006年）。
IESG Note
IESG注释
The following documents (RFC 4405, RFC 4406, RFC 4407, and RFC 4408) are published simultaneously as Experimental RFCs, although there is no general technical consensus and efforts to reconcile the two approaches have failed. As such, these documents have not received full IETF review and are published "AS-IS" to document the different approaches as they were considered in the MARID working group.
以下文件（RFC 4405、RFC 4406、RFC 4407和RFC 4408）作为实验性RFC同时发布，尽管没有普遍的技术共识，协调这两种方法的努力也失败了。因此，这些文件没有得到IETF的全面审查，而是按“原样”发布，以记录MARID工作组中考虑的不同方法。
The IESG takes no position about which approach is to be preferred and cautions the reader that there are serious open issues for each approach and concerns about using them in tandem. The IESG believes that documenting the different approaches does less harm than not documenting them.
IESG对首选哪种方法不持任何立场，并提醒读者，每种方法都存在严重的开放性问题，并关注如何同时使用它们。IESG认为，记录不同的方法比不记录它们危害更小。
Note that the Sender ID experiment may use DNS records that may have been created for the current SPF experiment or earlier versions in this set of experiments. Depending on the content of the record, this may mean that Sender-ID heuristics would be applied incorrectly to a message. Depending on the actions associated by the recipient with those heuristics, the message may not be delivered or may be discarded on receipt.
请注意，发送方ID实验可能使用为当前SPF实验或这组实验中的早期版本创建的DNS记录。根据记录的内容，这可能意味着发件人ID试探法将错误地应用于消息。根据接收者与这些试探法相关联的操作，消息可能不会被传递，也可能在接收时被丢弃。
Participants relying on Sender ID experiment DNS records are warned that they may lose valid messages in this set of circumstances. Participants publishing SPF experiment DNS records should consider
依赖发送方ID实验DNS记录的参与者将收到警告，在这种情况下，他们可能会丢失有效消息。参与者发布SPF实验DNS记录应考虑
the advice given in section 3.4 of RFC 4406 and may wish to publish both v=spf1 and spf2.0 records to avoid the conflict.
RFC 4406第3.4节中给出的建议，可能希望发布v=spf1和spf2.0记录以避免冲突。
Participants in the Sender-ID experiment need to be aware that the way Resent-* header fields are used will result in failure to receive legitimate email when interacting with standards-compliant systems (specifically automatic forwarders which comply with the standards by not adding Resent-* headers, and systems which comply with RFC 822 but have not yet implemented RFC 2822 Resent-* semantics). It would be inappropriate to advance Sender-ID on the standards track without resolving this interoperability problem.
发送者ID实验的参与者需要意识到，当与符合标准的系统交互时，使用Resent-*头字段的方式将导致无法接收合法电子邮件（特别是通过不添加RENT-*头来符合标准的自动转发器，以及符合RFC 822但尚未实现RFC 2822 RENT-*语义的系统）。在不解决此互操作性问题的情况下，在标准轨道上提前发送ID是不合适的。
The community is invited to observe the success or failure of the two approaches during the two years following publication, in order that a community consensus can be reached in the future.
请社区在出版后的两年内观察这两种方法的成功或失败，以便将来能够达成社区共识。
Abstract
摘要
Internet mail suffers from the fact that much unwanted mail is sent using spoofed addresses -- "spoofed" in this case means that the address is used without the permission of the domain owner. This document describes a family of tests by which SMTP servers can determine whether an e-mail address in a received message was used with the permission of the owner of the domain contained in that e-mail address.
Internet邮件的问题在于，许多不需要的邮件都是使用伪造的地址发送的。在本例中，“伪造”意味着该地址未经域所有者的许可而被使用。本文档介绍了一系列测试，通过这些测试，SMTP服务器可以确定所接收邮件中的电子邮件地址是否在该电子邮件地址中包含的域的所有者的许可下使用。
Table of Contents
目录
1. Introduction ....................................................3
1.1. Conventions Used in This Document ..........................4
2. Problem Statement ...............................................4
3. SPF 2.0 Records .................................................5
3.1. Version and Scope ..........................................5
3.1.1. Minor Version .......................................6
3.2. Multiple Records ...........................................6
3.3. Positional Modifiers .......................................7
3.4. Compatibility ..............................................8
4. Decision Model ..................................................8
4.1. Arguments ..................................................9
4.2. Results ....................................................9
4.3. Record Lookup ..............................................9
4.4. Record Selection ...........................................9
5. Actions Based on the Decision ..................................10
5.1. Neutral, None, SoftFail, or PermError .....................11
5.2. Pass ......................................................11
5.3. Fail ......................................................11
5.4. TempError .................................................11
6. Security Considerations ........................................11
6.1. DNS Attacks ...............................................12
6.2. TCP Attacks ...............................................12
6.3. Forged Sender Attacks .....................................12
6.4. Address Space Hijacking ...................................12
6.5. Malicious DNS Attacks on Third Parties ....................13
7. Implementation Guidance ........................................13
7.1. Simple E-Mailers ..........................................14
7.2. E-Mail Forwarders .........................................14
7.3. Mailing List Servers ......................................15
7.4. Third-Party Mailers .......................................15
7.5. MUA Implementers ..........................................15
8. Acknowledgements ...............................................16
9. References .....................................................17
9.1. Normative References ......................................17
9.2. Informative References ....................................17
1. Introduction ....................................................3
1.1. Conventions Used in This Document ..........................4
2. Problem Statement ...............................................4
3. SPF 2.0 Records .................................................5
3.1. Version and Scope ..........................................5
3.1.1. Minor Version .......................................6
3.2. Multiple Records ...........................................6
3.3. Positional Modifiers .......................................7
3.4. Compatibility ..............................................8
4. Decision Model ..................................................8
4.1. Arguments ..................................................9
4.2. Results ....................................................9
4.3. Record Lookup ..............................................9
4.4. Record Selection ...........................................9
5. Actions Based on the Decision ..................................10
5.1. Neutral, None, SoftFail, or PermError .....................11
5.2. Pass ......................................................11
5.3. Fail ......................................................11
5.4. TempError .................................................11
6. Security Considerations ........................................11
6.1. DNS Attacks ...............................................12
6.2. TCP Attacks ...............................................12
6.3. Forged Sender Attacks .....................................12
6.4. Address Space Hijacking ...................................12
6.5. Malicious DNS Attacks on Third Parties ....................13
7. Implementation Guidance ........................................13
7.1. Simple E-Mailers ..........................................14
7.2. E-Mail Forwarders .........................................14
7.3. Mailing List Servers ......................................15
7.4. Third-Party Mailers .......................................15
7.5. MUA Implementers ..........................................15
8. Acknowledgements ...............................................16
9. References .....................................................17
9.1. Normative References ......................................17
9.2. Informative References ....................................17
Today, a huge majority of unwanted e-mail contains headers that lie about the origin of the mail. This is true of most spam and substantially all of the virus e-mail that is sent.
如今，绝大多数不需要的电子邮件都包含关于邮件来源的标题。大多数垃圾邮件和发送的几乎所有病毒电子邮件都是如此。
This document describes a mechanism such that receiving Mail Transfer Agents (MTAs), Mail Delivery Agents (MDAs), and/or Mail User Agents (MUAs) can recognize mail in the above category and take appropriate action. For example, an MTA might refuse to accept a message, an MDA
本文档介绍了一种机制，使接收邮件传输代理（MTA）、邮件传递代理（MDA）和/或邮件用户代理（MUA）可以识别上述类别的邮件并采取适当的操作。例如，MTA可能拒绝接受消息，即MDA
might discard a message rather than placing it into a mailbox, and an MUA might render that message in some distinctive fashion.
可能会丢弃邮件而不是将其放入邮箱，MUA可能会以某种独特的方式呈现该邮件。
In order to avoid further fragmentation of the Internet e-mail system, it is desirable that the Internet community as a whole come to a consensus as to what mail senders should do to make their mail appear non-spoofed, and how mail receivers should determine whether mail is spoofed. On the other hand, it is not necessary to reach a consensus regarding the actions that various parties take once a message has been determined to be spoofed. This can be done unilaterally -- one agent might decide to discard a spoofed message whereas another decides to add a disclaimer.
为了避免互联网电子邮件系统进一步分裂，希望整个互联网社区就邮件发送者应如何使其邮件看起来不受欺骗以及邮件接收者应如何确定邮件是否受到欺骗达成共识。另一方面，一旦确定某一信息被欺骗，就没有必要就各方采取的行动达成共识。这可以单方完成——一个代理可能决定丢弃伪造的消息，而另一个代理决定添加免责声明。
This document defines a pair of closely-related tests. One validates a message's Purported Responsible Address (PRA) as defined in [RFC4407]. The other validates a message's Reverse-Path (also known as MAIL-FROM address) as defined in [RFC4408].
本文件定义了一对密切相关的测试。验证[RFC4407]中定义的消息的声称责任地址（PRA）。另一个验证[RFC4408]中定义的消息反向路径（也称为邮件发送地址）。
An e-mail sender complying with this specification SHOULD publish information for both tests, and SHOULD arrange that any mail that is sent will pass both tests. An e-mail receiver complying with this specification SHOULD perform at least one of these tests.
符合此规范的电子邮件发件人应发布这两项测试的信息，并应安排发送的任何邮件都将通过这两项测试。符合本规范的电子邮件接收器应至少执行其中一项测试。
In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中的说明进行解释。
Briefly stated, the mechanisms of this document allow one to answer the following question:
简单地说，本文件的机制允许我们回答以下问题：
When a message is transferred via SMTP between two unrelated parties, does the SMTP client host have permission to send mail on behalf of a mailbox referenced by the message?
当邮件在两个不相关的方之间通过SMTP传输时，SMTP客户端主机是否有权代表邮件引用的邮箱发送邮件？
As seen from the question, this mechanism applies to unrelated parties: It is useful at the point where a message passes across the Internet from one organization to another. It is beyond the scope of this document to describe authentication mechanisms that can be deployed within an organization.
从问题中可以看出，这种机制适用于不相关方：在信息通过互联网从一个组织传递到另一个组织时，它非常有用。描述可在组织内部署的身份验证机制超出了本文档的范围。
The PRA version of the test seeks to authenticate the mailbox associated with the most recent introduction of a message into the mail delivery system. In simple cases, this is who the mail is from. However, in the case of a third-party mailer, a forwarder, or a
PRA版本的测试旨在验证与邮件传递系统中最近引入的邮件相关的邮箱。在简单的情况下，这就是邮件的来源。但是，如果是第三方邮寄者、转发商或
mailing list server, the address being authenticated is that of the third party, the forwarder, or the mailing list.
邮件列表服务器，正在验证的地址是第三方、转发器或邮件列表的地址。
On the other hand, the MAIL-FROM version of the test seeks to authenticate the mailbox that would receive Delivery Status Notifications (DSNs, or bounces) for the message. In simple cases, this too is who the mail is from. However, third-party mailers, forwarders, and mailing list servers MUST specify an address under their control, and SHOULD arrange that DSNs received at this address are forwarded to the original bounce address.
另一方面，MAIL-FROM版本的测试试图对接收邮件传递状态通知（DSN或反弹）的邮箱进行身份验证。在简单的情况下，这也是邮件的来源。但是，第三方邮件服务器、转发器和邮件列表服务器必须指定其控制下的地址，并应安排将在此地址收到的DSN转发到原始跳转地址。
In both cases, the domain associated with an e-mail address is what is authenticated; no attempt is made to authenticate the local-part. A domain owner gets to determine which SMTP clients speak on behalf of addresses within the domain; a responsible domain owner should not authorize SMTP clients that will lie about local parts.
在这两种情况下，与电子邮件地址关联的域都是经过身份验证的域；未尝试对本地部件进行身份验证。域所有者可以确定哪些SMTP客户端代表域内的地址说话；负责任的域所有者不应授权将谎报本地部分的SMTP客户端。
In the long run, once the domain of the sender is authenticated, it will be possible to use that domain as part of a mechanism to determine the likelihood that a given message is spam, using, for example, reputation and accreditation services. (These services are not the subject of the present mechanism, but it should enable them.)
从长远来看，一旦发件人的域经过身份验证，就可以使用该域作为确定给定邮件是否为垃圾邮件的机制的一部分，例如使用信誉和认证服务。（这些服务不属于当前机制的主题，但应使其成为可能。）
Domains declare which hosts are and are not authorized to transmit e-mail messages on their behalf by publishing Sender Policy Framework (SPF) records in the Domain Name System. [RFC4408] defines a format for these records identified by the version prefix "v=spf1". This section defines an amended format, identified by the version prefix "spf2.0", that allows sending domains to explicitly specify how their records should be interpreted, and provides for additional extensibility. Sending domains MAY publish either or both formats.
域通过在域名系统中发布发件人策略框架（SPF）记录来声明哪些主机被授权或未被授权代表其传输电子邮件。[RFC4408]定义了由版本前缀“v=spf1”标识的这些记录的格式。本节定义了一种修订的格式，由版本前缀“spf2.0”标识，该格式允许发送域明确指定其记录的解释方式，并提供了额外的扩展性。发送域可以发布一种或两种格式。
Since the two formats are identical in most respects, the following subsections define the "spf2.0" format relative to [RFC4408].
由于这两种格式在大多数方面是相同的，以下小节定义了与[RFC4408]相关的“spf2.0”格式。
Under Sender ID, receiving domains may perform a check of either the PRA identity or the MAIL-FROM identity. Sending domains therefore require a method for declaring whether their published list of authorized outbound e-mail servers can be used for the PRA check, the MAIL-FROM check, or both.
在“发件人ID”下，接收域可以执行PRA身份或邮件发件人身份的检查。因此，发送域需要一种方法来声明其已发布的授权出站电子邮件服务器列表是否可用于PRA检查、邮件发件人检查或两者。
This section replaces the definition of the version identifier in Section 4.5 of [RFC4408] and adds the concept of SPF record scopes.
本节取代了[RFC4408]第4.5节中版本标识符的定义，并添加了SPF记录范围的概念。
SPF records begin with a version identifier and may also include a scope:
SPF记录以版本标识符开头，还可能包括范围：
record = version terms *SP
version = "v=spf1" | ( "spf2." ver-minor scope)
ver-minor = 1*DIGIT
scope = "/" scope-id *( "," scope-id )
scope-id = "mfrom" / "pra" / name
record = version terms *SP
version = "v=spf1" | ( "spf2." ver-minor scope)
ver-minor = 1*DIGIT
scope = "/" scope-id *( "," scope-id )
scope-id = "mfrom" / "pra" / name
For example, the SPF record
例如，SPF记录
spf2.0/mfrom,pra +mx +ip4:192.168.0.100 -all
spf2.0/mfrom,pra +mx +ip4:192.168.0.100 -all
defines an SPF record that can be used for either MAIL FROM or PRA checks.
定义可用于邮件发件人或PRA检查的SPF记录。
This document only defines the existence of two scopes: "mfrom" and "pra". The details of these two scopes are defined in other documents: "mfrom" is defined in [RFC4408]; "pra" is defined in [RFC4407].
本文件仅定义了两个范围的存在：“mfrom”和“pra”。这两个范围的细节在其他文件中有定义：“mfrom”在[RFC4408]中有定义；[RFC4407]中定义了“pra”。
Other scopes may be defined by future documents only. There is no registry for scopes. A scope definition must define what it identifies as the sending mailbox for a message, how to extract that information from a message, how to determine the initial arguments for the check_host() function, and what the compliant responses to the result are. This ensures that domains with published records and mail receiver agree on the semantics of the scope.
其他范围只能由将来的文档定义。没有作用域的注册表。作用域定义必须定义它标识为消息的发送邮箱的内容、如何从消息中提取该信息、如何确定check_host（）函数的初始参数以及对结果的符合性响应。这确保具有已发布记录的域和邮件接收者在作用域的语义上达成一致。
A compliant domain SHOULD publish authorizations for every defined scope.
合规域应为每个定义的范围发布授权。
All published records that use the "spf2" version identifier MUST start with "spf2.0". This document only specifies records with a minor version of "0".
所有使用“spf2”版本标识符的已发布记录必须以“spf2.0”开头。本文档仅指定具有次要版本“0”的记录。
Future versions of this document may define other minor versions to be used.
本文件的未来版本可能会定义要使用的其他次要版本。
A domain MAY publish multiple SPF 2.0 records, provided that each scope appears in at most one SPF 2.0 record. In addition, a domain MAY also publish an SPF record that uses the "v=spf1" version identifier defined in [RFC4408]. The selection rules in Section 4.4 define the precedence of these records.
一个域可以发布多个SPF 2.0记录，前提是每个作用域最多出现在一个SPF 2.0记录中。此外，域还可以发布使用[RFC4408]中定义的“v=spf1”版本标识符的SPF记录。第4.4节中的选择规则定义了这些记录的优先级。
This section replaces Section 4.6.3 of [RFC4408] and adds the concept of positional modifiers.
本节取代[RFC4408]的第4.6.3节，并添加了位置修改器的概念。
Modifiers are key/value pairs that affect the evaluation of the check_host() function.
修饰符是影响check_host（）函数计算的键/值对。
Modifiers are either global or positional:
修改器可以是全局的，也可以是位置的：
Global modifiers MAY appear anywhere in the record, but SHOULD appear at the end, after all mechanisms and positional modifiers.
全局修改器可以出现在记录中的任何位置，但应该出现在所有机构和位置修改器之后的末尾。
Positional modifiers apply only to the mechanism they follow. It is a syntax error for a positional modifier to appear before the first mechanism.
位置修改器仅适用于它们所遵循的机构。位置修改器出现在第一个机构之前是一个语法错误。
Modifiers of either type are also either singular or multiple:
这两种类型的修饰符也可以是单数或多个：
Singular modifiers may appear only once in the record if they are global, or once after each mechanism if they are positional.
如果是全局的，则单个修改器只能在记录中显示一次，如果是位置的，则在每个机构之后显示一次。
Multiple modifiers may appear multiple times in the record if they are global, or multiple times after each mechanism if they are positional.
如果多个修改器是全局修改器，则它们可能会在记录中出现多次，如果它们是位置修改器，则可能会在每个机构之后出现多次。
A modifier is not allowed to be defined as both global and positional.
不允许将修改器同时定义为全局修改器和位置修改器。
The modifiers "redirect" and "exp" described in Section 6 of [RFC4408] are global and singular.
[RFC4408]第6节中描述的修饰符“redirect”和“exp”是全局的和单数的。
Ordering of modifiers does not matter, except that:
修改器的顺序无关紧要，除非：
1. positional modifiers must appear after the mechanism they affect and before any subsequent mechanisms; and
1. 位置修改器必须出现在其影响的机构之后和任何后续机构之前；和
2. when a multiple modifier appears more than one time, the ordering of the appearances may be significant to the modifier.
2. 当多个修改器多次出现时，外观的顺序可能对修改器很重要。
Other than these constraints, implementations MUST treat different orders of modifiers the same. An intended side effect of these rules is that modifiers cannot be defined that modify other modifiers.
除了这些约束之外，实现必须将不同的修饰符顺序视为相同的。这些规则的一个预期副作用是不能定义修改其他修改器的修改器。
These rules allow an implementation to correctly pre-parse a record. Furthermore, they are crafted to allow the parsing algorithm to be stable, even when new modifiers are introduced.
这些规则允许实现正确地预解析记录。此外，即使引入了新的修饰符，它们也可以使解析算法保持稳定。
Modifiers that are unrecognized MUST be ignored. This allows older implementations to handle records with modifiers that were defined after they were written.
必须忽略无法识别的修饰符。这允许较旧的实现使用写入记录后定义的修饰符处理记录。
Domain administrators complying with this specification are required to publish information in DNS regarding their authorized outbound e-mail servers. [RFC4408] describes a format for this information identified by the version prefix "v=spf1". Many domains have published information in DNS using this format. In order to provide compatibility for these domains, Sender ID implementations SHOULD interpret the version prefix "v=spf1" as equivalent to "spf2.0/mfrom,pra", provided no record starting with "spf2.0" exists.
符合此规范的域管理员需要在DNS中发布有关其授权出站电子邮件服务器的信息。[RFC4408]描述了由版本前缀“v=spf1”标识的该信息的格式。许多域已使用此格式在DNS中发布信息。为了提供这些域的兼容性，发送方ID实现应将版本前缀“v=spf1”解释为等同于“spf2.0/mfrom，pra”，前提是不存在以“spf2.0”开头的记录。
Administrators who have already published "v=spf1" records SHOULD review these records to determine whether they are also valid for use with PRA checks. If the information in a "v=spf1" record is not correct for a PRA check, administrators SHOULD publish either an "spf2.0/pra" record with correct information or an "spf2.0/pra ?all" record indicating that the result of a PRA check is explicitly inconclusive.
已发布“v=spf1”记录的管理员应查看这些记录，以确定它们是否也可用于PRA检查。如果“v=spf1”记录中的信息对于PRA检查不正确，管理员应发布包含正确信息的“spf2.0/PRA”记录或“spf2.0/PRA？all”记录，表明PRA检查的结果明显不确定。
Sender ID enables receiving e-mail systems to answer the following question:
发件人ID使接收电子邮件系统能够回答以下问题：
Given an e-mail message, and given an IP address from which it has been (or will be) received, is the SMTP client at that IP address authorized to send that e-mail message?
给定一封电子邮件，并给定一个已接收（或将接收）该电子邮件的IP地址，该IP地址的SMTP客户端是否有权发送该电子邮件？
This question will usually be asked by an SMTP server as part of deciding whether to accept an incoming mail message. However, this question could also be asked later by a different party. An MUA, for example, could use the result of this question to determine how to file or present a message.
SMTP服务器通常会在决定是否接受传入邮件时询问此问题。不过，这个问题稍后也可以由另一方提出。例如，MUA可以使用此问题的结果来确定如何归档或呈现消息。
There are three steps to answering this question:
回答这个问题有三个步骤：
1. From an e-mail message, extract the address to verify. The PRA variant of this test does so as specified in [RFC4407], or alternatively, using the submitter address as specified in [RFC4405]. The MAIL FROM variant of this test does so as specified in [RFC4408].
1. 从电子邮件中提取要验证的地址。本测试的PRA变体按照[RFC4407]中的规定进行，或者使用[RFC4405]中规定的提交者地址。此测试的MAIL FROM变体按照[RFC4408]中的规定执行。
2. Extract the domain part of the address determined in step 1.
2. 提取步骤1中确定的地址的域部分。
3. Call the check_host() function defined in [RFC4408] and modified by the following subsections.
3. 调用[RFC4408]中定义并由以下小节修改的check_host（）函数。
If the Sender ID check is being performed by an MTA as part of receiving an e-mail message, and it cannot determine an address in step 1 above (because the message or address is malformed), then the message SHOULD be rejected with error "550 5.7.1 Missing Purported Responsible Address" or error "550 5.7.1 Missing Reverse-Path address".
如果MTA在接收电子邮件时正在执行发件人ID检查，并且无法在上述步骤1中确定地址（因为邮件或地址格式不正确），则应拒绝该邮件，并出现错误“550 5.7.1缺少声称的责任地址”或错误“550 5.7.1缺少反向路径地址”。
Sender ID modifies the check_host() function by the addition of a scope parameter. Thus, for Sender ID the check_host() function is called passing the following parameters:
Sender ID通过添加范围参数修改check_host（）函数。因此，对于发送方ID，调用check_host（）函数传递以下参数：
a. A scope of "pra" (for the PRA variant of the test), or "mfrom" (for the MAIL FROM variant of the test). b. The IP address (either IPv4 or IPv6) from which the message is being or has been received. c. The domain from step 2 above. d. The address from step 1 above.
a. “pra”（用于测试的pra变体）或“mfrom”（用于测试的邮件变体）的范围。B正在或已从中接收消息的IP地址（IPv4或IPv6）。C上面步骤2中的域。D上面步骤1中的地址。
The result of the check_host() function is one of the values "Neutral", "Pass", "Fail", "SoftFail", "None", "TempError", or "PermError". Section 5 describes how these results are used by MTAs receiving messages. This specification imposes no requirements on parties performing this test in other environments.
check_host（）函数的结果是值“Neutral”、“Pass”、“Fail”、“SoftFail”、“None”、“TempError”或“permeror”之一。第5节介绍接收邮件的MTA如何使用这些结果。本规范对在其他环境中执行此测试的各方没有任何要求。
SPF records are looked up in DNS in accordance with Section 4.4 of [RFC4408].
根据[RFC4408]第4.4节，在DNS中查找SPF记录。
When performing the PRA version of the test, if the DNS query returns "non-existent domain" (RCODE 3), then check_host() exits immediately with the result "Fail".
在执行PRA版本的测试时，如果DNS查询返回“不存在的域”（RCODE 3），则检查_host（）立即退出，结果为“失败”。
This section replaces the record selection steps described in Section 4.5 of [RFC4408].
本节取代[RFC4408]第4.5节中描述的记录选择步骤。
Starting with the set of records that were returned by the lookup, record selection proceeds in these steps:
从查找返回的记录集开始，记录选择按以下步骤进行：
1. If any records of type SPF are in the set, then all records of type TXT are discarded.
1. 如果集合中有SPF类型的任何记录，则TXT类型的所有记录都将被丢弃。
2. Records that do not begin with proper version and scope sections are discarded. The version section for "spf2" records contains a ver-minor field that is for backward-compatible future extensions. This field must be well formed for a record to be retained, but is otherwise ignored.
2. 不以正确版本和范围节开头的记录将被丢弃。“spf2”记录的版本部分包含一个版本次要字段，用于向后兼容的将来扩展。要保留记录，此字段必须格式正确，否则将被忽略。
3. Records that use the "spf2" version identifier and do not have a scope-id that matches <scope> are discarded. Note that this is a complete string match on the scope-id tokens: If <scope> is "pra", then the record starting "spf2.0/mfrom,prattle,fubar" would be discarded, but a record starting "spf2.0/mfrom,pra,fubar" would be retained.
3. 使用“spf2”版本标识符且没有与<scope>匹配的作用域id的记录将被丢弃。请注意，这是范围id标记上的完整字符串匹配：如果<scope>为“pra”，则将丢弃以“spf2.0/mfrom，prattle，fubar”开头的记录，但保留以“spf2.0/mfrom，pra，fubar”开头的记录。
4. If the lookup returned two records, one containing the "v=spf1" version identifier and the other containing the "spf2" version identifier, the "spf2" version takes precedence for the desired scope-id. If the "spf2" record does not contain the desired scope-id, then the "v=spf1" record is selected.
4. 如果查找返回两条记录，一条包含“v=spf1”版本标识符，另一条包含“spf2”版本标识符，“spf2”版本优先于所需的作用域id。如果“spf2”记录不包含所需的作用域id，则选择“v=spf1”记录。
5. If an "spf2" record does not contain the desired scope-id and there is no "v=spf1" record for the domain, then no record is selected.
5. 如果“spf2”记录不包含所需的作用域id，并且域没有“v=spf1”记录，则不会选择任何记录。
After the above steps, there should be one record remaining and evaluation can proceed. If there are two or more records remaining, then check_host() exits immediately with the error "PermError".
完成上述步骤后，应剩余一条记录，并可继续评估。如果还有两条或多条记录，请检查_host（）是否立即退出，并显示错误“PermError”。
If there are no matching records remaining after the initial DNS query or any subsequent optional DNS queries, then check_host() exits immediately with the result "None".
如果在初始DNS查询或任何后续可选DNS查询后没有剩余的匹配记录，则检查_host（）立即退出，结果为“无”。
When the Sender ID test is used by an SMTP server as part of receiving a message, the server should take the actions described by this section.
当SMTP服务器将发件人ID测试用作接收邮件的一部分时，服务器应执行本节所述的操作。
The check_host() function returns one of the following results. See [RFC4408] for the meaning of these results.
函数的作用是：返回以下结果之一。有关这些结果的含义，请参见[RFC4408]。
An SMTP server receiving one of these results SHOULD NOT reject the message for this reason alone, but MAY subject the message to heightened scrutiny by other measures, and MAY reject the message as a result of this heightened scrutiny.
接收到这些结果之一的SMTP服务器不应仅出于此原因拒绝邮件，但可能会通过其他措施对邮件进行更严格的检查，并可能会由于更严格的检查而拒绝邮件。
Such additional security measures MAY take into account that a message for which the result is "SoftFail" is less likely to be authentic than a message for which the result is "Neutral".
此类附加安全措施可考虑结果为“SoftFail”的消息比结果为“中立”的消息更不可能是真实的消息。
An SMTP server receiving this result SHOULD treat the message as authentic. It may accept or reject the message depending on other policies.
收到此结果的SMTP服务器应将邮件视为真实邮件。它可以接受或拒绝消息，具体取决于其他策略。
When performing the Sender ID test during an SMTP transaction, an MTA that chooses to reject a message receiving this result SHOULD reject the message with a "550 5.7.1 Sender ID (xxx) yyy - zzz" SMTP error, where "xxx" is replaced with "PRA" or "MAIL FROM", "yyy" is replaced with the additional reason returned by the check_host() function, and "zzz" is replaced with the explanation string returned by the check_host() function.
在SMTP事务期间执行发件人ID测试时，选择拒绝接收此结果的邮件的MTA应拒绝带有“550 5.7.1发件人ID（xxx）yyy-zzz”SMTP错误的邮件，其中“xxx”替换为“PRA”或“邮件发件人”，“yyy”替换为check_host（）函数返回的其他原因，以及“zzz”替换为check_host（）函数返回的解释字符串。
When performing the Sender ID test after accepting an e-mail message for delivery, an MTA that chooses to reject a message receiving this result SHOULD NOT deliver the message. Instead, it should create a DSN message, consistent with the usual rules for DSN messages.
在接受要传递的电子邮件后执行发件人ID测试时，选择拒绝接收此结果的邮件的MTA不应传递该邮件。相反，它应该创建一条DSN消息，与DSN消息的常规规则一致。
An SMTP server receiving this result MAY reject the message with a "450 4.4.3 Sender ID check is temporarily unavailable" error code. Alternatively, an SMTP server receiving this result MAY accept a message and optionally subject it to heightened scrutiny by other anti-spam measures.
收到此结果的SMTP服务器可能会拒绝包含“450 4.4.3发件人ID检查暂时不可用”错误代码的邮件。或者，接收此结果的SMTP服务器可能会接受邮件，并选择性地接受其他反垃圾邮件措施的严格审查。
This entire document describes a new mechanism for mitigating spoofed e-mail, which is today a pervasive security problem in the Internet.
这篇完整的文档描述了一种新的机制来缓解欺骗电子邮件，这是当今互联网上普遍存在的安全问题。
Assuming that this mechanism is widely deployed, the following sections describe counter attacks that could be used to defeat this mechanism.
假设此机制已广泛部署，以下各节将介绍可用于击败此机制的反击。
The new mechanism is entirely dependent on DNS lookups, and is therefore only as secure as DNS. An attacker bent on spoofing messages could attempt to get his messages accepted by sending forged answers to DNS queries.
新机制完全依赖于DNS查找，因此只与DNS一样安全。致力于欺骗消息的攻击者可以通过向DNS查询发送伪造的答案来尝试接受其消息。
An MTA could largely defeat such an attack by using a properly paranoid DNS resolver. DNS Security (DNSSEC) may ultimately provide a way to completely neutralize this class of attacks.
MTA可以通过使用正确的偏执型DNS解析器在很大程度上击败此类攻击。DNS安全（DNSSEC）可能最终提供一种完全消除此类攻击的方法。
This mechanism is designed to be used in conjunction with SMTP over TCP. A sufficiently resourceful attacker might be able to send TCP packets with forged from-addresses, and thus execute an entire SMTP session that appears to come from somewhere other than its true origin.
此机制旨在与TCP上的SMTP配合使用。足智多谋的攻击者可能会使用伪造的from地址发送TCP数据包，从而执行整个SMTP会话，该会话似乎来自真实来源之外的其他地方。
Such an attack requires guessing what TCP sequence numbers an SMTP server will use. It also requires transmitting completely in the blind -- the attack will be unable to hear any of the server's side of the conversation.
这种攻击需要猜测SMTP服务器将使用的TCP序列号。它还需要完全盲传——攻击将无法听到服务器端的任何对话。
Attacks of this sort can be ameliorated if IP gateways refuse to forward packets when the source address is clearly bogus.
如果IP网关在源地址明显虚假时拒绝转发数据包，则此类攻击可以得到改进。
This mechanism chooses an address to validate either from one of a number of message headers or from the RFC 2821 MAIL command, and then uses that address for validation. A message with a true Resent-From header or Return-Path, but a forged From header, will be accepted. Since many MUAs do not display all of the headers of received messages, the message will appear to be forged when displayed.
此机制从多个消息头或RFC 2821邮件命令中选择要验证的地址，然后使用该地址进行验证。将接受消息头或返回路径为true Recent From，但消息头为伪造From的消息。由于许多MUA不显示接收到的消息的所有标题，因此显示消息时将显示为伪造消息。
In order to neutralize this attack, MUAs will need to start displaying at least the address that was verified. In addition, MTAs could subject messages to heightened scrutiny when the validated address differs from the From header.
为了消除这种攻击，MUA需要至少开始显示已验证的地址。此外，当验证的地址与发件人标头不同时，MTA可能会对邮件进行更严格的检查。
This mechanism assumes the integrity of IP address space for determining whether a given client is authorized to send messages from a given PRA. In addition to the TCP attack given in Section 6.2, a sufficiently resourceful attacker might be able to alter the IP routing structure to permit two-way communication using a
该机制假设IP地址空间的完整性，以确定给定客户机是否有权从给定PRA发送消息。除了第6.2节中给出的TCP攻击外，足智多谋的攻击者还可以更改IP路由结构，以允许使用
specified IP address. It would then be possible to execute an SMTP session that appears to come from an authorized address, without the need to guess TCP sequence numbers or transmit in the blind.
指定的IP地址。这样就可以执行一个看起来来自授权地址的SMTP会话，而无需猜测TCP序列号或进行盲传输。
Such an attack might occur if the attacker obtained access to a router that participates in external BGP routing. Such a router could advertise a more specific route to a rogue SMTP client, temporarily overriding the legitimate owner of the address.
如果攻击者获得了对参与外部BGP路由的路由器的访问权，则可能会发生此类攻击。这样的路由器可以向恶意SMTP客户端公布更具体的路由，临时覆盖地址的合法所有者。
There is class of attacks in which an attacker A can entice a participant P to send a malicious message to a victim V.
有一类攻击，其中攻击者A可以诱使参与者P向受害者V发送恶意消息。
These attacks are undertaken by A citing the address of V in the SMTP MAIL FROM request and then by causing P to generate (or invoke the generation of) a Delivery Status Notification 'bounce' message (RFC3464), which is sent to the victim V.
这些攻击是由A引用SMTP MAIL FROM request中的V地址，然后导致P生成（或调用生成）传递状态通知“bounce”消息（RFC3464）进行的，该消息发送给受害者V。
The attacker relies upon it being common practice to copy the original message into the 'bounce' report, thereby causing the malice to be sent onward to V.
攻击者通常会将原始消息复制到“bounce”报告中，从而将恶意信息发送到V。
This mode of attack has the advantages (to the attacker) of obfuscating the location of the host from which the attack was mounted, and of possibly damaging the reputation of P by making it appear that P originated or was an active participant in the sending of the malicious message.
这种攻击模式的优点是（对攻击者而言）混淆了发起攻击的主机的位置，并且通过使P看起来是发起恶意消息的或是发送恶意消息的积极参与者，可能会损害P的声誉。
In current practice, A causes P to cause the 'bounce' by addressing the original message to a nonexistent recipient.
在当前实践中，A通过将原始消息寻址到不存在的收件人，使P引起“反弹”。
Sender ID enables a new variant of this attack.
发件人ID启用此攻击的新变体。
In this variant, the attacker A sends a message whose PRA (Section 4) is selected by the attacker to be such that, when P undertakes the Sender ID test, a Fail will result (Section 5.3).
在此变体中，攻击者A发送一条消息，其PRA（第4节）由攻击者选择，当P进行发送者ID测试时，将导致失败（第5.3节）。
The message will be rejected (as the attacker intended) and a malicious 'bounce' message may be generated and sent to the victim V.
该消息将被拒绝（如攻击者所愿），并可能生成恶意“反弹”消息并发送给受害者V。
This section describes the actions that certain members of the Internet e-mail ecosystem must take to be compliant with this specification.
本节介绍Internet电子邮件生态系统的某些成员必须采取的操作，以符合本规范。
A domain that injects original e-mail into the Internet, using its own name in From headers, need do nothing to be compliant. However, such domains SHOULD publish records in DNS as defined by [RFC4408] and this specification.
将原始电子邮件注入到Internet的域，在From头中使用自己的名称，不需要做任何事情即可兼容。但是，此类域应在[RFC4408]和本规范定义的DNS中发布记录。
In the majority of cases, the domain's published information will be the same for both the PRA and MAIL FROM variants of this test. In this case, domains SHOULD publish their information using an SPF record with the prefix "v=spf1". Doing so will render their published information usable by the older SPF protocol, too. (See [RFC4408] for information on the SPF protocol.)
在大多数情况下，PRA和来自此测试变体的邮件的域发布信息都是相同的。在这种情况下，域应使用前缀为“v=spf1”的SPF记录发布其信息。这样做也将使它们发布的信息可由较旧的SPF协议使用。（有关SPF协议的信息，请参阅[RFC4408]）
In order to pass the PRA variant of the test, a program that forwards received mail to other addresses MUST add an appropriate header that contains an e-mail address that it is authorized to use. Such programs SHOULD use the Resent-From header for this purpose.
为了通过PRA变体的测试，将收到的邮件转发到其他地址的程序必须添加一个适当的头，该头包含一个它被授权使用的电子邮件地址。为此，此类程序应使用“重新发送自”标题。
In order to pass the MAIL FROM variant of the test, a program that forwards received mail to other addresses MUST alter the MAIL FROM address to an address under its control. Should that address eventually receive a DSN relating to the original message, that DSN SHOULD be forwarded to the original MAIL FROM address. However, if this altered address receives any messages other than DSNs related to the original message, these messages MUST NOT be forwarded to the original MAIL FROM address; they SHOULD be refused during an SMTP transaction.
为了通过测试的MAIL FROM变体，将收到的邮件转发到其他地址的程序必须将MAIL FROM地址更改为其控制的地址。如果该地址最终收到与原始邮件相关的DSN，则该DSN应转发至原始邮件发件人地址。但是，如果此更改的地址收到与原始邮件相关的DSN以外的任何邮件，则不得将这些邮件转发到原始邮件发件人地址；在SMTP事务期间，应拒绝它们。
In addition, e-mail forwarders SHOULD publish Sender ID records for their domains, and SHOULD use MTAs for which the Sender ID check yields a "pass" result.
此外，电子邮件转发器应发布其域的发件人ID记录，并应使用MTA，发件人ID检查将为其生成“通过”结果。
Some of today's forwarders already add an appropriate header (although many of them use Sender rather than Resent-From.) Most of them do not perform the address-rewriting specified above.
今天的一些转发器已经添加了一个适当的头（尽管其中许多转发器使用Sender而不是resentfrom）。大多数转发器不执行上面指定的地址重写。
Note that an e-mail forwarder might receive a single message for two or more recipients, each of whom requests forwarding to a new address. In this case, the forwarder's MTA SHOULD transmit the message to each new recipient individually, with each copy of the message containing a different newly inserted Resent-From header field.
请注意，电子邮件转发器可能会收到两个或多个收件人的单个邮件，每个收件人都请求转发到新地址。在这种情况下，转发器的MTA应将邮件单独发送给每个新收件人，邮件的每个副本都包含不同的新插入的“重新发送自”标题字段。
In order to pass the PRA variant of the test, a mailing list server MUST add an appropriate header that contains an e-mail address that it is authorized to use. Such programs SHOULD use the Resent-From header for this purpose.
为了通过PRA变体的测试，邮件列表服务器必须添加一个适当的头，其中包含一个它被授权使用的电子邮件地址。为此，此类程序应使用“重新发送自”标题。
In order to pass the MAIL FROM variant of the test, a mailing list server MUST alter the MAIL FROM address to an address under its control.
为了通过测试变体的邮件，邮件列表服务器必须将邮件从地址更改为其控制的地址。
In addition, mailing list servers SHOULD publish Sender ID records for their domains, and SHOULD use MTAs for which the Sender ID check yields a "pass" result.
此外，邮件列表服务器应发布其域的发件人ID记录，并应使用发件人ID检查产生“通过”结果的MTA。
Most of today's mailing list software already adds an appropriate header (although most of them use Sender rather than Resent-From), and most of them already alter the MAIL FROM address.
今天的大多数邮件列表软件已经添加了一个适当的标题（尽管大多数使用发件人而不是重新发送发件人），并且大多数已经更改了邮件发件人地址。
In order to pass the PRA variant of this test, a program that sends mail on behalf of another user MUST add an appropriate header that contains an e-mail address that it is authorized to use. Such programs SHOULD use the Sender header for this purpose.
为了通过此测试的PRA变体，代表另一个用户发送邮件的程序必须添加一个适当的标头，该标头包含其授权使用的电子邮件地址。这类程序应使用发送方标头来实现此目的。
In order to pass the MAIL FROM variant of this test, a program that sends mail on behalf of another user MUST use a MAIL FROM address that is under its control. Defining what the program does with any mail received at that address is beyond the scope of this document.
为了通过此测试的MAIL FROM变体，代表其他用户发送邮件的程序必须使用其控制下的MAIL FROM地址。定义程序如何处理在该地址收到的任何邮件超出了本文档的范围。
In addition, third-party mailers, servers SHOULD publish Sender ID records for their domains, and SHOULD use MTAs for which the Sender ID check yields a "pass" result.
此外，第三方邮件服务器应发布其域的发件人ID记录，并应使用MTA，发件人ID检查将为其生成“通过”结果。
Many, but not all, of today's third-party mailers are already compliant with the PRA variant of the test. The extent to which mailers are already compliant with the MAIL FROM variant of this test is unknown.
许多，但不是所有，今天的第三方邮件已经符合PRA测试变体。邮寄者在多大程度上已经符合此测试的MAIL FROM变体，这是未知的。
When displaying a received message, an MUA SHOULD display the purported responsible address as defined by this document whenever that address differs from the RFC 2822 From address. This display SHOULD be in addition to the RFC 2822 From address.
当显示收到的消息时，MUA应显示本文件定义的声称负责的地址，只要该地址与RFC 2822的“发件人地址”不同。此显示应该是RFC 2822 From地址之外的显示。
When a received message contains multiple headers that might be used for the purported responsible address determination, an MUA should consider displaying all of them. That is, if a message contains several Resent-From's, a Sender, and a From, an MUA should consider displaying all of them.
当接收到的消息包含多个可能用于所声称的负责地址确定的标头时，MUA应该考虑显示所有这些地址。也就是说，如果消息包含从发件人、发送者和发件人中的几个REST，则MUA应该考虑显示它们中的所有内容。
Sender ID also does not validate the display name that may be transmitted along with an e-mail address. The display name is also vulnerable to spoofing and other forms of attacks. In order to reduce the occurrence and effectiveness of such attacks, MUA implementers should consider methods to safeguard the display name. This could include the following:
发件人ID也不会验证可能随电子邮件地址一起传输的显示名称。显示名称也容易受到欺骗和其他形式的攻击。为了减少这种攻击的发生和有效性，MUA实现者应该考虑保护显示名称的方法。这可能包括以下内容：
* Not presenting the display name to the user at all, or not presenting the display name unless the corresponding e-mail address is listed in the user's address book.
* 根本不向用户显示显示名称，或者除非用户的通讯簿中列出了相应的电子邮件地址，否则不显示名称。
* Treating as suspicious any e-mail where the display name is itself in the form of an e-mail address, especially when it differs from the actual e-mail address in the header.
* 将显示名称本身为电子邮件地址形式的任何电子邮件视为可疑电子邮件，特别是当其与标题中的实际电子邮件地址不同时。
* Making it clear to users that the e-mail address has been checked rather than the display name.
* 向用户表明已选中电子邮件地址而不是显示名称。
This design is based on earlier work published in 2003 in [RMX] and [DMP] drafts (by Hadmut Danisch and Gordon Fecyk, respectively). The idea of using a DNS record to check the legitimacy of an e-mail address traces its ancestry to "Repudiating Mail From" draft by Paul Vixie [Vixie] (based on suggestion by Jim Miller) and to "Domain-Authorized SMTP Mail" draft by David Green [Green], who first introduced this idea on the namedroppers mailing list in 2002.
该设计基于2003年在[RMX]和[DMP]草稿中发表的早期作品（分别由Hadmut Danisch和Gordon Fecyk完成）。使用DNS记录检查电子邮件地址合法性的想法可以追溯到Paul Vixie[Vixie]（基于Jim Miller的建议）的“拒绝邮件”草稿和David Green[Green]的“域授权SMTP邮件”草稿，David Green在2002年首次将此想法引入了NameDropper邮件列表。
The current document borrows heavily from each of the above, as well as earlier versions of [RFC4408] and [CallerID], and incorporates ideas proposed by many members of the MARID working group. The contributions of each of the above are gratefully acknowledged.
目前的文件大量借鉴了上述每一个版本以及[RFC4408]和[CallerID]的早期版本，并纳入了许多MARID工作组成员提出的想法。感谢以上每一位的贡献。
[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月。
[RFC4405] Allman E. and H. Katz, "SMTP Service Extension for Indicating the Responsible Submitter of an E-Mail Message", RFC 4405, April 2006.
[RFC4405]Allman E.和H.Katz，“用于指示电子邮件负责提交者的SMTP服务扩展”，RFC 4405，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", RFC 4408, April 2006.
[RFC4408]Wong，M.和W.Schlitt，“授权在电子邮件中使用域的发件人策略框架（SPF）”，RFC 4408，2006年4月。
[CallerID] Microsoft Corporation, Caller ID for E-Mail Technical
Specification, http://www.microsoft.com/mscorp/safety/
technologies/senderid/resources.mspx
[CallerID] Microsoft Corporation, Caller ID for E-Mail Technical
Specification, http://www.microsoft.com/mscorp/safety/
technologies/senderid/resources.mspx
[DMP] Fecyk, G., "Designated Mailers Protocol", http://www.pan-am.ca/dmp/draft-fecyk-dmp-01.txt, December 2003.
[DMP]Fecyk，G.，“指定邮递员协议”，http://www.pan-am.ca/dmp/draft-fecyk-dmp-01.txt，2003年12月。
[Green] David Green, "Mail-Transmitter RR", http://ops.ietf.org/lists/namedroppers/namedroppers.2002/ msg00656.html, June 2002.
[Green]David Green，“邮件发送器RR”，http://ops.ietf.org/lists/namedroppers/namedroppers.2002/ msg00656.html，2002年6月。
[RMX] H. Danisch, "The RMX DNS RR and method for lightweight
SMTP sender authorization",
http://www.danisch.de/work/security/txt/
draft-danisch-dns-rr-smtp-04.txt
[RMX] H. Danisch, "The RMX DNS RR and method for lightweight
SMTP sender authorization",
http://www.danisch.de/work/security/txt/
draft-danisch-dns-rr-smtp-04.txt
[Vixie] Paul Vixie, "Repudiating Mail From", http://ops.ietf.org/lists/namedroppers/namedroppers.2002/ msg00658.html, June 2002.
[Vixie]Paul Vixie，“拒绝邮件”，http://ops.ietf.org/lists/namedroppers/namedroppers.2002/ msg00658.html，2002年6月。
Authors' Addresses
作者地址
Jim Lyon Microsoft Corporation One Microsoft Way Redmond, WA 98052 USA
Jim Lyon微软公司美国华盛顿州雷德蒙微软大道一号，邮编：98052
EMail: jimlyon@microsoft.com
EMail: jimlyon@microsoft.com
Meng Weng Wong Singapore
孟翁王新加坡
EMail: mengwong@dumbo.pobox.com
EMail: mengwong@dumbo.pobox.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（2006年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY 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.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFC编辑器功能的资金由IETF行政支持活动（IASA）提供。