Network Working Group G. Lindberg
Request for Comments: 2505 Chalmers University of Technology
BCP: 30 February 1999
Category: Best Current Practice
Network Working Group G. Lindberg
Request for Comments: 2505 Chalmers University of Technology
BCP: 30 February 1999
Category: Best Current Practice
Anti-Spam Recommendations for SMTP MTAs
SMTP MTA的反垃圾邮件建议
Status of this Memo
本备忘录的状况
This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited.
本文件规定了互联网社区的最佳现行做法，并要求进行讨论和提出改进建议。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (1999). All Rights Reserved.
版权所有（C）互联网协会（1999年）。版权所有。
Abstract
摘要
This memo gives a number of implementation recommendations for SMTP, [1], MTAs (Mail Transfer Agents, e.g. sendmail, [8]) to make them more capable of reducing the impact of spam(*).
本备忘录为SMTP、[1]、MTA（邮件传输代理，例如sendmail，[8]）提供了许多实施建议，以使它们能够更有效地减少垃圾邮件（*）的影响。
The intent is that these recommendations will help clean up the spam situation, if applied on enough SMTP MTAs on the Internet, and that they should be used as guidelines for the various MTA vendors. We are fully aware that this is not the final solution, but if these recommendations were included, and used, on all Internet SMTP MTAs, things would improve considerably and give time to design a more long term solution. The Future Work section suggests some ideas that may be part of such a long term solution. It might, though, very well be the case that the ultimate solution is social, political, or legal, rather than technical in nature.
其目的是，如果将这些建议应用于Internet上足够多的SMTP MTA，则它们将有助于清理垃圾邮件情况，并应作为各种MTA供应商的指导原则。我们完全知道这不是最终的解决方案，但如果在所有Internet SMTP MTA上都包含并使用这些建议，情况将有很大改善，并有时间设计更长期的解决方案。未来工作部分提出了一些想法，这些想法可能是长期解决方案的一部分。不过，最终解决方案很可能是社会、政治或法律的，而不是技术性的。
The implementor should be aware of the increased risk of denial of service attacks that several of the proposed methods might lead to. For example, increased number of queries to DNS servers and increased size of logfiles might both lead to overloaded systems and system crashes during an attack.
实施者应该意识到，一些建议的方法可能会导致拒绝服务攻击的风险增加。例如，对DNS服务器的查询数量的增加和日志文件大小的增加都可能导致攻击期间系统过载和系统崩溃。
A brief summary of this memo is:
本备忘录的简要摘要如下：
o Stop unauthorized mail relaying. o Spammers then have to operate in the open; deal with them. o Design a mail system that can handle spam.
o 停止未经授权的邮件转发。o然后，垃圾邮件发送者必须公开操作；对付他们。o设计一个能够处理垃圾邮件的邮件系统。
This memo is a Best Current Practice (BCP) RFC. As such it should be used as a guideline for SMTP MTA implementors to make their products more capable of preventing/handling spam. Despite this being its primary goal, an intended side effect is to suggest to the sysadmin/Postmaster community which "anti spam knobs" an SMTP MTA is expected to have.
本备忘录是最佳现行做法（BCP）RFC。因此，它应该作为SMTP MTA实施者的指导方针，使其产品更能防止/处理垃圾邮件。尽管这是它的主要目标，但一个预期的副作用是向系统管理员/邮政管理员社区建议SMTP MTA应该具有哪些“反垃圾邮件旋钮”。
However, this memo is not generally intended as a description on how to operate an SMTP MTA - which "knobs" to turn and how to configure the options. If suggestions are provided, they will be clearly marked and they should be read as such.
但是，本备忘录一般不用于说明如何操作SMTP MTA-打开哪些“旋钮”以及如何配置选项。如果提供了建议，则应清楚地标记这些建议，并将其视为建议。
Mass unsolicited electronic mail, often known as spam(*), has increased considerably during a short period of time and has become a serious threat to the Internet email community as a whole. Something needs to be done fairly quickly.
大量未经请求的电子邮件，通常被称为垃圾邮件（*），在短时间内大幅增加，已成为对整个互联网电子邮件社区的严重威胁。有些事情需要相当快地完成。
The problem has several components:
该问题有几个组成部分：
o It is high volume, i.e. people get a lot of such mail in their mailboxes.
o 它是高容量的，也就是说，人们在邮箱中收到很多这样的邮件。
o It is completely "blind", i.e. there is no correlation between the receivers' areas of interest and the actual mail sent out (at least if one assumes that not everybody on the Internet is interested in porno pictures and spam programs...).
o 这是完全“盲目”的，即接收者感兴趣的领域与实际发送的邮件之间没有关联（至少假设互联网上并非所有人都对色情图片和垃圾邮件程序感兴趣……）。
o It costs real money for the receivers. Since many receivers pay for the time to transfer the mailbox from the (dialup) ISP to their computer they in reality pay real money for this.
o 对接受者来说，这需要真正的钱。由于许多接收者为将邮箱从（拨号）ISP传输到他们的计算机的时间付费，他们实际上为此支付了实实在在的费用。
o It costs real money for the ISPs. Assume one 10 Kbyte message sent to 10 000 users with their mailboxes at one ISP host; that means an unsolicited, unexpected, storage of 100 Mbytes. State of the art disks, 4 Gbyte, can take 40 such message floods before they are filled. It is almost impossible to plan ahead for such "storms".
o 对于ISP来说，这是一笔实实在在的费用。假设一个10千字节的消息发送给10000个用户，其邮箱位于一个ISP主机上；这意味着100兆字节的未经请求、意外存储。最先进的4 Gbyte磁盘在填充之前可以容纳40个这样的消息流。对于这样的“风暴”，提前计划几乎是不可能的。
o Many of the senders of spam are dishonest, e.g. hide behind false return addresses, deliberately write messages to look like they were between two individuals so the spam recipient will think it was just misdelivered to them, say the message is "material you
o 许多垃圾邮件发送者是不诚实的，例如，隐藏在虚假的回信地址后面，故意写邮件，使其看起来像是两个人之间的邮件，这样垃圾邮件接收者会认为邮件只是误发给他们，说邮件是“重要的你”
requested" when you never asked for it, and generally do everything they can without regard to honesty or ethics, to try to get a few more people to look at their message.
请求“当你从来没有要求过，并且通常会尽一切可能不考虑诚实或道德，试图让更多的人看到他们的信息。
In fact some of the spam-programs take a pride in adding false info that will "make the ISPs scratch their heads".
事实上，一些垃圾邮件程序以添加虚假信息而自豪，这些虚假信息将“让ISP挠头”。
It is usually the case that people who send in protests (often according to the instructions in the mail) find their mail addresses added to more lists and sold to other parties.
通常情况下，发送抗议信的人（通常根据邮件中的指示）会发现他们的邮件地址被添加到更多的列表中，并卖给其他方。
o It is quite common practice to make use of third party hosts as relays to get the spam mail sent out to the receivers. This theft of service is illegal in most - if not all - countries (at least in the US spammers have been successfully sued). However, with the original sender in the US, the (innocent) relay in Sweden and the list of receivers back in the US, the legal process of getting damages from the spammers becomes extremely difficult.
o 利用第三方主机作为中继将垃圾邮件发送给收件人是一种非常常见的做法。这种窃取服务的行为在大多数（如果不是所有的话）国家都是非法的（至少在美国，垃圾邮件发送者已经被成功起诉）。然而，由于原始发送者在美国，（无辜的）转送者在瑞典，接收者名单又回到了美国，从垃圾邮件发送者那里获得损害赔偿的法律程序变得极其困难。
This memo has no intention of being the final solution to the spam problem.
本备忘录无意成为垃圾邮件问题的最终解决方案。
If, however, enough Internet MTAs did implement enough of the rules described below (especially the Non-Relay rules), we would get the spammers out in the open, where they could be taken care of. Either pure legal actions would help, or we can block them technically using other rules described below (since the Non-Relay rules now make them appear openly, with their own hosts and domains, we can apply various access filters against them). In reality, a combination of legal and technical methods is likely to give the best result.
然而，如果有足够多的互联网MTA实施了足够多的下述规则（特别是非中继规则），我们将把垃圾邮件发送者公开出来，让他们得到照顾。无论是纯粹的法律行动都会有所帮助，或者我们可以使用下面描述的其他规则从技术上阻止它们（因为非中继规则现在使它们公开出现，并且有自己的主机和域，我们可以对它们应用各种访问过滤器）。事实上，法律和技术手段的结合可能会产生最佳效果。
This way, the spam problem could be reduced enough to allow the Internet community to design and deploy a real and general solution.
这样，垃圾邮件问题就可以减少到足以让互联网社区设计和部署一个真正的通用解决方案的程度。
But, please note:
但是，请注意：
The Non-Relay rules are not in themselves enough to stop spam. Even if 99% of the SMTP MTAs implemented them from Day 1, spammers would still find the remaining 1% and use them. Or spammers would just switch gear and connect directly to each and every recipient host; that will be to a higher cost for the spammer, but is still quite likely.
非中继规则本身不足以阻止垃圾邮件。即使99%的SMTP MTA从第1天开始实施，垃圾邮件发送者仍会找到剩余的1%并使用它们。或者，垃圾邮件发送者只需切换设备，直接连接到每个收件人主机；这将给垃圾邮件发送者带来更高的成本，但可能性仍然很大。
Even though IPv6 deployment may be near, the spam problem is here already and thus this memo restricts itself to the current IPv4.
尽管IPv6部署可能即将到来，但垃圾邮件问题已经存在，因此本备忘录仅限于当前的IPv4。
Throughout this memo we will use the terminology of RFC2119, [4]:
在本备忘录中，我们将使用RFC2119的术语[4]：
o "MUST"
o “必须”
This word or the adjective "REQUIRED" means that the item is an absolute requirement.
这个词或形容词“REQUIRED”表示该项为绝对要求。
o "SHOULD"
o “应该”
This word or the adjective "RECOMMENDED" means that there may exist valid reasons in particular circumstances to ignore this item, but the full implications should be understood and the case carefully weighed before choosing a different course.
这个词或形容词“推荐”意味着在特定情况下可能存在忽略该项目的正当理由，但在选择不同的课程之前，应理解其全部含义并仔细权衡案例。
o "MAY"
o “五月”
This word or the adjective "OPTIONAL" means that this item is truly optional. One vendor may choose to include the item because a particular marketplace requires it or because it enhances the product, for example; another vendor may omit the same item.
这个词或形容词“可选”意味着这个项目是真正可选的。一个供应商可能会选择包括该项目，因为特定的市场需要它，或者因为它增强了产品，例如；另一个供应商可以省略相同的项目。
In the memo we sometimes use the term "host name" or "domain name" which should be interpreted as a Fully Qualified Domain Name, FQDN. By this we mean the name returned from the DNS in response to a PTR query (.IN-ADDR.ARPA), i.e. when an IP address is translated to a name, or we mean a name with a DNS A or MX record associated to it RFC1034, [5], and RFC1035, [6].
In the memo we sometimes use the term "host name" or "domain name" which should be interpreted as a Fully Qualified Domain Name, FQDN. By this we mean the name returned from the DNS in response to a PTR query (.IN-ADDR.ARPA), i.e. when an IP address is translated to a name, or we mean a name with a DNS A or MX record associated to it RFC1034, [5], and RFC1035, [6].translate error, please retry
When we suggest use of FQDNs rather than IP addresses this is because FQDNs are intuitively much easier to use. However, all such usage depends heavily on DNS and .IN-ADDR.ARPA (PTR) information. Since it is fairly easy to forge that, either by false cache information injected in DNS servers or spammers running their own DNS with false information in them, host and domain names must be used with care, e.g. verified so that the translation address->name corresponds to name->address. With Secure DNS, RFC2065, [7], things will improve, since spoofing of .IN-ADDR.ARPA will no longer be possible.
当我们建议使用FQDN而不是IP地址时，这是因为FQDN直观上更易于使用。然而，所有这些使用在很大程度上依赖于DNS和.IN-ADDR.ARPA（PTR）信息。由于通过在DNS服务器中注入错误的缓存信息或运行自己的DNS并在其中包含错误信息的垃圾邮件发送者很容易伪造，因此必须谨慎使用主机名和域名，例如，验证以使翻译地址->名称对应于名称->地址。有了安全的DNS RFC2065，[7]，情况会有所改善，因为不再可能对.IN-ADDR.ARPA进行欺骗。
One of the recommendations is about verifying "MAIL From:" (envelope originator) domains with the DNS (assure that appropriate DNS information exists for the domain). When making use of this capability there are a few things to consider:
其中一项建议是使用DNS验证“邮件发件人”（“信封发起者”）域（确保该域存在适当的DNS信息）。使用此功能时，需要考虑以下几点：
(1) One must not forget the increased amount of DNS queries which might result in problems for the DNS server itself to cope with the load. This itself can result in a denial of service attack against the DNS server just by sending email to a site.
(1) 人们不能忘记DNS查询量的增加，这可能会导致DNS服务器本身在处理负载时出现问题。仅通过向站点发送电子邮件，这本身就可能导致针对DNS服务器的拒绝服务攻击。
(2) It should be noted that with negative caching in the DNS, forged DNS responses can be used to mount denial of service attacks. For example, if a site is known to implement a FQDN validity check on addresses in SMTP "MAIL From:" commands, an attacker may be able to use negative DNS responses to effectively block acceptance of mail from one or more origins. Because of this, one should carefully check the DNS server in use, e.g. how it verifies that incoming responses correspond to outstanding queries, to minimize the risk for such attacks.
(2) 需要注意的是，如果DNS中存在负缓存，伪造的DNS响应可用于发起拒绝服务攻击。例如，如果已知某个站点对SMTP“MAIL From:”命令中的地址实施FQDN有效性检查，则攻击者可能会使用负面DNS响应来有效阻止接受来自一个或多个来源的邮件。因此，应仔细检查正在使用的DNS服务器，例如，它如何验证传入响应是否对应于未完成的查询，以将此类攻击的风险降至最低。
(3) For early versions of spam software FQDN checks provide quite some relief, since that software generates mail with completely bogus "MAIL From:" that will never get into the system if verified with the DNS. This is in active use at many installations today and it does reduce spam.
(3) 对于垃圾邮件软件的早期版本，FQDN检查提供了相当大的缓解，因为该软件生成的邮件带有完全虚假的“邮件来源：”如果使用DNS验证，这些邮件将永远不会进入系统。这在今天的许多安装中都得到了积极的使用，它确实减少了垃圾邮件。
On the other hand, sites with weak DNS connectivity may find their legitimate mail having problems reaching destinations due to DNS timeouts when the receivers verify their "MAIL From:". However, since DNS information is handled asynchronously and is cached even though the initial requester has given up, chances are high that the necessary information is there at a later attempt.
另一方面，DNS连接较弱的站点可能会发现其合法邮件在收件人验证其“邮件发件人：”时由于DNS超时而无法到达目的地。但是，由于DNS信息是异步处理的，并且即使初始请求者已经放弃，也会缓存这些信息，因此在以后的尝试中很有可能存在必要的信息。
For later versions of spam software, a check of "MAIL From:" is much less likely to help, since spam software evolves too and will start using existing mail addresses (whether or not that is legal is beyond the scope of this memo). But, at least the Internet will benefit from the side effect that this test stops typos and misconfigured UAs.
对于更高版本的垃圾邮件软件，检查“邮件发件人：”的帮助不大，因为垃圾邮件软件也会发展，并将开始使用现有的邮件地址（这是否合法超出了本备忘录的范围）。但是，至少互联网将受益于这一测试阻止打字错误和错误配置的UAs的副作用。
Our basic assumption is that refuse/accept is handled at the SMTP layer and that an MTA that decides to refuse a message should do so while still in the SMTP dialogue. First, this means that we do not have to store a copy of a message we later decide to refuse and second, our responsibility for that message is low or none - since we have not yet read it in, we leave it to the sender to handle the error.
我们的基本假设是，拒绝/接受是在SMTP层处理的，决定拒绝邮件的MTA应该在SMTP对话中这样做。首先，这意味着我们不必存储我们后来决定拒绝的邮件的副本；其次，我们对该邮件的责任很低或根本没有责任——因为我们还没有读入该邮件，我们将其留给发件人处理错误。
SMTP has several classes of Return Codes, see [1] for a discussion:
SMTP有几种类型的返回码，有关讨论，请参见[1]：
o 5xx is a Permanent Negative Completion reply (Fatal Error) and results in the mail transfer being terminated and the mail returned to sender.
o 5xx是一个永久性的否定完成回复（致命错误），导致邮件传输终止，邮件返回给发件人。
o 4xx is a Transient Negative Completion reply (Temporary Error) and results in the mail transfer being put back on queue again and a new attempt being made later.
o 4xx是一个暂时的否定完成回复（临时错误），导致邮件传输再次放回队列，并在稍后进行新的尝试。
o 2xx is a Positive Completion reply and indicates that the MTA now has taken responsibility for the delivery of the mail.
o 2xx是一个肯定的完成回复，表示MTA现在已负责邮件的交付。
When making use of the options/"knobs" described in this memo there are a few things to consider:
使用本备忘录中描述的选项/旋钮时，需要考虑以下几点：
For some events, like "Denied - you're on the spammer's list", 5xx may be the correct Return Code, since it terminates the session at once and we are done with it (assuming that the spammer plays by the SMTP rules, which he may decide not to do - in fact he can put the mail back on queue or turn to some other host, regardless of Return Code). However, a 5xx mistake in a configuration may cause legitimate mail to bounce, which may be quite unfortunate.
对于某些事件，如“拒绝-您在垃圾邮件发送者列表中”，5xx可能是正确的返回码，因为它会立即终止会话，而我们已经完成了会话（假设垃圾邮件发送者遵守SMTP规则，他可能决定不这样做-事实上，他可以将邮件放回队列或转到其他主机，而不管返回码如何）。然而，配置中的5xx错误可能会导致合法邮件跳出，这可能是非常不幸的。
Therefore, we suggest 4xx as the Return Code for most cases. Since that is a non fatal error, the mail gets re-queued at the sender and we have at least some time to discover and correct configuration errors, rather than have mail bounce (typically this is when we refuse to Relay for domains that we actually should accept since we are on their MX list).
因此，我们建议在大多数情况下使用4xx作为返回码。由于这是一个非致命错误，邮件将在发件人处重新排队，我们至少有一些时间来发现和纠正配置错误，而不是让邮件跳出（通常是当我们拒绝中继我们实际上应该接受的域时，因为我们在它们的MX列表上）。
A 4xx response also makes the spammer's host re-queue the mail and if it really is his own host who gets to do this it is probably a good thing - fill up his disks with his own spam. If, on the other hand, he is using someone else as Relay Host, all the spam mail being queued is a fairly strong evidence that something bad is going on and should cause attention at that Relay Host.
4xx响应还会使垃圾邮件发送者的主机将邮件重新排队，如果真的是他自己的主机执行此操作，这可能是一件好事——用他自己的垃圾邮件填充他的磁盘。另一方面，如果他使用其他人作为中继主机，那么排队的所有垃圾邮件都是一个相当有力的证据，表明正在发生一些不好的事情，应该引起该中继主机的注意。
However, 4xx Temporary Errors may have unexpected interaction with MX-records. If the receiving domain has several MX records and the lowest preference MX-host refuses to receive mail with a "451" Response Code, the sending host may choose to - and often will - use the next host on the MX list.
但是，4xx临时错误可能会与MX记录发生意外交互。如果接收域有多个MX记录，并且最低首选MX主机拒绝接收带有“451”响应代码的邮件，则发送主机可以选择使用MX列表上的下一个主机，并且通常会选择使用该主机。
If that next MX host does not have the same refuse-list, it will of course accept the mail, only to find that the final host still refuses to receive that piece of mail ("MAIL From:"). Our intent was to make the offending mail stay at the offending sender's host and fill up his mqueue disk, but it all ended up at our friend, the next lowest preference MX-host.
如果下一个MX主机没有相同的拒绝列表，它当然会接受邮件，但发现最后一个主机仍然拒绝接收该邮件（“邮件发件人：”）。我们的意图是让有问题的邮件留在有问题的发件人的主机上，并填满他的MQUE磁盘，但最终都是在我们的朋友处，下一个偏好最低的MX主机上。
Finally, it has been suggested that one may use a 2xx Return Code but nevertheless decide not to forward or receive the spam mail; typical alternatives are to store it elsewhere (e.g. /dev/null). This clearly violates the intent of RFC821 and should not be done without careful consideration - instead of blindly dropping the mail one could re-queue it and manually (or automagically) inspect whether it is spam or legitimate mail and whether it should be dropped or forwarded.
最后，有人建议可以使用2xx返回码，但决定不转发或接收垃圾邮件；典型的替代方法是将其存储在其他位置（例如/dev/null）。这显然违反了RFC821的意图，不应在未经仔细考虑的情况下执行此操作-与其盲目丢弃邮件，还可以对其重新排队，并手动（或自动）检查其是否为垃圾邮件或合法邮件，以及是否应丢弃或转发。
An MTA that also has the ability to handle mailing lists and expand that to a number of recipients, needs to be able to authorize senders and protect its lists from spam. The mechanisms for this may be very different from those for ordinary mail and ordinary users and are not covered in this memo.
MTA还能够处理邮件列表并将其扩展到多个收件人，它需要能够授权发件人并保护其列表不受垃圾邮件的影响。这方面的机制可能与普通邮件和普通用户的机制大不相同，本备忘录不包括这方面的内容。
Here we first give a brief list of recommendations, followed by a more thorough discussion of each of them. We will also give recommendations on things NOT to do, things that may seem natural in the spam fight (and might even work so far) but that might wreak havoc on Internet mail and thus may cause more damage than good.
在这里，我们首先给出一个简短的建议列表，然后对每个建议进行更深入的讨论。我们还将对不应该做的事情提出建议，这些事情可能在垃圾邮件斗争中看起来很自然（甚至到目前为止可能奏效），但可能会对互联网邮件造成严重破坏，因此可能造成更多的损害而不是好处。
1) MUST be able to restrict unauthorized use as Mail Relay.
1) 必须能够限制未经授权的邮件中继使用。
2) MUST be able to provide "Received:" lines with enough information to make it possible to trace the mail path, despite spammers use forged host names in HELO statements etc.
2) 必须能够提供“已收到：”行足够的信息，使其能够跟踪邮件路径，尽管垃圾邮件发送者在HELO声明中使用伪造的主机名等。
3) MUST be able to provide local log information that makes it possible to trace the event afterwards.
3) 必须能够提供本地日志信息，以便事后跟踪事件。
4) SHOULD be able to log all occurrences of anti-relay/anti-spam actions.
4) 应能够记录所有发生的反中继/反垃圾邮件操作。
5) SHOULD be able to refuse mail from a host or a group of hosts.
5) 应该能够拒绝来自一个主机或一组主机的邮件。
6a) MUST NOT refuse "MAIL From: <>".
6a）不得拒绝“来自：<>的邮件”。
6b) MUST NOT refuse "MAIL From: <user@my.local.dom.ain>".
6b）不得拒绝来自以下地址的“邮件”：<user@my.local.dom.ain>".
7a) SHOULD be able to refuse mail from a specific "MAIL From:" user, <foo@domain.example>.
7a）应能够拒绝来自特定“邮件发件人：”用户的邮件<foo@domain.example>.
7b) SHOULD be able to refuse mail from an entire "MAIL From:" domain <.*@domain.example>.
7b）应该能够拒绝来自整个“邮件发件人：”域<.@domain.example>的邮件。
8) SHOULD be able to limit ("Rate Control") mail flow.
8) 应该能够限制（“速率控制”）邮件流。
9) SHOULD be able to verify "MAIL From:" domain (using DNS or other means).
9) 应该能够验证“邮件发件人：”域（使用DNS或其他方式）。
10) SHOULD be able to verify <local-part> in outgoing mail.
10） 应该能够在发送邮件中验证<local part>。
11) SHOULD be able to control SMTP VRFY and EXPN.
11） 应该能够控制SMTP VRFY和EXPN。
12) SHOULD be able to control SMTP ETRN.
12） 应该能够控制SMTP ETRN。
13) MUST be able to configure to provide different Return Codes for different rules (e.g. 451 Temp Fail vs 550 Fatal Error).
13） 必须能够配置为针对不同规则提供不同的返回代码（例如451 Temp Fail与550致命错误）。
The discussion below often ends up with a need to do various forms of pattern matching on domain/host names and IP addresses/subnets. It is RECOMMENDED that the data/template for doing so may be supplied outside of the MTA, e.g. that the pattern matching rules be included in the MTA but that the actual patterns may be in an external file. It is also RECOMMENDED that the pattern matching rules (external file) may contain regular expressions, to give maximum flexibility.
下面的讨论通常以需要对域名/主机名和IP地址/子网进行各种形式的模式匹配而结束。建议在MTA之外提供执行此操作的数据/模板，例如，MTA中应包含模式匹配规则，但实际模式可能位于外部文件中。还建议模式匹配规则（外部文件）可以包含正则表达式，以提供最大的灵活性。
Of course string matching on domain/host names MUST NOT be case sensitive. Since <local-part> may be case sensitive it may be natural to keep that here. However, since <sPAmMeR@domain.example> and <spammer@domain.example> is most probably the same user and since the string compares are used to refuse his messages, we suggest that <local-part> comparisons be case insensitive too.
当然，域名/主机名上的字符串匹配不能区分大小写。由于<local part>可能区分大小写，因此将其保留在此处可能很自然。但是,<sPAmMeR@domain.example>及<spammer@domain.example>很可能是同一个用户，由于字符串比较用于拒绝他的消息，我们建议<local part>比较也不区分大小写。
The interpretation that should apply to all these recommendations is flexibility - regardless of how well we design anti-spam rules today, spammers will find ways around them and a well designed MTA should be flexible enough to meet those new threats.
适用于所有这些建议的解释是灵活性——无论我们今天设计的反垃圾邮件规则有多好，垃圾邮件发送者都会找到绕过这些规则的方法，设计良好的MTA应该足够灵活，以应对这些新威胁。
Unauthorized usage of a host as Mail Relay means theft of the relay's resources and puts the relay owner's reputation at risk. It also makes it impossible to filter out or block spam without at the same time blocking legitimate mail.
未经授权将主机用作邮件中继意味着窃取中继的资源，并使中继所有者的声誉处于危险之中。它还使得在不同时阻止合法邮件的情况下，无法过滤或阻止垃圾邮件。
Therefore, the MTA MUST be able to control/refuse such Relay usage.
因此，MTA必须能够控制/拒绝此类中继使用。
In an SMTP session we have 4 elements, each with a varying degree of trust:
在SMTP会话中，我们有4个元素，每个元素具有不同程度的信任：
1) "HELO Hostname" Easily and often forged. 2) "MAIL From:" Easily and often forged. 3) "RCPT To:" Correct, or at least intended. 4) SMTP_Caller (host) IP.src addr OK, FQDN may be OK.
1) “HELO主机名”很容易伪造。2） 邮件来源：“容易伪造。3） “RCPT To:”正确，或至少是预期的。4） SMTP_呼叫方（主机）IP.src地址正常，FQDN可能正常。
Since 1) and 2) are so easily and often forged, we cannot depend on them at all to authorize usage of our host as Mail Relay.
由于1）和2）非常容易伪造，我们根本无法依靠它们来授权将主机用作邮件中继。
Instead, the MTA MUST be able to authorize Mail Relay usage based on a combination of:
相反，MTA必须能够基于以下组合授权邮件中继使用：
o "RCPT To:" address (domain). o SMTP_Caller FQDN hostname. o SMTP_Caller IP address.
o “RCPT To:”地址（域）。o SMTP_呼叫方FQDN主机名。o SMTP_呼叫方IP地址。
The suggested algorithm is:
建议的算法是：
a) If "RCPT To:" is one of "our" domains, local or a domain that we accept to forward to (alternate MX), then accept to Relay.
a) 如果“RCPT To:”是“我们的”域之一，本地域或我们接受转发的域（备用MX），则接受中继。
b) If SMTP_Caller is authorized, either its IP.src or its FQDN (depending on if you trust the DNS), then accept to Relay.
b) 如果SMTP_调用方已授权，则其IP.src或FQDN（取决于您是否信任DNS），然后接受中继。
c) Else refuse to Relay.
c) 否则拒绝接力。
When doing a) you have to make sure all kinds of SMTP source routing (both the official [@a,@b:u@c], the '%' hack and uucp-style '!' path) is either removed completely before the test, or at least is taken into account.
执行a）时，必须确保所有类型的SMTP源路由（包括官方[@a，@b:u@c]，则在测试之前完全删除“%”hack and uucp style“！”路径），或者至少将其考虑在内。
A site implementing this requirement must also be aware that they might block correctly addressed messages, especially such originating or terminating in a gateway to a different mail system than SMTP. Before implementing such a policy, a careful inventory should be done to make sure all routing algorithms used, either by other mail systems or ad-hoc, are known. Each one of such systems must be taken care of on a case-by-case basis.
实现此要求的站点还必须知道，它们可能会阻止正确寻址的邮件，尤其是在与SMTP不同的邮件系统的网关中发起或终止的邮件。在实施此类策略之前，应仔细清点，以确保其他邮件系统或ad-hoc使用的所有路由算法都是已知的。这些系统中的每一个都必须根据具体情况加以处理。
Examples of such mail systems, and their addressing schemes are X.400 with an address of the type:
此类邮件系统的示例及其寻址方案为X.400，地址类型为：
"/c=us/admd= /prmd=xyz/dd.rfc-822=user(a)final/"@x400-gateway
"/c=us/admd= /prmd=xyz/dd.rfc-822=user(a)final/"@x400-gateway
Another example involves DECnet MAIL-11, which can have addresses in the form:
另一个例子涉及DECnet MAIL-11，其地址可以是：
"gateway::smtp%\"user@final\""@mail-11-gateway
"gateway::smtp%\"user@final\""@mail-11-gateway
In all cases the configuration MUST support wild cards for FQDNs and classful IP addresses and SHOULD support "address/mask" for classless IP addresses, e.g. domain.example and *.domain.example; 10.11.*.*, 192.168.1.*, 192.168.2.*, 10.0.0.0/13, 192.168.1.0/23.
在所有情况下，配置必须支持FQDN和类IP地址的通配符，并应支持无类IP地址的“地址/掩码”，例如domain.example和*.domain.example；10.11.*.*, 192.168.1.*, 192.168.2.*, 10.0.0.0/13, 192.168.1.0/23.
The configuration SHOULD allow for the decision/template data to be supplied by an external source, e.g. text file or dbm database. The decision/template SHOULD be allowed to contain regular expressions.
配置应允许决策/模板数据由外部源提供，例如文本文件或dbm数据库。应该允许决策/模板包含正则表达式。
The MTA MUST prepend a "Received:" line in the mail (as described in RFC822, [2], and required in RFC1123, [3]). This "Received:" line MUST contain enough information to make it possible to trace the mail path back to the sender. We have two cases:
MTA必须在邮件中的“Received:”行前面加上前缀（如RFC822[2]中所述，并且RFC1123[3]中要求）。此“Received:”行必须包含足够的信息，以便能够将邮件路径追溯回发件人。我们有两个案例：
Internet mail was designed such that the sending host connects directly to the recipient as described by MX records (there may be several MX hosts on a priority list). To assure traceability back to the sending host (which may be a firewall/gateway, as described later) each MTA along the path, including the final MTA, MUST prepend a "Received:" line. For such a "Received:" line we have:
Internet邮件的设计使发送主机直接连接到MX记录所述的收件人（优先级列表上可能有多个MX主机）。为确保可追溯到发送主机（可能是防火墙/网关，如下文所述），路径上的每个MTA（包括最终MTA）必须在“已接收：”行前加上前缀。对于这样一个“收到：”行，我们有：
It MUST contain:
它必须包含：
o The IP address of the caller.
o 调用方的IP地址。
o The 'date-time' as described in RFC822, [2], pp 18.
o RFC822[2]，第18页所述的“日期-时间”。
It SHOULD contain:
它应包括：
o The FQDN corresponding to the callers IP address.
o 与呼叫者IP地址对应的FQDN。
o The argument given in the "HELO" statement.
o “HELO”语句中给出的论点。
o Authentication information, if an authenticated connection was used for the transmission / submission.
o 身份验证信息，如果传输/提交使用了经过身份验证的连接。
It is suggested that most other "Received:" fields described in RFC822 be included in the "Received:" lines.
建议将RFC822中描述的大多数其他“已接收：”字段包括在“已接收：”行中。
Basically, any information that can help tracing the message can and should be added to the "Received:" line. It is true even when the initial submission is non-SMTP, for example submission via a web-based
基本上，任何有助于跟踪消息的信息都可以而且应该添加到“Received:”行中。即使初始提交是非SMTP的，例如通过基于web的
mail client where http is used between the web client and server, a "Received:" line can be used to identify that connection stating what IP-address was used when connecting to the http server where the mail was created.
邮件客户端在web客户端和服务器之间使用http时，可以使用“Received:”行来标识该连接，说明在连接到创建邮件的http服务器时使用的IP地址。
These recommendations are deliberately stronger than RFC1123, [3], and are there to assure that mail sent directly from a spammer's host to a recipient can be traced with enough accuracy; a typical example is when a spammer uses a dialup account and the ISP needs to have his IP address at the 'date-time' to be able to take action against him.
这些建议故意强于RFC1123[3]，旨在确保直接从垃圾邮件发送者的主机发送给收件人的邮件能够被足够准确地追踪；一个典型的例子是，当垃圾邮件发送者使用拨号帐户时，ISP需要在“日期时间”拥有其IP地址才能对其采取行动。
Organizations with a policy of hiding their internal network structure must still be allowed and able to do so. They usually make their internal MTAs prepend "Received:" lines with a very limited amount of information, or prepend none at all. Then they send out the mail through some kind of firewall/gateway device, which may even remove all the internal MTAs' "Received:" lines before it prepends its own "Received:" line (as required in RFC1123, [3]).
具有隐藏其内部网络结构策略的组织必须仍然被允许并能够这样做。他们通常在内部MTA前加上“已接收：”行，信息量非常有限，或者根本不预加任何信息。然后他们通过某种防火墙/网关设备发送邮件，这种设备甚至可以在预处理自己的“接收：”行之前删除所有内部MTA的“接收：”行（如RFC1123[3]中所要求）。
By doing so they take on the full responsibility to trace spammers that send from inside their organization or they accept to be held responsible for those spammers' activities. It is REQUIRED that the information provided in their outgoing mail is sufficient for them to perform any necessary traces.
通过这样做，他们承担了追踪从组织内部发送的垃圾邮件发送者的全部责任，或者他们接受对这些垃圾邮件发送者的活动负责。要求其发送邮件中提供的信息足以进行任何必要的跟踪。
In the case of incoming mail to an organization, the "Received:" lines MUST be kept intact to make sure that users receiving mail on the inside can give information needed to trace incoming messages to their origin.
对于发送给组织的传入邮件，“已接收：”行必须保持完整，以确保从内部接收邮件的用户可以提供跟踪传入邮件至其来源所需的信息。
Generally, a gateway SHOULD NOT change or delete "Received:" lines unless it is a security requirement to do so. Changing the content of existing "Received:" lines to make sure they "make sense" when passing a mail gateway of some kind most often destroys and deletes information needed to make a message traceable. Care must be taken to preserve the information in "Received:" lines, either in the message itself, the mail that the receiver gets, or if that is impossible, in logfiles.
通常，网关不应更改或删除“已接收：”行，除非是出于安全要求。更改现有“已接收：”行的内容，以确保它们在通过某种邮件网关时“有意义”，通常会破坏和删除使邮件可跟踪所需的信息。必须注意将信息保存在“Received:”行中，或者保存在消息本身、接收者收到的邮件中，或者如果不可能，保存在日志文件中。
The MTA MUST be able to provide enough local log information to make it possible to trace the event. This includes most of the information put into the "Received:" lines; see above.
MTA必须能够提供足够的本地日志信息，以便能够跟踪事件。这包括输入“已接收：”行的大部分信息；见上文。
The MTA SHOULD be able to log all anti-relay/anti-spam actions. The log entries SHOULD contain at least:
MTA应该能够记录所有反中继/反垃圾邮件操作。日志条目应至少包含以下内容：
o Time information.
o 时间信息。
o Refusal information, i.e. why the request was refused ("Mail From", "Relaying Denied", "Spam User", "Spam Host", etc).
o 拒绝信息，即拒绝请求的原因（“来自”、“拒绝转发”、“垃圾邮件用户”、“垃圾邮件主机”等）。
o "RCPT To:" addresses (domains). (If the connection was disallowed at an earlier stage, e.g. by checking the SMTP_Caller IP address, the "RCPT To:" address is unknown and therefore cannot be logged).
o “RCPT To:”地址（域）。（如果在早期阶段不允许连接，例如通过检查SMTP_呼叫者IP地址，“RCPT To:”地址未知，因此无法记录）。
o Offending host's IP address.
o 有问题的主机IP地址。
o Offending host's FQDN hostname.
o 有问题的主机的FQDN主机名。
o Other relevant information (e.g. given during the SMTP dialogue, before we decided to refuse the request).
o 其他相关信息（例如，在我们决定拒绝请求之前，SMTP对话期间提供的信息）。
It should be noted that by logging more events, especially denied email, one opens the possibility for denial of service attacks, for example by filling logs by having a very large amount of "RCPT To:" commands. An implementation that implements increased logging according to this description must be aware of the fact that the size of the logfiles increases, especially during attacks.
应该注意的是，通过记录更多的事件，特别是被拒绝的电子邮件，可以打开拒绝服务攻击的可能性，例如通过使用大量“RCPT To:”命令填充日志。根据此描述实现增加日志记录的实现必须了解日志文件的大小增加的事实，尤其是在攻击期间。
The MTA SHOULD be able to accept or refuse mail from a specific host or from a group of hosts. Here we mean the IP.src address or the FQDN that its .IN-ADDR.ARPA resolves to (depending on whether you trust the DNS). This functionality could be implemented at a firewall, but since the MTA should be able to "defend itself" we recommend it be able to as well.
MTA应该能够接受或拒绝来自特定主机或一组主机的邮件。这里我们指的是IP.src地址或其.IN-ADDR.ARPA解析为的FQDN（取决于您是否信任DNS）。此功能可以在防火墙上实现，但由于MTA应该能够“自我防护”，我们建议它也能够。
It is RECOMMENDED that the MTA be able to decide based on FQDN hostnames (host.domain.example), on wild card domain names (*.domain.example), on individual IP addresses (10.11.12.13) or on IP addresses with a prefix length (10.0.0.0/8, 192.168.1.0/24).
建议MTA能够根据FQDN主机名（host.domain.example）、通配符域名（*.domain.example）、单个IP地址（10.11.12.13）或前缀长度的IP地址（10.0.0.0/8192.168.1.0/24）做出决定。
It is also RECOMMENDED that these decision rules can be combined to form a flexible list of accept/refuse/accept/refuse, e.g:
还建议将这些决策规则结合起来，形成一个灵活的接受/拒绝/接受/拒绝列表，例如：
accept host.domain.example refuse *.domain.example accept 10.11.12.13 accept 192.168.1.0/24 refuse 10.0.0.0/8
接受host.domain.example拒绝*.domain.example接受10.11.12.13接受192.168.1.0/24拒绝10.0.0.0/8
The list is searched until first match and the accept/refuse action is based on that.
搜索列表直到第一次匹配，并且接受/拒绝操作基于此。
IP-address/length is RECOMMENDED. However, implementations with wild cards, e.g. 10.11.12.* (classful networks on byte boundaries only) are of course much better than those without.
建议使用IP地址/长度。然而，使用通配符的实现，例如10.11.12.*（仅限字节边界上的类网络）当然比没有通配符的实现要好得多。
To improve filtering even more, the MTA MAY provide complete regular expressions to be used for hostnames; possibly also for IP addresses.
为了进一步改进过滤，MTA可以提供用于主机名的完整正则表达式；也可能是IP地址。
Although the fight against spammers is important it must never be done in a way that violates existing email standards. Since spammers often forge "MAIL From:" addresses it is tempting to put general restrictions on that, especially for some "obvious" addresses. This may, however, wreak more havoc to the mail community than spam does.
尽管打击垃圾邮件发送者很重要，但绝不能以违反现有电子邮件标准的方式进行。由于垃圾邮件发送者经常伪造“发件人：”地址，因此很容易对其进行一般性限制，特别是对一些“明显”的地址。然而，这可能比垃圾邮件对邮件社区造成更大的破坏。
When there is a need to refuse mail from a particular host or site our recommendation is to use other methods mentioned in this memo, e.g. refuse mail based on SMTP_Caller address (or name), regardless of what "MAIL From:" was used.
当需要拒绝来自特定主机或站点的邮件时，我们建议使用本备忘录中提到的其他方法，例如根据SMTP_呼叫者地址（或名称）拒绝邮件，无论使用的是“邮件发件人”。
The MTA MUST NOT refuse to receive "MAIL From: <>".
MTA不得拒绝接收“邮件发件人：<>”。
The "MAIL From: <>" address is used in error messages from the mail system itself, e.g. when a legitimate mail relay is used and forwards an error message back to the user. Refusing to receive such mail means that users may not be notified of errors in their outgong mail, e.g. "User unknown", which will no doubt wreak more havoc to the mail community than spam does.
“邮件发件人：<>”地址用于来自邮件系统本身的错误消息，例如，当使用合法邮件中继并将错误消息转发回用户时。拒绝接收此类邮件意味着用户可能不会被通知其outgong邮件中的错误，例如“用户未知”，这无疑会比垃圾邮件对邮件社区造成更大的破坏。
The most common case of such legitimate "MAIL From: <>" is to one recipient, i.e. an error message returned to one single individual. Since spammers have used "MAIL From: <>" to send to many recipients, it is tempting to either reject such mail completely or to reject all but the first recipient. However, there are legitimate causes for an error mail to go to multiple recipients, e.g. a list with several list owners, all located at the same remote site, and thus the MTA MUST NOT refuse "MAIL From: <>" even in this case.
这种合法的“邮件发件人：<>”最常见的情况是发送给一个收件人，即返回给一个人的错误消息。由于垃圾邮件发送者使用“邮件发件人：<>”发送给许多收件人，因此很容易完全拒绝此类邮件，或者拒绝除第一个收件人以外的所有收件人。但是，错误邮件发送给多个收件人是有正当理由的，例如，有多个列表所有者的列表都位于同一远程站点，因此MTA即使在这种情况下也不得拒绝“来自：<>”的邮件。
However, the MTA MAY throttle down the TCP connection ("read()" frequency) if there are more than one "RCPT To:" and that way slow down spammers using "MAIL From: <>".
但是，如果存在多个“RCPT To:”，MTA可能会限制TCP连接（“读取（）”频率），这样可以使用“邮件发件人：<>”减慢垃圾邮件发送者的速度。
The MTA MUST NOT refuse "MAIL From: <user@my.local.dom.ain>".
MTA不得拒绝来自以下地址的“邮件”：<user@my.local.dom.ain>".
By "my.local.dom.ain" we mean the domain name(s) that are treated as local and result in local delivery. At first thought it may seem like noone else will need to use "MAIL From: <user@my.local.dom.ain>" and that restrictions on who may use that would reduce the risk of fraud and thus reduce spam. While this may be true in the (very) short term, it also does away with at least two legitimate usages:
我们所说的“my.local.dom.ain”是指被视为本地域名并导致本地交付的域名。乍一看，似乎没有其他人需要使用“来自：<user@my.local.dom.ain>“对谁可以使用的限制将降低欺诈风险，从而减少垃圾邮件。虽然这在（非常）短期内可能是正确的，但它也至少取消了两种合法用法：
o Aliases (.forward files). <user1@my.local.dom.ain> sends to <user2@external.example> and that mail gets forwarded back to <user2@my.local.dom.ain>, e.g. since <user2> has moved to my.local.dom.ain and has a .forward file at external.example.
o 别名（.forward文件）<user1@my.local.dom.ain>发送到<user2@external.example>邮件会被转发回<user2@my.local.dom.ain>，例如，<user2>已移动到my.local.dom.ain，并在external.example中有一个.forward文件。
o Mailing lists. RFC1123, [3], gives a clear requirement that "MAIL From:" for mail from a mailing list should reflect the owner of the list, rather than the individual sender. Because of this fact, and the fact that the owner of the list might not be in the same domain as the list (list host) itself, mail may arrive to the list owner's domain (mail host) from a foreign domain (from a host serving a foreign domain) with the list owner's local domain in the "Mail From:" command.
o 邮件列表。RFC1123[3]明确要求，对于邮件列表中的邮件，“邮件发件人：”应反映列表的所有者，而不是单个发件人。由于这一事实，以及列表所有者可能与列表（列表主机）本身不在同一个域中的事实，邮件可能从外部域（从服务于外部域的主机）到达列表所有者的域（邮件主机），而列表所有者的本地域位于“邮件发件人：”命令中。
If "MAIL From: <user@my.local.dom.ain>" is rejected, both these cases will result in failure to deliver legitimate mail.
如果是“从以下地址发送邮件：<user@my.local.dom.ain>如果被拒绝，这两种情况都将导致无法发送合法邮件。
The MTA SHOULD be able to refuse to receive mail from a specific "MAIL From:" user (foo@domain.example) or from an entire "MAIL From:" domain (domain.example). In general these kinds of rules are easily overcome by the spammers changing "MAIL From:" every so often, but the ability to block a certain user or a certain domain is quite helpful while an attack has just been discovered and is ongoing.
MTA应该能够拒绝接收来自特定“邮件发件人：”用户的邮件(foo@domain.example)或者来自整个“邮件发件人：”域（domain.example）。一般来说，这些规则很容易被垃圾邮件发送者经常更改“邮件发件人：”所克服，但在攻击刚刚被发现并正在进行时，阻止某个用户或某个域的功能非常有用。
Please note that
请注意
"MAIL From: <>"
and
"MAIL From: <user@my.local.dom.ain>"
"MAIL From: <>"
and
"MAIL From: <user@my.local.dom.ain>"
MUST NOT be refused (see above), except when other policies block the connection, for example when the SMTP_Caller IP address of the peer belongs to a network which is deliberately refused.
不得拒绝（见上文），除非其他策略阻止连接，例如对等方的SMTP_呼叫方IP地址属于故意拒绝的网络。
The MTA SHOULD provide tools for the mail host to control the rate with which mail is sent or received. The idea is twofold:
MTA应为邮件主机提供控制邮件发送或接收速率的工具。这个想法有两个方面：
1) If we happen to have an legitimate mail user with an existing legitimate account and this user sends out spam, we may want to reduce the speed with which he sends it out. This is not without controversy and must be used with extreme care, but it may protect the rest of the Internet from him.
1) 如果我们碰巧有一个拥有合法帐户的合法邮件用户，并且该用户发送垃圾邮件，我们可能希望降低他发送垃圾邮件的速度。这不是没有争议的，必须非常小心地使用，但它可能会保护互联网的其他部分不受他的影响。
2) If we are under a spam attack it may help us considerably just being able to slow down the incoming mail rate for that particular user/host.
2) 如果我们受到垃圾邮件攻击，它可能会大大帮助我们降低特定用户/主机的接收邮件速率。
For sending mail, this has to be done by throttling the TCP connection to set the acceptable output data rate, e.g. reduce the "write()" frequency.
对于发送邮件，必须通过限制TCP连接来设置可接受的输出数据速率，例如降低“write（）”频率。
For receiving mail, we could use basically the same technique, e.g. reduce the "read()" frequency, or we could signal with a 4xx Return Code that we cannot receive. It is RECOMMENDED that the decision to take such action be based on "MAIL From:" user, "MAIL From:" domain, SMTP_Caller (name/address), "RCPT TO:", or a combination of all these.
对于接收邮件，我们可以使用基本相同的技术，例如降低“read（）”频率，或者我们可以使用4xx返回码发送无法接收的信号。建议根据“邮件发件人：”用户、“邮件发件人：”域、SMTP_呼叫者（名称/地址）、“RCPT to:”或所有这些的组合来决定是否采取此类行动。
The MTA SHOULD be able to perform a simple "sanity check" of the "MAIL From:" domain and refuse to receive mail if that domain is nonexistent (i.e. does not resolve to having an MX or an A record). If the DNS error is temporary, TempFail, the MTA MUST return a 4xx Return Code (Temporary Error). If the DNS error is an Authoritative NXdomain (host/domain unknown) the MTA SHOULD still return a 4xx Return Code (since this may just be primary and secondary DNS not being in sync) but it MAY allow for an 5xx Return Code (as configured by the sysadmin).
MTA应该能够对“邮件发件人：”域执行简单的“健全性检查”，并在该域不存在时拒绝接收邮件（即，未解析为具有MX或a记录）。如果DNS错误是临时性的TempFail，MTA必须返回4xx返回码（临时错误）。如果DNS错误是授权域（主机/域未知），MTA仍应返回4xx返回码（因为这可能只是主DNS和辅助DNS不同步），但它可能允许5xx返回码（由系统管理员配置）。
The MTA SHOULD allow outgoing mail to have its <local-part> verified so that the sender name is a real user or an existing alias. This is basically to protect the rest of the Internet from various "typos"
MTA应允许对传出邮件的<local part>进行验证，以便发件人名称为真实用户或现有别名。这基本上是为了保护互联网的其他部分免受各种“打字错误”的影响
MAIL From: <fo0bar@domain.example>
MAIL From: <fo0bar@domain.example>
and/or malicious users
和/或恶意用户
MAIL From: <I.am.unknown.to.you.he.he@domain.example>
MAIL From: <I.am.unknown.to.you.he.he@domain.example>
As always this can be overcome by spammers really wanting to do so, but with more strict rules for relaying it becomes harder and harder. In fact, catching "typos" at the initial (and official) mail relay is in itself enough motivation for this recommendation.
像往常一样，这可以被真正想这样做的垃圾邮件发送者克服，但随着对转发的更严格的规则，这变得越来越难。事实上，在最初（和官方）的邮件传递中发现“打字错误”本身就足以成为这项建议的动机。
Both SMTP VRFY and EXPN provide means for a potential spammer to test whether the addresses on his list are valid (VRFY) and even get more addresses (EXPN). Therefore, the MTA SHOULD control who is is allowed to issue these commands. This may be "on/off" or it may use access lists similar to those mentioned previously.
SMTP VRFY和EXPN都为潜在的垃圾邮件发送者提供了测试其列表上的地址是否有效（VRFY）甚至获取更多地址（EXPN）的方法。因此，MTA应该控制允许谁发出这些命令。这可能是“开/关”，也可能使用类似于前面提到的访问列表。
Note that the "VRFY" command is required according to RFC821, [1]. The response can, though, be "252 Argument not checked" to represent "off" or blocked via an access list. This should be the default.
注意，根据RFC821[1]，需要“VRFY”命令。不过，响应可以是“252参数未选中”，表示“关闭”或通过访问列表阻止。这应该是默认值。
Default for the "EXPN" command should be "off".
“EXPN”命令的默认值应为“off”。
SMTP ETRN means that the MTA will re-run its mail queue, which may be quite costly and open for Denial of Service attacks. Therefore, the MTA SHOULD control who is is allowed to issue the ETRN command. This may be "on/off" or it may use access lists similar to those mentioned previously. Default should be "off".
SMTP ETRN意味着MTA将重新运行其邮件队列，这可能会非常昂贵，并且会导致拒绝服务攻击。因此，MTA应控制允许谁发出ETRN命令。这可能是“开/关”，也可能使用类似于前面提到的访问列表。默认值应为“关闭”。
The primary issue here is flexibility - it is simply not possible to define in a document how to make tradeoffs between returning 5xx and make legitimate mail fail at once due to a configuration mistake and returning 4xx and be able to catch such configuration mistakes via log file inspection.
这里的主要问题是灵活性—在文档中无法定义如何在返回5xx和使合法邮件因配置错误而立即失败与返回4xx之间进行权衡，并且无法通过日志文件检查捕获此类配置错误。
Therefore, the MTA MUST be configurable to provide "Success" (2xx), "Temporary Failure" (4xx) or "Permanent Failure" (5xx) for different rules or policies. The exact return codes, other than the first digit (2, 4 or 5) should, however, not be configurable. This is because of the ease of configuring the software in the wrong way, and the fact
因此，MTA必须可配置为为不同的规则或策略提供“成功”（2xx）、“暂时失败”（4xx）或“永久失败”（5xx）。但是，除了第一个数字（2、4或5）之外，不应配置精确的返回码。这是因为易于以错误的方式配置软件，而且
that the selection of exactly what error code to use is very subtle and that many software implementations do check more than the first digit (2, 4 or 5) in the return code.
选择要使用的错误代码是非常微妙的，许多软件实现都会检查返回代码中的第一个数字（2、4或5）。
However, when the response is the result of a DNS lookup and the DNS system returned TempFail, a temporary error, the MTA MUST reflect this and provide a 4xx return code. If the DNS response is an Authoritative NXdomain (host or domain unknown) the MTA MAY reflect this by a 5xx Return Code.
但是，当响应是DNS查找的结果并且DNS系统返回临时错误TempFail时，MTA必须反映这一情况并提供4xx返回代码。如果DNS响应是权威域（主机或域未知），MTA可能会通过5xx返回代码反映这一点。
Please refer to the previous discussion on SMTP Return Codes for additional information.
有关更多信息，请参阅前面关于SMTP返回代码的讨论。
At Chalmers University of Technology our DNS contains
在查尔默斯技术大学，我们的DNS包含
cdg.chalmers.se. IN MX 0 mail.cdg.chalmers.se. IN MX 100 mail.chalmers.se.
cdg.chalmers.se。在MX 0 mail.cdg.chalmers.se中。在MX 100 mail.chalmers.se中。
and similarly for most subdomains, i.e. a second host to store mail to each subdomain, should their mail host be down. This means that mail.chalmers.se must be prepared to act as Mail Relay for the subdomains ("RCPT To:") it serves and that those subdomains' mail hosts have to accept SMTP connections from mail.chalmers.se. Late versions of spam software make use of this fact by always using mail.chalmers.se to get their mail delivered to our subdomains and by doing so they still get Mail Relaying done for them and they prevent recipient hosts from refusing SMTP connections based on the sending host's FQDN or IP-address.
同样，对于大多数子域，也就是说，如果它们的邮件主机关闭，则为每个子域存储邮件的第二个主机。这意味着mail.chalmers.se必须准备好充当其服务的子域（“RCPT to:”）的邮件中继，并且这些子域的邮件主机必须接受来自mail.chalmers.se的SMTP连接。垃圾邮件软件的最新版本利用这一事实，始终使用mail.chalmers.se将其邮件发送到我们的子域，这样他们仍然可以为他们完成邮件中继，并防止收件人主机拒绝基于发送主机的FQDN或IP地址的SMTP连接。
As long as we keep our design with a secondary MX host we cannot really have mail.chalmers.se refuse Mail Relay, at least not with a 5xx return code. However, it has been fairly straight forward to identify the hosts/domains/networks that make use of this possibility and refuse to act as Mail Relay for them them - and only them - and do so with a 4xx return code. Legitimate mail from them may be delayed if the final recipient host is down but will eventually be delivered when it gets up again (4xx Return Code) and this is no worse then if we changed our MX design. Spam now faces a "Denied" response and have to connect to each and every one of the recipients, who may decide to refuse the SMTP connection.
只要我们使用辅助MX主机进行设计，我们就不能真正使用mail.chalmers.se拒绝邮件中继，至少不能使用5xx返回码。然而，识别利用这种可能性的主机/域/网络并拒绝充当它们的邮件中继（并且仅限于它们），并使用4xx返回码来实现这一点是相当直接的。如果最终收件人主机关闭，来自他们的合法邮件可能会延迟，但最终会在它再次启动时送达（4xx返回码），如果我们更改MX设计，情况也不会更糟。垃圾邮件现在面临“拒绝”响应，必须连接到每个收件人，这些收件人可能决定拒绝SMTP连接。
The bottom line is that this is made possible because of 1) enough flexibility in the Relay Authorization code and 2) enough flexibility in assigning Return Codes - an MTA with a 5xx Return Code carved in stone would have made this absolutely impossible.
归根结底，这是可能的，因为1）中继授权代码具有足够的灵活性，2）分配返回代码具有足够的灵活性-如果MTA在石头上刻上5xx返回代码，这将是绝对不可能的。
Even though this memo is about MTAs and recommendations for them, some of what is done here also impacts UAs (User Agents, the "ordinary mail programs").
尽管本备忘录是关于MTA及其建议的，但此处所做的一些工作也会影响UAs（用户代理，即“普通邮件程序”）。
A UA does two things:
UA做两件事：
1) Reads mail from a mailbox and prints on the screen. This typically uses a protocol like POP, IMAP or NFS.
1) 从邮箱读取邮件并在屏幕上打印。这通常使用POP、IMAP或NFS等协议。
2) Reads text from the keyboard and hands that over to the mailbox MTA for delivery as a piece of mail. This typically uses the SMTP protocol, i.e. the same protocol that is used between MTAs.
2) 从键盘读取文本，并将其交给邮箱MTA，作为邮件发送。这通常使用SMTP协议，即MTA之间使用的相同协议。
When MTAs now start to implement various anti-relay filters as described above, a UA on a portable laptop host may get a response like "Relaying Denied" just because it happens to use IP addresses within an unknown range or that resolve to unknown FQDNs.
当MTA现在开始实施如上所述的各种反中继筛选器时，便携式笔记本电脑主机上的UA可能会收到类似“拒绝中继”的响应，因为它碰巧使用未知范围内的IP地址或解析为未知FQDN的IP地址。
The typical victim of this "Relaying Denied" response is a salesman carrying a laptop on a business trip, or even an IETF delegate at a meeting hotel. The salesman will probably dial his nearest ISP and will get an IP address from that dialup pool; the IETF delegate will use an IP address from the terminal room. In both cases their laptop mail program (the UA; e.g. pine, Netscape, Eudora) will try to send out mail via their home MTA, e.g. SMTP-SERVER=mail.home.example, but unless mail.home.example has been updated to accept that (temporary) IP address it will respond "Relaying Denied" and refuse.
这种“拒绝转达”回答的典型受害者是出差时携带笔记本电脑的推销员，甚至是会议酒店的IETF代表。销售人员可能会拨打最近的ISP，并从拨号池中获得IP地址；IETF代表将使用来自终端室的IP地址。在这两种情况下，他们的笔记本电脑邮件程序（UA；例如pine、Netscape、Eudora）将尝试通过他们的家庭MTA发送邮件，例如SMTP-SERVER=mail.home.example，但除非mail.home.example已更新为接受（临时）IP地址，否则它将响应“拒绝中继”并拒绝。
To get around this problem we could simply add the terminal room's or the dialup pool's IP network to the list of accepted networks at mail.home.example. This does open up some minimal risk of spammers using that host as their Mail Relay: If they use the same ISP's dialup pool and they configure to use mail.home.example at the same time as our salesman is on his trip, then the spammers will be authorized to relay their spam through mail.home.example. However, this is not extremely likely and as long as we do not open up for the entire world all the time and we keep the log files under close observation and we stop relaying at once we find we're being used, this solution is probably good enough.
为了解决这个问题，我们可以简单地将终端室或拨号池的IP网络添加到mail.home.example的可接受网络列表中。这确实会使垃圾邮件发送者将该主机用作邮件中继的风险降至最低：如果他们使用同一ISP的拨号池，并在我们的销售人员出差的同时配置为使用Mail.home.example，那么垃圾邮件发送者将被授权通过Mail.home.example中继他们的垃圾邮件。然而，这种可能性不大，只要我们不一直向全世界开放，我们密切观察日志文件，一旦发现我们正在使用，我们就停止转发，这种解决方案可能就足够好了。
Another way around is that our salesman uses a Mail Relay provided by the current dialup ISP, if that service exists. To do so he has to modify SMTP-SERVER= in his UA, which may or may not be reasonable.
另一种方法是，我们的销售人员使用由当前拨号ISP提供的邮件中继，如果该服务存在的话。为此，他必须修改UA中的SMTP-SERVER=，这可能合理，也可能不合理。
The correct way to handle this situation, though, is by some other mail-sending protocol between the UA and the MTA.
但是，处理这种情况的正确方法是通过UA和MTA之间的其他邮件发送协议。
Although a separate submission protocol does not exist, a profile of SMTP for this, the "Message Submission" specification, [9], has recently been defined.
虽然不存在单独的提交协议，但最近定义了用于此协议的SMTP配置文件“邮件提交”规范[9]。
Or, we could note that when the SMTP Authentication work, [10], is all in place, it will allow for Authenticated SMTP to serve as The Protocol between the UAs and the home MTA (whether that should be considered a new protocol or "the same old SMTP" is irrelevant here).
或者，我们可以注意到，当SMTP身份验证工作[10]全部就绪时，它将允许经过身份验证的SMTP充当UAs和家庭MTA之间的协议（这是一个新协议还是“相同的旧SMTP”在这里无关紧要）。
This adds one item to the suggested Relay algorithm in section 2.1:
这为第2.1节中建议的中继算法增加了一项：
+ If "SMTP Authenticated" then accept to Relay.
+ 如果“SMTP已验证”，则接受中继。
Since all users are individuals, there is little hope that any central anti-spam action will suit them all - in fact people can and do argue about Freedom of Speech infringement if some central set of anti-spam rules is enforced without the users' approval. (One could of course also argue whether spam really adds anything to anyone, but that must be up to each individual user to decide, rather than being centrally decided).
由于所有用户都是个人，因此没有希望任何中央反垃圾邮件行动会对他们所有人都有利——事实上，如果在未经用户批准的情况下执行某些中央反垃圾邮件规则，人们可以而且确实会对侵犯言论自由进行辩论。（当然，人们也可以争论垃圾邮件是否真的会给任何人带来任何好处，但这必须由每个用户自己决定，而不是集中决定）。
Therefore the only reasonable extension is to allow for personal anti-spam filters, i.e. anti-spam filters like the ones described earlier in this memo, but available and configurable on a per user basis. Since most users will not have a strong opinion (except that they want to avoid spam) the mail system should provide a system default and give each user the ability to override or modify that. In a UNIX based environment one could have something like
因此，唯一合理的扩展是允许个人反垃圾邮件过滤器，即如本备忘录前面所述的反垃圾邮件过滤器，但每个用户都可以使用和配置。由于大多数用户不会有强烈的意见（除非他们希望避免垃圾邮件），邮件系统应该提供一个系统默认值，并给每个用户覆盖或修改该值的能力。在基于UNIX的环境中，可以使用以下内容
/etc/mail/rc.spam
~/.spamrc
/etc/mail/rc.spam
~/.spamrc
and rules on how the latter can interfere with the former.
以及关于后者如何干预前者的规则。
All of this opens up quite a number of unresolved issues, e.g. whether each user himself really should be allowed to decide on SMTP Return Codes (and how it should be described so he understands enough of the implications) and how existing mail systems will deal with different per user responses, especially how they will deal with a mix of 5xx and 4xx codes:
所有这些都带来了许多尚未解决的问题，例如，是否真的应该允许每个用户自己决定SMTP返回码（以及如何描述它以使其充分了解其含义），以及现有邮件系统将如何处理不同的每个用户响应，特别是他们将如何处理5xx和4xx代码的混合：
C MAIL From: <usr@spam.example>
S 250 <usr@spam.example>... Sender ok
C MAIL From: <usr@spam.example>
S 250 <usr@spam.example>... Sender ok
C RCPT To: <usr@domain.example>
S 250 <usr@domain.example>... Recipient ok
C RCPT To: <foo@domain.example>
S 451 <foo@domain.example>... Denied due to spam list
C RCPT To: <bar@domain.example>
S 550 <bar@domain.example>... Denied due to spam list
C RCPT To: <usr@domain.example>
S 250 <usr@domain.example>... Recipient ok
C RCPT To: <foo@domain.example>
S 451 <foo@domain.example>... Denied due to spam list
C RCPT To: <bar@domain.example>
S 550 <bar@domain.example>... Denied due to spam list
Of course one could decide on either "250 OK" or "550 Denied" with no other alternatives for the individual user, but this too has to be explained enough that an ordinary user understands the implications of "Refuse 'MAIL From: <.*@spam.example>'" and that it can do away with, or block out, mail he actually wanted.
当然，用户可以在没有其他选择的情况下决定“250 OK”或“550 Denied”，但这也必须得到足够的解释，让普通用户理解“拒绝”来自以下地址的邮件的含义：<.@spam.example>”，并且它可以删除或阻止他真正想要的邮件。
SMTP Authentication, [10], has already been mentioned as a method to authorize Mail Relaying, but of course there is much more to it than that. When that infrastructure and functionality is all in place, spammers will have a much harder time forging addresses and hiding.
SMTP身份验证[10]已经被提到是一种授权邮件中继的方法，但当然还有更多。当这些基础设施和功能都到位时，垃圾邮件发送者将很难伪造地址和隐藏。
With the increased use of Network Address Translators (NATs) may come a need for additional information in log files. As long as there is a 1:1 mapping between the addresses inside the NAT and the addresses used outside it everything is OK, but if the NAT box also translates port numbers (to combine many internal hosts into one external address) we will need to log not only the IP addresses of spam hosts but also the port numbers. Otherwise we will not be able to identify the individual host inside the NAT.
随着网络地址转换器（NAT）使用的增加，可能需要日志文件中的附加信息。只要NAT内部的地址和外部使用的地址之间存在1:1的映射，一切都正常，但是如果NAT框还转换端口号（将许多内部主机合并为一个外部地址），我们不仅需要记录垃圾邮件主机的IP地址，还需要记录端口号。否则，我们将无法识别NAT中的单个主机。
The grassfire-like increase of spam raises several security issues which, in fact, puts the entire Internet mail community at risk:
垃圾邮件的“草火”式增长引发了几个安全问题，事实上，这些问题将整个互联网邮件社区置于风险之中：
o People may fail to find important mail in their flooded mailboxes. Or, they may delete it while cleaning up.
o 人们可能无法在被淹没的邮箱中找到重要邮件。或者，他们可以在清理时删除它。
o ISPs get overloaded mailbox hosts and filled disk. Cleaning up and helping customers requires a lot of human resources. In fact, ISP mail servers have crashed by too much mail.
o ISP得到过载的邮箱主机和充满的磁盘。清理和帮助客户需要大量人力资源。事实上，ISP邮件服务器因邮件过多而崩溃。
o While disks are unaccessible, either due to being filled or due to "mail quota", important mail may be delayed or lost. Normally this would not happen without notice, but if both the sender and
o 由于磁盘已满或“邮件配额”的原因，无法访问磁盘时，重要邮件可能会延迟或丢失。通常情况下，这不会在没有通知的情况下发生，但如果发送者和
receiver hosts have their disk flooded, the mail being returned may also fail, i.e. the email service may become less trustworthy than before.
接收方主机的磁盘被淹没，返回的邮件也可能失败，即电子邮件服务可能变得比以前更不可信。
o Hosts used as unauthorized Mail Relays become overloaded. Besides the technical implications, this too requires a lot of human resources, cleaning up mail queues and taking care of furious external users that were spammed through the Relay.
o 用作未经授权邮件中继的主机会过载。除了技术上的影响，这也需要大量的人力资源，清理邮件队列，照顾通过中继发送垃圾邮件的愤怒的外部用户。
o The fight against spammers includes blocking their hosts (which is described in this memo). However, there is a great risk that Mail Relay hosts may be blocked too, even though they are also victims. In the long run, this may cause Internet mail service to deteriorate.
o 与垃圾邮件发送者的斗争包括阻止他们的主机（这在本备忘录中有描述）。然而，邮件中继主机也有很大的风险被阻止，即使它们也是受害者。从长远来看，这可能会导致互联网邮件服务恶化。
o The common use of forged "MAIL From:" and "From:" addresses puts the blame on innocent persons/hosts/organizations. This is bad for reputations and may affect business relations.
o 伪造“发件人：”和“发件人：”地址的普遍使用将责任推到了无辜的人/主人/组织身上。这对声誉不利，并可能影响业务关系。
Several of the methods described in this document increases the load on several support systems to the email system itself. Those support systems can be DNS, logging, databases with lists of local users, authentication mechanisms and others. Implementing the methods described in this document will, because of that, increase the risk of a denial of service attack against the support system by sending spam to a site. Logging facilities must for example be able to handle more logging (what happens when the logfiles fills the disk?). DNS servers and authentication mechanisms must be able to stand the load of more lookups etc.
本文档中描述的几种方法增加了电子邮件系统本身在几个支持系统上的负载。这些支持系统可以是DNS、日志、包含本地用户列表的数据库、身份验证机制等。因此，实施本文档中描述的方法将通过向站点发送垃圾邮件增加对支持系统进行拒绝服务攻击的风险。例如，日志记录设施必须能够处理更多日志记录（当日志文件填满磁盘时会发生什么情况？）。DNS服务器和身份验证机制必须能够承受更多的查找等负载。
The functionality of the support systems during high load should be carefully studied before implementing the methods described in this document.
在实施本文件所述方法之前，应仔细研究高负载期间支撑系统的功能。
The mail system should be carefully studied, e.g. how it behaves when one or more of the support systems needed for a specific method fails. A mail server MUST NOT respond with "Permanent Failure" (5xx) if there is a temporary problem with one of its support systems.
应仔细研究邮件系统，例如，当特定方法所需的一个或多个支持系统出现故障时，邮件系统的行为。如果邮件服务器的某个支持系统出现临时问题，则邮件服务器不得以“永久性故障”（5xx）响应。
This memo is the result of discussions in an ad hoc group of Swedish ISPs and Universities. Without any hope on mentioning everyone we simply give the domain names here: algonet.se, global-ip.net, pi.se, swip.net, telia.net, udac.se; chalmers.se, sunet.se, umu.se, and uu.se.
这份备忘录是瑞典ISP和大学特设小组讨论的结果。没有任何希望提及每个人，我们只是在这里给出域名：algonet.se、global-ip.net、pi.se、swip.net、telia.net、udac.se；chalmers.se、sunet.se、umu.se和uu.se。
We want to acknowledge valuable input and suggestions from Andras Salamon, John Myers, Bob Flandrena, Dave Presotto, Dave Kristol, Donald Eastlake, Ned Freed, Keith Moore and Paul Hoffman.
我们要感谢安德拉斯·萨拉蒙、约翰·迈尔斯、鲍勃·弗兰德雷纳、戴夫·普雷索托、戴夫·克里斯托、唐纳德·伊斯特莱克、内德·弗里德、基思·摩尔和保罗·霍夫曼的宝贵意见和建议。
Finally many thanks to Harald Alvestrand and Patrik Faltstrom, both for useful comments and for their support and guidance through the IETF process.
最后，非常感谢Harald Alvestrand和Patrik Faltstrom，感谢他们在IETF过程中提供的有用意见和支持与指导。
[1] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821, August 1982.
[1] Postel，J.，“简单邮件传输协议”，STD 10，RFC 821，1982年8月。
[2] Crocker, D., "Standard for the format of ARPA Internet text messages", STD 11, RFC 822, August 1982.
[2] Crocker，D.，“ARPA互联网文本信息格式标准”，STD 11，RFC 822，1982年8月。
[3] Braden, R., "Requirements for Internet hosts - application and support", STD 3, RFC 1123, October 1989.
[3] Braden，R.，“互联网主机的要求-应用和支持”，STD 3，RFC 1123，1989年10月。
[4] Bradner, S., "Key words for use in RFCs to Indicate Requirement Level", BCP 14, RFC 2119, March 1997.
[4] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[5] Mockapetris, P., "Domain Names - Concepts and Facilities", STD 13, RFC 1034, November 1987.
[5] Mockapetris，P.，“域名-概念和设施”，STD 13，RFC 1034，1987年11月。
[6] Mockapetris, P., "Domain Names - Implementation and Specifications", STD 13, RFC 1035, November 1987.
[6] Mockapetris，P.，“域名-实施和规范”，STD 13，RFC 10351987年11月。
[7] Eastlake, D. and C. Kaufman, "Domain Name System Security Extensions", RFC 2065, January 1997.
[7] Eastlake，D.和C.Kaufman，“域名系统安全扩展”，RFC 20651997年1月。
[8] sendmail Home Page. http://www.sendmail.org
[8] sendmail Home Page. http://www.sendmail.org
[9] Gellens, R. and J. Klensin "Message Submission", RFC 2476, September 1998.
[9] Gellens，R.和J.Klensin“信息提交”，RFC 24761998年9月。
[10] Myers, J., "SMTP Service Extension for Authentication", Work in Progress.
[10] Myers，J.，“用于身份验证的SMTP服务扩展”，正在进行中。
* Spam (R) (capitalized) is a registered trademark of a meat product made by Hormel. Use of the term spam (uncapitalized) in the Internet community comes from a Monty Python sketch and is almost Internet folklore. The term spam is usually pejorative, however this is not in any way intended to describe the Hormel product.
* Spam（R）（大写）是荷美尔公司生产的肉制品的注册商标。在互联网社区中使用术语垃圾邮件（未资本化）源于一幅巨蟒素描，几乎是互联网上的民间传说。“垃圾邮件”一词通常带有贬义，但这并不是用来描述霍梅尔产品的。
Editor's Address
编辑地址
Gunnar Lindberg Computer Communications Group Chalmers University of Technology SE-412 96 Gothenburg, SWEDEN,
Gunnar林德伯格计算机通信集团查尔默斯技术大学SE-412 96哥德堡，瑞典，
Phone: +46 31 772 5913
FAX: +46 31 772 5922
EMail: lindberg@cdg.chalmers.se
Phone: +46 31 772 5913
FAX: +46 31 772 5922
EMail: lindberg@cdg.chalmers.se
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (1999). All Rights Reserved.
版权所有（C）互联网协会（1999年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。