RFC974邮件路由与域名系统.doc

邮件路由与域名系统 (RFC974 MAIL ROUTING AND THE DOMAIN SYSTEM) 备忘录状态 本RFC文档描述了Internet上的邮件系统如何根据域名系统（参见RFC882、883和973RFC882、883和973的信息发送消息。本备忘录的传播不受限制。 简介 本备忘录的目的在于阐明邮寄方如何确定以给定的Internet域名为地址的消息的发送路 由。其中包括关于邮寄方如何解释MX RR的讨论，MX RR用于消息路由。注意，本备忘 录没有涉及邮寄方如何处理MB RR和MG RR的陈述，这两者用于邮箱名的解释。 RCF 882和RFC 883中关于邮件地址的一些设想已经发生了变化。现在一般可以认为如 果消息的地址是一个信箱——比如LOKI.BBN.COM，只要打开一个对LOKI.BBN.COM的 SMTP连接向前发就可以了。这种系统不适用于某些特定的情况，比如没有直接接入Internet 的特定的UUCP和CSNET主机，不过这些主机可以在配置文件中作为特殊情况处理（比如 大部分邮寄者都设定把发送给CSNET的邮件自动转发给CSNET-RELAY.ARPA）。 在域名系统中不能简单地打开对LOKI.BBN.COM的连接，而必须向域名系统询问发往 LOKI.BBN.COM的消息如何递送。域名系统可能会指导邮寄者把消息传递到一个完全不同 的主机，譬如SH.CS.NET。或者在更加复杂的情形中，邮寄者可能得知它有一个到 LOKI.BBN.COM的路径可以选择。本备忘录主要讲述在这种更加复杂的情况下邮寄者如何 工作的一些指导原则。 希望读者已经熟悉了RFC 882、RFC 883和它们的更新版本（如RFC973）。 目录 域服务器了解什么 2 路由原则概述 2 确定消息要发往哪儿 3 发出查询 3 解释MX资源记录列表 3 次要的特殊问题 4 例子 5 域服务器了解什么 域名服务器把信息保存为一系列的资源记录（resource record，RR），每个记录包含有关 于某个域名（通常但不一定是一台主机）的特定信息片段。可以简单地把资源记录想象为数 据的代表对，每个域名都与对应的数据相匹配，还存储有其他的类型信息以帮助系统确定何 时与资源记录关联。为了确定消息路由，系统存储了称为MX RR的资源记录。每个MX都 一个域名相对应，包含两段数据：优先值（16位无符号整数）和主机名。优先值表示邮寄 者给MX主机传递消息的发送顺序，编号最低的MX最先发送。允许多个MX拥有相同的 优先值，此时它们具有相同的优先级。 除了邮件信息，服务器还存储有其他类型的资源记录，邮寄者可能会遇到或者选择使用 这些RR。其中包括：规范名资源记录（CNAME），它表示查询的域名实际上是另外一个域 名的别名，而CNAME才是严格的或者说规范的域名；知名服务资源记录（Well Known Service，WKS），保存给定域名所支持的网络服务（如SMTP）信息。 路由原则概述 在深入探讨邮寄者如何选择邮件路由之前，似乎有必要给出一个本备忘录所讨论的解决 路由选择问题的简要概述。 第一条主要的原则来自MX记录中定义的优先值字段，目的在于避免循环邮寄。如果邮 寄者的主机也列入目标主机的MX，邮寄者只能给优先值比自身主机低的MX传送邮件。 路由信息过时或者不完全也可能造成循环邮寄。信息过时问题只有在域表改变时才会发 生，因为那些被影响的主机只有在它们的分析器缓存超时后才会了解这些变化。只要不要求 邮寄者及其分析器必须向权威的服务器发出询问而且绝不使用缓存中的数据，就无法保证不 会发生这样的问题。而这种方法是不切实际的，因为去掉分析器的缓存会导致邮件非常昂贵。 另外，只要在域表改变时刷新受影响主机的（MX列表中的那些）分析器缓存，就不会发生 资源记录过时的问题。按句话说，只要有适当的预防措施，域信息带来的循环邮寄问题完全 可以避免，也不需要邮寄者查询权威服务器。（适当的预防措施是再把主机添加进MX列表 前，由主机管理员进行检查。） 数据不完整的问题在处理域查询时也需要注意。如果查询的答复段不完整，可能会漏掉 关键的MX资源记录。这样可能造成循环邮寄，或者信息给错误地贴上无法邮递的标签。 因此，邮寄者只能接受那些提供完整答复段的域系统的响应。注意，只要使用虚拟的查询循 环就可以完全避免这个问题。不过由于这种情况很少发生，而且与域系统交互的首选方式是 数据报，因此应用者可能只需要保证邮寄者使用虚拟循环反复重发查询，直到获取被截断的 数据。确定消息要发往哪儿 根据这样的一个问题讨论并说明邮寄者如何确定消息的路由：域名为LOCAL的主机上的邮 寄者试图邮递消息，消息的地址是域名REMOTE。假定LOCAL和REMOTE都是语法正确 的域名。另外，假设LO