邮件路由与域名系统

域服务器了解什么
域名服务器把信息保存为一系列的资源记录（resourcerecord，RR），每个记录包含有关
于某个域名（通常但不一定是一台主机）的特定信息片段。可以简单地把资源记录想象为数
据的代表对，每个域名都与对应的数据相匹配，还存储有其他的类型信息以帮助系统确定何
时与资源记录关联。为了确定消息路由，系统存储了称为MXRR的资源记录。每个MX都
一个域名相对应，包含两段数据：优先值（16位无符号整数）和主机名。优先值表示邮寄
者给MX主机传递消息的发送顺序，编号最低的MX最先发送。答应多个MX拥有相同的
优先值，此时它们具有相同的优先级。
除了邮件信息，服务器还存储有其他类型的资源记录，邮寄者可能会碰到或者选择使用
这些RR。其中包括：规范名资源记录（CNAME），它表示查询的域名实际上是另外一个域
名的别名，而CNAME才是严格的或者说规范的域名；知名服务资源记录（WellKnown
Service，WKS），保存给定域名所支持的网络服务（如SMTP）信息。
路由原则概述
在深入探讨邮寄者如何选择邮件路由之前，似乎有必要给出一个本备忘录所讨论的解决
路由选择问题的简要概述。
第一条主要的原则来自MX记录中定义的优先值字段，目的在于避免循环邮寄。假如邮
寄者的主机也列入目标主机的MX，邮寄者只能给优先值比自身主机低的MX传送邮件。
路由信息过时或者不完全也可能造成循环邮寄。信息过时问题只有在域表改变时才会发
生，因为那些被影响的主机只有在它们的分析器缓存超时后才会了解这些变化。只要不要求
邮寄者及其分析器必须向权威的服务器发出询问而且绝不使用缓存中的数据，就无法保证不
会发生这样的问题。而这种方法是不切实际的，因为去掉分析器的缓存会导致邮件非常昂贵。
另外，只要在域表改变时刷新受影响主机的（MX列表中的那些）分析器缓存，就不会发生
资源记录过时的问题。按句话说，只要有适当的预防措施，域信息带来的循环邮寄问题完全
可以避免，也不需要邮寄者查询权威服务器。（适当的预防措施是再把主机添加进MX列表
前，由主机治理员进行检查。）
数据不完整的问题在处理域查询时也需要注重。假如查询的答复段不完整，可能会漏掉
要害的MX资源记录。这样可能造成循环邮寄，或者信息给错误地贴上无法邮递的标签。
因此，邮寄者只能接受那些提供完整答复段的域系统的响应。注重，只要使用虚拟的查询循
环就可以完全避免这个问题。不过由于这种情况很少发生，而且与域系统交互的首选方式是
数据报，因此应用者可能只需要保证邮寄者使用虚拟循环反复重发查询，直到获取被截断的
数据。
确定消息要发往哪儿
根据这样的一个问题讨论并说明邮寄者如何确定消息的路由：域名为LOCAL的主机上的邮
寄者试图邮递消息，消息的地址是域名REMOTE。假定LOCAL和REMOTE都是语法正确
的域名。另外，假设LOCAL是邮寄者所在主机的正式名称（即不是一个别名）。
发出查询
LOCAL邮寄者的第一步是查询REMOTE的MX资源记录。强烈要求邮寄者每次试图发
送消息时都要执行这一步。目的是保证邮寄者能够及时地应用域数据库的变动，这样对于不
完备的主机，域治理员就可以通过简单地修改其域数据库为传送的消息重新设置路由
（re-route）。
有几种查询响应被认为出错：
1．查询无响应。邮寄者查询的域服务器没有回复（与没有查询结果的回复不同，后
者不是错误）。
2．得到设定了头部截断字段的响应。（回顾一下前面对不完全查询的讨论）。邮寄者
可能无法使用这样的回复，应使用虚拟循环而不是数据报反复查询。
3．得到响应码非0的响应。
邮寄者应该合理地处理错误。这里没有指明如何处理各种类型的错误，但是应用者不同
类型的错误可能需要区别对待。比如响应码“域不存在”可能需要把消息视为无效并返回发
送方，而响应码“服务器故障”则可能导致稍后重新发送消息。
还存在其它的非凡情况。假如响应结果是一个CNAME资源记录，这表明REMOTE实
际上是另外一个域名的别名，需要使用规范域名重新查询。
假如响应不包含错误，也没有别名，答复段（answersection）应该是域名REMOTE（如
果REMOTE是别名就是它的真正的名称）的（长度可能为0的）MX资源记录列表。下一
节将说明该表的解释。
解释MX资源记录列表
注重：本节只讨论邮寄者如何从资源记录列表中选择传递消息的目的名，没有讨论邮寄
者如何真正地执行邮递。无论何时提及消息传递，都意味着邮寄者执行必要的操作把消息发
往一个给定了域名的远程站点。（比如，SMTP邮寄者将首先试图取得域名的地址，其中包
括对域系统进行另外的查询，然后假如得到了地址，就建立对SMTPTCP端口的连接）。通
过网络把消息传输到一个与给定域名相关的地址的具体机制超出了本备忘录的范围。
查询响应中的MX列表有可能是空表，这是一种非凡情况。对此，邮寄者应把空表视作包
含一条资源记录，这条MX资源记录的优先值是0，主机名是REMOTE（就是说REMOTE
也是其自身唯一的MX）。另外，邮寄者也不需要进一步处理资源记录表，而应直接把消息
递送给REMOTE。这种考虑是为了在域无法提供主机名的任何信息的情况下，我们可以根
据猜测试着传递消息。
假如表不为空，邮寄者应按照下面的步骤从列表中删除无关的资源记录，注重先后顺序
很重要。
对于每个MX发送WKS查询，看看列出的域名是否确实支持需要的邮件服务。域
名不支持该服务的MX资源记录应摒弃。这一步骤不是必需的，但强烈建议执行。
假如域名LOCAL也被列为MX资源记录，优先值大于或等于LOCAL的优先值的
所有MX资源记录必须摒弃。
去除无关的资源记录后列表可能又变空了。这种情况是发生了错误，可能由几种原因造
成。最简单的情形是WKS查询发现列出的主机都不支持需要的邮件服务。这样就认为消息
无法传递，不过一些非常稳妥的邮件系统在返回这个消息前可能会首先试着传送到
REMOTE的地址（假如存在这样一个地址）。另外一种更加危险的可能是域系统认为LOCAL
在处理发往REMOTE的消息，而LOCAL上的邮寄者并没有预备处理发往REMOTE的邮
件。例如，假如域系统列出的REMOTEMX只有LOCAL一条记录，LOCAL就会把列表清
空。但是LOCAL查询域系统大概是因为它不知道如何处理地址为REMOTE的消息。显然
某些地方出了差错。邮寄者如何处理此类情况在一定程度上依靠于具体的实现，因此留给应
用者来判定。
假如MX资源记录列表不为空，邮寄者将依序（优先值低者优先）试着把消息发往每个
MX。邮寄者被要求尽量传送给优先值最低的MX。鼓励应用者编制邮寄者对每个MX依序
试用，直到某个MX接收消息或者试过全部的MX为止。对于一些不过分苛求的系统，仅
仅试用一定数量的MX也是合理的。要注重可能有多个MX具有相同的优先值。此时，必
须在试过具有该优先值的所有的MX之后，才能继续试用优先值更高的MX。另外，非凡的
情况下可能会出现几个MX都具有最低的优先值，在确认消息不可传递之前必须对它们全
部试用。
次要的非凡问题
为了避免复杂化，上一节的讨论没有牵扯两个非凡的问题。在这里对它们的讨论并没有
非凡的顺序。
带有字符“*”的通配符名也可能用于邮件路由。网络上的服务器很可能简单的规定发
往某个域的邮件都要经过一个中继转发。例如，在本文档写作的时候，所有发往域IL主机
的邮件都经过RELAY.CS.NET发送。这是通过建立一个带有通配符的资源记录实现的，该
记录表明“*.IL”具有RELAY.CS.NET的MX。这对邮寄者应该保持透明，因为域服务器
会把匹配的通配符隐藏起来（比如HUJI.IL与*.IL匹配，域服务器返回的资源记录将包括
HUJI.IL，而不是*.IL）。假如由于某种意外，邮寄者收到的资源记录在域名或者数据段中包
含通配符，就应该摒弃该项资源记录。
需要注重的是，假如LOCAL有一个别名而且这个别名出现在REMOTE的MX记录列
表中（比如REMOTE有一项MX称为ALIAS，而ALIAS的CNAME是LOCAL），这会破
坏删除无关资源记录的算法。只要保证在MX资源记录的数据段不使用别名就可以避免这
一问题。
应用者应该理解查询以及对查询的解释只对REMOTE而言，不会对REMOTE列出的
MX资源记录反复查询。你不能试图构造一个MX链来支持更加复杂的邮件路由。（比如，
UNIX.BBN.COM是RELAY.CS.NET的一项MX，而RELAY.CS.NET又是.IL上所有主机的
MX，但这并不意味着UNIX.BBN.COM会承担把邮件发往.IL的职责。）
最后要注重这是一个在Internet上选择路由的标准。为分布在多个网络上的主机服务的
邮寄者可能还必须就使用哪个网络传送做出决策。这样的决策超出了本备忘录的范围，尽管
邮寄者也可以利用域系统帮助选择。但是，只要邮寄者决定使用Internet递送消息，就必须
根据这些原则选择消息路由。
例子
作为上述讨论的进一步说明，这里举3个邮寄者选择消息路由的例子。这些例子都是用下面
的数据库：
A.EXAMPLE.ORGINMX10A.EXAMPLE.ORG
A.EXAMPLE.ORGINMX15B.EXAMPLE.ORG
A.EXAMPLE.ORGINMX20C.EXAMPLE.ORG
A.EXAMPLE.ORGINWKS10.0.0.1TCPSMTP
B.EXAMPLE.ORGINMX0B.EXAMPLE.ORG
B.EXAMPLE.ORGINMX10C.EXAMPLE.ORG
B.EXAMPLE.ORGINWKS10.0.0.2TCPSMTP
C.EXAMPLE.ORGINMX0C.EXAMPLE.ORG
C.EXAMPLE.ORGINWKS10.0.0.3TCPSMTP
D.EXAMPLE.ORGINMX0D.EXAMPLE.ORG
D.EXAMPLE.ORGINMX0C.EXAMPLE.ORG
D.EXAMPLE.ORGINWKS10.0.0.4TCPSMTP
在第一个例子中，位于D.EXAMPLE.ORG上的SMTP邮寄者试图传递一个地址标为
A.EXAMPLE.ORG的消息。在查询结果中，它了解到A.EXAMPLE.ORG有三个MX资源
记录。D.EXAMPLE.ORG不在这些MX资源记录中，而且三个MX都支持SMTP邮件（取
决于WKS项），因此没有排除一个MX。因为A.EXAMPLE.ORG是优先值最低的MX，邮
寄者被迫试图发送到A.EXAMPLE.ORG。假如无法抵达A.EXAMPLE.ORG，可以（但不是
必须）再试一下B.EXAMPLE.ORG；假如B.EXAMPLE.ORG仍然没有响应，还可以再试
C.EXAMPLE.ORG。
在第二个例子中，邮寄者位于B.EXAMPLE.ORG上，同样是要传送地址标为
A.EXAMPLE.ORG的消息。这一次A.EXAMPLE.ORG也有三个MX资源记录，不同的是邮
寄者必须摒弃自身的MX资源记录和C.EXAMPLE.ORG的资源记录（因为
C.EXAMPLE.ORGMX资源记录的优先值比B.EXAMPLE.ORG高）。这样A.EXAMPLE.ORG
只剩下一条资源记录，只能试着传递给A.EXAMPLE.ORG。
在第三个例子中，考虑位于A.EXAMPLE.ORG上的邮寄者要给D.EXAMPLE.ORG传递
消息。这种情况下只有两条MX资源记录而且优先值相同，每一个MX都可以为
D.EXAMPLE.ORG接收消息。邮寄者可以先试用一个（哪一个取决于邮寄者，不过
D.EXAMPLE.ORG似乎更加合理），假如传送失败再试另一个（如C.EXAMPLE.ORG）。