邮件路由的工作原理 转

 

将邮件消息导向到收件人主机的过程就叫作路由。除了找出发送站点到目标站点的路径外，路由还涉及到错误检查和传输速度和成本的优化。
　　UUCP站点和因特网站点处理路由的方式是有很大区别的。因特网上，将邮件数据导向收件人主机（只要能得知其IP地址）的主要任务是由IP层来完成的，而UUCP区内，路由必须由用户提供或由邮件传输代理生成。
　　12.4.1因特网上的邮件路由
　　因特网上，完全依靠目标主机来执行邮件路由的选择。默认情况是通过查找目标主机之IP地址，将消息直接投递给它，把真正的路由数据留在IP传输层。
　　对许多站点来说，都想将所有封装好的邮件导向一个具有较强处理能力的邮件服务器，这类服务器能够对所有的邮件通信进行处理，并在本地就开始进行分发。为宣布这项服务器，站点须在DNS数据库内，为其本地域出版一条所谓的“MX”记录。MX代表“邮件交换者”，基本上可表示服务器主机愿意充当该域内所有主机的邮件转发者。MX记录还可用于处理主机通信，这些主机本身没有接入因特网，比如UUCP网络或公司内网内用于传输机密信息的主机。
　　同时，MX记录还有一个与之关联的优先级。这个首选项是一个正整数值。如果一个主机对应若干个邮件交换者，邮件传输代理就会试着将邮件消息传给优先级最低的交换者，失败之后，再尝试优先级较高的交换者。如果本地主机本身就是目标地址的邮件交换者，它就会禁止向任何一台优先级高于它自己的MX主机转发邮件；其目的是为了避免邮件循环。
　　我们以Foobar公司为例。该公司打算让一台名为mailhub的机器来处理他们的邮件。所以，他们的DNS数据库内就有一条这样的MX记录：
　　foobar.comINMX5mailhub.foobar.com
　　该记录宣布mailhub.foobar.com作为foobar.com的邮件交换者，其优先级为5。希望将邮件消息投递给joe@greenhouse.foobar.com的主机，将在DNS数据库内查找foobar.com，并发现这条MX记录位于mailhub。如果没有找到优先级低于5的MX，这条邮件消息就会投递到mailhub，然后，再由后者将其分发到greenhouse。
上面的例子只是简单说明了MX的工作原理。如果想更多地了解因特网上的邮件路由，请参考RFC-974。
　　12.4.2UUCP网络内的邮件路由
　　UUCP网络内的邮件路由比因特网上的复杂得多，因为传输软件自身是不会执行任何路由的。早期，所有的邮件都必须利用bang路径进行寻址。bang路径指定一系列邮件必须经由的主机，中间用感叹号隔开，最后才是用户名。如果你想为发给Janet的邮件寻址，而她是Moria机器的用户，就应该采用这条路径：eek!swim!moria!janet。这样，就会把邮件从你的主机发送到Eek，再由Eek发给Swim，最后再投递到Moria。
这种路由的不足是它要求你必须记住网络拓扑、必须有快速链接等等。更糟糕的是，一旦网络结构发生了变化，比如链接已被删除或主机已发生增减，都可能导致邮件投递失败，究其原因，仅仅是你不知道这一变化。最后，如果你搬到另一个地方，很可能将不得不更新所有路由。
　　采用源路由的另一个必要原因是主机名指代不明。比如，我们以两个名为moria的站点为例，一个位于美国，另一个位于法国。moria!janet指的究竟是哪个站点呢？只有指定抵达moria的路径之后，才能得知。
解决主机名指代不明的第一步是：成立UUCP映射工程。它位于Rutgers大学，对所有正式的UUCP主机名及其UUCP邻居和地理位置进行注册，以保证主机名不会发生雷同。映射工程收集的这些信息作为UsenetMaps出版，并定期通过Usenet向外发布（用UUCP映射工程注册的站点映射信息则通过新闻组comp.mail.maps发布；其他一些组织可能也会发布自己的网络映射信息）。一个典型的映射系统条目（在删除批注之后）如下所示：
　　moria
　　bert(DAILY/2),
　　swim(WEEKLY)
　　这个条目是说Moria分别有一条指向Bert和Swim的链接，前者每天拨打前两次，后者则是一周一次。接下来详情讲解映射（map）文件的格式。
　　利用映射中提供的连接信息，便可自动生成从主机到任何一个目标站点的完整路径。这些信息通常都保存在paths（路径）文件内，该文件有时也称为路径别名数据库（pathaliasdatabase）。以通过Ernie抵达Bert的连接映射状态为例，从前面摘录的映射针对Moria生成的路径别名如下：
　　moriaernie!bert!moria!%s
　　现在，如果你指定目标地址janet@moria.uucp，你的MTA就会从上面选出一条路由，并采用bert!moria!janet这个地址向Ernie发送消息。
　　但是，根据Usenet映射构建路径文件并不是上策。因为映射中提供的连接信息通常变动很大，而且有时已经过时。因此，只有主要主机才会采用完整的UUCP全球映射来构建自己的路径文件。许多站点只是在其邻近维护自己的路径信息，将目标站点不在其数据库内的邮件消息发送给一个更“聪明”的主机，后者具有更完整的路径信息。这种方案称为“智能主机路由”（smart-hostrouting）。只有一条UUCP邮件链接的主机（也就是所谓的叶子站点）没有自己的路由信息；完全依靠它们的智能主机进行路由。
　　12.4.3UUCP和RFC-822
　　迄今为止，要解决UUCP网络内邮件路由问题，最好的办法是修改UUCP网络内的域名系统。当然，你是不能在UUCP网络上查询域名服务器的。但不管怎样，许多UUCP站点都有与其内部路由对应的小型区域。在这些映射中，这些域声明了一台或两台主机作为自己的邮件网关，所以域内的每台主机都不必有自己的映射条目。网关对流入或流出该域的所有邮件进行处理。该域内部的路由方案在外界看来，是不可见的。
　　这对前面提到的智能主机路由方案来说，也非常有用。全局路径信息只由网关进行维护；该域内的次要主机只负责一个小型的手工写入的路径文件，该文件中列出了域内的路由和指向邮件中转器的路由。甚至于邮件网关，也不必再有针对全球范围内每台独立UUCP主机的路由信息。对邮件网关来说，除了有完整的、用于自己提供服务的域的路由信息外，只需要在其数据库内有指向整个域的路由。比方说，下面的路径别名条目将把sub.org域内站点的所有邮件路由到Smurf：
　　.sub.orgswim!smurf!%s
　　地址是claire@jones.sub.org的所有邮件都将投到swim，后者的地址是smurf!jones!claire。域名空间的分层式结构允许邮件服务器采用多种特定路径。例如，位于法国的一个系统，可能有用于“fr”子域的特定路由，但它会把目标为“us”域内的主机的所有邮件路由到美国的特定系统。通过这种方式，基于域的路由将大大减少路由数据库的规模并减少路由管理上的开支。
　　但是，在UUCP环境内采用域名的好处主要是顺应RFC-822的需要，后者要求UUCP网络和因特网之间必须容易沟通。目前，许多UUCP域都有一条具有因特网网关的链接，由该网关充当其智能主机。通过因特网发送消息更为快捷，而且路由信息也更为可靠，因为因特网主机可用DNS来代替Usenet映射。
　　对基于UUCP的域来说，为了邮件能通过因特网抵达自己域内的主机，它们通常都有自己的因特网网关为其声明一条MX记录。比如，假设Moria属于orcnet.org域。Gcc2.groucho.edu充当其因特网网关。因此，Moria将采用gcc2作为自己的智能主机，发到域外的所有邮件都将通过因特网得以投递。另一方面，gcc2将为orcnet.org域声明一条MX记录，并将目标为orcnet站点的所有进入邮件都投递到Moria。
　　现在，唯一的问题是UUCP传输程序不能处理完整资格域名。大多数UUCP站点的站点名都限制在8个字符之内，有的甚至更少，而且是不包括文字或数字的名字。多数情况下，点.是绝不可用的。
　　所以，需要一些映射进行RFC822名和UUCP主机名之间的转换。映射方法与实施方案有关。对FQDN（完整资格域名）和UUCP主机名之间的映射来说，常见方法是利用路径别名文件：
　　moria.orcnet.orgernie!bert!moria!%s
　　该文件将根据指定完整资格域名的一个地址，产生一个纯粹的UUCP样式的bang路径。有些邮件服务器会为此提供一个特殊文件；比如sendmail采用的就是uucpxtable。
　　从UUCP网络向因特网发送邮件时，有时还需要逆向转换（俗称domainizing，定域）。只要发件人在其目标地址中采用的是完整资格域名，这个问题便可迎刃而解。作法是：在把邮件消息转发给智能主机时，不要从信封地址中删除域名。但是，还有些UUCP站点不属于任何一个域。它们通常会通过增加伪域UUCP的方式，进行定域。