网络工作组G.林德伯格 征求意见：科技2505查尔姆斯理工大学 BCP：1999年2月30日 类别：当前最佳实践 用于SMTP MTA的反垃圾邮件的建议 本备忘录的状态 这个文件规定了互联网社区的互联网当前的最佳实践，并要求讨论和建议以得到改进。本备忘录的发布是无限的。 版权声明 版权所有（C）互联网协会（1999年）。版权所有。 抽象 本备忘录给出了许多用于SMTP实现的建议，[1]，的MTA（邮件传输代理，如sendmail的，[8]），使他们更能够减少垃圾邮件（*）的影响。 意图是，这些建议将有助于清理垃圾，如果应用在因特网上足够多的SMTP MTA，并且它们应该被用作各个MTA厂商的指导方针。我们充分意识到，这不是最终的解决方案，但如果这些建议都包括并使用在所有的互联网SMTP MTA的，事情将大大提高，并给时间去设计一个更长期的解决方案。"今后的工作"一节提出一些想法，可能作为长期解决方案的一部分。不过，很可能最终的解决办法是社会，政治或法律，而不是技术。 实现者应该意识到，有几个提出的方法可能会导致拒绝服务的风险增加。例如，增加的DNS查询次数和日志文件大小都可能导致系统过载和系统在攻击中崩溃。 本备忘录的一个简短的总结是： O停止未经授权的邮件。 Ø然后垃圾邮件发送者不得不暴露出来; 对付他们。 O设计一个邮件系统，能够处理垃圾邮件。 林德伯格最佳当前做法[第1页] RFC 2505反垃圾邮件的建议1999年2月 1.简介 这个备忘录是当前最佳实践（BCP）RFC。因此，它应该被用来作为SMTP MTA实现者的指导方针，以使自己的产品更能够防止/处理的垃圾邮件。尽管这是其主要目标，预期的副作用是建议授予sysadmin /postmaster 社区SMTP MTA预计将有“反垃圾邮件旋钮”。 然而，本备忘录并不打算作为如何操作的SMTP MTA的描述 - “旋钮”如何开启以及如何配置。如果有写建议的话，会清楚地标明。 1.1。背景 大量不请自来的电子邮件，经常称为垃圾邮件（*），已经在很短时间内显著增加，并已成为整体的互联网电子邮件社区的严重威胁。需要尽快采取行动。 这个问题有几个组成部分： Ø数量巨大，即人们收到了很多此类邮件。 Ø它完全是“盲目的”，也就是说，接受者的兴趣范围与发出的实际的邮件之间没有相关性（至少假设在互联网上不是每个人都感兴趣色情图片和邮件程序...） 。 Ø它花费接收者的金钱成本。由于许多接收者为邮件从（拨号）ISP转移到自己的电脑，实际支付了金钱。 Ø它花费互联网服务供应商的金钱成本。假设发送1个10K字节的信息到一个有10 000用户的ISP主机; 这意味着一个不请自来的，意外的100兆字节存储。一个4GB的现代磁盘只需要收到40个这样的消息就会被填满了。几乎不可能提前对这样的“风暴”做计划。 Ø许多垃圾邮件发送者诚实，例如 提供虚假的回信地址，特意写邮件看起来像两个人之间的往来、使垃圾邮件的收件人会以为它只是误投给他们，说消息是“您要的材料”而你从来没有要求过，做一切不考虑诚信或道德的事情，试图让更多的人看他们的消息。 事实上，一些垃圾邮件中采取添加虚假信息，使互联网服务商挠头，并引以为豪。 人们回信抗议以后（通常根据邮件中的说明）发现自己的邮箱地址添加到多个列表，并出售给其他方。 Ø很常见的做法是利用第三方主机作为中转来发送垃圾邮件。这种对服务的偷窃是大多数 - 如果不是全部 - 国家是非法的（至少在美国，已经成功起诉过垃圾邮件发送者）。然而，当原始发件人在美国，无辜的中转服务器在瑞典，再转回到美国的收信人，这种情况下，向垃圾邮件发送者获得赔偿的法律程序变得非常困难。 1.2。范围 这个备忘录无意作为解决垃圾邮件问题的最终方案。 但是，如果足够多的互联网的MTA实现下述规则（尤其是 不转发 规则），我们能把垃圾邮件发送者赶到太阳底下，然后就可以处理他们。无论是纯粹的法律诉讼会有所帮助，或者我们可以在技术上使用下述规则阻止他们（因为 不转发 规则让他们公开暴露了自己的主机和域名，我们可以对他们应用各种访问过滤器）。在现实中，法律和技术相结合的方法，很可能会给最好的结果。 这样一来，垃圾问题可以减少，足以让互联网社区设计和部署一个实际和通用的解决方案。 但是，请注意： Non-Relay规则本身并不足以阻止垃圾邮件。即使99%的SMTP在第一天实现这点,垃圾邮件发送者仍然会找到剩下的1%并使用它们。或垃圾邮件发送者更新换代，直接连接到每个接收者的主机;这将为垃圾信息散布者带来更高的成本,但仍很有可能。 尽管IPv6部署可能临近,垃圾邮件问题已经存在，因此这个备忘录限制在当前的IPv4。 林德伯格最佳当前做法[第3页] RFC 2505反垃圾邮件的建议1999年2月 1.3。术语 贯穿本备忘录，我们将使用RFC2119的术语，[4]： O“MUST” “需要”这个词或形容词意味着，该项目是一个绝对的要求。 O“应该” “建议”这个词或形容词意味着有可能存在在特定情况下正当的理由对这一条款不予理会，但全部含义应理解，并在选择不同的做法之前，请仔细权衡。 O“MAY” 这个词或形容词“可选”意味着这一条款是真正可选的。一个供货商可以选择含有该条款，因为实际市场需要它或因为它能提高产品，例如; 另一个供应商可以忽略同样的条款。 1.4。使用DNS信息 在备忘录中，我们有时使用术语“主机名”或“域名”,应被视为一个完全限定的域名,即FQDN。这是指DNS PTR查询(.IN-ADDR.ARPA)返回的名字,即一个IP地址被翻译的名字,或者是这个IP地址对应的DNS A记录或MX记录，参见RFC1034,[5],和RFC1035,[6]。 我们建议使用FQDN而不是IP地址，是因为FQDN更直观更容易使用。然而，这些使用在很大程度上依赖于DNS和.in-ADDR.ARPA（PTR）的信息。因为它是很容易伪造的，通过虚假的DNS服务器的缓存信息注入或垃圾邮件发送者用虚假信息,运行自己的DNS主机和域名必须小心使用,例如验证,这样翻译地址- >名称对应名称- >地址。用安全的DNS,RFC2065[7],情况会好转,因为.IN-ADDR的欺骗。ARPA将不再可能。 有一项建议是有关验证“MAIL FROM：”（信封发起者）与DNS域（确保对应该域的DNS信息存在）。当利用这个功能时，需要考虑几件事情： 林德伯格最佳当前做法[第4页] RFC 2505反垃圾邮件的建议1999年2月 (1)不要忘记DNS查询的增加可能导致DNS服务器本身应对负载的问题。这样一来，发封邮件就可能造成对DNS服务器的拒绝服务攻击。 (2)需要注意的是,利用DNS缓存否定,伪造DNS响应可用于发起拒绝服务攻击。例如,如果已知一个网站实现了针对SMTP "MAIL From:"命令进行FQDN有效性检查的话,攻击者有可能利用DNS否定响应有效地阻止来自一个或多个起源的邮件的接收。正因为如此,都应该仔细检查使用的DNS服务器,例如，是如何对响应和请求进行校验的,以便将这种攻击的风险降到最低。 (3)对早期版本的垃圾软件,FQDN检查提供了一些缓解,因为软件生成完全虚假的“MAIL From:”，如果经过验证DNS，就永远不会进入系统。现在使用很广，而且确实减少了垃圾邮件。 另一方面,DNS连接性较差的网站可能会发现他们的合法邮件到达目的地有问题,原因是接收者在验证他们的“MAIL From:”时超时。然而,由于缓存DNS信息是异步处理的,即使最初的请求放弃了,很可能这些必要的信息在稍后尝试时就能获得了。 更高版本的邮件软件中的“MAIL FROM：”检查是不太可能有帮助了，因为垃圾邮件软件的发展也开始使用现有的邮件地址（合法性与否超出了本备忘录的范围）。但是仍有一些用处，例如检查拼写错误，或者UA配置错误。 1.5。在哪阻挡垃圾邮件，SMTP中，在RFC822或UA 我们的基本假设是,拒绝/接受在SMTP层处理,当MTA决定拒绝一封消息时就立刻执行，即使仍在SMTP会话中。首先,这意味着不需要存储一份消息之后再决定拒绝,第二,我们对这封消息的责任很低或没有,因为我们还没有读过,我们把它留给发送者来处理错误。 林德伯格当前最好的实践(第5页) 2505年2月RFC 2505反垃圾邮件的建议 1.6。SMTP返回码 SMTP有几个类型的返回代码,请参见[1]的讨论: o 5 xx 永久负面完成回复(致命错误),导致邮件传输被终止，邮件返回给发送者。 o 4 xx 临时负面完成回复(临时错误)，并导致邮件传输被重新放回到队列中，稍后再重试。 o 2 xx 是一个积极的完成回复,表明MTA现在负责发送邮件。 当利用选项/本备忘录中描述“旋钮”时，有几件事情要考虑: 对于一些事件,比如“拒绝——你在垃圾信息散布者名单上”,5 xx可能是正确的返回代码,因为它会立即终止会话,我们也到此结束(假设SMTP垃圾信息散布者按规则办事,而他很可能不会——事实上他可以把邮件重新放进队列或转向其他主机,而不管返回代码)。然而,一个5 xx的错误配置可能会导致合法邮件反弹,这可能是很不幸的。 因此,我们建议4 xx作为大多数情况下的返回代码。因为这是一个非致命错误,邮件会重新在发送方排队，并且我们至少有一些时间来发现和纠正配置错误,而不是反弹邮件(通常这是当我们对某些域拒绝中转而事实上我们应该接受,因为我们处在他们的MX列表)。 4 xx响应也使垃圾信息散布者的主机将邮件重新排队,如果真的是他的主机来做这个，那可能是件好事——用自己的垃圾填满他的磁盘。另一方面,如果他是使用别人作为中继主机,所有的垃圾邮件被排队是一个相当强有力的证据表明,坏事是怎么回事,应该引起关注。 然而,4 xx临时错误可能与mx记录有意想不到的交互。如果接收域有多个MX记录，最高优先级的MX-host用“451”响应代码来拒收邮件,发送主机可以选择、并且通常会使用MX列表上的下一个主机。 林德伯格当前最好的实践(第6页) 2505年2月RFC 2505反垃圾邮件的建议 如果下一个MX主机没有相同的refuse-list,它当然会接受邮件,却发现最后一个主机仍然拒绝接收的邮件("MAIL From:”)。我们的意图是使违规邮件留在违法的发送方主机和填满他的mqueue磁盘,但最终在我们的朋友,下一个最高优先级的MX-host。 最后,有人建议可以使用一个2 xx返回代码但是决定不转发或接收垃圾邮件;典型的替代方案是存储在其他地方(如/ dev / null)。这显然违反RFC821的目的,没有仔细考虑就不应这样做,不应盲目地把邮件丢弃,可以重新排队，手动或自动检查是合法邮件还是垃圾邮件，是应该删除还是转发。 1.7。邮件列表 MTA,也有能力处理邮件列表和扩展到收件人,需要能够对发送者鉴权，并且保护邮件列表免遭垃圾邮件骚扰。其中机制可能非常不同于普通邮件和普通用户,也不包括在本备忘录。 2。建议 在这里,我们先给一个简短的推荐列表,紧随其后的是一个更彻底的讨论。我们还将建议哪些事不要做,这些事情似乎在与垃圾邮件斗争中看似正常(甚至可能一直有效),但这可能对互联网邮件造成严重破坏,因此可能会造成更大的伤害。 1)必须能够限制未经授权地邮件中转。 2)必须能够提供“Received:“行，带着足够的信息来跟踪邮件路径,尽管垃圾邮件发送者使用伪造的主机名在HELO等语句。 3)必须能够提供本地日志信息以便跟踪事件。 4)应该能够记录所有出现过的anti-relay /反垃圾邮件的行为。 5)应该能够拒绝来自一个主机或一组主机的邮件。 6 a)不能拒绝“MAIL From: < >”。 6 b)不能拒绝“MAIL From:< user@my.local.dom.ain >”。 林德伯格当前最好的实践(第7页) 2505年2月RFC 2505反垃圾邮件的建议 7 a)应该能够拒绝来自一个特定的“MAIL From:”user,< foo@domain.example >的邮件。 7 b)应该能够拒绝来自整个“MAIL From:”domain<.* @domain.example > 的邮件。 8)应该能够限制(“速率控制”)邮件流。 9)应该能够验证"MAIL From:“域(使用DNS或其他方法)。 10)应该能够验证外发邮件的。 11)应该能够控制SMTP VRFY和EXPN。 12)应该能够控制SMTP ETRN。 13)必须能够配置为对不同的规则提供不同的返回代码(例如451临时失败vs 550致命错误)。 下面的讨论往往最终需要对域/主机名和IP地址/子网进行各种形式的模式匹配。建议把相应的数据/模板放在MTA外部,例如,模式匹配规则被包括在MTA,但实际的模式可能在一个外部文件。也建议模式匹配规则(外部文件)可以包含正则表达式,以便有最大的灵活性。 当然字符串匹配域/主机名不能区分大小写。可能区分大小写，所以对这里可以保持这样处理。然而,由于< sPAmMeR@domain.example>和< spammer@domain.example>很有可能是相同的用户，而且拒绝信息是用字符串比较,因此我们建议做不区分大小写的比较。 对于所有这些建议的解释应当是灵活的——无论今天我们如何设计反垃圾邮件规则,垃圾邮件发送者总会设法绕过去，并且一个设计良好的MTA应该足够灵活,能够应当这些新的威胁。 2.1。限制未经授权的邮件中继使用 未经授权使用中继主机意味着盗窃中继资源并给中继所有者的声誉带来风险。也导致过滤或屏蔽垃圾邮件的同事也影响合法的邮件。 因此,MTA必须能够控制/拒绝这样的对中继的使用。 林德伯格当前最好实践[8]页 2505年2月RFC 2505反垃圾邮件的建议 在一个SMTP会话中有4个元素,每一个都有不同程度的信任: 1)“HELO 主机名” 容易伪造，常被伪造。 2)“MAIL From:” 容易伪造,常被伪造。 3)“RCPT To:”正确,或者至少是预期的。 4)SMTP_Caller(主机) IP。src addr好,FQDN可能是好的。 因为1)和2)是那么容易伪造且常被伪造,我们不能依靠他们授权使用我们的主机作为邮件中继。 相反,MTA必须能够授权邮件中继使用基于的组合: o“RCPT To:”地址(域)。 o SMTP_Caller FQDN主机名。 o SMTP_Caller IP地址。 建议算法是: a)如果“RCPT To:”是“我们的”域之一,本地或一个域,我们允许转发的(备用MX), 那么同意转发。 b)如果SMTP_Caller 鉴权通过,要么它的IP。src或FQDN(取决于你是否信任DNS),然后同意转发。 c)其他则拒绝转发。 进行a)时，你必须确保所有的SMTP源路由(包括官方的[@a,@b:u@c),‘%’技巧和uucp-style”!路径)要么在测试前完全删除，或者至少要考虑进来。 网站实现这个需求还必须意识到,他们可能会阻止地址正确的消息,尤其是那种起源或终止在一个通往非SMTP邮件系统的网关上。在实施这样的政策之前,仔细库存应该确保所有路由算法,通过其他邮件系统或自由互联,是已知的。每一个这样的系统必须在针对个案来考虑。 例如这样一个邮件系统,他们的寻址方案是X.400，地址的类型是: “/ c = us / admd = / prmd = xyz / dd.rfc - 822 =user(a)final/”@x400-gateway 另一个例子包括DECnet MAIL-11,地址格式是: 林德伯格当前最好的实践(9页) 2505年2月RFC 2505反垃圾邮件的建议 “gateway::smtp % \”user@final \”“@mail-11-gateway 在所有情况下的配置必须对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。 配置应该允许决策/模板数据是由外部源来应用,如文本文件或dbm数据库。决定/模板应该允许包含正则表达式。 2.2。Received:行 MTA必须在邮件前部添加"Received:"行(如RFC822[2]所述,并RFC1123,[3]中要求)。这个“Received:“行必须包含足够的信息可以跟踪邮件路径回到发送方。我们有两种情况: 2.2.1。直接MTA-to-MTA连接 互联网邮件设计为：发送主机直接连接到MX记录所描述的接收方(可能有几个MX主机优先级列表)。为保证可追溯到发送主机(可能是防火墙/网关,如后所述)路径上的每个MTA包括最后的MTA,都必须追加“Received:“行。对于这样的“Received:“行: 它必须包含: 调用者的IP地址。 o根据RFC822,以描述的“日期时间”[2],页18。 它应该包含: o调用者IP地址对应的FQDN。 oHELO语句中给出的参数。 o认证信息,如果传输/提交中使用了经过身份验证的连接。 建议将RFC822中描述的其他“Received:”字段列入“Received:“行。 基本上,任何可以帮助跟踪消息来源的信息都可以而且应该被添加到“Received:“行。即使当初始提交是非SMTP也是如此,例如提交是通过一个基于网页的邮件客户端,web客户端和服务器之间使用http ,“Received:“行可以记录创建邮件时、连接服务器的客户端的IP地址。 这些建议故意强于RFC1123,[3],并且确保从垃圾信息散布者的主机直接发送给收件人的邮件可以有足够的追溯精度,一个典型的例子是当垃圾信息散布者使用拨号账户时，ISP需要他的IP地址的日期-时间能够对他采取行动。 2.2.2。防火墙/网关型设备 组织隐藏内部网络结构的政策必须被允许能够这样做。他们通常让他们内部的MTA给"Received:"行添加很少的信息，甚至完全不加。然后他们通过某种防火墙/网关设备发送邮件,这些设备甚至可以删除所有内部MTA的"Received:“行，然后加上自己的“Received:“行(在RFC1123中要求,[3])。 通过这样做,他们承担的全部责任跟踪垃圾邮件发送者发送在他们的组织，或者他们接受这些垃圾邮件发送者的活动负责。要求他们的发信中提供的信息带有足够执行任何必要追踪所需的信息。 对于进入组织的信,“收到:“行必须保持完整,以确保在里面收到邮件的用户可以提供跟踪消息来源所需的信息。 一般来说,一个网关不应该更改或删除“收到:“行,除非它是一个安全的需求。改变现有的内容”了:“行,以确保他们“有意义”通过邮件网关所需的一些最常见的破坏和删除信息消息可追踪的。必须注意保护信息”了:“行,要么是在消息本身,接收方的邮件,或者如果可能的话,日志。 2.3。事件日志 MTA必须能够提供足够的本地日志信息可以跟踪事件。这包括大多数的信息放入”了:“行,见上图。 林德伯格当前最好的实践(11页) 2505年2月RFC 2505反垃圾邮件的建议 2.4。日志anti-relay /反垃圾邮件的行为 MTA应该能够记录所有anti-relay /反垃圾邮件的行为。日志条目至少应包含: o时间信息。 o拒绝信息,即为什么请求被拒绝(“邮件”,“传送否认”,“垃圾邮件用户”,“垃圾邮件主机”,等等)。 o“收件人:”地址(域)。(如果连接在较早的阶段是不允许,例如通过检查SMTP_Caller IP地址、“收件人:”地址是未知的,因此不能登录)。 o恶意主机的IP地址。 o恶意主机的FQDN主机名。 o其他相关信息(如SMTP对话期间,在我们决定拒绝请求之前)。 应该注意的是,通过记录更多的事件,尤其是被拒绝的电子邮件,提高了拒绝服务攻击的可能性,比如非常多的“收件人:”命令容易填满日志。根据这个描述来实现的增加日志必须知道日志的大小增加,尤其是在攻击时。 2.5。基于SMTP_Caller拒绝邮件地址 MTA应该能够接受或拒绝来自一个或一组特定主机的邮件。这里我们指的是IP.src地址或通过.IN-ADDR.ARPA解析出的FQDN(取决于你是否相信DNS)。这个功能可以在防火墙实现,但是因为MTA应该能够“自卫”我们建议MTA进行自卫。 建议MTA能够根据以下来做出决定：基于FQDN主机名(host.domain.example),基于域名通配符(* .domain.example),基于独立IP地址(10.11.12.13)或基于IP地址前缀长度(10.0.0.0/8 192.168.1.0/24)。 还建议这些决策规则可以组合在一起形成一个灵活的接受/拒绝/接受/拒绝列表,如: 林德伯格当前最好的实践(第12页) 2505年2月RFC 2505反垃圾邮件的建议 接受host.domain.example 拒绝* .domain.example 接受10.11.12.13 接受192.168.1.0/24 拒绝10.0.0.0/8 在列表中搜索,直到第一个匹配，然后接受/拒绝行动是基于这个匹配项。 建议采用ip地址/长度。然而,实现通配符,例如10.11.12。*(分级网络字节边界)当然也比没有好。 为了进一步改进过滤效果,MTA可以提供完整的正则表达式用于主机名;也可能为IP地址。 2.6。“MAIL From:< >”和“MAIL From:< user@my.local.dom.ain >” 虽然打击垃圾邮件发送者是很重要的,但是也不能违反现有的电子邮件标准。因为垃圾信息散布者通常伪造“MAIL From:“地址，很容易想要对此进行通用的限制,特别是对一些“显而易见”地址。然而,这可能对邮件社区造成比垃圾邮件更多的破坏。 当需要拒绝来自一个特定的主机或网站的邮件时，我们的建议是使用这份备忘录中提到的其他方法,如基于SMTP_Caller地址(或名称),而不是“MAIL From:”来进行拒绝。 2.6.1。“MAIL From:< > " MTA不得拒绝接收MAIL From:< >。 “MAIL From:< > "是用来表明邮件系统本身的错误消息,例如当使用了一个合法的邮件中继,并将一个错误消息发回给用户。拒绝接收此类邮件意味着用户可能无法收到关于外发邮件的错误通知,例如“用户未知”,这无疑会对邮件社区造成比垃圾邮件更多的破坏。 最常见的情况下这种合法”MAIL From:< > "是给单个接受者,即一个错误消息返回单独一个人。因为垃圾邮件发送者常用“MAIL From:< > "来发送给许多人,人们很容易完全拒绝这样的邮件,或第一个收件人之后所有人来拒绝。然而,有合法的原因使错误通知邮件发到多个接收者,如都位于相同的远程站点的邮件列表所有者,因此MTA即使在这种情况下也不能拒绝“MAIL From:< > "。 林德伯格当前最好的实践(13页) 2505年2月RFC 2505反垃圾邮件的建议 然而,如果有一个以上的“RCPT:”时，MTA可以节流TCP连接(“read()“频率),这样会减缓垃圾邮件发送者使用“MAIL From:< >”的速度。 2.6.2。“MAIL From:< user@my.local.dom.ain >” MTA不能拒绝“MAIL From:< user@my.local.dom.ain >”。 “my.local.dom.ain“是指域名,被视为本地和导致当地的邮件传送。乍一想似乎没人需要使用“MAIL From:< user@my.local.dom.ain>”，并且对此进行限制会减少欺诈的风险,从而降低垃圾邮件。虽然这在(非常)短期可能是真的,它也至少有两个合法的用法: oAlias(.forward 文件)。 < user1@my.local.dom.ain>发送< user2@external.example>,邮件被转发回< user2@my.local.dom.ain>,例如< user2 >已经搬到my.local.dom.ain并且在external.example有一个.forward文件。 邮件列表。 [3],RFC1123给一个明确的要求:从邮件列表来的邮件应该反映的列表的所有者,而不是单独的发送者。因为这个事实,并且因为列表所有者可能与列表(列表主机)本身不是相同的域,邮件的Mail From:可能带着列表所有者的本地域从外域(从一个服务于外域的主机)到达列表所有者的域(邮件主机)。 如果“MAIL From:< user@my.local.dom.ain>”被拒绝,在上述两种情况下会导致无法传递合法的邮件。 2.7。基于“MAIL From:”来拒绝 MTA应该能够拒收来自特定的MAIL From:“用户(foo@domain.example)或从整个“MAIL From:”domain(domain.example)的邮件。一般情况下这些规则很容易被垃圾邮件发送者越过，如果MAIL From:“经常变化的话,但是能够阻止特定用户或特定领域非常有用如果攻击刚被发现并且正在进行。 请注意, “MAIL From:< > " 和 “MAIL From:< user@my.local.dom.ain >” 林德伯格当前最好的实践(14页) 2505年2月RFC 2505反垃圾邮件的建议 不得拒绝(见上图),除非其他策略阻止了连接,例如当对方的SMTP_Caller IP地址属于特意拒绝的范围。 2.8。速率控制 MTA应提供工具给邮件主机来控制发送或接收邮件的速度。我们的想法是双重的: 1)如果我们有一个合法的邮件用户，拥有已知合法的账户,而该用户发送垃圾邮件,我们可能会降低他的发信速度。这里存在争议,并且使用上必须非常谨慎,但这样可以让互联网其他地方得到保护。 2)如果我们正遭受垃圾邮件攻击，减缓对来自特定的用户/主机的邮件接收率可能有很大帮助。 对于发送邮件,需要通过节流TCP连接设定可接受的输出数据率,如减少“write()“频率。 对于接收邮件,我们可以使用基本相同的技术,如减少“read()“的频率,或者我们可以4 xx返回代码表示我们无法收信。建议采取这样的行动决定是基于“MAIL From:”用户,“MAIL From:”域,SMTP_Caller(名称/地址),“收件人:”,或者所有这些的组合。 2.9。验证”MAIL From:“ MTA应该能够对“MAIL From:”域执行一个简单的检查,如果域不存在的(即无法解析MX或A记录)就拒绝接收邮件。如果DNS错误是暂时的,TempFail,MTA必须返回一个4 xx返回代码(临时错误)。如果DNS错误是一个权威NXdomain(主机/域未知)MTA仍然应该返回一个4 xx返回代码(因为可能只是主DNS和备份DNS不同步)但可以允许5 xx返回代码(如果系统管理员配置的话)。 2.10。验证<本地部分> MTA应该允许外发邮件对其<本地部分>进行验证,以便保证发送者的名字是一个真正的用户或现有的别名。这基本上是防止“笔误”。 邮件:< fo0bar@domain.example > 和/或恶意用户 邮件:< I.am.unknown.to.you.he.he@domain.example > 如果垃圾邮件发送者想攻克这点的话，也是能做到的,但更严格的规则会使之变得越来越困难。事实上,抓住“输入错误”对于初始的(官方的)邮件中继节点本身就是足够的动机。 2.11。SMTP VRFY和EXPN SMTP VRFY和EXPN为潜在的垃圾信息散布者来测试名单上的地址是否有效(VRFY),甚至获取更多的地址(EXPN)。因此,MTA应该控制谁可以发出这些命令。这可能是“开/关”或使用类似于前面提到的访问列表。 需要注意,“VRFY”命令根据RFC821,[1]是必须的。不过,响应可以是“252 参数未检查”来表示“关闭”或被访问列表屏蔽。这应该是默认的。 “EXPN”命令默认应该“关闭”。 2.12。SMTP ETRN SMTP ETRN意味着MTA将重新运行邮件队列,这可能是相当昂贵的,并且容易遭到拒绝服务攻击。因此,MTA应该控制谁能运行ETRN命令。这可能是“开/关”或使用类似于前面提到的访问列表。默认应该是“关闭”。 2.13。返回代码 这里的主要问题是灵活性—— 如果既要做到：a)由于配置错误，返回5 xx并且使合法的邮件立刻失败，又要做到：b)返回4 xx并且能够通过检查日志文件抓住这样配置错误，则几乎是无法在文档中定义的。 因此,MTA必须能够配置成对于不同的规则或策略提供“成功”(2 xx),“暂时失败”(4 xx)或“永久失败”(5 xx)。然而,确切的返回码,除了第一个数字(2、4、5),不应当是可配置的。这是因为很容易配错，并且错误代码使用的选择是非常微妙的,而且许多软件实现确实会检查返回代码第一个数字(2、4或5)之后的值。 然而,当响应是一个DNS查询的结果，并且DNS系统返回TempFail,一个临时错误,MTA必须反映这点并提供一个4 xx返回代码。如果DNS的响应是一个权威NXdomain(主机或域名未知)MTA可以用5 xx返回代码反映这点。 更多信息请参阅前面关于SMTP返回代码的讨论。 2.13.1。灵活性的重要性——一个例子 在查尔姆斯理工大学,我们的DNS包含 cdg.chalmers.se. IN MX 0 mail.cdg.chalmers.se. IN MX 100 mail.chalmers.se. 而且对于大多数子域也基本相似,即对于每个子域，如果邮件主机当掉的话，有第二个主机来存储邮件。这意味着mail.chalmers。se必须运作为它所服务的(“RCPT:”)的子域的邮件中继,这些子域的邮件主机必须能够来自mail.chalmers.se 的SMTP连接。后期版本的垃圾软件利用了这一点，总是用mail.chalmers。se来发送他们的邮件到我们的子域,这样他们还是完成邮件传送,并且防止了接收方主机基于发送主机的FQDN或ip地址来拒绝SMTP连接。 如果我们坚持保留二级MX主机的设计，就无法让mail.chalmers。se拒绝邮件中继,至少没法返回5 xx返回代码。然而,能够很直接地识别利用这种可能性的主机/域/网络,并对他们（只对他们）拒绝作为邮件传递,通过4 xx返回代码。来自他们的合法邮件可能会被推迟,如果最终接收方主机当掉的话，但当主机起来的时候最终会投递到的(4 xx返回代码),这与改变我们的MX设计的效果差不多。垃圾邮件现在面临着“拒绝”的反应,必须连接到每一个人,这些人就可以决定拒绝SMTP连接。 这样实现的底线是因为,1)中继授权代码有足够的灵活性,2)分配返回代码有足够的灵活性——如果写死了5 xx返回代码，那就做不到这些了。 林德伯格当前最好的实践(第17页) 2505年2月RFC 2505反垃圾邮件的建议 3所示。未来的工作 3.1。影响SMTP UA和最终用户 尽管这个备忘录是关于MTA和对之的建议,这里做的一些也影响UA(用户代理,“普通邮件程序”)。 UA做两件事: 1)从邮箱读取邮件并打印在屏幕上。这通常使用一个协议例如POP、IMAP或NFS。 2)从键盘读取文本并发送到邮箱MTA,交付邮件。这通常使用SMTP协议,即与MTA之间所用的相同的协议。 当MTA现在开始实施各种anti-relay过滤器如上所述,UA或便携式笔记本电脑主机上可能得到回应就像“中继被拒绝“只是因为未知的IP地址范围或者未能解析fqdn。 这种“中继被拒绝”响应的典型受害者是一个推销员随身带着笔记本电脑出差,甚至是一个在会议酒店的IETF代理人。售货员可能会拨他的最近的ISP，获取到一个IP地址从拨号池,IETF委托将使用IP地址从终端房间。在这两种情况下笔记本电脑邮件程序(UA;如pine,网景,Eudora)将试图发送邮件通过归属MTA,如smtp服务器= mail.home.example,但除非mail.home.example已经更新来接受这个(临时)IP地址，它会回复 中继被拒绝，并拒绝发信。 为了解决这个问题我们可以简单地添加终端室或加拨号池的IP网络到mail.home.example接受网络的列表。这确实对使用这台主机作为邮件中继的垃圾邮件制造者开放了一些最小的风险：如果他们使用相同的ISP的拨号池,配置使用mail.home.example当我们的销售员在他的旅行中,垃圾邮件发送者将被授权通过mail.home.example传递他们的垃圾邮件。然而,这不太可能,只要我们不同时对整个世界开放，并且保持近距离观察的日志文件,当发现我们被利用立刻停止传送,这个解决方案可能已经足够好了。 另一种方法是,我们的销售员使用当前拨号ISP提供的邮件中继,如果该服务存在。为此他不得在UA中修改smtp服务器,这可能是也可能不是合理的。 林德伯格当前最好的实践(18页) 2505年2月RFC 2505反垃圾邮件的建议 处理这种情况的正确方法,是由其他UA和MTA之间的发信协议完成。 尽管一个单独的提交协议不存在,一个概要文件的SMTP,“消息提交”规范,[9],最近被定义。 或者,我们可以注意到,当SMTP认证工作,[10],已经处处就位时,可以将身份验证SMTP作为UA和归属MTA之间的协议(这里不考虑是一个新的协议或“老SMTP”)。 这将在2.1节建议的中继算法中添加一个条目: +如果“SMTP已认证”，那么允许中继。 3.2。个人反垃圾邮件过滤器 因为所有的用户都是个体,不太可能有适合所有人的集中式反垃圾邮件操作——事实上人们会争论侵犯言论自由如果一些中央组反垃圾邮件规则是未经用户批准执行。(当然还可以争辩垃圾邮件是否真的带来骚扰,但这必须由每个用户来决定,而不是中央决定)。 因此唯一合理的扩展是允许个人反垃圾邮件过滤器,即在本备忘录前面描述的反垃圾邮件过滤器,但针对每个用户的基础可用和可配置。因为大多数用户不会有强烈的意见(除了他们希望避免垃圾邮件)邮件系统应该提供一个系统默认值,给每个用户的能力来重写或修改。在基于UNIX的环境中可以有 /etc/mail/rc.spam ~ / .spamrc 并定义后者如何作用于前者的规则。 这开辟了相当多的未解决的问题,例如应该是否真的允许每个用户自己决定如何处理SMTP返回代码(以及如何向他解释里面的细节)，以及现有的邮件系统如何处理每个用户的不同反应,特别是如何处理4 5 xx和4xx代码的混合: 邮件从C:< usr@spam.example > 250 < usr@spam.example >…发送好了 林德伯格当前最好的实践(19页) 2505年2月RFC 2505反垃圾邮件的建议 C收件人:< usr@domain.example > 250 < usr@domain.example >…收件人好 C收件人:< foo@domain.example > 451 < foo@domain.example >…否认由于垃圾邮件列表 C收件人:< bar@domain.example > 550 < bar@domain.example >…否认由于垃圾邮件列表 当然我们可以知道“250 OK”或“550”对于个人用户来说没有其他选择,但也要向一个普通用户解释"拒绝 MAIL From:<.*@spam.example>'的含义，然后用户可以处理或屏蔽他想要的邮件。 3.3。SMTP认证 SMTP认证,[10],已经提到了，作为授权邮件中继的方法,当然还有更多。当基础设施和功能都已就位时,垃圾邮件发送者会更难伪造地址和隐藏。 3.4。垃圾邮件和NATs 随着网络地址翻译(NATs)使用的增加,在日志文件中可能会需要额外的信息。只要有一个1:1 NAT中的地址和地址之间的映射之外使用它一切都是好的,但如果NAT机也翻译端口号(结合许多内部主机到一个外部地址)我们需要日志不仅垃圾邮件主机的IP地址,还要包括端口号。否则我们将无法识别单个主机在NAT。 4。安全注意事项 铺天盖地的垃圾邮件引出了几个安全问题,事实上,让整个互联网邮件社区处于风险: o可能在满满的邮箱里找不到重要的邮件。或者在清理时误删除。 o isp获得超载邮箱主机和磁盘。清理和帮助客户需要大量的人力资源。事实上,ISP邮件服务器有过被太多邮件导致崩溃的时候。 o虽然磁盘是达不到的,由于填充或由于“邮件配额”,重要的邮件可能会延迟或丢失。通常这会有相关通知,但如果发送方和接收方主机磁盘淹没,返回邮件也可能失败,即电子邮件服务可能比以前变得不那么可信。 o作为未授权的邮件中继的中继变得超载。除了技术的影响,这也需要大量的人力资源,清理邮件队列和照顾被中继骚扰的愤怒的外部用户。 o对抗垃圾邮件发送者包括阻断宿主(本备忘录中描述)。然而,风险很大,邮件中继主机也可能被阻塞,尽管他们也是受害者。从长远来看,这可能导致网络邮件服务恶化。 o常用伪造的“MAIL From:”和“From:”地址将问题归咎于无辜的人/主机/组织。这是对名声不好,可能会影响业务关系。 本文档中描述的几个方法增加了几个支持系统负荷电子邮件系统本身。这些支持系统可以DNS、日志、数据库的本地用户列表,身份验证机制等。因此,实现本文档中描述的方法,将增加拒绝服务攻击的风险。例如日志设施必须能够处理更多的日志(日志填满磁盘时发生了什么?)。DNS服务器和认证机制必须能够忍受负载更多的查找等。 支持系统在高负载的功能前应该仔细研究实现本文档中描述的方法。 邮件系统应该仔细研究,例如：在一个或多个支持系统所需的特定方法失败时应如何表现。邮件服务器不能对“永久失败”(5 xx)做出响应 如果其支持系统之一有临时的问题。 5。确认 这份备忘录是讨论的结果在一个特别小组的瑞典isp和大学。没有任何希望提到每个人我们只是给这里的域名:algonet。se,global-ip.net,π。se,swip.net,swip.net,udac。se,查尔默斯。se,sunet。se,umu。se,uu.se。 林德伯格当前最好的实践(21页) 2505年2月RFC 2505反垃圾邮件的建议 我们要承认有价值的输入和建议从Andras班子,约翰·迈尔斯,鲍勃•Flandrena Dave Presotto戴夫•克里斯托尔(Donald东湖牌,Ned释放,基思·摩尔和保罗·霍夫曼。 最后感谢Harald Alvestrand和帕特里克•Faltstrom,有用的评论和通过IETF的支持和指导的过程。 6。引用 [1]Postel J。“简单邮件传输协议”,性病,RFC 821, 1982年8月。 [2]克罗克,D。”标准的格式ARPA互联网文本 RFC 822消息”,性病11日,1982年8月。 [3]布莱登,R。,“互联网主机应用程序和要求 支持”,性病3,RFC 1123,1989年10月。 [4]他,S。”关键字用于rfc指示要求 RFC 2119水平”,BCP 14日,1997年3月。 [5]Mockapetris,P。“域名-概念和设施”,性病 1034年11月13日,RFC 1034,。 [6]Mockapetris,P。”,实现和域名 RFC 1035规范”,性病13日,1987年11月。 [7]东湖牌、d和c·考夫曼”域名系统安全 扩展”,RFC 2065,1997年1月。 [8]sendmail主页。http://www.sendmail.org [9]Gellens,r . j . Klensin“消息提交”,RFC 2476, 1998年9月。 [10]迈尔斯,J。、“SMTP服务扩展为身份验证”工作 的进步。 *垃圾邮件(R)(大写)是一个注册商标的肉类产品由客户。使用术语垃圾邮件(光)的互联网社区来自Monty Python草图和互联网几乎是民间传说。垃圾这个词通常是贬义的,然而这并不以任何方式旨在描述客户的产品。 林德伯格当前最好的实践(第22页) 2505年2月RFC 2505反垃圾邮件的建议 编辑器的地址 贡纳·林德伯格 计算机通信集团 查尔莫斯理工大学 瑞典的哥德堡se - 412 96, 电话:+ 46 31 772 5913 传真:+ 46 31 772 5922 电子邮件:lindberg@cdg.chalmers.se 林德伯格当前最好的实践(23页) 2505年2月RFC 2505反垃圾邮件的建议 完整的版权声明 版权(C)互联网协会(1999)。保留所有权利。 这个文档可能被复制和翻译和家具 其他衍生著作,评论或者解释 或者协助其实现可能准备,复制,出版 和分布式,全部或部分,没有任何的限制 ,前提是上面的版权声明和本段 包括所有此类副本和衍生著作。然而,这 文档本身可能不会以任何方式修改,如通过移除 版权通知或引用互联网协会或其他 网络组织,除了需要为目的的 在这种情况下,程序开发的互联网标准 版权在互联网标准中定义过程必须 之后,需要把它翻译成其他语言 英语。 有限的权限授予上面是永久的,不会 撤销的互联网协会或其继承人或受让人。 这个文件和本文所包含的信息的提供 “目前”的基础和网络社会和网络工程 专责小组并不保证,明示或暗示的保证,包括 但不限于任何保修的使用信息 这里不会侵犯任何权利或任何默示保证 适销性或健身为特定目的。 林德伯格当前最好练习(24页)