邮件路由与域名系统( 二 )


有几种查询响应被认为出错:
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依序

推荐阅读