Network Working Group M. Wong
Request for Comments: 4408 W. Schlitt
Category: Experimental April 2006
Network Working Group M. Wong
Request for Comments: 4408 W. Schlitt
Category: Experimental April 2006
Sender Policy Framework (SPF) for Authorizing Use of Domains in E-Mail, Version 1
用于授权在电子邮件中使用域的发件人策略框架（SPF），版本1
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. aParticipants publishing SPF experiment DNS records should consider 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.
依赖发送方ID实验DNS记录的参与者将收到警告，在这种情况下，他们可能会丢失有效消息。发布SPF实验DNS记录的参与者应该考虑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
摘要
E-mail on the Internet can be forged in a number of ways. In particular, existing protocols place no restriction on what a sending host can use as the reverse-path of a message or the domain given on the SMTP HELO/EHLO commands. This document describes version 1 of the Sender Policy Framework (SPF) protocol, whereby a domain may explicitly authorize the hosts that are allowed to use its domain name, and a receiving host may check such authorization.
互联网上的电子邮件可以通过多种方式伪造。特别是，现有协议对发送主机可以使用什么作为邮件的反向路径或SMTP HELO/EHLO命令中给定的域没有任何限制。本文档描述了发送方策略框架（SPF）协议的第1版，其中域可以明确授权允许使用其域名的主机，接收主机可以检查此类授权。
Table of Contents
目录
1. Introduction ....................................................4
1.1. Protocol Status ............................................4
1.2. Terminology ................................................5
2. Operation .......................................................5
2.1. The HELO Identity ..........................................5
2.2. The MAIL FROM Identity .....................................5
2.3. Publishing Authorization ...................................6
2.4. Checking Authorization .....................................6
2.5. Interpreting the Result ....................................7
2.5.1. None ................................................8
2.5.2. Neutral .............................................8
2.5.3. Pass ................................................8
2.5.4. Fail ................................................8
2.5.5. SoftFail ............................................9
2.5.6. TempError ...........................................9
2.5.7. PermError ...........................................9
3. SPF Records .....................................................9
3.1. Publishing ................................................10
3.1.1. DNS Resource Record Types ..........................10
3.1.2. Multiple DNS Records ...............................11
3.1.3. Multiple Strings in a Single DNS record ............11
3.1.4. Record Size ........................................11
3.1.5. Wildcard Records ...................................11
1. Introduction ....................................................4
1.1. Protocol Status ............................................4
1.2. Terminology ................................................5
2. Operation .......................................................5
2.1. The HELO Identity ..........................................5
2.2. The MAIL FROM Identity .....................................5
2.3. Publishing Authorization ...................................6
2.4. Checking Authorization .....................................6
2.5. Interpreting the Result ....................................7
2.5.1. None ................................................8
2.5.2. Neutral .............................................8
2.5.3. Pass ................................................8
2.5.4. Fail ................................................8
2.5.5. SoftFail ............................................9
2.5.6. TempError ...........................................9
2.5.7. PermError ...........................................9
3. SPF Records .....................................................9
3.1. Publishing ................................................10
3.1.1. DNS Resource Record Types ..........................10
3.1.2. Multiple DNS Records ...............................11
3.1.3. Multiple Strings in a Single DNS record ............11
3.1.4. Record Size ........................................11
3.1.5. Wildcard Records ...................................11
4. The check_host() Function ......................................12
4.1. Arguments .................................................12
4.2. Results ...................................................13
4.3. Initial Processing ........................................13
4.4. Record Lookup .............................................13
4.5. Selecting Records .........................................13
4.6. Record Evaluation .........................................14
4.6.1. Term Evaluation ....................................14
4.6.2. Mechanisms .........................................15
4.6.3. Modifiers ..........................................15
4.7. Default Result ............................................16
4.8. Domain Specification ......................................16
5. Mechanism Definitions ..........................................16
5.1. "all" .....................................................17
5.2. "include" .................................................18
5.3. "a" .......................................................19
5.4. "mx" ......................................................20
5.5. "ptr" .....................................................20
5.6. "ip4" and "ip6" ...........................................21
5.7. "exists" ..................................................22
6. Modifier Definitions ...........................................22
6.1. redirect: Redirected Query ................................23
6.2. exp: Explanation ..........................................23
7. The Received-SPF Header Field ..................................25
8. Macros .........................................................27
8.1. Macro Definitions .........................................27
8.2. Expansion Examples ........................................30
9. Implications ...................................................31
9.1. Sending Domains ...........................................31
9.2. Mailing Lists .............................................32
9.3. Forwarding Services and Aliases ...........................32
9.4. Mail Services .............................................34
9.5. MTA Relays ................................................34
10. Security Considerations .......................................35
10.1. Processing Limits ........................................35
10.2. SPF-Authorized E-Mail May Contain Other False
Identities ...............................................37
10.3. Spoofed DNS and IP Data ..................................37
10.4. Cross-User Forgery .......................................37
10.5. Untrusted Information Sources ............................38
10.6. Privacy Exposure .........................................38
11. Contributors and Acknowledgements .............................38
12. IANA Considerations ...........................................39
12.1. The SPF DNS Record Type ..................................39
12.2. The Received-SPF Mail Header Field .......................39
13. References ....................................................39
13.1. Normative References .....................................39
13.2. Informative References ...................................40
4. The check_host() Function ......................................12
4.1. Arguments .................................................12
4.2. Results ...................................................13
4.3. Initial Processing ........................................13
4.4. Record Lookup .............................................13
4.5. Selecting Records .........................................13
4.6. Record Evaluation .........................................14
4.6.1. Term Evaluation ....................................14
4.6.2. Mechanisms .........................................15
4.6.3. Modifiers ..........................................15
4.7. Default Result ............................................16
4.8. Domain Specification ......................................16
5. Mechanism Definitions ..........................................16
5.1. "all" .....................................................17
5.2. "include" .................................................18
5.3. "a" .......................................................19
5.4. "mx" ......................................................20
5.5. "ptr" .....................................................20
5.6. "ip4" and "ip6" ...........................................21
5.7. "exists" ..................................................22
6. Modifier Definitions ...........................................22
6.1. redirect: Redirected Query ................................23
6.2. exp: Explanation ..........................................23
7. The Received-SPF Header Field ..................................25
8. Macros .........................................................27
8.1. Macro Definitions .........................................27
8.2. Expansion Examples ........................................30
9. Implications ...................................................31
9.1. Sending Domains ...........................................31
9.2. Mailing Lists .............................................32
9.3. Forwarding Services and Aliases ...........................32
9.4. Mail Services .............................................34
9.5. MTA Relays ................................................34
10. Security Considerations .......................................35
10.1. Processing Limits ........................................35
10.2. SPF-Authorized E-Mail May Contain Other False
Identities ...............................................37
10.3. Spoofed DNS and IP Data ..................................37
10.4. Cross-User Forgery .......................................37
10.5. Untrusted Information Sources ............................38
10.6. Privacy Exposure .........................................38
11. Contributors and Acknowledgements .............................38
12. IANA Considerations ...........................................39
12.1. The SPF DNS Record Type ..................................39
12.2. The Received-SPF Mail Header Field .......................39
13. References ....................................................39
13.1. Normative References .....................................39
13.2. Informative References ...................................40
Appendix A. Collected ABNF .......................................42
Appendix B. Extended Examples ....................................44
B.1. Simple Examples ..........................................44
B.2. Multiple Domain Example ..................................45
B.3. DNSBL Style Example ......................................46
B.4. Multiple Requirements Example ............................46
Appendix A. Collected ABNF .......................................42
Appendix B. Extended Examples ....................................44
B.1. Simple Examples ..........................................44
B.2. Multiple Domain Example ..................................45
B.3. DNSBL Style Example ......................................46
B.4. Multiple Requirements Example ............................46
The current E-Mail infrastructure has the property that any host injecting mail into the mail system can identify itself as any domain name it wants. Hosts can do this at a variety of levels: in particular, the session, the envelope, and the mail headers. Although this feature is desirable in some circumstances, it is a major obstacle to reducing Unsolicited Bulk E-Mail (UBE, aka spam). Furthermore, many domain name holders are understandably concerned about the ease with which other entities may make use of their domain names, often with malicious intent.
当前的电子邮件基础结构具有这样的特性：任何将邮件注入邮件系统的主机都可以将自己标识为它想要的任何域名。主机可以在多个级别执行此操作：特别是会话、信封和邮件标题。虽然此功能在某些情况下是可取的，但它是减少未经请求的批量电子邮件（UBE，又称垃圾邮件）的主要障碍。此外，许多域名持有人担心其他实体可能很容易利用他们的域名，这是可以理解的，通常是出于恶意目的。
This document defines a protocol by which domain owners may authorize hosts to use their domain name in the "MAIL FROM" or "HELO" identity. Compliant domain holders publish Sender Policy Framework (SPF) records specifying which hosts are permitted to use their names, and compliant mail receivers use the published SPF records to test the authorization of sending Mail Transfer Agents (MTAs) using a given "HELO" or "MAIL FROM" identity during a mail transaction.
本文档定义了一个协议，通过该协议，域所有者可以授权主机在“邮件发件人”或“直升机”身份中使用其域名。合规域持有者发布发件人策略框架（SPF）记录，指定允许哪些主机使用其名称，合规邮件接收者使用已发布的SPF记录来测试在邮件事务期间使用给定的“HELO”或“mail FROM”身份发送邮件传输代理（MTA）的授权。
An additional benefit to mail receivers is that after the use of an identity is verified, local policy decisions about the mail can be made based on the sender's domain, rather than the host's IP address. This is advantageous because reputation of domain names is likely to be more accurate than reputation of host IP addresses. Furthermore, if a claimed identity fails verification, local policy can take stronger action against such E-Mail, such as rejecting it.
邮件接收者的另一个好处是，在验证身份的使用后，可以根据发件人的域而不是主机的IP地址来做出有关邮件的本地策略决策。这是有利的，因为域名的信誉可能比主机IP地址的信誉更准确。此外，如果声明的身份验证失败，本地策略可以对此类电子邮件采取更有力的措施，例如拒绝。
SPF has been in development since the summer of 2003 and has seen deployment beyond the developers beginning in December 2003. The design of SPF slowly evolved until the spring of 2004 and has since stabilized. There have been quite a number of forms of SPF, some written up as documents, some submitted as Internet Drafts, and many discussed and debated in development forums.
SPF从2003年夏天开始开发，并从2003年12月开始在开发人员之外部署。SPF的设计在2004年春季之前一直在缓慢发展，此后趋于稳定。SPF的形式有很多，有些是作为文件编写的，有些是作为互联网草稿提交的，还有许多是在发展论坛上讨论和辩论的。
The goal of this document is to clearly document the protocol defined by earlier draft specifications of SPF as used in existing implementations. This conception of SPF is sometimes called "SPF Classic". It is understood that particular implementations and
本文档的目标是清楚地记录SPF早期规范草案中定义的协议，该协议在现有实现中使用。这种SPF概念有时被称为“SPF经典”。可以理解的是，特定的实现和
deployments may differ from, and build upon, this work. It is hoped that we have nonetheless captured the common understanding of SPF version 1.
部署可能不同于此项工作，并基于此项工作展开。尽管如此，希望我们已经掌握了SPF版本1的共识。
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]中所述进行解释。
This document is concerned with the portion of a mail message commonly called "envelope sender", "return path", "reverse path", "bounce address", "2821 FROM", or "MAIL FROM". Since these terms are either not well defined or often used casually, this document defines the "MAIL FROM" identity in Section 2.2. Note that other terms that may superficially look like the common terms, such as "reverse-path", are used only with the defined meanings from normative documents.
本文档涉及邮件消息中通常称为“信封发件人”、“返回路径”、“反向路径”、“跳出地址”、“2821发件人”或“邮件发件人”的部分。由于这些术语要么定义不明确，要么经常随意使用，因此本文件在第2.2节中定义了“发件人”标识。请注意，表面上看起来像通用术语的其他术语，如“反向路径”，仅与规范性文件中定义的含义一起使用。
The "HELO" identity derives from either the SMTP HELO or EHLO command (see [RFC2821]). These commands supply the SMTP client (sending host) for the SMTP session. Note that requirements for the domain presented in the EHLO or HELO command are not always clear to the sending party, and SPF clients must be prepared for the "HELO" identity to be malformed or an IP address literal. At the time of this writing, many legitimate E-Mails are delivered with invalid HELO domains.
“HELO”标识来自SMTP HELO或EHLO命令（请参见[RFC2821]）。这些命令为SMTP会话提供SMTP客户端（发送主机）。请注意，发送方并不总是清楚EHLO或HELO命令中显示的域的要求，SPF客户端必须为“HELO”标识的格式错误或IP地址文字做好准备。在撰写本文时，许多合法的电子邮件都带有无效的HELO域。
It is RECOMMENDED that SPF clients not only check the "MAIL FROM" identity, but also separately check the "HELO" identity by applying the check_host() function (Section 4) to the "HELO" identity as the <sender>.
建议SPF客户端不仅检查“邮件发件人”身份，还可以通过将check_host（）函数（第4节）应用于作为<sender>的“HELO”身份来单独检查“HELO”身份。
The "MAIL FROM" identity derives from the SMTP MAIL command (see [RFC2821]). This command supplies the "reverse-path" for a message, which generally consists of the sender mailbox, and is the mailbox to which notification messages are to be sent if there are problems delivering the message.
“邮件发件人”标识源自SMTP邮件命令（请参见[RFC2821]）。此命令为邮件提供“反向路径”，该路径通常由发件人邮箱组成，并且是在传递邮件时出现问题时将通知邮件发送到的邮箱。
[RFC2821] allows the reverse-path to be null (see Section 4.5.5 in RFC 2821). In this case, there is no explicit sender mailbox, and such a message can be assumed to be a notification message from the mail system itself. When the reverse-path is null, this document
允许反向路径为RFC25.821中的[RF825]部分。在这种情况下，没有显式的发件人邮箱，可以假定这样的消息是来自邮件系统本身的通知消息。当反向路径为空时，此文档
defines the "MAIL FROM" identity to be the mailbox composed of the localpart "postmaster" and the "HELO" identity (which may or may not have been checked separately before).
将“邮件发件人”标识定义为由localpart“postmaster”和“HELO”标识组成的邮箱（之前可能已单独检查过，也可能未单独检查过）。
SPF clients MUST check the "MAIL FROM" identity. SPF clients check the "MAIL FROM" identity by applying the check_host() function to the "MAIL FROM" identity as the <sender>.
SPF客户端必须检查“邮件发件人”标识。SPF客户端通过将check_host（）函数应用于作为<sender>的“邮件发件人”标识来检查“邮件发件人”标识。
An SPF-compliant domain MUST publish a valid SPF record as described in Section 3. This record authorizes the use of the domain name in the "HELO" and "MAIL FROM" identities by the MTAs it specifies.
符合SPF的域必须发布有效的SPF记录，如第3节所述。此记录授权MTA使用其指定的“HELO”和“MAIL FROM”标识中的域名。
If domain owners choose to publish SPF records, it is RECOMMENDED that they end in "-all", or redirect to other records that do, so that a definitive determination of authorization can be made.
如果域所有者选择发布SPF记录，建议以“-all”结尾，或重定向到其他发布SPF记录的记录，以便最终确定授权。
Domain holders may publish SPF records that explicitly authorize no hosts if mail should never originate using that domain.
如果邮件不应该使用域发起，域持有者可以发布SPF记录，该记录不明确授权任何主机。
When changing SPF records, care must be taken to ensure that there is a transition period so that the old policy remains valid until all legitimate E-Mail has been checked.
更改SPF记录时，必须注意确保有一个过渡期，以便在检查所有合法电子邮件之前，旧策略保持有效。
A mail receiver can perform a set of SPF checks for each mail message it receives. An SPF check tests the authorization of a client host to emit mail with a given identity. Typically, such checks are done by a receiving MTA, but can be performed elsewhere in the mail processing chain so long as the required information is available and reliable. At least the "MAIL FROM" identity MUST be checked, but it is RECOMMENDED that the "HELO" identity also be checked beforehand.
邮件接收者可以对收到的每封邮件执行一组SPF检查。SPF检查测试客户端主机发出具有给定标识的邮件的授权。通常，此类检查由接收MTA完成，但只要所需信息可用且可靠，就可以在邮件处理链的其他位置执行。至少必须检查“邮件发件人”身份，但建议事先检查“直升机”身份。
Without explicit approval of the domain owner, checking other identities against SPF version 1 records is NOT RECOMMENDED because there are cases that are known to give incorrect results. For example, almost all mailing lists rewrite the "MAIL FROM" identity (see Section 9.2), but some do not change any other identities in the message. The scenario described in Section 9.3, sub-section 1.2, is another example. Documents that define other identities should define the method for explicit approval.
如果没有域所有者的明确批准，则不建议根据SPF版本1记录检查其他身份，因为存在已知会给出错误结果的情况。例如，几乎所有邮件列表都会重写“邮件发件人”标识（请参见第9.2节），但有些列表不会更改邮件中的任何其他标识。第9.3节第1.2小节中描述的场景是另一个示例。定义其他标识的文档应定义明确批准的方法。
It is possible that mail receivers will use the SPF check as part of a larger set of tests on incoming mail. The results of other tests may influence whether or not a particular SPF check is performed. For example, finding the sending host's IP address on a local white
邮件接收者可能会使用SPF检查作为对传入邮件的一组更大测试的一部分。其他测试的结果可能会影响是否执行特定SPF检查。例如，在本地服务器上查找发送主机的IP地址
list may cause all other tests to be skipped and all mail from that host to be accepted.
列表可能会导致跳过所有其他测试，并接受来自该主机的所有邮件。
When a mail receiver decides to perform an SPF check, it MUST use a correctly-implemented check_host() function (Section 4) evaluated with the correct parameters. Although the test as a whole is optional, once it has been decided to perform a test it must be performed as specified so that the correct semantics are preserved between publisher and receiver.
当邮件接收者决定执行SPF检查时，必须使用正确实现的check_host（）函数（第4节），并使用正确的参数进行计算。尽管测试作为一个整体是可选的，但一旦决定执行测试，就必须按照指定的方式执行，以便在发布者和接收者之间保留正确的语义。
To make the test, the mail receiver MUST evaluate the check_host() function with the arguments set as follows:
要进行测试，邮件接收者必须使用如下设置的参数计算check_host（）函数：
<ip> - the IP address of the SMTP client that is emitting the mail, either IPv4 or IPv6.
<ip>-发送邮件的SMTP客户端的ip地址，IPv4或IPv6。
<domain> - the domain portion of the "MAIL FROM" or "HELO" identity.
<domain>“邮件发件人”或“直升机”标识的域部分。
<sender> - the "MAIL FROM" or "HELO" identity.
<sender>“邮件发件人”或“HELO”标识。
Note that the <domain> argument may not be a well-formed domain name. For example, if the reverse-path was null, then the EHLO/HELO domain is used, with its associated problems (see Section 2.1). In these cases, check_host() is defined in Section 4.3 to return a "None" result.
请注意，<domain>参数可能不是格式正确的域名。例如，如果反向路径为null，则使用EHLO/HELO域及其相关问题（参见第2.1节）。在这些情况下，第4.3节中定义了check_host（）以返回“None”结果。
Although invalid, malformed, or non-existent domains cause SPF checks to return "None" because no SPF record can be found, it has long been the policy of many MTAs to reject E-Mail from such domains, especially in the case of invalid "MAIL FROM". In order to prevent the circumvention of SPF records, rejecting E-Mail from invalid domains should be considered.
虽然无效、格式错误或不存在的域会导致SPF检查返回“无”，因为找不到SPF记录，但长期以来，许多MTA的策略是拒绝来自此类域的电子邮件，尤其是在“来自”的邮件无效的情况下。为了防止规避SPF记录，应考虑拒绝来自无效域的电子邮件。
Implementations must take care to correctly extract the <domain> from the data given with the SMTP MAIL FROM command as many MTAs will still accept such things as source routes (see [RFC2821], Appendix C), the %-hack (see [RFC1123]), and bang paths (see [RFC1983]). These archaic features have been maliciously used to bypass security systems.
实现必须注意从SMTP MAIL from命令提供的数据中正确提取<domain>，因为许多MTA仍将接受诸如源路由（请参见[RFC2821]，附录C]、%-hack（请参见[RFC1123]）和bang路径（请参见[RFC1983]）等内容。这些过时的功能被恶意用于绕过安全系统。
This section describes how software that performs the authorization should interpret the results of the check_host() function. The authorization check SHOULD be performed during the processing of the SMTP transaction that sends the mail. This allows errors to be returned directly to the sending MTA by way of SMTP replies.
本节介绍执行授权的软件应如何解释check_host（）函数的结果。授权检查应在处理发送邮件的SMTP事务期间执行。这允许通过SMTP回复将错误直接返回给发送MTA。
Performing the authorization after the SMTP transaction has finished may cause problems, such as the following: (1) It may be difficult to accurately extract the required information from potentially deceptive headers; (2) legitimate E-Mail may fail because the sender's policy may have since changed.
在SMTP事务完成后执行授权可能会导致以下问题：（1）可能难以准确地从可能具有欺骗性的标头中提取所需信息；（2） 合法电子邮件可能会失败，因为发件人的策略可能已更改。
Generating non-delivery notifications to forged identities that have failed the authorization check is generally abusive and against the explicit wishes of the identity owner.
向未通过授权检查的伪造身份生成未送达通知通常是滥用行为，违背身份所有者的明确意愿。
A result of "None" means that no records were published by the domain or that no checkable sender domain could be determined from the given identity. The checking software cannot ascertain whether or not the client host is authorized.
“无”的结果表示域未发布任何记录，或者无法根据给定标识确定可检查的发件人域。检查软件无法确定客户端主机是否经过授权。
The domain owner has explicitly stated that he cannot or does not want to assert whether or not the IP address is authorized. A "Neutral" result MUST be treated exactly like the "None" result; the distinction exists only for informational purposes. Treating "Neutral" more harshly than "None" would discourage domain owners from testing the use of SPF records (see Section 9.1).
域所有者已明确声明，他不能或不想断言IP地址是否已授权。“中性”结果必须与“无”结果完全相同；这种区别仅用于提供信息。与“无”相比，更严厉地对待“中立”将阻止域所有者测试SPF记录的使用（参见第9.1节）。
A "Pass" result means that the client is authorized to inject mail with the given identity. The domain can now, in the sense of reputation, be considered responsible for sending the message. Further policy checks can now proceed with confidence in the legitimate use of the identity.
“通过”结果意味着客户端被授权使用给定的身份注入邮件。从声誉的角度来看，域现在可以被视为负责发送消息。进一步的政策检查现在可以在对合法使用身份有信心的情况下进行。
A "Fail" result is an explicit statement that the client is not authorized to use the domain in the given identity. The checking software can choose to mark the mail based on this or to reject the mail outright.
“失败”结果是一个明确的声明，表明客户端无权使用给定标识中的域。检查软件可以选择基于此标记邮件或直接拒绝邮件。
If the checking software chooses to reject the mail during the SMTP transaction, then it SHOULD use an SMTP reply code of 550 (see [RFC2821]) and, if supported, the 5.7.1 Delivery Status Notification (DSN) code (see [RFC3464]), in addition to an appropriate reply text. The check_host() function may return either a default explanation string or one from the domain that published the SPF records (see Section 6.2). If the information does not originate with the
如果检查软件选择在SMTP事务期间拒绝邮件，则除了适当的回复文本外，还应使用550的SMTP回复代码（请参见[RFC2821]），以及5.7.1传递状态通知（DSN）代码（请参见[RFC3464]）。check_host（）函数可以返回默认解释字符串，也可以从发布SPF记录的域返回解释字符串（请参见第6.2节）。如果信息不是源于
checking software, it should be made clear that the text is provided by the sender's domain. For example:
检查软件时，应明确文本由发件人所在域提供。例如：
550-5.7.1 SPF MAIL FROM check failed:
550-5.7.1 The domain example.com explains:
550 5.7.1 Please see http://www.example.com/mailpolicy.html
550-5.7.1 SPF MAIL FROM check failed:
550-5.7.1 The domain example.com explains:
550 5.7.1 Please see http://www.example.com/mailpolicy.html
A "SoftFail" result should be treated as somewhere between a "Fail" and a "Neutral". The domain believes the host is not authorized but is not willing to make that strong of a statement. Receiving software SHOULD NOT reject the message based solely on this result, but MAY subject the message to closer scrutiny than normal.
“软失败”结果应被视为介于“失败”和“中性”之间。域名认为主机未经授权，但不愿意做出如此强烈的声明。接收软件不应仅基于此结果拒绝消息，但可能会对消息进行比正常情况更仔细的检查。
The domain owner wants to discourage the use of this host and thus desires limited feedback when a "SoftFail" result occurs. For example, the recipient's Mail User Agent (MUA) could highlight the "SoftFail" status, or the receiving MTA could give the sender a message using a technique called "greylisting" whereby the MTA can issue an SMTP reply code of 451 (4.3.0 DSN code) with a note the first time the message is received, but accept it the second time.
域所有者希望阻止使用此主机，因此在出现“SoftFail”结果时希望得到有限的反馈。例如，收件人的邮件用户代理（MUA）可以突出显示“SoftFail”状态，或者接收MTA可以使用一种称为“greylisting”的技术向发件人发送一条邮件，MTA可以在第一次收到邮件时发出一个451（4.3.0 DSN代码）的SMTP回复代码和一条注释，但在第二次接收时接受。
A "TempError" result means that the SPF client encountered a transient error while performing the check. Checking software can choose to accept or temporarily reject the message. If the message is rejected during the SMTP transaction for this reason, the software SHOULD use an SMTP reply code of 451 and, if supported, the 4.4.3 DSN code.
“TempError”结果表示SPF客户端在执行检查时遇到暂时错误。检查软件可以选择接受或暂时拒绝消息。如果邮件在SMTP事务期间因此原因被拒绝，软件应使用SMTP回复代码451，如果支持，则应使用4.4.3 DSN代码。
A "PermError" result means that the domain's published records could not be correctly interpreted. This signals an error condition that requires manual intervention to be resolved, as opposed to the TempError result. Be aware that if the domain owner uses macros (Section 8), it is possible that this result is due to the checked identities having an unexpected format.
“PermError”结果意味着无法正确解释域的已发布记录。这表示需要手动干预才能解决的错误情况，而不是温度结果。请注意，如果域所有者使用宏（第8节），则此结果可能是由于选中的标识具有意外的格式。
An SPF record is a DNS Resource Record (RR) that declares which hosts are, and are not, authorized to use a domain name for the "HELO" and "MAIL FROM" identities. Loosely, the record partitions all hosts into permitted and not-permitted sets (though some hosts might fall into neither category).
SPF记录是一个DNS资源记录（RR），它声明哪些主机被授权或未被授权为“HELO”和“MAIL FROM”标识使用域名。松散地，记录将所有主机划分为允许和不允许的集合（尽管有些主机可能不属于这两个类别）。
The SPF record is a single string of text. An example record is the following:
SPF记录是单个文本字符串。下面是一个示例记录：
v=spf1 +mx a:colo.example.com/28 -all
v=spf1 +mx a:colo.example.com/28 -all
This record has a version of "spf1" and three directives: "+mx", "a:colo.example.com/28" (the + is implied), and "-all".
该记录有一个版本的“spf1”和三个指令：“+mx”、“a:colo.example.com/28”（暗含“+”）和“-all”。
Domain owners wishing to be SPF compliant must publish SPF records for the hosts that are used in the "MAIL FROM" and "HELO" identities. The SPF records are placed in the DNS tree at the host name it pertains to, not a subdomain under it, such as is done with SRV records. This is the same whether the TXT or SPF RR type (see Section 3.1.1) is used.
希望符合SPF的域所有者必须为“邮件发件人”和“直升机”身份中使用的主机发布SPF记录。SPF记录以其所属的主机名放置在DNS树中，而不是其下的子域，如SRV记录。无论使用TXT还是SPF RR类型（见第3.1.1节），这都是相同的。
The example above in Section 3 might be published via these lines in a domain zone file:
第3节中的上述示例可能通过域区域文件中的以下行发布：
example.com. TXT "v=spf1 +mx a:colo.example.com/28 -all"
smtp-out.example.com. TXT "v=spf1 a -all"
example.com. TXT "v=spf1 +mx a:colo.example.com/28 -all"
smtp-out.example.com. TXT "v=spf1 a -all"
When publishing via TXT records, beware of other TXT records published there for other purposes. They may cause problems with size limits (see Section 3.1.4).
当通过TXT记录发布时，请注意出于其他目的发布的其他TXT记录。它们可能会导致尺寸限制问题（见第3.1.4节）。
This document defines a new DNS RR of type SPF, code 99. The format of this type is identical to the TXT RR [RFC1035]. For either type, the character content of the record is encoded as [US-ASCII].
本文档定义了SPF类型的新DNS RR，代码99。此类型的格式与TXT RR[RFC1035]相同。对于任何一种类型，记录的字符内容都编码为[US-ASCII]。
It is recognized that the current practice (using a TXT record) is not optimal, but it is necessary because there are a number of DNS server and resolver implementations in common use that cannot handle the new RR type. The two-record-type scheme provides a forward path to the better solution of using an RR type reserved for this purpose.
目前的做法（使用TXT记录）并非最佳做法，但这是必要的，因为有许多常见的DNS服务器和解析器实现无法处理新的RR类型。双记录类型方案提供了一个前进路径，以更好地解决使用为此目的保留的RR类型的问题。
An SPF-compliant domain name SHOULD have SPF records of both RR types. A compliant domain name MUST have a record of at least one type. If a domain has records of both types, they MUST have identical content. For example, instead of publishing just one record as in Section 3.1 above, it is better to publish:
符合SPF的域名应具有两种RR类型的SPF记录。兼容域名必须具有至少一种类型的记录。如果域具有这两种类型的记录，则它们必须具有相同的内容。例如，与其像上面第3.1节那样只发布一条记录，不如发布：
example.com. IN TXT "v=spf1 +mx a:colo.example.com/28 -all"
example.com. IN SPF "v=spf1 +mx a:colo.example.com/28 -all"
example.com. IN TXT "v=spf1 +mx a:colo.example.com/28 -all"
example.com. IN SPF "v=spf1 +mx a:colo.example.com/28 -all"
Example RRs in this document are shown with the TXT record type; however, they could be published with the SPF type or with both types.
本文档中的RRs示例以TXT记录类型显示；但是，它们可以使用SPF类型发布，也可以同时使用两种类型发布。
A domain name MUST NOT have multiple records that would cause an authorization check to select more than one record. See Section 4.5 for the selection rules.
域名不能有多个记录，这会导致授权检查选择多个记录。选择规则见第4.5节。
As defined in [RFC1035] sections 3.3.14 and 3.3, a single text DNS record (either TXT or SPF RR types) can be composed of more than one string. If a published record contains multiple strings, then the record MUST be treated as if those strings are concatenated together without adding spaces. For example:
如[RFC1035]第3.3.14和3.3节所定义，单个文本DNS记录（TXT或SPF RR类型）可以由多个字符串组成。如果发布的记录包含多个字符串，则必须将该记录视为将这些字符串连接在一起而不添加空格。例如：
IN TXT "v=spf1 .... first" "second string..."
IN TXT "v=spf1 .... first" "second string..."
MUST be treated as equivalent to
必须被视为等同于
IN TXT "v=spf1 .... firstsecond string..."
IN TXT "v=spf1 .... firstsecond string..."
SPF or TXT records containing multiple strings are useful in constructing records that would exceed the 255-byte maximum length of a string within a single TXT or SPF RR record.
包含多个字符串的SPF或TXT记录在构造超过单个TXT或SPF RR记录中字符串最大长度255字节的记录时非常有用。
The published SPF record for a given domain name SHOULD remain small enough that the results of a query for it will fit within 512 octets. This will keep even older DNS implementations from falling over to TCP. Since the answer size is dependent on many things outside the scope of this document, it is only possible to give this guideline: If the combined length of the DNS name and the text of all the records of a given type (TXT or SPF) is under 450 characters, then DNS answers should fit in UDP packets. Note that when computing the sizes for queries of the TXT format, one must take into account any other TXT records published at the domain name. Records that are too long to fit in a single UDP packet MAY be silently ignored by SPF clients.
给定域名的已发布SPF记录应保持足够小，以便查询结果在512个八位字节以内。这将防止更旧的DNS实现落入TCP。由于答案大小取决于本文档范围之外的许多内容，因此只能给出以下准则：如果DNS名称和给定类型（TXT或SPF）的所有记录的文本的组合长度小于450个字符，则DNS答案应适合UDP数据包。请注意，在计算TXT格式查询的大小时，必须考虑在域名上发布的任何其他TXT记录。SPF客户端可能会忽略太长而无法放入单个UDP数据包的记录。
Use of wildcard records for publishing is not recommended. Care must be taken if wildcard records are used. If a domain publishes wildcard MX records, it may want to publish wildcard declarations,
不建议使用通配符记录进行发布。如果使用通配符记录，必须小心。如果域发布通配符MX记录，它可能希望发布通配符声明，
subject to the same requirements and problems. In particular, the declaration must be repeated for any host that has any RR records at all, and for subdomains thereof. For example, the example given in [RFC1034], Section 4.3.3, could be extended with the following:
受到相同的要求和问题的影响。特别是，必须对具有任何RR记录的任何主机及其子域重复该声明。例如，第4.3.3节[RFC1034]中给出的示例可以扩展为以下内容：
X.COM. MX 10 A.X.COM X.COM. TXT "v=spf1 a:A.X.COM -all"
X.COM。MX 10 A.X.COM X.COM。TXT“v=spf1 a:a.X.COM-全部”
*.X.COM. MX 10 A.X.COM
*.X.COM. TXT "v=spf1 a:A.X.COM -all"
*.X.COM. MX 10 A.X.COM
*.X.COM. TXT "v=spf1 a:A.X.COM -all"
A.X.COM. A 1.2.3.4 A.X.COM. MX 10 A.X.COM A.X.COM. TXT "v=spf1 a:A.X.COM -all"
A.X.COM.A 1.2.3.4 A.X.COM.MX 10 A.X.COM A.X.COM.TXT“v=spf1 A:A.X.COM-全部”
*.A.X.COM. MX 10 A.X.COM
*.A.X.COM. TXT "v=spf1 a:A.X.COM -all"
*.A.X.COM. MX 10 A.X.COM
*.A.X.COM. TXT "v=spf1 a:A.X.COM -all"
Notice that SPF records must be repeated twice for every name within the domain: once for the name, and once with a wildcard to cover the tree under the name.
请注意，对于域中的每个名称，SPF记录必须重复两次：一次用于名称，一次使用通配符覆盖名称下的树。
Use of wildcards is discouraged in general as they cause every name under the domain to exist and queries against arbitrary names will never return RCODE 3 (Name Error).
一般不鼓励使用通配符，因为通配符会导致域下的每个名称都存在，对任意名称的查询将永远不会返回RCODE 3（名称错误）。
The check_host() function fetches SPF records, parses them, and interprets them to determine whether a particular host is or is not permitted to send mail with a given identity. Mail receivers that perform this check MUST correctly evaluate the check_host() function as described here.
函数的作用是：获取SPF记录，对其进行解析，并对其进行解释，以确定是否允许特定主机发送具有给定标识的邮件。执行此检查的邮件接收者必须正确计算check_host（）函数，如下所述。
Implementations MAY use a different algorithm than the canonical algorithm defined here, so long as the results are the same in all cases.
实现可能使用与此处定义的规范算法不同的算法，只要结果在所有情况下都相同。
The check_host() function takes these arguments:
check_host（）函数接受以下参数：
<ip> - the IP address of the SMTP client that is emitting the mail, either IPv4 or IPv6.
<ip>-发送邮件的SMTP客户端的ip地址，IPv4或IPv6。
<domain> - the domain that provides the sought-after authorization information; initially, the domain portion of the "MAIL FROM" or "HELO" identity.
<domain>-提供所需授权信息的域；最初，“邮件发件人”或“HELO”标识的域部分。
<sender> - the "MAIL FROM" or "HELO" identity.
<sender>“邮件发件人”或“HELO”标识。
The domain portion of <sender> will usually be the same as the <domain> argument when check_host() is initially evaluated. However, this will generally not be true for recursive evaluations (see Section 5.2 below).
最初计算check_host（）时，<sender>的域部分通常与<domain>参数相同。然而，对于递归评估，这通常不是真的（见下文第5.2节）。
Actual implementations of the check_host() function may need additional arguments.
check_host（）函数的实际实现可能需要额外的参数。
The function check_host() can return one of several results described in Section 2.5. Based on the result, the action to be taken is determined by the local policies of the receiver.
函数check_host（）可以返回第2.5节中描述的几个结果之一。根据结果，要采取的行动由接收方的本地策略决定。
If the <domain> is malformed (label longer than 63 characters, zero-length label not at the end, etc.) or is not a fully qualified domain name, or if the DNS lookup returns "domain does not exist" (RCODE 3), check_host() immediately returns the result "None".
如果<domain>格式不正确（标签长度超过63个字符，零长度标签不在末尾等），或者不是完全限定的域名，或者如果DNS查找返回“domain not exist”（RCODE 3），请选中\u host（）立即返回结果“None”。
If the <sender> has no localpart, substitute the string "postmaster" for the localpart.
如果<sender>没有localpart，则用字符串“postmaster”替换localpart。
In accordance with how the records are published (see Section 3.1 above), a DNS query needs to be made for the <domain> name, querying for either RR type TXT, SPF, or both. If both SPF and TXT RRs are looked up, the queries MAY be done in parallel.
根据记录的发布方式（见上文第3.1节），需要对<domain>名称进行DNS查询，查询RR类型TXT、SPF或两者。如果同时查找SPF和TXT RRs，则可以并行执行查询。
If all DNS lookups that are made return a server failure (RCODE 2), or other error (RCODE other than 0 or 3), or time out, then check_host() exits immediately with the result "TempError".
如果进行的所有DNS查找都返回服务器故障（RCODE 2）或其他错误（RCODE不是0或3）或超时，则check_host（）立即退出，结果为“TempError”。
Records begin with a version section:
记录以版本部分开始：
record = version terms *SP
version = "v=spf1"
record = version terms *SP
version = "v=spf1"
Starting with the set of records that were returned by the lookup, record selection proceeds in two steps:
从查找返回的记录集开始，记录选择分两步进行：
1. Records that do not begin with a version section of exactly "v=spf1" are discarded. Note that the version section is terminated either by an SP character or the end of the record. A record with a version section of "v=spf10" does not match and must be discarded.
1. 不以“v=spf1”的版本节开头的记录将被丢弃。请注意，版本部分以SP字符或记录结尾终止。版本节为“v=spf10”的记录不匹配，必须丢弃。
2. If any records of type SPF are in the set, then all records of type TXT are discarded.
2. 如果集合中有SPF类型的任何记录，则TXT类型的所有记录都将被丢弃。
After the above steps, there should be exactly one record remaining and evaluation can proceed. If there are two or more records remaining, then check_host() exits immediately with the result of "PermError".
完成上述步骤后，应该只剩下一条记录，并且可以继续评估。如果还有两条或多条记录，则check_host（）立即退出，结果为“permerro”。
If no matching records are returned, an SPF client MUST assume that the domain makes no SPF declarations. SPF processing MUST stop and return "None".
如果没有返回匹配的记录，SPF客户端必须假定域没有SPF声明。SPF处理必须停止并返回“无”。
After one SPF record has been selected, the check_host() function parses and interprets it to find a result for the current test. If there are any syntax errors, check_host() returns immediately with the result "PermError".
选择一条SPF记录后，check_host（）函数将对其进行分析和解释，以查找当前测试的结果。如果有任何语法错误，请检查\u host（）立即返回结果“PermError”。
Implementations MAY choose to parse the entire record first and return "PermError" if the record is not syntactically well formed. However, in all cases, any syntax errors anywhere in the record MUST be detected.
实现可能会选择首先解析整个记录，如果记录的语法格式不正确，则返回“permerro”。但是，在所有情况下，必须检测记录中任何位置的语法错误。
There are two types of terms: mechanisms and modifiers. A record contains an ordered list of these as specified in the following Augmented Backus-Naur Form (ABNF).
术语有两种类型：机制和修饰语。一个记录包含一个有序的列表，这些列表在下面的扩展的Backus Naur表单（ABNF）中指定。
terms = *( 1*SP ( directive / modifier ) )
terms = *( 1*SP ( directive / modifier ) )
directive = [ qualifier ] mechanism
qualifier = "+" / "-" / "?" / "~"
mechanism = ( all / include
/ A / MX / PTR / IP4 / IP6 / exists )
modifier = redirect / explanation / unknown-modifier
unknown-modifier = name "=" macro-string
directive = [ qualifier ] mechanism
qualifier = "+" / "-" / "?" / "~"
mechanism = ( all / include
/ A / MX / PTR / IP4 / IP6 / exists )
modifier = redirect / explanation / unknown-modifier
unknown-modifier = name "=" macro-string
name = ALPHA *( ALPHA / DIGIT / "-" / "_" / "." )
name = ALPHA *( ALPHA / DIGIT / "-" / "_" / "." )
Most mechanisms allow a ":" or "/" character after the name.
大多数机制允许在名称后使用“：”或“/”字符。
Modifiers always contain an equals ('=') character immediately after the name, and before any ":" or "/" characters that may be part of the macro-string.
修饰符总是在名称后面紧跟着一个等于（'='）字符，在可能是宏字符串一部分的任何“：”或“/”字符之前。
Terms that do not contain any of "=", ":", or "/" are mechanisms, as defined in Section 5.
不包含任何“=”、“：”或“/”的术语是第5节中定义的机制。
As per the definition of the ABNF notation in [RFC4234], mechanism and modifier names are case-insensitive.
根据[RFC4234]中ABNF符号的定义，机制和修饰符名称不区分大小写。
Each mechanism is considered in turn from left to right. If there are no more mechanisms, the result is specified in Section 4.7.
从左到右依次考虑每个机构。如果没有更多的机制，结果在第4.7节中规定。
When a mechanism is evaluated, one of three things can happen: it can match, not match, or throw an exception.
评估机制时，可能会发生以下三种情况之一：匹配、不匹配或引发异常。
If it matches, processing ends and the qualifier value is returned as the result of that record. If it does not match, processing continues with the next mechanism. If it throws an exception, mechanism processing ends and the exception value is returned.
如果匹配，则处理结束，并返回限定符值作为该记录的结果。如果不匹配，处理将继续下一个机制。如果抛出异常，则机制处理结束并返回异常值。
The possible qualifiers, and the results they return are as follows:
可能的限定符及其返回的结果如下：
"+" Pass "-" Fail "~" SoftFail "?" Neutral
“+”通过“-”失败“~”软失败“？”中性
The qualifier is optional and defaults to "+".
限定符是可选的，默认为“+”。
When a mechanism matches and the qualifier is "-", then a "Fail" result is returned and the explanation string is computed as described in Section 6.2.
当机制匹配且限定符为“-”时，将返回“失败”结果，并按照第6.2节中的说明计算解释字符串。
The specific mechanisms are described in Section 5.
具体机制见第5节。
Modifiers are not mechanisms: they do not return match or not-match. Instead they provide additional information. Although modifiers do not directly affect the evaluation of the record, the "redirect" modifier has an effect after all the mechanisms have been evaluated.
修饰符不是机制：它们不返回匹配或不匹配。它们提供了额外的信息。虽然修饰符不会直接影响记录的求值，但“重定向”修饰符在所有机制求值后都会起作用。
If none of the mechanisms match and there is no "redirect" modifier, then the check_host() returns a result of "Neutral", just as if "?all" were specified as the last directive. If there is a "redirect" modifier, check_host() proceeds as defined in Section 6.1.
如果没有匹配的机制，并且没有“重定向”修饰符，那么check_host（）将返回一个“Neutral”结果，就像将“？all”指定为最后一个指令一样。如果有“重定向”修饰符，请检查_host（）是否按照第6.1节中的定义进行。
Note that records SHOULD always use either a "redirect" modifier or an "all" mechanism to explicitly terminate processing.
请注意，记录应始终使用“重定向”修饰符或“全部”机制来显式终止处理。
For example:
例如：
v=spf1 +mx -all
or
v=spf1 +mx redirect=_spf.example.com
v=spf1 +mx -all
or
v=spf1 +mx redirect=_spf.example.com
Several of these mechanisms and modifiers have a <domain-spec> section. The <domain-spec> string is macro expanded (see Section 8). The resulting string is the common presentation form of a fully-qualified DNS name: a series of labels separated by periods. This domain is called the <target-name> in the rest of this document.
其中一些机制和修饰符具有<domain spec>部分。<domain spec>字符串是宏展开的（参见第8节）。结果字符串是完全限定DNS名称的常见表示形式：由句点分隔的一系列标签。在本文档的其余部分中，此域称为<target name>。
Note: The result of the macro expansion is not subject to any further escaping. Hence, this facility cannot produce all characters that are legal in a DNS label (e.g., the control characters). However, this facility is powerful enough to express legal host names and common utility labels (such as "_spf") that are used in DNS.
注意：宏扩展的结果不受任何进一步转义的影响。因此，此功能无法生成DNS标签中的所有合法字符（例如，控制字符）。但是，此功能强大到足以表示DNS中使用的合法主机名和通用实用程序标签（如“_spf”）。
For several mechanisms, the <domain-spec> is optional. If it is not provided, the <domain> is used as the <target-name>.
对于几种机制，<domain spec>是可选的。如果未提供，则将<domain>用作<target name>。
This section defines two types of mechanisms.
本节定义了两种类型的机制。
Basic mechanisms contribute to the language framework. They do not specify a particular type of authorization scheme.
基本机制有助于语言框架。它们没有指定特定类型的授权方案。
all include
全部包括
Designated sender mechanisms are used to designate a set of <ip> addresses as being permitted or not permitted to use the <domain> for sending mail.
指定发件人机制用于将一组<ip>地址指定为允许或不允许使用<domain>发送邮件。
a mx ptr ip4 ip6 exists
存在mx ptr ip4 ip6
The following conventions apply to all mechanisms that perform a comparison between <ip> and an IP address at any point:
以下约定适用于在任何点执行<ip>和ip地址之间比较的所有机制：
If no CIDR-length is given in the directive, then <ip> and the IP address are compared for equality. (Here, CIDR is Classless Inter-Domain Routing.)
如果指令中未给出CIDR长度，则比较<ip>和ip地址是否相等。（这里，CIDR是无类域间路由。）
If a CIDR-length is specified, then only the specified number of high-order bits of <ip> and the IP address are compared for equality.
如果指定了CIDR长度，则仅比较指定数量的<ip>高阶位和ip地址是否相等。
When any mechanism fetches host addresses to compare with <ip>, when <ip> is an IPv4 address, A records are fetched, when <ip> is an IPv6 address, AAAA records are fetched. Even if the SMTP connection is via IPv6, an IPv4-mapped IPv6 IP address (see [RFC3513], Section 2.5.5) MUST still be considered an IPv4 address.
当任何机制获取主机地址以与<ip>进行比较时，当<ip>是IPv4地址时，将获取记录；当<ip>是IPv6地址时，将获取AAAA记录。即使SMTP连接通过IPv6，IPv4映射的IPv6 IP地址（请参阅[RFC3513]，第2.5.5节）仍必须视为IPv4地址。
Several mechanisms rely on information fetched from DNS. For these DNS queries, except where noted, if the DNS server returns an error (RCODE other than 0 or 3) or the query times out, the mechanism throws the exception "TempError". If the server returns "domain does not exist" (RCODE 3), then evaluation of the mechanism continues as if the server returned no error (RCODE 0) and zero answer records.
有几种机制依赖于从DNS获取的信息。对于这些DNS查询，除非另有说明，否则如果DNS服务器返回错误（RCODE不是0或3）或查询超时，该机制将抛出异常“TempError”。如果服务器返回“域不存在”（RCODE 3），则机制的评估将继续进行，就像服务器未返回任何错误（RCODE 0）和零应答记录一样。
all = "all"
all = "all"
The "all" mechanism is a test that always matches. It is used as the rightmost mechanism in a record to provide an explicit default.
“全部”机制是一个始终匹配的测试。它用作记录中最右边的机制，以提供显式默认值。
For example:
例如：
v=spf1 a mx -all
v=spf1 a mx-全部
Mechanisms after "all" will never be tested. Any "redirect" modifier (Section 6.1) has no effect when there is an "all" mechanism.
“所有”之后的机制永远不会被测试。当存在“全部”机制时，任何“重定向”修改器（第6.1节）均无效。
include = "include" ":" domain-spec
include=“include”“：”域规范
The "include" mechanism triggers a recursive evaluation of check_host(). The domain-spec is expanded as per Section 8. Then check_host() is evaluated with the resulting string as the <domain>. The <ip> and <sender> arguments remain the same as in the current evaluation of check_host().
“include”机制触发check_host（）的递归计算。域规范按照第8节进行扩展。然后，check_host（）将使用结果字符串作为<domain>进行计算。<ip>和<sender>参数与check_host（）当前计算中的参数保持相同。
In hindsight, the name "include" was poorly chosen. Only the evaluated result of the referenced SPF record is used, rather than acting as if the referenced SPF record was literally included in the first. For example, evaluating a "-all" directive in the referenced record does not terminate the overall processing and does not necessarily result in an overall "Fail". (Better names for this mechanism would have been "if-pass", "on-pass", etc.)
事后看来，“包括”这个名字选得不好。仅使用引用的SPF记录的评估结果，而不是将引用的SPF记录视为包含在第一条记录中。例如，评估引用记录中的“-all”指令不会终止整体处理，也不一定会导致整体“失败”。（这个机制的更好名称应该是“如果通过”、“通过”等。）
The "include" mechanism makes it possible for one domain to designate multiple administratively-independent domains. For example, a vanity domain "example.net" might send mail using the servers of administratively-independent domains example.com and example.org.
“包含”机制使一个域可以指定多个管理上独立的域。例如，虚荣域“example.net”可能使用管理独立域example.com和example.org的服务器发送邮件。
Example.net could say
net可以这样说
IN TXT "v=spf1 include:example.com include:example.org -all"
IN TXT "v=spf1 include:example.com include:example.org -all"
This would direct check_host() to, in effect, check the records of example.com and example.org for a "Pass" result. Only if the host were not permitted for either of those domains would the result be "Fail".
这将指示check_host（）实际上检查example.com和example.org的记录以获得“通过”结果。只有当这些域中的任何一个都不允许主机时，结果才会是“失败”。
Whether this mechanism matches, does not match, or throws an exception depends on the result of the recursive evaluation of check_host():
此机制是否匹配、不匹配或引发异常取决于check_host（）的递归计算结果：
+---------------------------------+---------------------------------+
| A recursive check_host() result | Causes the "include" mechanism |
| of: | to: |
+---------------------------------+---------------------------------+
| Pass | match |
| | |
| Fail | not match |
| | |
| SoftFail | not match |
| | |
| Neutral | not match |
| | |
| TempError | throw TempError |
| | |
| PermError | throw PermError |
| | |
| None | throw PermError |
+---------------------------------+---------------------------------+
+---------------------------------+---------------------------------+
| A recursive check_host() result | Causes the "include" mechanism |
| of: | to: |
+---------------------------------+---------------------------------+
| Pass | match |
| | |
| Fail | not match |
| | |
| SoftFail | not match |
| | |
| Neutral | not match |
| | |
| TempError | throw TempError |
| | |
| PermError | throw PermError |
| | |
| None | throw PermError |
+---------------------------------+---------------------------------+
The "include" mechanism is intended for crossing administrative boundaries. Although it is possible to use includes to consolidate multiple domains that share the same set of designated hosts, domains are encouraged to use redirects where possible, and to minimize the number of includes within a single administrative domain. For example, if example.com and example.org were managed by the same entity, and if the permitted set of hosts for both domains was "mx:example.com", it would be possible for example.org to specify "include:example.com", but it would be preferable to specify "redirect=example.com" or even "mx:example.com".
“包括”机制旨在跨越行政界限。虽然可以使用包含来合并共享同一组指定主机的多个域，但鼓励域在可能的情况下使用重定向，并尽量减少单个管理域中包含的数量。例如，如果example.com和example.org由同一实体管理，并且如果两个域允许的主机集是“mx:example.com”，example.org可以指定“include:example.com”，但最好指定“redirect=example.com”甚至“mx:example.com”。
This mechanism matches if <ip> is one of the <target-name>'s IP addresses.
如果<ip>是<target name>的ip地址之一，则此机制匹配。
A = "a" [ ":" domain-spec ] [ dual-cidr-length ]
A=“A”[“：”域规范][双cidr长度]
An address lookup is done on the <target-name>. The <ip> is compared to the returned address(es). If any address matches, the mechanism matches.
在<target name>上执行地址查找。将<ip>与返回的地址进行比较。如果任何地址匹配，则机制匹配。
This mechanism matches if <ip> is one of the MX hosts for a domain name.
如果<ip>是域名的MX主机之一，则此机制匹配。
MX = "mx" [ ":" domain-spec ] [ dual-cidr-length ]
MX=“MX”[”：“域规范][双cidr长度]
check_host() first performs an MX lookup on the <target-name>. Then it performs an address lookup on each MX name returned. The <ip> is compared to each returned IP address. To prevent Denial of Service (DoS) attacks, more than 10 MX names MUST NOT be looked up during the evaluation of an "mx" mechanism (see Section 10). If any address matches, the mechanism matches.
check_host（）首先对<target name>执行MX查找。然后，它对返回的每个MX名称执行地址查找。将<ip>与每个返回的ip地址进行比较。为防止拒绝服务（DoS）攻击，在评估“MX”机制期间，不得查找超过10个MX名称（见第10节）。如果任何地址匹配，则机制匹配。
Note regarding implicit MXs: If the <target-name> has no MX records, check_host() MUST NOT pretend the target is its single MX, and MUST NOT default to an A lookup on the <target-name> directly. This behavior breaks with the legacy "implicit MX" rule. See [RFC2821], Section 5. If such behavior is desired, the publisher should specify an "a" directive.
关于隐式MX的注意事项：如果<target name>没有MX记录，则check_host（）不得假装目标是其单个MX，也不得直接默认为对<target name>进行A查找。此行为违反了传统的“隐式MX”规则。见[RFC2821]，第5节。如果需要这种行为，发布者应该指定一个“a”指令。
This mechanism tests whether the DNS reverse-mapping for <ip> exists and correctly points to a domain name within a particular domain.
此机制测试<ip>的DNS反向映射是否存在并正确指向特定域中的域名。
PTR = "ptr" [ ":" domain-spec ]
PTR=“PTR”[“：”域规范]
First, the <ip>'s name is looked up using this procedure: perform a DNS reverse-mapping for <ip>, looking up the corresponding PTR record in "in-addr.arpa." if the address is an IPv4 one and in "ip6.arpa." if it is an IPv6 address. For each record returned, validate the domain name by looking up its IP address. To prevent DoS attacks, more than 10 PTR names MUST NOT be looked up during the evaluation of a "ptr" mechanism (see Section 10). If <ip> is among the returned IP addresses, then that domain name is validated. In pseudocode:
首先，使用以下过程查找<ip>的名称：对<ip>执行DNS反向映射，如果地址是IPv4地址，则在“in addr.arpa.”中查找相应的PTR记录，如果地址是IPv6地址，则在“ip6.arpa.”中查找。对于返回的每个记录，通过查找其IP地址来验证域名。为了防止DoS攻击，在评估“PTR”机制期间，不得查找超过10个PTR名称（参见第10节）。如果<ip>在返回的ip地址中，则验证该域名。在伪代码中：
sending-domain_names := ptr_lookup(sending-host_IP); if more than 10
sending-domain_names are found, use at most 10. for each name in
(sending-domain_names) {
IP_addresses := a_lookup(name);
if the sending-domain_IP is one of the IP_addresses {
validated-sending-domain_names += name;
} }
sending-domain_names := ptr_lookup(sending-host_IP); if more than 10
sending-domain_names are found, use at most 10. for each name in
(sending-domain_names) {
IP_addresses := a_lookup(name);
if the sending-domain_IP is one of the IP_addresses {
validated-sending-domain_names += name;
} }
Check all validated domain names to see if they end in the <target-name> domain. If any do, this mechanism matches. If no validated domain name can be found, or if none of the validated
检查所有已验证的域名，查看它们是否以<target name>域结尾。如果有，则此机制匹配。如果找不到经过验证的域名，或者如果没有经过验证的
domain names end in the <target-name>, this mechanism fails to match. If a DNS error occurs while doing the PTR RR lookup, then this mechanism fails to match. If a DNS error occurs while doing an A RR lookup, then that domain name is skipped and the search continues.
域名以<target name>结尾，此机制无法匹配。如果在执行PTR RR查找时发生DNS错误，则此机制无法匹配。如果在执行RR查找时发生DNS错误，则跳过该域名并继续搜索。
Pseudocode:
伪代码：
for each name in (validated-sending-domain_names) {
if name ends in <domain-spec>, return match.
if name is <domain-spec>, return match.
}
return no-match.
for each name in (validated-sending-domain_names) {
if name ends in <domain-spec>, return match.
if name is <domain-spec>, return match.
}
return no-match.
This mechanism matches if the <target-name> is either an ancestor of a validated domain name or if the <target-name> and a validated domain name are the same. For example: "mail.example.com" is within the domain "example.com", but "mail.bad-example.com" is not.
如果<target name>是已验证域名的祖先，或者<target name>和已验证域名相同，则此机制匹配。例如：“mail.example.com”在域“example.com”中，但“mail.bad example.com”不在域“example.com”中。
Note: Use of this mechanism is discouraged because it is slow, it is not as reliable as other mechanisms in cases of DNS errors, and it places a large burden on the arpa name servers. If used, proper PTR records must be in place for the domain's hosts and the "ptr" mechanism should be one of the last mechanisms checked.
注意：不鼓励使用此机制，因为它速度慢，在DNS错误情况下不如其他机制可靠，并且会给arpa名称服务器带来很大负担。如果使用，必须为域的主机准备适当的PTR记录，“PTR”机制应该是最后检查的机制之一。
These mechanisms test whether <ip> is contained within a given IP network.
这些机制测试<ip>是否包含在给定的ip网络中。
IP4 = "ip4" ":" ip4-network [ ip4-cidr-length ]
IP6 = "ip6" ":" ip6-network [ ip6-cidr-length ]
IP4 = "ip4" ":" ip4-network [ ip4-cidr-length ]
IP6 = "ip6" ":" ip6-network [ ip6-cidr-length ]
ip4-cidr-length = "/" 1*DIGIT
ip6-cidr-length = "/" 1*DIGIT
dual-cidr-length = [ ip4-cidr-length ] [ "/" ip6-cidr-length ]
ip4-cidr-length = "/" 1*DIGIT
ip6-cidr-length = "/" 1*DIGIT
dual-cidr-length = [ ip4-cidr-length ] [ "/" ip6-cidr-length ]
ip4-network = qnum "." qnum "." qnum "." qnum
qnum = DIGIT ; 0-9
/ %x31-39 DIGIT ; 10-99
/ "1" 2DIGIT ; 100-199
/ "2" %x30-34 DIGIT ; 200-249
/ "25" %x30-35 ; 250-255
; as per conventional dotted quad notation. e.g., 192.0.2.0
ip6-network = <as per [RFC 3513], section 2.2>
; e.g., 2001:DB8::CD30
ip4-network = qnum "." qnum "." qnum "." qnum
qnum = DIGIT ; 0-9
/ %x31-39 DIGIT ; 10-99
/ "1" 2DIGIT ; 100-199
/ "2" %x30-34 DIGIT ; 200-249
/ "25" %x30-35 ; 250-255
; as per conventional dotted quad notation. e.g., 192.0.2.0
ip6-network = <as per [RFC 3513], section 2.2>
; e.g., 2001:DB8::CD30
The <ip> is compared to the given network. If CIDR-length high-order bits match, the mechanism matches.
将<ip>与给定网络进行比较。如果CIDR长度高阶位匹配，则机制匹配。
If ip4-cidr-length is omitted, it is taken to be "/32". If ip6-cidr-length is omitted, it is taken to be "/128". It is not permitted to omit parts of the IP address instead of using CIDR notations. That is, use 192.0.2.0/24 instead of 192.0.2.
如果省略ip4 cidr长度，则取“/32”。如果省略ip6 cidr长度，则取“/128”。不允许省略部分IP地址而不是使用CIDR符号。也就是说，使用192.0.2.0/24而不是192.0.2。
This mechanism is used to construct an arbitrary domain name that is used for a DNS A record query. It allows for complicated schemes involving arbitrary parts of the mail envelope to determine what is permitted.
此机制用于构造用于DNS a记录查询的任意域名。它允许涉及邮件信封任意部分的复杂方案来确定允许的内容。
exists = "exists" ":" domain-spec
exists=“exists”“：”域规范
The domain-spec is expanded as per Section 8. The resulting domain name is used for a DNS A RR lookup. If any A record is returned, this mechanism matches. The lookup type is A even when the connection type is IPv6.
域规范按照第8节进行扩展。生成的域名用于DNS a RR查找。如果返回任何A记录，则此机制匹配。即使连接类型为IPv6，查找类型也为。
Domains can use this mechanism to specify arbitrarily complex queries. For example, suppose example.com publishes the record:
域可以使用此机制指定任意复杂的查询。例如，假设example.com发布记录：
v=spf1 exists:%{ir}.%{l1r+-}._spf.%{d} -all
v=spf1 exists:%{ir}.%{l1r+-}._spf.%{d} -all
The <target-name> might expand to "1.2.0.192.someuser._spf.example.com". This makes fine-grained decisions possible at the level of the user and client IP address.
<target name>可能会扩展到“1.2.0.192.someuser.\u spf.example.com”。这使得在用户和客户端IP地址级别进行细粒度决策成为可能。
This mechanism enables queries that mimic the style of tests that existing anti-spam DNS blacklists (DNSBL) use.
此机制支持模拟现有反垃圾邮件DNS黑名单（DNSBL）使用的测试样式的查询。
Modifiers are name/value pairs that provide additional information. Modifiers always have an "=" separating the name and the value.
修饰符是提供附加信息的名称/值对。修饰符始终有一个“=”分隔名称和值。
The modifiers defined in this document ("redirect" and "exp") MAY appear anywhere in the record, but SHOULD appear at the end, after all mechanisms. Ordering of these two modifiers does not matter. These two modifiers MUST NOT appear in a record more than once each. If they do, then check_host() exits with a result of "PermError".
本文档中定义的修饰符（“重定向”和“exp”）可能出现在记录中的任何位置，但应出现在所有机制之后的末尾。这两个修饰符的顺序无关紧要。这两个修饰符在记录中的出现次数不得超过一次。如果是，则检查_host（）是否退出，结果为“PermError”。
Unrecognized modifiers MUST be ignored no matter where in a record, or how often. This allows implementations of this document to gracefully handle records with modifiers that are defined in other specifications.
无论记录中的位置或频率如何，都必须忽略无法识别的修饰符。这使得本文档的实现能够使用其他规范中定义的修饰符优雅地处理记录。
If all mechanisms fail to match, and a "redirect" modifier is present, then processing proceeds as follows:
如果所有机制都不匹配，并且存在“重定向”修饰符，则处理过程如下：
redirect = "redirect" "=" domain-spec
redirect=“redirect”“=”域规范
The domain-spec portion of the redirect section is expanded as per the macro rules in Section 8. Then check_host() is evaluated with the resulting string as the <domain>. The <ip> and <sender> arguments remain the same as current evaluation of check_host().
重定向部分的域规范部分按照第8部分中的宏规则展开。然后，check_host（）将使用结果字符串作为<domain>进行计算。<ip>和<sender>参数与check_host（）的当前计算结果保持相同。
The result of this new evaluation of check_host() is then considered the result of the current evaluation with the exception that if no SPF record is found, or if the target-name is malformed, the result is a "PermError" rather than "None".
然后，check_host（）的新求值结果被视为当前求值的结果，但如果未找到SPF记录，或者如果目标名称格式不正确，则结果为“PermError”而不是“None”。
Note that the newly-queried domain may itself specify redirect processing.
请注意，新查询的域本身可能会指定重定向处理。
This facility is intended for use by organizations that wish to apply the same record to multiple domains. For example:
此功能旨在供希望将同一记录应用于多个域的组织使用。例如：
la.example.com. TXT "v=spf1 redirect=_spf.example.com"
ny.example.com. TXT "v=spf1 redirect=_spf.example.com"
sf.example.com. TXT "v=spf1 redirect=_spf.example.com"
_spf.example.com. TXT "v=spf1 mx:example.com -all"
la.example.com. TXT "v=spf1 redirect=_spf.example.com"
ny.example.com. TXT "v=spf1 redirect=_spf.example.com"
sf.example.com. TXT "v=spf1 redirect=_spf.example.com"
_spf.example.com. TXT "v=spf1 mx:example.com -all"
In this example, mail from any of the three domains is described by the same record. This can be an administrative advantage.
在本例中，来自三个域中任意一个域的邮件由同一记录描述。这可能是一种管理优势。
Note: In general, the domain "A" cannot reliably use a redirect to another domain "B" not under the same administrative control. Since the <sender> stays the same, there is no guarantee that the record at domain "B" will correctly work for mailboxes in domain "A", especially if domain "B" uses mechanisms involving localparts. An "include" directive may be more appropriate.
注意：通常，域“A”无法可靠地使用重定向到不在同一管理控制下的另一个域“B”。由于<sender>保持不变，因此无法保证域“B”中的记录将正确用于域“A”中的邮箱，特别是如果域“B”使用涉及localpart的机制。“包含”指令可能更合适。
For clarity, it is RECOMMENDED that any "redirect" modifier appear as the very last term in a record.
为清楚起见，建议将任何“重定向”修饰符显示为记录中的最后一项。
explanation = "exp" "=" domain-spec
解释=“exp”“=”域规范
If check_host() results in a "Fail" due to a mechanism match (such as "-all"), and the "exp" modifier is present, then the explanation string returned is computed as described below. If no "exp" modifier
如果check_host（）由于机制匹配（例如“-all”）而导致“失败”，并且存在“exp”修饰符，则返回的解释字符串将按如下所述进行计算。如果没有“exp”修饰符
is present, then either a default explanation string or an empty explanation string may be returned.
则可以返回默认解释字符串或空解释字符串。
The <domain-spec> is macro expanded (see Section 8) and becomes the <target-name>. The DNS TXT record for the <target-name> is fetched.
<domain spec>被宏扩展（参见第8节），并成为<target name>。获取<target name>的DNS TXT记录。
If <domain-spec> is empty, or there are any DNS processing errors (any RCODE other than 0), or if no records are returned, or if more than one record is returned, or if there are syntax errors in the explanation string, then proceed as if no exp modifier was given.
如果<domain spec>为空，或者存在任何DNS处理错误（除0以外的任何RCODE），或者如果未返回任何记录，或者如果返回多个记录，或者如果解释字符串中存在语法错误，则继续操作，就像未给出exp修饰符一样。
The fetched TXT record's strings are concatenated with no spaces, and then treated as an <explain-string>, which is macro-expanded. This final result is the explanation string. Implementations MAY limit the length of the resulting explanation string to allow for other protocol constraints and/or reasonable processing limits. Since the explanation string is intended for an SMTP response and [RFC2821] Section 2.4 says that responses are in [US-ASCII], the explanation string is also limited to US-ASCII.
获取的TXT记录的字符串被连接起来，没有空格，然后被视为一个被宏扩展的<explain string>。最后的结果就是解释字符串。实现可能会限制结果解释字符串的长度，以允许其他协议约束和/或合理的处理限制。由于解释字符串用于SMTP响应，[RFC2821]第2.4节规定响应为[US-ASCII]，因此解释字符串也仅限于US-ASCII。
Software evaluating check_host() can use this string to communicate information from the publishing domain in the form of a short message or URL. Software SHOULD make it clear that the explanation string comes from a third party. For example, it can prepend the macro string "%{o} explains: " to the explanation, such as shown in Section 2.5.4.
可以使用主机URL（）或主机URL（）的短字符串形式来传递发布信息。软件应明确说明解释字符串来自第三方。例如，它可以在解释前面加上宏字符串“{o}explains:”，如第2.5.4节所示。
Suppose example.com has this record:
假设example.com有以下记录：
v=spf1 mx -all exp=explain._spf.%{d}
v=spf1 mx -all exp=explain._spf.%{d}
Here are some examples of possible explanation TXT records at explain._spf.example.com:
以下是explain.spf.EXPLACE.com上可能的解释TXT记录的一些示例：
"Mail from example.com should only be sent by its own servers." -- a simple, constant message
“来自example.com的邮件只能由它自己的服务器发送。”——一条简单、不变的消息
"%{i} is not one of %{d}'s designated mail servers."
-- a message with a little more information, including the IP
address that failed the check
"%{i} is not one of %{d}'s designated mail servers."
-- a message with a little more information, including the IP
address that failed the check
"See http://%{d}/why.html?s=%{S}&i=%{I}"
-- a complicated example that constructs a URL with the
arguments to check_host() so that a web page can be
generated with detailed, custom instructions
"See http://%{d}/why.html?s=%{S}&i=%{I}"
-- a complicated example that constructs a URL with the
arguments to check_host() so that a web page can be
generated with detailed, custom instructions
Note: During recursion into an "include" mechanism, an exp= modifier
from the <target-name> MUST NOT be used. In contrast, when executing
Note: During recursion into an "include" mechanism, an exp= modifier
from the <target-name> MUST NOT be used. In contrast, when executing
a "redirect" modifier, an exp= modifier from the original domain MUST NOT be used.
不能使用“重定向”修饰符，即来自原始域的exp=修饰符。
It is RECOMMENDED that SMTP receivers record the result of SPF processing in the message header. If an SMTP receiver chooses to do so, it SHOULD use the "Received-SPF" header field defined here for each identity that was checked. This information is intended for the recipient. (Information intended for the sender is described in Section 6.2, Explanation.)
建议SMTP收件人在邮件头中记录SPF处理的结果。如果SMTP接收方选择这样做，则应使用此处为每个检查的标识定义的“Received SPF”标头字段。此信息仅供收件人使用。（第6.2节“解释”中描述了发送人的信息。）
The Received-SPF header field is a trace field (see [RFC2822] Section 3.6.7) and SHOULD be prepended to the existing header, above the Received: field that is generated by the SMTP receiver. It MUST appear above all other Received-SPF fields in the message. The header field has the following format:
接收到的SPF标头字段是一个跟踪字段（请参见[RFC2822]第3.6.7节），应在现有标头之前，位于SMTP接收器生成的Received:字段上方。它必须出现在消息中所有其他收到的SPF字段的上方。标题字段的格式如下：
header-field = "Received-SPF:" [CFWS] result FWS [comment FWS] [ key-value-list ] CRLF
header field=“Received SPF:[CFWS]结果FWS[注释FWS][键值列表]CRLF
result = "Pass" / "Fail" / "SoftFail" / "Neutral" /
"None" / "TempError" / "PermError"
result = "Pass" / "Fail" / "SoftFail" / "Neutral" /
"None" / "TempError" / "PermError"
key-value-list = key-value-pair *( ";" [CFWS] key-value-pair )
[";"]
key-value-list = key-value-pair *( ";" [CFWS] key-value-pair )
[";"]
key-value-pair = key [CFWS] "=" ( dot-atom / quoted-string )
key-value-pair = key [CFWS] "=" ( dot-atom / quoted-string )
key = "client-ip" / "envelope-from" / "helo" /
"problem" / "receiver" / "identity" /
mechanism / "x-" name / name
key = "client-ip" / "envelope-from" / "helo" /
"problem" / "receiver" / "identity" /
mechanism / "x-" name / name
identity = "mailfrom" ; for the "MAIL FROM" identity
/ "helo" ; for the "HELO" identity
/ name ; other identities
identity = "mailfrom" ; for the "MAIL FROM" identity
/ "helo" ; for the "HELO" identity
/ name ; other identities
dot-atom = <unquoted word as per [RFC2822]>
quoted-string = <quoted string as per [RFC2822]>
comment = <comment string as per [RFC2822]>
CFWS = <comment or folding white space as per [RFC2822]>
FWS = <folding white space as per [RFC2822]>
CRLF = <standard end-of-line token as per [RFC2822]>
dot-atom = <unquoted word as per [RFC2822]>
quoted-string = <quoted string as per [RFC2822]>
comment = <comment string as per [RFC2822]>
CFWS = <comment or folding white space as per [RFC2822]>
FWS = <folding white space as per [RFC2822]>
CRLF = <standard end-of-line token as per [RFC2822]>
The header field SHOULD include a "(...)" style <comment> after the result, conveying supporting information for the result, such as <ip>, <sender>, and <domain>.
标题字段应在结果后包含一个“（…）”样式的<comment>，用于传递结果的支持信息，如<ip>、<sender>和<domain>。
The following key-value pairs are designed for later machine parsing. SPF clients SHOULD give enough information so that the SPF results can be verified. That is, at least "client-ip", "helo", and, if the "MAIL FROM" identity was checked, "envelope-from".
以下键值对是为以后的机器解析而设计的。SPF客户应提供足够的信息，以便验证SPF结果。也就是说，至少是“客户ip”、“helo”，如果选中了“邮件发件人”标识，“信封发件人”。
client-ip the IP address of the SMTP client
客户端ip SMTP客户端的ip地址
envelope-from the envelope sender mailbox
信封发件人邮箱中的信封
helo the host name given in the HELO or EHLO command
helo在helo或EHLO命令中给出的主机名
mechanism the mechanism that matched (if no mechanisms matched, substitute the word "default")
机制匹配的机制（如果没有匹配的机制，则替换“默认”一词）
problem if an error was returned, details about the error
问题如果返回错误，请提供有关错误的详细信息
receiver the host name of the SPF client
receiver SPF客户端的主机名
identity the identity that was checked; see the <identity> ABNF rule
标识已检查的标识；请参阅<identity>ABNF规则
Other keys may be defined by SPF clients. Until a new key name becomes widely accepted, new key names should start with "x-".
其他密钥可由SPF客户端定义。在新的密钥名被广泛接受之前，新的密钥名应该以“x-”开头。
SPF clients MUST make sure that the Received-SPF header field does not contain invalid characters, is not excessively long, and does not contain malicious data that has been provided by the sender.
SPF客户端必须确保接收的SPF标头字段不包含无效字符、不过长，并且不包含发件人提供的恶意数据。
Examples of various header styles that could be generated are the following:
可以生成的各种标题样式的示例如下：
Received-SPF: Pass (mybox.example.org: domain of
myname@example.com designates 192.0.2.1 as permitted sender)
receiver=mybox.example.org; client-ip=192.0.2.1;
envelope-from=<myname@example.com>; helo=foo.example.com;
Received-SPF: Pass (mybox.example.org: domain of
myname@example.com designates 192.0.2.1 as permitted sender)
receiver=mybox.example.org; client-ip=192.0.2.1;
envelope-from=<myname@example.com>; helo=foo.example.com;
Received-SPF: Fail (mybox.example.org: domain of
myname@example.com does not designate
192.0.2.1 as permitted sender)
identity=mailfrom; client-ip=192.0.2.1;
envelope-from=<myname@example.com>;
Received-SPF: Fail (mybox.example.org: domain of
myname@example.com does not designate
192.0.2.1 as permitted sender)
identity=mailfrom; client-ip=192.0.2.1;
envelope-from=<myname@example.com>;
Many mechanisms and modifiers perform macro expansion on part of the term.
许多机制和修饰符对术语的一部分执行宏展开。
domain-spec = macro-string domain-end
domain-end = ( "." toplabel [ "." ] ) / macro-expand
domain-spec = macro-string domain-end
domain-end = ( "." toplabel [ "." ] ) / macro-expand
toplabel = ( *alphanum ALPHA *alphanum ) /
( 1*alphanum "-" *( alphanum / "-" ) alphanum )
; LDH rule plus additional TLD restrictions
; (see [RFC3696], Section 2)
alphanum = ALPHA / DIGIT
toplabel = ( *alphanum ALPHA *alphanum ) /
( 1*alphanum "-" *( alphanum / "-" ) alphanum )
; LDH rule plus additional TLD restrictions
; (see [RFC3696], Section 2)
alphanum = ALPHA / DIGIT
explain-string = *( macro-string / SP )
explain-string = *( macro-string / SP )
macro-string = *( macro-expand / macro-literal )
macro-expand = ( "%{" macro-letter transformers *delimiter "}" )
/ "%%" / "%_" / "%-"
macro-literal = %x21-24 / %x26-7E
; visible characters except "%"
macro-letter = "s" / "l" / "o" / "d" / "i" / "p" / "h" /
"c" / "r" / "t"
transformers = *DIGIT [ "r" ]
delimiter = "." / "-" / "+" / "," / "/" / "_" / "="
macro-string = *( macro-expand / macro-literal )
macro-expand = ( "%{" macro-letter transformers *delimiter "}" )
/ "%%" / "%_" / "%-"
macro-literal = %x21-24 / %x26-7E
; visible characters except "%"
macro-letter = "s" / "l" / "o" / "d" / "i" / "p" / "h" /
"c" / "r" / "t"
transformers = *DIGIT [ "r" ]
delimiter = "." / "-" / "+" / "," / "/" / "_" / "="
A literal "%" is expressed by "%%".
文字“%”用“%”表示。
"%_" expands to a single " " space. "%-" expands to a URL-encoded space, viz., "%20".
“%”扩展到单个“”空间。“%-”扩展为URL编码的空间，即“%20”。
The following macro letters are expanded in term arguments:
以下宏字母在术语参数中展开：
s = <sender>
l = local-part of <sender>
o = domain of <sender>
d = <domain>
i = <ip>
p = the validated domain name of <ip>
v = the string "in-addr" if <ip> is ipv4, or "ip6" if <ip> is ipv6
h = HELO/EHLO domain
s = <sender>
l = local-part of <sender>
o = domain of <sender>
d = <domain>
i = <ip>
p = the validated domain name of <ip>
v = the string "in-addr" if <ip> is ipv4, or "ip6" if <ip> is ipv6
h = HELO/EHLO domain
The following macro letters are allowed only in "exp" text:
以下宏字母仅允许在“exp”文本中使用：
c = SMTP client IP (easily readable format) r = domain name of host performing the check t = current timestamp
c=SMTP客户端IP（易读格式）r=执行检查的主机的域名t=当前时间戳
A '%' character not followed by a '{', '%', '-', or '_' character is a syntax error. So
“%”字符后面没有“{'、“%”、“-”或“"”字符是语法错误。因此
-exists:%(ir).sbl.spamhaus.example.org
-存在：%（ir）.sbl.spamhaus.example.org
is incorrect and will cause check_host() to return a "PermError". Instead, say
不正确，将导致check_host（）返回“PermError”。相反，说
-exists:%{ir}.sbl.spamhaus.example.org
-exists:%{ir}.sbl.spamhaus.example.org
Optional transformers are the following:
可选变压器如下所示：
*DIGIT = zero or more digits 'r' = reverse value, splitting on dots by default
*数字=零或多个数字“r”=反向值，默认情况下在点上拆分
If transformers or delimiters are provided, the replacement value for a macro letter is split into parts. After performing any reversal operation and/or removal of left-hand parts, the parts are rejoined using "." and not the original splitting characters.
如果提供了转换符或分隔符，则宏字母的替换值将拆分为多个部分。执行任何反转操作和/或移除左侧零件后，零件将使用“.”而不是原始拆分字符重新连接。
By default, strings are split on "." (dots). Note that no special treatment is given to leading, trailing, or consecutive delimiters, and so the list of parts may contain empty strings. Older implementations of SPF prohibit trailing dots in domain names, so trailing dots should not be published by domain owners, although they must be accepted by implementations conforming to this document. Macros may specify delimiter characters that are used instead of ".".
默认情况下，字符串在“.”（点）上拆分。请注意，没有对前导、尾随或连续分隔符进行特殊处理，因此部件列表可能包含空字符串。旧的SPF实现禁止域名中的尾随点，因此域名所有者不应发布尾随点，尽管它们必须被符合本文档的实现所接受。宏可以指定使用的分隔符字符，而不是“.”。
The 'r' transformer indicates a reversal operation: if the client IP address were 192.0.2.1, the macro %{i} would expand to "192.0.2.1" and the macro %{ir} would expand to "1.2.0.192".
“r”转换器表示反转操作：如果客户端IP地址为192.0.2.1，则宏%{i}将扩展到“192.0.2.1”，宏%{ir}将扩展到“1.2.0.192”。
The DIGIT transformer indicates the number of right-hand parts to use, after optional reversal. If a DIGIT is specified, the value MUST be nonzero. If no DIGITs are specified, or if the value specifies more parts than are available, all the available parts are used. If the DIGIT was 5, and only 3 parts were available, the macro interpreter would pretend the DIGIT was 3. Implementations MUST support at least a value of 128, as that is the maximum number of labels in a domain name.
数字转换器指示可选反转后要使用的右侧部件的数量。如果指定了数字，则该值必须为非零。如果未指定数字，或者如果该值指定的零件数超过可用零件数，则使用所有可用零件。如果数字是5，并且只有3个部分可用，宏解释器将假装数字是3。实现必须至少支持128的值，因为这是域名中标签的最大数量。
The "s" macro expands to the <sender> argument. It is an E-Mail address with a localpart, an "@" character, and a domain. The "l" macro expands to just the localpart. The "o" macro expands to just the domain part. Note that these values remain the same during recursive and chained evaluations due to "include" and/or "redirect". Note also that if the original <sender> had no localpart, the localpart was set to "postmaster" in initial processing (see Section 4.3).
“s”宏展开为<sender>参数。它是一个带有localpart、“@”字符和域的电子邮件地址。“l”宏仅扩展到localpart。“o”宏仅扩展到域部分。请注意，由于“包含”和/或“重定向”，这些值在递归和链式计算期间保持不变。还请注意，如果原始<sender>没有localpart，则localpart在初始处理中设置为“postmaster”（参见第4.3节）。
For IPv4 addresses, both the "i" and "c" macros expand to the standard dotted-quad format.
对于IPv4地址，“i”和“c”宏都扩展为标准的虚线四元格式。
For IPv6 addresses, the "i" macro expands to a dot-format address; it is intended for use in %{ir}. The "c" macro may expand to any of the hexadecimal colon-format addresses specified in [RFC3513], Section 2.2. It is intended for humans to read.
对于IPv6地址，“i”宏扩展为点格式地址；它用于%{ir}。“c”宏可以扩展到[RFC3513]第2.2节中指定的任何十六进制冒号格式地址。它是供人类阅读的。
The "p" macro expands to the validated domain name of <ip>. The procedure for finding the validated domain name is defined in Section 5.5. If the <domain> is present in the list of validated domains, it SHOULD be used. Otherwise, if a subdomain of the <domain> is present, it SHOULD be used. Otherwise, any name from the list may be used. If there are no validated domain names or if a DNS error occurs, the string "unknown" is used.
“p”宏将扩展到已验证的域名<ip>。第5.5节定义了查找已验证域名的程序。如果验证域列表中存在<domain>，则应使用它。否则，如果存在<domain>的子域，则应使用它。否则，可以使用列表中的任何名称。如果没有经过验证的域名或发生DNS错误，则使用字符串“未知”。
The "r" macro expands to the name of the receiving MTA. This SHOULD be a fully qualified domain name, but if one does not exist (as when the checking is done by a MUA) or if policy restrictions dictate otherwise, the word "unknown" SHOULD be substituted. The domain name may be different from the name found in the MX record that the client MTA used to locate the receiving MTA.
“r”宏扩展为接收MTA的名称。这应该是一个完全限定的域名，但如果一个域名不存在（如MUA进行检查时），或者如果政策限制另有规定，则应替换“未知”一词。域名可能与客户端MTA用于定位接收MTA的MX记录中的名称不同。
The "t" macro expands to the decimal representation of the approximate number of seconds since the Epoch (Midnight, January 1, 1970, UTC). This is the same value as is returned by the POSIX time() function in most standards-compliant libraries.
“t”宏扩展为十进制表示，表示自纪元（1970年1月1日午夜，UTC）以来的大约秒数。这与大多数符合标准的库中POSIX time（）函数返回的值相同。
When the result of macro expansion is used in a domain name query, if the expanded domain name exceeds 253 characters (the maximum length of a domain name), the left side is truncated to fit, by removing successive domain labels until the total length does not exceed 253 characters.
在域名查询中使用宏扩展的结果时，如果扩展的域名超过253个字符（域名的最大长度），则通过删除连续的域标签，将左侧截断以适合查询，直到总长度不超过253个字符。
Uppercased macros expand exactly as their lowercased equivalents, and are then URL escaped. URL escaping must be performed for characters not in the "uric" set, which is defined in [RFC3986].
大写宏完全按照其小写等价项展开，然后进行URL转义。必须对不在[RFC3986]中定义的“URI”集中的字符执行URL转义。
Note: Care must be taken so that macro expansion for legitimate E-Mail does not exceed the 63-character limit on DNS labels. The localpart of E-Mail addresses, in particular, can have more than 63 characters between dots.
注意：必须小心，以便合法电子邮件的宏扩展不会超过DNS标签上63个字符的限制。尤其是电子邮件地址的localpart，点与点之间的字符数可以超过63个。
Note: Domains should avoid using the "s", "l", "o", or "h" macros in conjunction with any mechanism directive. Although these macros are powerful and allow per-user records to be published, they severely limit the ability of implementations to cache results of check_host() and they reduce the effectiveness of DNS caches.
注意：域应避免将“s”、“l”、“o”或“h”宏与任何机制指令结合使用。尽管这些宏功能强大，允许发布每用户记录，但它们严重限制了实现缓存check_host（）结果的能力，并降低了DNS缓存的有效性。
Implementations should be aware that if no directive processed during the evaluation of check_host() contains an "s", "l", "o", or "h" macro, then the results of the evaluation can be cached on the basis of <domain> and <ip> alone for as long as the shortest Time To Live (TTL) of all the DNS records involved.
实现应该注意，如果在check_host（）的计算过程中处理的任何指令都不包含“s”、“l”、“o”或“h”宏，那么计算结果可以仅基于<domain>和<ip>缓存，只要是所涉及的所有DNS记录的最短生存时间（TTL）。
The <sender> is strong-bad@email.example.com. The IPv4 SMTP client IP is 192.0.2.3. The IPv6 SMTP client IP is 2001:DB8::CB01. The PTR domain name of the client IP is mx.example.org.
<sender>很强-bad@email.example.com. IPv4 SMTP客户端IP为192.0.2.3。IPv6 SMTP客户端IP为2001:DB8:：CB01。客户端IP的PTR域名是mx.example.org。
macro expansion
------- ----------------------------
%{s} strong-bad@email.example.com
%{o} email.example.com
%{d} email.example.com
%{d4} email.example.com
%{d3} email.example.com
%{d2} example.com
%{d1} com
%{dr} com.example.email
%{d2r} example.email
%{l} strong-bad
%{l-} strong.bad
%{lr} strong-bad
%{lr-} bad.strong
%{l1r-} strong
macro expansion
------- ----------------------------
%{s} strong-bad@email.example.com
%{o} email.example.com
%{d} email.example.com
%{d4} email.example.com
%{d3} email.example.com
%{d2} example.com
%{d1} com
%{dr} com.example.email
%{d2r} example.email
%{l} strong-bad
%{l-} strong.bad
%{lr} strong-bad
%{lr-} bad.strong
%{l1r-} strong
macro-string expansion
--------------------------------------------------------------------
%{ir}.%{v}._spf.%{d2} 3.2.0.192.in-addr._spf.example.com
%{lr-}.lp._spf.%{d2} bad.strong.lp._spf.example.com
macro-string expansion
--------------------------------------------------------------------
%{ir}.%{v}._spf.%{d2} 3.2.0.192.in-addr._spf.example.com
%{lr-}.lp._spf.%{d2} bad.strong.lp._spf.example.com
%{lr-}.lp.%{ir}.%{v}._spf.%{d2}
bad.strong.lp.3.2.0.192.in-addr._spf.example.com
%{lr-}.lp.%{ir}.%{v}._spf.%{d2}
bad.strong.lp.3.2.0.192.in-addr._spf.example.com
%{ir}.%{v}.%{l1r-}.lp._spf.%{d2}
3.2.0.192.in-addr.strong.lp._spf.example.com
%{ir}.%{v}.%{l1r-}.lp._spf.%{d2}
3.2.0.192.in-addr.strong.lp._spf.example.com
%{d2}.trusted-domains.example.net example.com.trusted-domains.example.net
%{d2}.trusted-domains.example.net example.com.trusted-domains.example.net
IPv6:
%{ir}.%{v}._spf.%{d2} 1.0.B.C.0.0.0.0.
0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.B.D.0.1.0.0.2.ip6._spf.example.com
IPv6:
%{ir}.%{v}._spf.%{d2} 1.0.B.C.0.0.0.0.
0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.B.D.0.1.0.0.2.ip6._spf.example.com
This section outlines the major implications that adoption of this document will have on various entities involved in Internet E-Mail. It is intended to make clear to the reader where this document knowingly affects the operation of such entities. This section is not a "how-to" manual, or a "best practices" document, and it is not a comprehensive list of what such entities should do in light of this document.
本节概述了采用本文件将对涉及互联网电子邮件的各个实体产生的主要影响。本文件旨在向读者明确本文件在哪些方面故意影响此类实体的运作。本节不是“操作”手册或“最佳实践”文件，也不是此类实体根据本文件应做什么的综合清单。
This section is non-normative.
本节是非规范性的。
Domains that wish to be compliant with this specification will need to determine the list of hosts that they allow to use their domain name in the "HELO" and "MAIL FROM" identities. It is recognized that forming such a list is not just a simple technical exercise, but involves policy decisions with both technical and administrative considerations.
希望符合此规范的域需要确定允许在“HELO”和“MAIL FROM”标识中使用其域名的主机列表。人们认识到，形成这样一份清单不仅是一项简单的技术工作，而且涉及到技术和行政考虑的政策决定。
It can be helpful to publish records that include a "tracking exists:" mechanism. By looking at the name server logs, a rough list may then be generated. For example:
发布包含“跟踪存在：”机制的记录可能会有所帮助。通过查看名称服务器日志，可以生成一个粗略的列表。例如：
v=spf1 exists:_h.%{h}._l.%{l}._o.%{o}._i.%{i}._spf.%{d} ?all
v=spf1 exists:_h.%{h}._l.%{l}._o.%{o}._i.%{i}._spf.%{d} ?all
Mailing lists must be aware of how they re-inject mail that is sent to the list. Mailing lists MUST comply with the requirements in [RFC2821], Section 3.10, and [RFC1123], Section 5.3.6, that say that the reverse-path MUST be changed to be the mailbox of a person or other entity who administers the list. Whereas the reasons for changing the reverse-path are many and long-standing, SPF adds enforcement to this requirement.
邮件列表必须知道它们如何重新注入发送到列表的邮件。邮件列表必须符合[RFC2821]第3.10节和[RFC1123]第5.3.6节的要求，即反向路径必须更改为管理列表的个人或其他实体的邮箱。鉴于改变反向路径的原因很多且由来已久，SPF增加了对该要求的强制执行。
In practice, almost all mailing list software in use already complies with this requirement. Mailing lists that do not comply may or may not encounter problems depending on how access to the list is restricted. Such lists that are entirely internal to a domain (only people in the domain can send to or receive from the list) are not affected.
实际上，几乎所有正在使用的邮件列表软件都已经符合这一要求。不符合要求的邮件列表可能会遇到问题，也可能不会遇到问题，这取决于对列表访问的限制。这种完全在域内部的列表（只有域中的人可以发送到列表或从列表中接收）不受影响。
Forwarding services take mail that is received at a mailbox and direct it to some external mailbox. At the time of this writing, the near-universal practice of such services is to use the original "MAIL FROM" of a message when re-injecting it for delivery to the external mailbox. [RFC1123] and [RFC2821] describe this action as an "alias" rather than a "mail list". This means that the external mailbox's MTA sees all such mail in a connection from a host of the forwarding service, and so the "MAIL FROM" identity will not, in general, pass authorization.
转发服务接收邮箱接收的邮件，并将其定向到某个外部邮箱。在撰写本文时，这类服务近乎普遍的做法是在将邮件重新注入外部邮箱时使用邮件的原始“邮件发件人”。[RFC1123]和[RFC2821]将此操作描述为“别名”，而不是“邮件列表”。这意味着外部邮箱的MTA会看到来自转发服务主机的连接中的所有此类邮件，因此“邮件发件人”标识通常不会通过授权。
There are three places that techniques can be used to ameliorate this problem.
有三种方法可以用来改善这个问题。
1. The beginning, when E-Mail is first sent.
1. 第一次发送电子邮件时的开头。
1. "Neutral" results could be given for IP addresses that may be forwarders, instead of "Fail" results. For example:
1. 对于可能是转发器的IP地址，可以给出“中性”结果，而不是“失败”结果。例如：
"v=spf1 mx -exists:%{ir}.sbl.spamhaus.example.org ?all"
"v=spf1 mx -exists:%{ir}.sbl.spamhaus.example.org ?all"
This would cause a lookup on an anti-spam DNS blacklist (DNSBL) and cause a result of "Fail" only for E-Mail coming from listed sources. All other E-Mail, including E-Mail sent through forwarders, would receive a "Neutral" result. By checking the DNSBL after the known good sources, problems with incorrect listing on the DNSBL are greatly reduced.
这将导致查找反垃圾邮件DNS黑名单（DNSBL），并导致仅对来自列出来源的电子邮件“失败”。所有其他电子邮件，包括通过转发器发送的电子邮件，都将收到“中性”结果。通过在已知良好源之后检查DNSBL，DNSBL上错误列表的问题将大大减少。
2. The "MAIL FROM" identity could have additional information in the localpart that cryptographically identifies the mail as coming from an authorized source. In this case, such an SPF record could be used:
2. “邮件发件人”标识可以在localpart中包含其他信息，以加密方式将邮件标识为来自授权来源。在这种情况下，可以使用这样的SPF记录：
"v=spf1 mx exists:%{l}._spf_verify.%{d} -all"
"v=spf1 mx exists:%{l}._spf_verify.%{d} -all"
Then, a specialized DNS server can be set up to serve the _spf_verify subdomain that validates the localpart. Although this requires an extra DNS lookup, this happens only when the E-Mail would otherwise be rejected as not coming from a known good source.
然后，可以设置专门的DNS服务器来为验证localpart的_spf_verify子域提供服务。尽管这需要额外的DNS查找，但只有当电子邮件因来源不明而被拒绝时，才会发生这种情况。
Note that due to the 63-character limit for domain labels, this approach only works reliably if the localpart signature scheme is guaranteed either to only produce localparts with a maximum of 63 characters or to gracefully handle truncated localparts.
请注意，由于域标签的长度限制为63个字符，只有在保证localpart签名方案只生成最多63个字符的localpart或优雅地处理截断的localpart时，这种方法才能可靠地工作。
3. Similarly, a specialized DNS server could be set up that will rate-limit the E-Mail coming from unexpected IP addresses.
3. 类似地，可以设置专门的DNS服务器，对来自意外IP地址的电子邮件进行速率限制。
"v=spf1 mx exists:%{ir}._spf_rate.%{d} -all"
"v=spf1 mx exists:%{ir}._spf_rate.%{d} -all"
4. SPF allows the creation of per-user policies for special cases. For example, the following SPF record and appropriate wildcard DNS records can be used:
4. SPF允许为特殊情况创建每用户策略。例如，可以使用以下SPF记录和适当的通配符DNS记录：
"v=spf1 mx redirect=%{l1r+}._at_.%{o}._spf.%{d}"
"v=spf1 mx redirect=%{l1r+}._at_.%{o}._spf.%{d}"
2. The middle, when E-Mail is forwarded.
2. 中间，当电子邮件被转发时。
1. Forwarding services can solve the problem by rewriting the "MAIL FROM" to be in their own domain. This means that mail bounced from the external mailbox will have to be re-bounced by the forwarding service. Various schemes to do this exist though they vary widely in complexity and resource requirements on the part of the forwarding service.
1. 转发服务可以通过将“邮件发件人”重写为其自己的域来解决此问题。这意味着从外部邮箱跳转的邮件必须由转发服务重新跳转。尽管转发服务的复杂性和资源需求差异很大，但实现这一点的方案多种多样。
2. Several popular MTAs can be forced from "alias" semantics to "mailing list" semantics by configuring an additional alias with "owner-" prepended to the original alias name (e.g., an alias of "friends: george@example.com, fred@example.org" would need another alias of the form "owner-friends: localowner").
2. 通过将附加别名配置为原始别名前面加上“owner-”（例如，“friends:george@example.com, fred@example.org“将需要另一个“所有者朋友：localowner”形式的别名。
3. The end, when E-Mail is received.
3. 当收到电子邮件时结束。
1. If the owner of the external mailbox wishes to trust the forwarding service, he can direct the external mailbox's MTA to skip SPF tests when the client host belongs to the forwarding service.
1. 如果外部邮箱的所有者希望信任转发服务，则当客户端主机属于转发服务时，他可以指示外部邮箱的MTA跳过SPF测试。
2. Tests against other identities, such as the "HELO" identity, may be used to override a failed test against the "MAIL FROM" identity.
2. 针对其他身份（如“直升机”身份）的测试可用于覆盖针对“邮件发件人”身份的失败测试。
3. For larger domains, it may not be possible to have a complete or accurate list of forwarding services used by the owners of the domain's mailboxes. In such cases, whitelists of generally-recognized forwarding services could be employed.
3. 对于较大的域，可能无法获得域邮箱所有者使用的转发服务的完整或准确列表。在这种情况下，可以使用公认的转发服务白名单。
Service providers that offer mail services to third-party domains, such as sending of bulk mail, may want to adjust their setup in light of the authorization check described in this document. If the "MAIL FROM" identity used for such E-Mail uses the domain of the service provider, then the provider needs only to ensure that its sending host is authorized by its own SPF record, if any.
向第三方域提供邮件服务（如发送批量邮件）的服务提供商可能希望根据本文档中描述的授权检查调整其设置。如果用于此类电子邮件的“邮件发件人”标识使用服务提供商的域，则提供商只需确保其发送主机由其自己的SPF记录（如果有）授权。
If the "MAIL FROM" identity does not use the mail service provider's domain, then extra care must be taken. The SPF record format has several options for the third-party domain to authorize the service provider's MTAs to send mail on its behalf. For mail service providers, such as ISPs, that have a wide variety of customers using the same MTA, steps should be taken to prevent cross-customer forgery (see Section 10.4).
如果“邮件发件人”标识未使用邮件服务提供商的域，则必须格外小心。SPF记录格式为第三方域提供了多个选项，以授权服务提供商的MTA代表其发送邮件。对于使用相同MTA的各种客户的邮件服务提供商（如ISP），应采取措施防止跨客户伪造（见第10.4节）。
The authorization check generally precludes the use of arbitrary MTA relays between sender and receiver of an E-Mail message.
授权检查通常禁止在电子邮件的发件人和收件人之间使用任意MTA中继。
Within an organization, MTA relays can be effectively deployed. However, for purposes of this document, such relays are effectively transparent. The SPF authorization check is a check between border MTAs of different domains.
在一个组织内，可以有效地部署MTA中继。然而，就本文件而言，此类继电器实际上是透明的。SPF授权检查是不同域的边界MTA之间的检查。
For mail senders, this means that published SPF records must authorize any MTAs that actually send across the Internet. Usually, these are just the border MTAs as internal MTAs simply forward mail to these MTAs for delivery.
对于邮件发件人，这意味着已发布的SPF记录必须授权任何实际通过Internet发送的MTA。通常，这些只是边界MTA，因为内部MTA只是将邮件转发给这些MTA进行传递。
Mail receivers will generally want to perform the authorization check at the border MTAs, specifically including all secondary MXs. This allows mail that fails to be rejected during the SMTP session rather than bounced. Internal MTAs then do not perform the authorization test. To perform the authorization test other than at the border, the host that first transferred the message to the organization must be determined, which can be difficult to extract from the message header. Testing other than at the border is not recommended.
邮件接收者通常希望在边界MTA上执行授权检查，特别是包括所有辅助MX。这允许在SMTP会话期间拒绝失败的邮件，而不是退回。然后，内部MTA不执行授权测试。要执行授权测试，而不是在边界，必须确定首先将邮件传输到组织的主机，这可能很难从邮件头中提取。不建议在边境以外的地方进行测试。
As with most aspects of E-Mail, there are a number of ways that malicious parties could use the protocol as an avenue for a Denial-of-Service (DoS) attack. The processing limits outlined here are designed to prevent attacks such as the following:
与电子邮件的大多数方面一样，恶意方可以通过多种方式利用该协议进行拒绝服务（DoS）攻击。此处概述的处理限制旨在防止以下攻击：
o A malicious party could create an SPF record with many references to a victim's domain and send many E-Mails to different SPF clients; those SPF clients would then create a DoS attack. In effect, the SPF clients are being used to amplify the attacker's bandwidth by using fewer bytes in the SMTP session than are used by the DNS queries. Using SPF clients also allows the attacker to hide the true source of the attack.
o 恶意方可以创建一个SPF记录，其中包含对受害者域的许多引用，并向不同的SPF客户端发送许多电子邮件；然后，这些SPF客户端将创建DoS攻击。实际上，SPF客户端通过在SMTP会话中使用比DNS查询更少的字节来放大攻击者的带宽。使用SPF客户端还允许攻击者隐藏攻击的真实来源。
o Whereas implementations of check_host() are supposed to limit the number of DNS lookups, malicious domains could publish records that exceed these limits in an attempt to waste computation effort at their targets when they send them mail. Malicious domains could also design SPF records that cause particular implementations to use excessive memory or CPU usage, or to trigger bugs.
o 虽然check_host（）的实现应该限制DNS查找的数量，但恶意域可能会发布超过这些限制的记录，从而在向目标发送邮件时浪费计算时间。恶意域还可能设计SPF记录，导致特定实现使用过多内存或CPU，或触发错误。
o Malicious parties could send a large volume of mail purporting to come from the intended target to a wide variety of legitimate mail hosts. These legitimate machines would then present a DNS load on the target as they fetched the relevant records.
o 恶意方可以将大量声称来自预期目标的邮件发送到各种合法邮件主机。当这些合法机器获取相关记录时，它们将在目标上呈现DNS负载。
Of these, the case of a third party referenced in the SPF record is the easiest for a DoS attack to effectively exploit. As a result, limits that may seem reasonable for an individual mail server can still allow an unreasonable amount of bandwidth amplification. Therefore, the processing limits need to be quite low.
其中，SPF记录中引用的第三方的情况最容易被DoS攻击有效利用。因此，对于单个邮件服务器来说似乎合理的限制仍然允许不合理的带宽放大。因此，处理限制需要非常低。
SPF implementations MUST limit the number of mechanisms and modifiers that do DNS lookups to at most 10 per SPF check, including any lookups caused by the use of the "include" mechanism or the
SPF实现必须将每次SPF检查进行DNS查找的机制和修饰符的数量限制为最多10个，包括使用“include”机制或
"redirect" modifier. If this number is exceeded during a check, a PermError MUST be returned. The "include", "a", "mx", "ptr", and "exists" mechanisms as well as the "redirect" modifier do count against this limit. The "all", "ip4", and "ip6" mechanisms do not require DNS lookups and therefore do not count against this limit. The "exp" modifier does not count against this limit because the DNS lookup to fetch the explanation string occurs after the SPF record has been evaluated.
"redirect" modifier. If this number is exceeded during a check, a PermError MUST be returned. The "include", "a", "mx", "ptr", and "exists" mechanisms as well as the "redirect" modifier do count against this limit. The "all", "ip4", and "ip6" mechanisms do not require DNS lookups and therefore do not count against this limit. The "exp" modifier does not count against this limit because the DNS lookup to fetch the explanation string occurs after the SPF record has been evaluated.translate error, please retry
When evaluating the "mx" and "ptr" mechanisms, or the %{p} macro, there MUST be a limit of no more than 10 MX or PTR RRs looked up and checked.
在评估“mx”和“ptr”机制或%{p}宏时，查找和检查的mx或ptr RRs不得超过10个。
SPF implementations SHOULD limit the total amount of data obtained from the DNS queries. For example, when DNS over TCP or EDNS0 are available, there may need to be an explicit limit to how much data will be accepted to prevent excessive bandwidth usage or memory usage and DoS attacks.
SPF实现应限制从DNS查询获得的数据总量。例如，当TCP或EDNS0上的DNS可用时，可能需要明确限制接受的数据量，以防止过度的带宽使用或内存使用以及DoS攻击。
MTAs or other processors MAY also impose a limit on the maximum amount of elapsed time to evaluate check_host(). Such a limit SHOULD allow at least 20 seconds. If such a limit is exceeded, the result of authorization SHOULD be "TempError".
MTA或其他处理器也可能对评估check_host（）所用的最大时间量施加限制。该限制应至少允许20秒。如果超过此限制，则授权结果应为“TempError”。
Domains publishing records SHOULD try to keep the number of "include" mechanisms and chained "redirect" modifiers to a minimum. Domains SHOULD also try to minimize the amount of other DNS information needed to evaluate a record. This can be done by choosing directives that require less DNS information and placing lower-cost mechanisms earlier in the SPF record.
域发布记录应尽量将“包含”机制和链接的“重定向”修饰符的数量保持在最低限度。域还应尽量减少评估记录所需的其他DNS信息量。这可以通过选择需要较少DNS信息的指令和在SPF记录中较早地放置较低成本的机制来实现。
For example, consider a domain set up as follows:
例如，考虑以下设置的域：
example.com. IN MX 10 mx.example.com.
mx.example.com. IN A 192.0.2.1
a.example.com. IN TXT "v=spf1 mx:example.com -all"
b.example.com. IN TXT "v=spf1 a:mx.example.com -all"
c.example.com. IN TXT "v=spf1 ip4:192.0.2.1 -all"
example.com. IN MX 10 mx.example.com.
mx.example.com. IN A 192.0.2.1
a.example.com. IN TXT "v=spf1 mx:example.com -all"
b.example.com. IN TXT "v=spf1 a:mx.example.com -all"
c.example.com. IN TXT "v=spf1 ip4:192.0.2.1 -all"
Evaluating check_host() for the domain "a.example.com" requires the MX records for "example.com", and then the A records for the listed hosts. Evaluating for "b.example.com" requires only the A records. Evaluating for "c.example.com" requires none.
评估域“a.example.com”的check_host（）需要“example.com”的MX记录，然后是列出的主机的a记录。评估“b.example.com”只需要A记录。对“c.example.com”进行评估时不需要任何东西。
However, there may be administrative considerations: using "a" over "ip4" allows hosts to be renumbered easily. Using "mx" over "a" allows the set of mail hosts to be changed easily.
但是，可能存在管理方面的考虑：使用“ip4”上的“a”可以轻松地对主机重新编号。在“a”上使用“mx”可以轻松更改邮件主机集。
The "MAIL FROM" and "HELO" identity authorizations must not be construed to provide more assurance than they do. It is entirely possible for a malicious sender to inject a message using his own domain in the identities used by SPF, to have that domain's SPF record authorize the sending host, and yet the message can easily list other identities in its header. Unless the user or the MUA takes care to note that the authorized identity does not match the other more commonly-presented identities (such as the From: header field), the user may be lulled into a false sense of security.
“邮件发件人”和“直升机”身份授权不得解释为提供比其更多的保证。恶意发件人完全有可能使用自己的域在SPF使用的标识中插入消息，让该域的SPF记录授权发送主机，但消息可以很容易地在其头中列出其他标识。除非用户或MUA注意到授权身份与其他更常见的呈现身份（例如From:header字段）不匹配，否则用户可能会陷入错误的安全感。
There are two aspects of this protocol that malicious parties could exploit to undermine the validity of the check_host() function:
恶意方可以利用此协议的两个方面来破坏check_host（）函数的有效性：
o The evaluation of check_host() relies heavily on DNS. A malicious attacker could attack the DNS infrastructure and cause check_host() to see spoofed DNS data, and then return incorrect results. This could include returning "Pass" for an <ip> value where the actual domain's record would evaluate to "Fail". See [RFC3833] for a description of DNS weaknesses.
o check_host（）的计算在很大程度上依赖于DNS。恶意攻击者可以攻击DNS基础结构，并导致check_host（）看到伪造的DNS数据，然后返回不正确的结果。这可能包括返回<ip>值的“Pass”，实际域的记录将评估为“Fail”。有关DNS弱点的说明，请参见[RFC3833]。
o The client IP address, <ip>, is assumed to be correct. A malicious attacker could spoof TCP sequence numbers to make mail appear to come from a permitted host for a domain that the attacker is impersonating.
o 假定客户端IP地址<IP>，是正确的。恶意攻击者可以伪造TCP序列号，使邮件看起来来自攻击者模拟的域的允许主机。
By definition, SPF policies just map domain names to sets of authorized MTAs, not whole E-Mail addresses to sets of authorized users. Although the "l" macro (Section 8) provides a limited way to define individual sets of authorized MTAs for specific E-Mail addresses, it is generally impossible to verify, through SPF, the use of specific E-Mail addresses by individual users of the same MTA.
根据定义，SPF策略只是将域名映射到授权MTA集，而不是将整个电子邮件地址映射到授权用户集。虽然“l”宏（第8节）提供了一种有限的方法来定义特定电子邮件地址的授权MTA的各个集合，但通常无法通过SPF验证同一MTA的单个用户使用特定电子邮件地址的情况。
It is up to mail services and their MTAs to directly prevent cross-user forgery: based on SMTP AUTH ([RFC2554]), users should be restricted to using only those E-Mail addresses that are actually under their control (see [RFC4409], Section 6.1). Another means to verify the identity of individual users is message cryptography such as PGP ([RFC2440]) or S/MIME ([RFC3851]).
由邮件服务及其MTA直接防止跨用户伪造：基于SMTP身份验证（[RFC2554]），应限制用户仅使用其实际控制的电子邮件地址（请参见[RFC4409]，第6.1节）。验证单个用户身份的另一种方法是消息加密，如PGP（[RFC2440]）或S/MIME（[RFC3851]）。
SPF uses information supplied by third parties, such as the "HELO" domain name, the "MAIL FROM" address, and SPF records. This information is then passed to the receiver in the Received-SPF: trace fields and possibly returned to the client MTA in the form of an SMTP rejection message. This information must be checked for invalid characters and excessively long lines.
SPF使用第三方提供的信息，如“HELO”域名、“邮件发件人”地址和SPF记录。然后，此信息在接收的SPF:trace字段中传递给接收方，并可能以SMTP拒绝消息的形式返回给客户端MTA。必须检查此信息是否存在无效字符和过长的行。
When the authorization check fails, an explanation string may be included in the reject response. Both the sender and the rejecting receiver need to be aware that the explanation was determined by the publisher of the SPF record checked and, in general, not the receiver. The explanation may contain malicious URLs, or it may be offensive or misleading.
当授权检查失败时，拒绝响应中可能包含解释字符串。发送方和拒绝接收方都需要知道，解释是由SPF记录的发布方确定的，而通常不是接收方。解释可能包含恶意URL，也可能具有攻击性或误导性。
This is probably less of a concern than it may initially seem since such messages are returned to the sender, and the explanation strings come from the sender policy published by the domain in the identity claimed by that very sender. As long as the DSN is not redirected to someone other than the actual sender, the only people who see malicious explanation strings are people whose messages claim to be from domains that publish such strings in their SPF records. In practice, DSNs can be misdirected, such as when an MTA accepts an E-Mail and then later generates a DSN to a forged address, or when an E-Mail forwarder does not direct the DSN back to the original sender.
这可能不像最初看起来那样令人担忧，因为此类消息会返回给发件人，并且解释字符串来自域以该发件人声明的身份发布的发件人策略。只要DSN没有重定向到实际发件人以外的其他人，看到恶意解释字符串的只有那些消息声称来自在其SPF记录中发布此类字符串的域的人。实际上，DSN可能会被错误定向，例如MTA接受电子邮件后生成伪造地址的DSN，或者电子邮件转发器未将DSN定向回原始发件人。
Checking SPF records causes DNS queries to be sent to the domain owner. These DNS queries, especially if they are caused by the "exists" mechanism, can contain information about who is sending E-Mail and likely to which MTA the E-Mail is being sent. This can introduce some privacy concerns, which may be more or less of an issue depending on local laws and the relationship between the domain owner and the person sending the E-Mail.
检查SPF记录会导致将DNS查询发送给域所有者。这些DNS查询（尤其是由“存在”机制引起的查询）可能包含有关谁在发送电子邮件以及可能将电子邮件发送到哪个MTA的信息。这可能会带来一些隐私问题，这或多或少取决于当地法律以及域名所有者和发送电子邮件的人之间的关系。
This document is largely based on the work of Meng Weng Wong and Mark Lentczner. Although, as this section acknowledges, many people have contributed to this document, a very large portion of the writing and editing are due to Meng and Mark.
本文件主要基于王孟翁和马克·伦茨纳的工作。虽然，正如本节所承认的，许多人对本文件做出了贡献，但很大一部分的写作和编辑都是由于孟和马克。
This design owes a debt of parentage to [RMX] by Hadmut Danisch and to [DMP] by Gordon Fecyk. The idea of using a DNS record to check the legitimacy of an E-Mail address traces its ancestry further back through messages on the namedroppers mailing list by Paul Vixie
这种设计归功于Hadmut Danisch的[RMX]和Gordon Fecyk的[DMP]。使用DNS记录检查电子邮件地址合法性的想法可以通过Paul Vixie在NameDropper邮件列表上的消息追溯到电子邮件地址的起源
[Vixie] (based on suggestion by Jim Miller) and by David Green [Green].
[Vixie]（基于吉姆·米勒的建议）和大卫·格林[Green]。
Philip Gladstone contributed the concept of macros to the specification, multiplying the expressiveness of the language and making per-user and per-IP lookups possible.
Philip Gladstone在规范中提出了宏的概念，增加了语言的表达能力，并使每用户和每IP查找成为可能。
The authors would also like to thank the literally hundreds of individuals who have participated in the development of this design. They are far too numerous to name, but they include the following:
作者还想感谢数百名参与设计开发的个人。它们的数量多得数不清，但它们包括以下内容：
The folks on the spf-discuss mailing list. The folks on the SPAM-L mailing list. The folks on the IRTF ASRG mailing list. The folks on the IETF MARID mailing list. The folks on #perl.
spf上的人讨论邮件列表。垃圾邮件列表上的人。IRTF ASRG邮件列表上的人。IETF MARID邮件列表上的人。perl上的人。
The IANA has assigned a new Resource Record Type and Qtype from the DNS Parameters Registry for the SPF RR type with code 99.
IANA已从DNS参数注册表为代码为99的SPF RR类型分配了新的资源记录类型和Qtype。
Per [RFC3864], the "Received-SPF:" header field is added to the IANA Permanent Message Header Field Registry. The following is the registration template:
根据[RFC3864]，将“接收到的SPF:”标头字段添加到IANA永久消息标头字段注册表中。以下是注册模板：
Header field name: Received-SPF
Applicable protocol: mail ([RFC2822])
Status: Experimental
Author/Change controller: IETF
Specification document(s): RFC 4408
Related information:
Requesting SPF Council review of any proposed changes and
additions to this field are recommended. For information about
the SPF Council see http://www.openspf.org/Council
Header field name: Received-SPF
Applicable protocol: mail ([RFC2822])
Status: Experimental
Author/Change controller: IETF
Specification document(s): RFC 4408
Related information:
Requesting SPF Council review of any proposed changes and
additions to this field are recommended. For information about
the SPF Council see http://www.openspf.org/Council
[RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.
[RFC1035]Mockapetris，P.，“域名-实现和规范”，STD 13，RFC 1035，1987年11月。
[RFC1123] Braden, R., "Requirements for Internet Hosts - Application and Support", STD 3, RFC 1123, October 1989.
[RFC1123]Braden，R.，“互联网主机的要求-应用和支持”，STD 3，RFC 1123，1989年10月。
[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月。
[RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April 2001.
[RFC2821]Klensin，J.，“简单邮件传输协议”，RFC 28212001年4月。
[RFC2822] Resnick, P., "Internet Message Format", RFC 2822, April 2001.
[RFC2822]Resnick，P.，“互联网信息格式”，RFC 2822，2001年4月。
[RFC3464] Moore, K. and G. Vaudreuil, "An Extensible Message Format for Delivery Status Notifications", RFC 3464, January 2003.
[RFC3464]Moore，K.和G.Vaudreuil，“交付状态通知的可扩展消息格式”，RFC 3464，2003年1月。
[RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) Addressing Architecture", RFC 3513, April 2003.
[RFC3513]Hinden，R.和S.Deering，“互联网协议版本6（IPv6）寻址体系结构”，RFC 3513，2003年4月。
[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月。
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[RFC3986]Berners Lee，T.，Fielding，R.，和L.Masinter，“统一资源标识符（URI）：通用语法”，STD 66，RFC 3986，2005年1月。
[RFC4234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005.
[RFC4234]Crocker，D.和P.Overell，“语法规范的扩充BNF:ABNF”，RFC 4234，2005年10月。
[US-ASCII] American National Standards Institute (formerly United States of America Standards Institute), "USA Code for Information Interchange, X3.4", 1968.
[US-ASCII]美国国家标准协会（前美国标准协会），“美国信息交换代码，X3.4”，1968年。
ANSI X3.4-1968 has been replaced by newer versions with slight modifications, but the 1968 version remains definitive for the Internet.
ANSI X3.4-1968已被稍作修改的较新版本所取代，但1968年版本仍然是互联网的最终版本。
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987.
[RFC1034]Mockapetris，P.，“域名-概念和设施”，STD 13，RFC 1034，1987年11月。
[RFC1983] Malkin, G., "Internet Users' Glossary", RFC 1983, August 1996.
[RFC1983]Malkin，G.，“互联网用户词汇表”，RFC 1983，1996年8月。
[RFC2440] Callas, J., Donnerhacke, L., Finney, H., and R. Thayer, "OpenPGP Message Format", RFC 2440, November 1998.
[RFC2440]Callas，J.，Donnerhacke，L.，Finney，H.，和R.Thayer，“OpenPGP消息格式”，RFC 24401998年11月。
[RFC2554] Myers, J., "SMTP Service Extension for Authentication", RFC 2554, March 1999.
[RFC2554]迈尔斯，J.，“用于身份验证的SMTP服务扩展”，RFC2554，1999年3月。
[RFC3696] Klensin, J., "Application Techniques for Checking and Transformation of Names", RFC 3696, February 2004.
[RFC3696]Klensin，J.，“名称检查和转换的应用技术”，RFC 36962004年2月。
[RFC3833] Atkins, D. and R. Austein, "Threat Analysis of the Domain Name System (DNS)", RFC 3833, August 2004.
[RFC3833]Atkins，D.和R.Austein，“域名系统（DNS）的威胁分析”，RFC 38332004年8月。
[RFC3851] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification", RFC 3851, July 2004.
[RFC3851]Ramsdell，B.，“安全/多用途Internet邮件扩展（S/MIME）版本3.1消息规范”，RFC 38512004年7月。
[RFC4409] Gellens, R. and J. Klensin, "Message Submission for Mail", RFC 4409, April 2006.
[RFC4409]Gellens，R.和J.Klensin，“邮件邮件提交”，RFC 4409，2006年4月。
[RMX] Danish, H., "The RMX DNS RR Type for light weight sender authentication", Work In Progress
[RMX]Danish，H.，“用于轻型发送方身份验证的RMX DNS RR类型”，正在进行中
[DMP] Fecyk, G., "Designated Mailers Protocol", Work In Progress
[DMP]Fecyk，G.，“指定邮递员协议”，正在进行中
[Vixie] Vixie, P., "Repudiating MAIL FROM", 2002.
[Vixie]Vixie，P.，“拒绝邮件”，2002年。
[Green] Green, D., "Domain-Authorized SMTP Mail", 2002.
[Green]Green，D.，“域授权SMTP邮件”，2002年。
This section is normative and any discrepancies with the ABNF fragments in the preceding text are to be resolved in favor of this grammar.
本节是规范性的，与前面文本中ABNF片段的任何差异都应按照本语法解决。
See [RFC4234] for ABNF notation. Please note that as per this ABNF definition, literal text strings (those in quotes) are case-insensitive. Hence, "mx" matches "mx", "MX", "mX", and "Mx".
ABNF符号见[RFC4234]。请注意，根据ABNF的定义，文本字符串（引号中的字符串）不区分大小写。因此，“mx”与“mx”、“mx”、“mx”和“mx”匹配。
record = version terms *SP
version = "v=spf1"
record = version terms *SP
version = "v=spf1"
terms = *( 1*SP ( directive / modifier ) )
terms = *( 1*SP ( directive / modifier ) )
directive = [ qualifier ] mechanism
qualifier = "+" / "-" / "?" / "~"
mechanism = ( all / include
/ A / MX / PTR / IP4 / IP6 / exists )
directive = [ qualifier ] mechanism
qualifier = "+" / "-" / "?" / "~"
mechanism = ( all / include
/ A / MX / PTR / IP4 / IP6 / exists )
all = "all"
include = "include" ":" domain-spec
A = "a" [ ":" domain-spec ] [ dual-cidr-length ]
MX = "mx" [ ":" domain-spec ] [ dual-cidr-length ]
PTR = "ptr" [ ":" domain-spec ]
IP4 = "ip4" ":" ip4-network [ ip4-cidr-length ]
IP6 = "ip6" ":" ip6-network [ ip6-cidr-length ]
exists = "exists" ":" domain-spec
all = "all"
include = "include" ":" domain-spec
A = "a" [ ":" domain-spec ] [ dual-cidr-length ]
MX = "mx" [ ":" domain-spec ] [ dual-cidr-length ]
PTR = "ptr" [ ":" domain-spec ]
IP4 = "ip4" ":" ip4-network [ ip4-cidr-length ]
IP6 = "ip6" ":" ip6-network [ ip6-cidr-length ]
exists = "exists" ":" domain-spec
modifier = redirect / explanation / unknown-modifier
redirect = "redirect" "=" domain-spec
explanation = "exp" "=" domain-spec
unknown-modifier = name "=" macro-string
modifier = redirect / explanation / unknown-modifier
redirect = "redirect" "=" domain-spec
explanation = "exp" "=" domain-spec
unknown-modifier = name "=" macro-string
ip4-cidr-length = "/" 1*DIGIT
ip6-cidr-length = "/" 1*DIGIT
dual-cidr-length = [ ip4-cidr-length ] [ "/" ip6-cidr-length ]
ip4-cidr-length = "/" 1*DIGIT
ip6-cidr-length = "/" 1*DIGIT
dual-cidr-length = [ ip4-cidr-length ] [ "/" ip6-cidr-length ]
ip4-network = qnum "." qnum "." qnum "." qnum
qnum = DIGIT ; 0-9
/ %x31-39 DIGIT ; 10-99
/ "1" 2DIGIT ; 100-199
/ "2" %x30-34 DIGIT ; 200-249
/ "25" %x30-35 ; 250-255
; conventional dotted quad notation. e.g., 192.0.2.0
ip6-network = <as per [RFC 3513], section 2.2>
; e.g., 2001:DB8::CD30
ip4-network = qnum "." qnum "." qnum "." qnum
qnum = DIGIT ; 0-9
/ %x31-39 DIGIT ; 10-99
/ "1" 2DIGIT ; 100-199
/ "2" %x30-34 DIGIT ; 200-249
/ "25" %x30-35 ; 250-255
; conventional dotted quad notation. e.g., 192.0.2.0
ip6-network = <as per [RFC 3513], section 2.2>
; e.g., 2001:DB8::CD30
domain-spec = macro-string domain-end
domain-end = ( "." toplabel [ "." ] ) / macro-expand
toplabel = ( *alphanum ALPHA *alphanum ) /
( 1*alphanum "-" *( alphanum / "-" ) alphanum )
; LDH rule plus additional TLD restrictions
; (see [RFC3696], Section 2)
domain-spec = macro-string domain-end
domain-end = ( "." toplabel [ "." ] ) / macro-expand
toplabel = ( *alphanum ALPHA *alphanum ) /
( 1*alphanum "-" *( alphanum / "-" ) alphanum )
; LDH rule plus additional TLD restrictions
; (see [RFC3696], Section 2)
alphanum = ALPHA / DIGIT
alphanum = ALPHA / DIGIT
explain-string = *( macro-string / SP )
explain-string = *( macro-string / SP )
macro-string = *( macro-expand / macro-literal )
macro-expand = ( "%{" macro-letter transformers *delimiter "}" )
/ "%%" / "%_" / "%-"
macro-literal = %x21-24 / %x26-7E
; visible characters except "%"
macro-letter = "s" / "l" / "o" / "d" / "i" / "p" / "h" /
"c" / "r" / "t"
transformers = *DIGIT [ "r" ]
delimiter = "." / "-" / "+" / "," / "/" / "_" / "="
macro-string = *( macro-expand / macro-literal )
macro-expand = ( "%{" macro-letter transformers *delimiter "}" )
/ "%%" / "%_" / "%-"
macro-literal = %x21-24 / %x26-7E
; visible characters except "%"
macro-letter = "s" / "l" / "o" / "d" / "i" / "p" / "h" /
"c" / "r" / "t"
transformers = *DIGIT [ "r" ]
delimiter = "." / "-" / "+" / "," / "/" / "_" / "="
name = ALPHA *( ALPHA / DIGIT / "-" / "_" / "." )
name = ALPHA *( ALPHA / DIGIT / "-" / "_" / "." )
header-field = "Received-SPF:" [CFWS] result FWS [comment FWS] [ key-value-list ] CRLF
header field=“Received SPF:[CFWS]结果FWS[注释FWS][键值列表]CRLF
result = "Pass" / "Fail" / "SoftFail" / "Neutral" /
"None" / "TempError" / "PermError"
result = "Pass" / "Fail" / "SoftFail" / "Neutral" /
"None" / "TempError" / "PermError"
key-value-list = key-value-pair *( ";" [CFWS] key-value-pair )
[";"]
key-value-list = key-value-pair *( ";" [CFWS] key-value-pair )
[";"]
key-value-pair = key [CFWS] "=" ( dot-atom / quoted-string )
key-value-pair = key [CFWS] "=" ( dot-atom / quoted-string )
key = "client-ip" / "envelope-from" / "helo" /
"problem" / "receiver" / "identity" /
mechanism / "x-" name / name
key = "client-ip" / "envelope-from" / "helo" /
"problem" / "receiver" / "identity" /
mechanism / "x-" name / name
identity = "mailfrom" ; for the "MAIL FROM" identity
/ "helo" ; for the "HELO" identity
/ name ; other identities
identity = "mailfrom" ; for the "MAIL FROM" identity
/ "helo" ; for the "HELO" identity
/ name ; other identities
dot-atom = <unquoted word as per [RFC2822]>
quoted-string = <quoted string as per [RFC2822]>
comment = <comment string as per [RFC2822]>
CFWS = <comment or folding white space as per [RFC2822]>
FWS = <folding white space as per [RFC2822]>
CRLF = <standard end-of-line token as per [RFC2822]>
dot-atom = <unquoted word as per [RFC2822]>
quoted-string = <quoted string as per [RFC2822]>
comment = <comment string as per [RFC2822]>
CFWS = <comment or folding white space as per [RFC2822]>
FWS = <folding white space as per [RFC2822]>
CRLF = <standard end-of-line token as per [RFC2822]>
These examples are based on the following DNS setup:
这些示例基于以下DNS设置：
; A domain with two mail servers, two hosts ; and two servers at the domain name $ORIGIN example.com. @ MX 10 mail-a MX 20 mail-b A 192.0.2.10 A 192.0.2.11 amy A 192.0.2.65 bob A 192.0.2.66 mail-a A 192.0.2.129 mail-b A 192.0.2.130 www CNAME example.com.
; 具有两台邮件服务器和两台主机的域；以及域名$ORIGIN example.com上的两台服务器。@MX 10 mail-a MX 20 mail-b a 192.0.2.10 a 192.0.2.11 amy a 192.0.2.65 bob a 192.0.2.66 mail-a 192.0.2.129 mail-b a 192.0.2.130 www.CNAME example.com。
; A related domain $ORIGIN example.org. @ MX 10 mail-c mail-c A 192.0.2.140
; 相关域$ORIGIN example.org@MX 10 mail-c mail-c A 192.0.2.140
; The reverse IP for those addresses $ORIGIN 2.0.192.in-addr.arpa. 10 PTR example.com. 11 PTR example.com. 65 PTR amy.example.com. 66 PTR bob.example.com. 129 PTR mail-a.example.com. 130 PTR mail-b.example.com. 140 PTR mail-c.example.org.
; 这些地址的反向IP为$ORIGIN 2.0.192.in-addr.arpa。10 PTR example.com。11 PTR example.com。65 PTR amy.example.com。66 PTR bob.example.com。129 PTR mail-a.example.com。130 PTR mail-b.example.com。140 PTR mail-c.example.org。
; A rogue reverse IP domain that claims to be ; something it's not $ORIGIN 0.0.10.in-addr.arpa. 4 PTR bob.example.com.
; 声称是非法的反向IP域；它不是$ORIGIN 0.0.10.in-addr.arpa。4 PTR bob.example.com。
These examples show various possible published records for example.com and which values if <ip> would cause check_host() to return "Pass". Note that <domain> is "example.com".
这些示例显示了example.com等各种可能发布的记录，以及如果<ip>将导致check_host（）返回“Pass”的值。注意，<domain>是“example.com”。
v=spf1 +all
-- any <ip> passes
v=spf1 +all
-- any <ip> passes
v=spf1 a -all -- hosts 192.0.2.10 and 192.0.2.11 pass
v=spf1 a—所有—主机192.0.2.10和192.0.2.11通过
v=spf1 a:example.org -all
-- no sending hosts pass since example.org has no A records
v=spf1 a:example.org -all
-- no sending hosts pass since example.org has no A records
v=spf1 mx -all -- sending hosts 192.0.2.129 and 192.0.2.130 pass
v=spf1 mx-全部--发送主机192.0.2.129和192.0.2.130通过
v=spf1 mx:example.org -all
-- sending host 192.0.2.140 passes
v=spf1 mx:example.org -all
-- sending host 192.0.2.140 passes
v=spf1 mx mx:example.org -all
-- sending hosts 192.0.2.129, 192.0.2.130, and 192.0.2.140 pass
v=spf1 mx mx:example.org -all
-- sending hosts 192.0.2.129, 192.0.2.130, and 192.0.2.140 pass
v=spf1 mx/30 mx:example.org/30 -all
-- any sending host in 192.0.2.128/30 or 192.0.2.140/30 passes
v=spf1 mx/30 mx:example.org/30 -all
-- any sending host in 192.0.2.128/30 or 192.0.2.140/30 passes
v=spf1 ptr -all
-- sending host 192.0.2.65 passes (reverse DNS is valid and is in
example.com)
-- sending host 192.0.2.140 fails (reverse DNS is valid, but not
in example.com)
-- sending host 10.0.0.4 fails (reverse IP is not valid)
v=spf1 ptr -all
-- sending host 192.0.2.65 passes (reverse DNS is valid and is in
example.com)
-- sending host 192.0.2.140 fails (reverse DNS is valid, but not
in example.com)
-- sending host 10.0.0.4 fails (reverse IP is not valid)
v=spf1 ip4:192.0.2.128/28 -all
-- sending host 192.0.2.65 fails
-- sending host 192.0.2.129 passes
v=spf1 ip4:192.0.2.128/28 -all
-- sending host 192.0.2.65 fails
-- sending host 192.0.2.129 passes
These examples show the effect of related records:
这些示例显示了相关记录的效果：
example.org: "v=spf1 include:example.com include:example.net -all"
example.org: "v=spf1 include:example.com include:example.net -all"
This record would be used if mail from example.org actually came through servers at example.com and example.net. Example.org's designated servers are the union of example.com's and example.net's designated servers.
如果来自example.org的邮件实际上是通过example.com和example.net上的服务器发送的，则将使用此记录。org的指定服务器是Example.com和Example.net的指定服务器的联合体。
la.example.org: "v=spf1 redirect=example.org"
ny.example.org: "v=spf1 redirect=example.org"
sf.example.org: "v=spf1 redirect=example.org"
la.example.org: "v=spf1 redirect=example.org"
ny.example.org: "v=spf1 redirect=example.org"
sf.example.org: "v=spf1 redirect=example.org"
These records allow a set of domains that all use the same mail system to make use of that mail system's record. In this way, only the mail system's record needs to be updated when the mail setup changes. These domains' records never have to change.
这些记录允许使用同一邮件系统的一组域使用该邮件系统的记录。这样，当邮件设置更改时，只需要更新邮件系统的记录。这些域的记录永远不必更改。
Imagine that, in addition to the domain records listed above, there are these:
想象一下，除了上面列出的域记录之外，还有：
$ORIGIN _spf.example.com. mary.mobile-users A 127.0.0.2 fred.mobile-users A 127.0.0.2 15.15.168.192.joel.remote-users A 127.0.0.2 16.15.168.192.joel.remote-users A 127.0.0.2
$ORIGIN\u spf.example.com。mary.mobile-users A 127.0.0.2 fred.mobile-users A 127.0.0.2 15.15.168.192.joel.remote-users A 127.0.0.2 16.15.168.192.joel.remote-users A 127.0.0.2
The following records describe users at example.com who mail from arbitrary servers, or who mail from personal servers.
以下记录描述了example.com上从任意服务器发送邮件或从个人服务器发送邮件的用户。
example.com:
example.com：
v=spf1 mx
include:mobile-users._spf.%{d}
include:remote-users._spf.%{d}
-all
v=spf1 mx
include:mobile-users._spf.%{d}
include:remote-users._spf.%{d}
-all
mobile-users._spf.example.com:
移动用户。\u spf.example.com：
v=spf1 exists:%{l1r+}.%{d}
v=spf1 exists:%{l1r+}.%{d}
remote-users._spf.example.com:
远程用户。\u spf.example.com：
v=spf1 exists:%{ir}.%{l1r+}.%{d}
v=spf1 exists:%{ir}.%{l1r+}.%{d}
Say that your sender policy requires both that the IP address is within a certain range and that the reverse DNS for the IP matches. This can be done several ways, including the following:
假设您的发件人策略要求IP地址在特定范围内，并且IP的反向DNS匹配。这可以通过以下几种方式实现：
example.com. SPF ( "v=spf1 "
"-include:ip4._spf.%{d} "
"-include:ptr._spf.%{d} "
"+all" )
ip4._spf.example.com. SPF "v=spf1 -ip4:192.0.2.0/24 +all"
ptr._spf.example.com. SPF "v=spf1 -ptr +all"
example.com. SPF ( "v=spf1 "
"-include:ip4._spf.%{d} "
"-include:ptr._spf.%{d} "
"+all" )
ip4._spf.example.com. SPF "v=spf1 -ip4:192.0.2.0/24 +all"
ptr._spf.example.com. SPF "v=spf1 -ptr +all"
This example shows how the "-include" mechanism can be useful, how an SPF record that ends in "+all" can be very restrictive, and the use of De Morgan's Law.
这个例子展示了“-include”机制是如何有用的，以“+all”结尾的SPF记录是如何限制的，以及如何使用De Morgan定律。
Authors' Addresses
作者地址
Meng Weng Wong Singapore
孟翁王新加坡
EMail: mengwong+spf@pobox.com
EMail: mengwong+spf@pobox.com
Wayne Schlitt 4615 Meredeth #9 Lincoln Nebraska, NE 68506 United States of America
Wayne Schlitt 4615 Meredeth#9林肯内布拉斯加州，美国东北部68506
EMail: wayne@schlitt.net
URI: http://www.schlitt.net/spf/
EMail: wayne@schlitt.net
URI: http://www.schlitt.net/spf/
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）提供。