Linux网络管理员手册［共16章节］[转帖]

北南南北 · 发表于 2002-4-24 11:15:17

Linux网络管理员手册(11)

第十一章网络文件系统 
NFS，网络文件系统（network filesystem），或许是使用RPC最突出的网络服务了。它允许你以访问任何本地文件一样的方法来访问远程主机上的文件。这是通过将客户端的内核功能（它使用远程文件系统）与服务器端的NFS服务器功能（它提供文件数据）相混合而成为可能的。这种文件访问对客户来说是完全透明的，并且可在各种服务器和各种主机结构上工作。
NFS提供的许多优点：
&#61548; 被所有用户访问的数据可以存放在一台中央主机上，由客户在引导启动时加载这个目录。例如，你可以将所有用户的帐目存放在一台主机上，让你的网络上的所有用户从那台主机上加载/home目录。如果也安装了NIS的话，用户就可以登录进任何系统上，而始终在一组文件上工作。
&#61548; 需要耗费大量磁盘空间的数据可以被保存在一台主机上。例如，所有有关LaTeX和METAFONT的文件和程序可以在一个地方保存和维护。
&#61548; 管理用的数据可以存放在单个主机上。不再需要使用rcp将相同的文件安装到20个不同的机器上。
NFS在很大程度上是由Rick Sladkey做出的，[1] 他编制了NFS的内核代码和NFS服务器的大部分。后者源自于由Mark Shand编制的unfsd user-space NFS服务器和Donald Becker编制的hnfs Harris NFS服务器。
现在让我们观看一下NFS是如何工作的：一个客户可以请求将一台远程主机的目录加载到一个本地目录上，正如用加载一个物理设备同样的方法。然而，用于指定远程目录的句法是不同的。例如，为了主机vlager的/home加载到vale的/users上，管理员在vale上要发出以下的命令：[2] # mount –t nfs vlager:/home /users 此时，mount将试图通过RPC联系vlager上的mountd mount后台程序。服务器将检查vale是否允许加载所考虑的目录，如果行的话，就返回一个文件句柄（file handle）。这个文件句柄将被用于所有随后对/users下的文件的请求。
当某人通过NFS访问一个文件时，内核就将一个RPC调用送至服务器机器上的nfsd（NFS后台程序）。该调用将文件句柄、要访问的文件名以及用户的user和group id作为参数。这些用于确定对指定文件的访问权限。为了避免非授权用户读取或修改文件，user和group id在两台主机上必须相同。
在许多UN*X实现中，NFS的客户和服务器功能是作为内核层的后台程序实现的，是在系统引导时从用户空间启动的。NFS后台程序（nfsd）在服务器主机上，Block I/O后台程序（biod）在客户主机上。为了提高吞吐率，biod使用预读（read-ahead）和后写（迟写）（write-behind）来执行同步I/O；同样，几个nfsd后台程序通常是并发运行的。
NFS的Linux实现稍微有些不同，客户代码被紧密地集成到内核的虚拟文件系统中（VFS）并且不需要通过biod进行另外的控制。另一方面，服务器代码完全在用户空间运行，所以同时运行该服务器的几个拷贝几乎是不可能的—因为这将涉及到同步问题。目前Linux的NFS还缺乏预读和后写机制，但Rick Sladkey计划今后将添加进去。[3]
Linux的NFS代码的最大问题是Linux的1.0版内核不能分配大于4K的内存块；其结果是，网络代码不能处理除去头大小等数据后大于3500左右字节的数据报。这意味着对于使用默认的大的UDP数据报的系统（例如，在SunOS上是8K），从其上运行的NFS后台程序上传回的数据，需要人工地切成小块。在某些环境下这会严重地损害系统性能。[4] 这个限制在最近的Linux-1.1内核中已不复存在，并且客户代码也已进行了修改以克服这个问题。 11.1 准备NFS
在你能够使用NFS之前，不管是作为服务器还是客户，你必须确信你的内核已将NFS支持编译进去了。对此，较新的内核在proc文件系统上有一个简单的接口，即/proc/filesystems文件，你可以使用cat来显示它： $ cat /proc/filesystems
minix
ext2
msdos
nodev proc
nodev nfs 如果这个列表中没有nfs，那么你必须编译你自己的启用了NFS的内核。配置内核网络选项在第三章的“内核配置”一节中作过解释。
对于Linux 1.1以前的内核，要找出你的内核是否启用了NFS支持的最容易的方法是实际地试着加载一个NFS文件系统。对于此，你可以在/tmp下建立一个目录，并试着往上加载一个本地目录： # mkdir /tmp/test
# mount localhost:/etc/ tmp/test 如果这个加载尝试失败了，并有一段出错信息指出“fs type nfs no supported by kernel”，那么你就必须制作一个启用了NFS的新内核。任何其它的出错信息都完全无关紧要，因为你还没有在你的主机上配置NFS后台程序。 11.2 加载一个NFS卷
NFS卷[5]的加载方法与普通文件系统的加载方式是一样的。你使用下面的句法调用mount： # mount –t nfs nfs_volume local_dir options nfs_volume是以remote_host:remote_dir形式给出。由于这个表示法对NFS文件系统来说是唯一的，你可以省略-t nfs选项。
在加载一个NFS卷时，你可以指定许多别的选项。这些选项可以在命令行上在-o开关后面给出，或者在/etc/fstab该卷条目的选项字段内给出。在这两种情况下，多个选项是用逗号彼此分开的。在命令行上的选项总是覆盖fstab文件中给出的选项。
在/etc/fstab中的一个样本条目可以是 # volume mount point type options
news:/usr/spool/news /usr/spool/news nfs timeo=14,intr 然后，这个卷可以使用下面命令被加载 # mount news:/usr/spool/news 如果fstab中没有相应的条目，那么NFS的mount调用看上去就有点乱。例如，假如你从一台称为moonshot的机器上加载你的用户主目录，moonshot机器使用一个默认的4K大小的块来进行读/写操作。你可以发出如下命令将块的大小减至2K以适应Linux的数据报大小的限制 # mount moonshot:/home /home -o rsize=2048,wsize=2048 在随Rick Sladkey的基于NFS的mount工具（可以在Rik Faith的util-linux软件包中找到）而来的nfs(5)手册页中对所有有效选项的列表进行了完整的描述。下面是你可能要用到的这些选项的一个不完整的列表： rsize=n and wsize=n
这分别指出了用于NFS客户读写请求的数据报的大小。由于上述的UDP数据报大小的限制，它们目前的缺省值是1024字节。 timeo=n 这用于设置NFS客户将等待一个请求完成的等待时间（以十分之一秒计）。缺省值是0.7秒。 hard 明确地标记出这个卷是硬加载的（hard-mounted）。缺省值是on。 soft 软加载（Soft-mount）驱动程序（与硬加载相反）。 intr 允许通知中断一个NFS调用。对于服务器没有响应时的异常中止很有用。 除了rsize和wsize以外，所有这些选项应用于当服务器临时变得不可访问时客户的相应动作。它们一起以如下的方式行事：每当一个客户想NFS服务器发送了一个请求，它就期望操作在一给定的时间间隔内（由timeout选项指定）完成。如果在该时间内没有收到确认，就会发生一个所谓的次超时（minor timeout），操作被重试并且超时间隔时间翻倍。在到达60秒钟的最大超时时间时，就发生一个主超时（major timeout）。
缺省地，一个主超时将导致客户程序在控制台上打印出一条消息并且再次重新开始，这一次，时间值再次翻倍。潜在地，这将会一直继续下去。顽固地重复一个操作直到服务器再次可用时的卷称为硬加载（hard-mounted）。相反地，每当一个主超时发生时，软加载（soft-mounted）的卷就为调用进程生成一个I/O出错信息。由于缓冲引入了后写，所以在进程下一次调用write(2)函数之前，这个出错情形并没有传播到进程本身，因此一个程序就完全不能确知对一个软加载卷的写操作是否已经完成了。
硬加载还是软加载一个卷不仅只是一个感觉（习惯）问题，而且也是与从该卷上你要访问什么信息有关。例如，如果你通过NFS加载你的X程序，你当然不希望你的X会话仅仅因为有人同时开启7个xv致使网络几乎中断而抓狂，或者由于片刻插拔下以太网插头而使得X会话瞬时停止。通过硬加载这个卷，你可以确信你的计算机将会等待，直到能够重新与你的NFS服务器建立连接。另一方面，非关键数据比如NFS加载的news分区或FTP文档程序也可以软加载，那么在远程机器暂时连接不上或关闭时就不会挂起你的会话过程。如果到服务器的网络连接很脆弱或者要经过一个重负荷的路由器的话，那么你或者使用timeo选项增大初始的超时值，或者硬加载这个卷，但是要允许信号中断NFS调用，这样你仍然可以终止任何挂起的文件访问。
通常，mountd后台程序以某种方法保持哪个目录已被什么主机加载的轨迹。这个信息能够使用showmount程序显示出来，该程序也包括在NFS服务器软件包中。然而现在Linux mountd还不能做到这件事。 11.3 NFS后台程序（Daemons）
如果你想为其它主机提供NFS服务，那么必须在你的机器上运行nfsd和mountd后台程序。作为基于RPC的程序，它们不是由inetd管理的，而是在引导期间启动的，并且用portmapper注册自身的。因此你必须确信只在rpc.portmap运行之后才开始运行它们。通常，在你的rc.inet2脚本中要包括下面两行： if [ -x /usr/sbin/rpc.mountd ]; then
/usr/sbin/rpc.mountd; echo -n " mountd"
fi
if [ -x /usr/sbin/rpc.nfsd ]; then
/usr/sbin/rpc.nfsd; echo -n " nfsd"
fi NFS后台程序为它的客户所提供的文件的属主信息通常仅包含数值的user和group id。如果客户和服务器两者所用的user和group的名字与这些数值id的相关联，那么就称它们共享相同的uid/gid空间。例如，当你在你的LAN上对所有的主机使用NIS分发passwd信息就是这种情况。
然而，在某些情况下它们并不匹配。你可以不用更新客户的uid和gid以与服务器上的匹配，你可以使用ugidd映射后台程序来处理这事。使用下面描述的map_daemon选项，在客户ugidd的协助下你可以告知nfsd将服务器的uid/gid空间映射到客户的uid/gid空间上。
ugidd是一个基于RPC的服务器，并且如果nfsd和mountd一样是从rc.inet2中启动的。 if [ -x /usr/sbin/rpc.ugidd ]; then
/usr/sbin/rpc.ugidd; echo -n " ugidd"
fi
11.4 exports文件
上面的各个选项是用于客户的NFS配置的，在服务器一端有不同的选项集用于设置每一客户的行为。这些选项必须在/etc/exports中设置。
缺省地，mountd不允许任何人从本地主机加载目录，这是一种非常敏感的态度。为了许可一台或多台主机用NFS加载一个目录，这个目录必须exported（输出），也即，它必须在exports文件中被指定。一个样本文件看上去象这样： # exports file for vlager
/home vale(rw) vstout(rw) vlight(rw)
/usr/X386 vale(ro) vstout(ro) vlight(ro)
/usr/TeX vale(ro) vstout(ro) vlight(ro)
/ vale(rw,no root squash)
/home/ftp (ro) 每一行定义了一个目录，以及允许加载该目录的主机。主机名通常是一个全资域名，但又可以含有*和?通配符，它们的作用与在Bourne shell中的一样。例如，lab*.foo.com与lab01.foo.com匹配，也与laber.foo.com匹配。如果主机名没有给出，就象上列中的/home/ftp目录，那么任何主机都允许加载这个目录。
当使用exports文件检查一台客户主机时，mountd将使用gethostbyaddr(2)调用查找客户的主机名，所以你必须确信没有在exports中使用别名。当不使用DNS时，那么返回的名字是在hosts文件中找到的与客户地址匹配的第一个主机名。
主机名字后跟一个可选的、用逗号分开的标志的列表，这些标志是用括号括住的。这些标志可以使用下面这些值： insecure 允许从这台机器过来的非授权访问。 unix-rpc 要求对这台机器进行UNIX域RPC认证。这简单的要求请求要从一个保留的internet端口生成（也即，端口号必须小于1024）。缺省地，这个选项是启用的（on）。 secure-rpc 要求对这台机器进行安全的RCP认证。这个选项还没有实现。参见Sun的有关安全RPC的文档。 kerberos 要求对这台机器来的访问进行Kerberos认证。这个选项还没有实现。参见MIT有关Kerberos认证系统的文档。 root-squash 这是一个安全特性，它通过将客户的uid 0请求映射到服务器的uid 65534(-2)来拒绝指定主机上的超级用户的任何特殊访问权限。这个uid应该与user nobody相关联。 no_root_squash
不映射来自uid 0的请求。这个选项的缺省值为on。 ro 将文件结构加载为只读。这个选项缺省值为on。 rw 将文件结构加载为读-写。 link-relative 通过装扮所需的几个../来从服务器上含有连接到根的目录上将绝对符号连接（以一个斜杠开始的连接形式）转换成为相对连接。只有当主机的整个文件系统被加载时，这个选项才有意义，否则的话，某些连接将不指向任何地方，或者更糟的是，指向它们根本就没有想指的文件上。
这个选项缺省的为on。 link-absolute 保留所有符号连接为原样（这是Sun提供的NFS服务器的常规行为）。 map_daemon 这个选项告知NFS服务器假设客户和服务器不共享相同的uid/gid空间。此时，nfsd将通过查询客户的ugidd后台程序来建立一个在客户和服务器之间映射id的列表。 在nfsd或mountd启动时，解析exports文件所得的出错信息在notice层上被报告到syslogd的后台程序设施中。
注意，主机名字是通过逆向映射从客户的IP地址获取的，所以你必须正确地配置好解析器。如果你使用BIND并且特别注重安全性，你应该在你的host.conf文件中激活spoof检查。 11.5 Linux自动加载器（Automounter）
有时候，加载用户可能要访问的所有NFS卷是很浪费时间的；一方面是由于要被加载的卷数量，另一方面是在启动时要占用很多时间。对此一个可选择的方案是所谓的自动加载器（automounter）。这是一个daemon，它能自动地和透明地加载任何需要的NFS卷，并且在一定时间没有用到时自动卸载它们。automounter的一个聪明之处是它可以从另外一个地方加载某个卷。例如，你可能在两到三台主机上保存有你的X程序和支持文件的拷贝，并且所有其它主机通过NFS加载它们。使用automounter，你可以指定加载所有这三个到/usr/X386上；此时automounter将尝试加载其中任何一个，直到有一个加载尝试成功。
Linux常用的automounter称为amd。它最初是由Jan-Simon Pendry编制的并且由Rick Sladkey移植到Linux上。当前的版本是amd-5.3。
对amd作讨论已超出本书的范围；要想有一本好手册，请参阅源程序；其中含有一个有详细信息的文本文件。 注释
[1] 可以通过jrs@world.std.com联系到Rick。
[2] 注意，你可以省略-t nfs参数，因为mount从冒号上看出这里指定了一个NFS卷。
[3] 后写的问题是内核高速缓冲是用device/inode对索引的，因此，不能用于NFS加载的文件系统上。
[4] 正如Alan Cox向我解释的：NFS规范要求服务器在返回应答之前将每次写入的数据刷新到磁盘上。因为，BSD内核只能进行页大小的写入（4K），因此写入4块1K的数据将导致基于BSD的NFS服务器执行4次每块4K的写操作。
[5] 我们没有说文件系统，因为这些不是适当的文件系统。

北南南北 · 发表于 2002-4-24 11:16:54

Linux网络管理员手册(12)

第十二章管理Taylor UUCP 
12.1 历史回顾
UUCP是AT&T贝尔实验室的Mike Lesk在七十年代末期设计的，用于在公共电话线路上提供简单的拨号上网服务。由于许多想在自己的机器上有email和Usenet News的人仍然使用modem进行通信，所以UUCP仍然很流行。尽管有运行于各种类型的硬件平台和操作系统上的许多实现版本，然而它们在很高的程度上是兼容的。
然而，尽管在过去的这些年中有许多软件以各种方式已成为“标准”，还没有一个UUCP软件被称为UUCP的。自从在1976年第一个版本实现以来，它经历了一个稳固的演变过程。目前，存在着两个主要种类，它们在硬件支持和配置上是不同的。它们都有各式各样的实现，每种实现都有一些细微的差别。
其中一类就是所谓的“版本2 UUCP”，它是Mike Lesk、David A. Novitz和Greg Chesson于1977年实现的。尽管这是一个很老的版本，但仍然被经常使用。版本2的近期实现提供了更新的UUCP种类的易用性。
第二种是于1983年开发的，并且通常被称为BNU（基本连网工具）、HoneyDanBer UUCP，或简称为HDB。这个名称产生自作者的名字，P. Honeyman、D. A. Novitz和B. E. Redman。HDB考虑到了排除版本2 UUCP的某些不足之处。例如，增加了新的传输协议并且针对每个与之有UUCP通信的站点都有一个独立的目录。
目前随同Linux发行的UUCP实现是Taylor UUCP 1.04，[1]本章即基于这个版本进行讨论。Taylor UUCP 版本1.04是于1993年2月发布的。除了传统的配置文件以外，Taylor UUCP也可被编译成使用新的样式 – a.k.a.“Taylor”—配置文件。
最近发行了1.05版，并且不久就将融入大多数Linux发行版中。这些版本的不同之处主要在于你不太会使用到的特性上，所以你可以使用本书中的信息来配置Taylor UUCP 1.05版。
对于包含在许多Linux发行中的Taylor UUCP，它通常被编译成BNU兼容的，或者是使用Taylor配置方案的，或者间而有之。由于后者更具灵活性，并且可能比经常是晦涩的BNU配置文件易于理解，所以下面我将介绍Taylor配置方案。
本章的目的不是给你一个对UUCP命令的命令行选项是什么和怎么使用的详尽描述，而是给你一个对如何设置一个可使用的UUCP站点的概要介绍。第一部分给出了有关UUCP是如何实现远程执行和文件传输的一个简要说明。如果对于UUCP，你不是一个完全的新手的话，你可以跳过这一部分而直接到UUCP的配置文件部分，该部分解释了用于设置UUCP的各种文件。
然而，我们将假设你对UUCP套件的用户程序很熟悉。这些程序是uucp和uux。有关这两个命令的介绍，请参见在线手册页。
除了通常使用的uux和uucp程序，UUCP套件还包含了仅用于管理目的的一系列命令。它们用于监视通过你的节点的UUCP通信、删除老的日志文件或者汇总统计参数。这里将不对它们进行任何说明，因为它们与UUCP的主要任务是并行的。而且，它们有很好的文档可作参考并且很容易理解。不过，还有一类，它们是由UUCP实际的“工作机器”组成。它们被称为uucico（这里cico代表copy-in copy-out）和uuxqt—用于执行远程系统发送来的作业。
12.1.1 有关UUCP的更多信息
对于不能在本章中找到所要信息的人，应该阅览随该软件包而来的文档。这是描述使用Taylor配置方案进行设置的一打texinfo文件。可以分别使用tex和makeinfo将texinfo转换成DVI和GNU信息文件。
如果你想使用BNU或者甚至是（令人战栗的）版本2配置文件的话，这里有一本很好的书，“管理UUCP和Usenet”（[Oreilly89]）。我发现它非常有用。其它有关Linux上UUCP的很好的信息来源是Vince Skahan的UUCP-HOWTO，它是定期地投递到comp.os.linux.announce上的。
当然还有一个专门讨论UUCP的新闻组，叫做comp.mail.uucp。如果你有针对Taylor UUCP的问题，你最好在那里去问他们，而不要在comp.os.linux组中。 12.2 概述
12.2.1 UUCP传输和远程执行的概要
对于理解UUCP至关重要的概念是作业（jobs）。用户使用uucp或uux发起的每一个传输被称作一个作业。它是由在远程系统上执行的命令，以及将要被在站点间传输的文件集构成。当然，可以省略其中一部分。
作为一个例子，假设你在你的主机上发出了下面的命令，该命令使得UUCP将文件netguide.ps拷贝到主机pablo上，并且使得它执行lpr命令来打印这个文件。 $ uux –r pablo!lpr !netguide.ps UUCP通常不会立刻调用远程系统来执行一个作业（不过你可以使用kermit来做到）。而是临时地将该作业描述存储起来。这称为假脱机操作（spooling）。作业所存放的目录树因此也就称为假脱机目录（spool directory）并且通常位于/var/spool/uucp中。在我们的例子中，该作业描述含有将被执行的远程命令（lpr）的有关信息、要求进行该操作的命令以及其它一些项目。除了这个作业描述，UUCP也需要存储输入的文件netguide.ps。
假脱机文件所在的确切位置和命名方法是可以不同的，这依赖于一些编译时的选项。HDB兼容的UUCP通常将假脱机文件存储于命名为/var/spool/uucp/site的目录中，这里site是远端站点的名称。当以Taylor配置方式编译时，UUCP将针对不同类型的假脱机文件在指定站点的假脱机目录下再创建子目录。
在规定的时间间隔，UUCP将向远程系统拨号。当与远程系统的连接建立后，UUCP就会传输描述作业的文件，加上所有的输入文件。输入的作业不会立刻被执行的，而要到连接结束关闭之后。这是用uuxqt来执行的，如果有指定到其它站点的作业，它也处理这些作业的转发工作。
为了区分重要的和不很重要的作业，UUCP给每个作业指定了一级别（grade）。这是一单个字母，范围从0到9、A到Z以及a到z，级别从大到小。Mail通常以级别B或C进行假脱机操作，而news则以级别N进行假脱机操作。级别越高的作业传输的越早。级别可以在调用uucp或uux时用-g标志来指定。
你也可以在一定时间内禁止低于某级别的作业的传输。这称为在对话期间所允许的最大假脱机级别（maximum spool grade），缺省值是z。这里请注意术语上的含糊不清：一个文件将被传输当且仅当它的级别等于或高于最大假脱机级别。 12.2.2 uucico的内部工作机制
要理解为什么uucico需要知道某些事情，这里给出了它实际上是如何连接至远程系统的一个快速描述。
当你在命令行上执行uucico –s system时，它首先必须进行物理连接。所进行的操作起决于所打开的连接类型 – 例如，当使用电话线时，它必须找到一个modem，并且进行拨号。而在TCP上，它就必须调用gethostbyname(3)将名字转换为一个网络地址、找出要打开那一个端口，并且将该地址绑定于相应的套接字（socket）上。
在这个连接被建立起来后，接下来必须通过一个认证过程。这常常是由远程系统询问一个登录名字以及一个可能的密码组成。这通常被称为登录对话（login chat）。认证过程或者是通过通常的getty/login套件执行的，或者是由uucico自身在TCP套接字上完成的。如果认证成功的话，远端系统就会启动uucico。初始化连接的本地uucico拷贝被视作主端（master），远端的则作为从端（slave）。
接下来是握手阶段（handshake phase）；主端现在发出自己的主机名，加上几个标志，从端检查这个主机名的登录许可，发送和接收文件等等。这些标志用于描述（以及在其它一些事情中）被传输的假脱机文件的最大级别。如果使能的话，这里将会进行一个对话计数，或调用序列号的检查。使用这个特性，两端站点就维持有一个成功连接的计数，可用于进行比较。如果它们不匹配的话，握手过程就失败了。这对于保护你免受冒充者是很有用的。
最后，两个uucico试着达成一个共同的传输协议。这个协议指导数据被传输的方法、检查一致性并且在出错时进行重传操作。针对所支持的不同的连接类型需要有不同的协议。例如，电话线路要求有一个对于出错保守的“安全”协议，而TCP传输天生就是可靠的因此可以使用一个更为有效的无须附加出错检查的协议。
在握手阶段完成以后，就开始进行实际的传输阶段。传输两端开启所选的协议驱动程序。驱动程序一般还要进行与该协议相关的初始化过程。
首先，主端将发送假脱机级别足够高的排于队列中的所有文件到远程系统中。当它完成传输后就会通知从端，此时从端就可以挂断了。现在从端可以或者同意挂断，或者将对话控制权接过来。这是一个规则的变化：现在远程系统变成了主端，而本地则变成了从端。新的主端现在发送它的文件。当完成后，两个uucico互相交换传输消息，并关闭连接。
我们将不再进行更为详细的描述：请参阅代码或任何针对于此的有关UUCP的好书。在网上也还流传着一篇很古老的文章，是由David A. Novitz写的，它给出了UUCP协议的详细描述。Taylor UUCP FAQ也讨论了UUCP实现方法的某些细节。它被定期地投递到comp.mail.uucp上。 12.2.3 uucico命令行选项
本节描述uucico的一些最重要的命令行选项。有关完整的命令行选项列表，请参阅uucico(1)手册页。 -s system 呼叫指定的系统（system）除非受到呼叫时间的限制。 -S system 无条件地呼叫指定的（system）。 -r1 以主端（master）模式启动uucico。这是在给出-s或-S时的缺省值。如果只有该选项，该-r1选项将致使uucico试尝呼叫sys中的所有系统（systems），除非受到呼叫限制或重试次数限制。 -r0 以从端（slave）模式启动uucico。这是在没有-s或-S给出时的缺省值。在从端模式中，或者是标准的输入/输出被假设连接至一个串行端口，或者是使用由-p指定的TCP端口。 -x type,-X type 开启指定类型的调试。可以用逗号分开的一个列表指定几种类型。以下类型是有效的：abnormal，chat，handshake，uucp-proto，proto，port，config，spooldir，execute，incoming，outgoing。为了与其它UUCP实现方式的兼容，可以用一个数字代替，该数字开启上面列表中的头n项。 调试信息将被记录在/var/spool/uucp文件Debug中。 12.3 UUCP的配置文件
与简单的文件传输程序相比，UUCP被设计成能够自动地处理所有的传输操作。一旦被正确地设置好，就无须管理员每日进行干预了。操作所需要的信息被保存在/usr/lib/uucp目录下的几个配置文件中。这些文件大多数用于拨出操作中。 12.3.1 Taylor UUCP简介
要是说UUCP的配置很难，这只是一种保守的说法。实际上它是一个错综复杂的问题，并且有时候配置文件简明的格式并没有使得问题变得更容易些。（尽管与HDB或版本2中的老式格式相比较，Taylor格式几乎是很容易阅读的）。
为了给你一个这些文件是如何相互作用的感觉，我们将向你介绍一个非常重要的文件，并对这些文件的样本进行观察。现在我们将不解释各种细节问题；更精确的描述将在下面各个独立小节中给出。如果你想在你的机器上设置UUCP，你最好是从某些样本文件开始，并逐渐地对样本文件加以调整。你可以或者采用下面示出的，或者采用那些包含在你的Linux发行版本中的样本文件。
本节描述的所有文件都存储在/usr/lib/uucp或其中的一个子目录中。有些Linux发行版含有UUCP执行文件，它们对HDB和Taylor配置都支持，并且对每种配置文件集使用不同的子目录。在/usr/lib/uucp中通常有一个README文件。
为了让UUCP能正常地工作，这些文件必须为uucp用户所有。其中某些文件含有密码和电话号码，因此应该有600的许可权限。[2]
最主要的UUCP配置文件是/usr/lib/uucp/config，并用于设置通常的参数。其中最重要的（并且到现在为止，也是仅有的），是你的主机的UUCP名字。在虚拟酿酒厂，他们使用vstout作为他们的UUCP网关： # /usr/lib/uucp/config – UUCP main configuration file
hostname vstout 另一个重要的配置文件是sys文件。它含有你将连接站点的所有系统方面的信息。这包括站点名字以及连接本身的信息，比如当使用modem连接时的电话号码。一个以modem连接的称为pablo站点的典型内容将是
图12.1: Taylor UUCP配置文件之间的相互关系。 # /usr/lib/uucp/sys – name UUCP neighbors
# system: pablo
system pablo
time Any
phone 123-456
port serial1
speed 38400
chat ogin: vstout ssword: lorca port指定了所使用的端口，而time指出了它将被呼叫的时刻。Chat描述了登录对话脚本-必须相互交换以允许uucico登录进pablo的字符串序列。我们将稍后讨论登录脚本。port命令并不指定一个设备相关的文件比如/dev/cua1，而是指定了port文件中的一个入口。你可以随心所欲地指定分配这些名字只要这些名字在port文件中有有效的引用。
port文件掌握着与连接相关的信息。对于modem连接，它描述了所使用的设备相关文件、所支持的速度范围以及连接至端口的拨号设备的类型。下面的入口条目描述/dev/cua1（即已知的COM2），一个NakWell modem连接到它上面，该modem可以运行在最高38400bps的速度上。入口条目的命名方法是选择与sys文件中端口名匹配的名字。 # /usr/lib/uucp/port – UUCP ports
# /dev/cua1 (COM2)
port serial1
type modem
device /dev/cua1
speed 38400
dialer nakwell 属于拨号器（dialer）本身的信息则被保存在另一个文件中，称为-你猜得到的：dial。对于每种拨号器类型，它基本上含有用于发出拨号到一个远程站点的命令序列、和给出的电话号码。再一次，这是作为一个对话脚本给出的。例如，对于上面的NakWell的入口条目看上去可以象这样： # /usr/lib/uucp/dial – per-dialer information
# NakWell modems
dialer nakwell
chat “” ATZ OK ATDT T CONNECT 以chat开头的一行指出了modem对话，它是发送到modem和从modem接收的初始化modem并使它拨出所期望号码的命令串。” T”序列将被uucico替换成电话号码。
为了给你一个uucico是如何处理这些配置文件的大概思路，假设你在命令行上发出命令 # uucico –s pablo uucico所做的第一件事是在sys文件中查找pablo。从sys文件的pablo入口条目中它看到它应该使用serial1端口来建立连接。port文件告知它这是一个modem端口，并且有一个NakWell modem连在该端口上。
uucico现在在dial文件中查找描述NakWell modem的入口条目，并且找到一个，并打开串行端口/dev/cua1并执行拨号器对话。也即，它发送出“ATZ”，等待响应“OK”，等等。当遇到字符串“ T”时，就用从sys文件中获得的电话号码（123-456）取代之。
在modem返回CONNECT以后，连接就被建立好了，并且modem对话也就结束了。uucico现在返回到sys文件并执行登录对话。在我们的例子中，它将等待提示“login:”，然后送出它的用户名（neruda），等待“password:”提示，并送出它的密码，“lorca”。
在完成了权限认证以后，远端即会启动它自己的uucico。然后，这两个uucico将进入前节所述的握手阶段。
配置文件之间的相互关系也在图12.1中示出了。 12.3.2 UUCP需要知道些什么
在你开始编写UUCP配置文件之前，你必须收集它需要知道的一些信息。
首先，你必须知道你的modem连接在哪个串行端口上。通常，（DOS）端口COM1至COM4映射到设备文件/dev/cua0至/dev/cua3上。对于大多数发行版，比如象Slackware，创建了一个链/dev/modem作为到适当cua*设备文件的一个链，并配置kermit、seyon等等，以使用这个通用文件。在我们这个情况下，你也应该在你的UUCP配置中使用/dev/modem。
这样做的原因是所有拨号程序在串行端口被占用时使用所谓的lock文件来作出通知。这些锁定文件的名称是字符串LCK..和设备文件名的串联，例如LCK..cua1。如果程序对于同样的设备使用不同的文件名，它们将不能识别出各自的锁定文件。结果，当它们同时启动时，将毁坏对方的进程。在你使用crontab确定你的UUCP呼叫时间表时，这并非不常发生的事。
关于设置你的串行端口的详细信息，请参见第四章。
下一步，你必须找出在什么速度上你的modem将与Linux通信。你必须将它设置成你所期望获得的最大有效传输速率上。有效的传输速率可能比你的modem的原始物理传输速率高得多。例如，许多modem以2400bps(每秒比特数)发送和接收数据。如果使用了压缩协议如V.42bis，实际的传输速率可能爬升至9600bps。
当然，如果UUCP要做任何事的话，你将需要一个被呼叫的系统的电话号码。同样，对与远程系统，你还需要一个有效的登录id和一个可能的密码。[3]
你也必须明确地知道如何登录进系统。例如，在登录提示出现之前你是否需要按下BREAK键？它是显示login:还是user:？这对于编制对话脚本（chat script）是必须的，这个对话脚本告知uucico如何进行登录。如果你不知道，或者如果常用的对话脚本失败了，就尝试使用象kermit或minicom的终端程序，并明确地写下来你必须做些什么。 12.3.3 站点命名
对于基于TCP/IP的网络，使用UUCP连网时，你的主机必须有一个名字。要是你只是想简单地使用UUCP来进行你直接拨号的站点间或在在本地网上文件的传输工作，那么这个名字就不需要符合任何标准。[4]
然而，如果你将UUCP用于mail或news连接，你应该考虑把你的名字注册在UUCP映射计划项目中。UUCP映射计划将在第13章加以描述。即使你只是在一个域中，你也应该考虑为你的站点获取一个官方的UUCP名字。
人们常常选择他们的UUCP名字与他们的全资域名相匹配。假如你的站点的域名地址是swim.twobirds.com，那么你的UUCP主机名就应该是swim。考虑那些互相熟知的基于第一个名字的UUCP站点。当然，你也可以使用一个完全与你的全资域名无关的UUCP名字。
然而，请确信不要在邮件地址中使用不合格的站点名称除非你已经将其注册为你的正式UUCP名字。在最好的情况下，邮递到没有注册的UUCP主机的所有信息将只是悄无声息地消失掉了。如果你使用了一个早已属于其它站点的名字，那么邮件将会路由到那个站点去，并会给那个站点的邮件管理者带来无穷无尽的烦恼。
默认地，UUCP站点使用由hostname设置的名字作为该站点的UUCP名字。这个名字通常是在/etc/rc.local脚本中设置的。如果你的UUCP名字与你的主机名的设置不同的话，你就必须在config文件中使用hostname选项来告知uucico你的UUCP的名字。这将在下面讲解。 12.3.4 Taylor配置文件
现在我们回过来讨论配置文件。Taylor UUCP从下列文件中获取信息： config 这是个主要的配置文件。你可以在这里定义你的站点的UUCP名字。 sys 这个文件描述了你所知道的所有站点。对于每个站点，它指定了站点的名字、呼叫时间、拨号号码（如果有的话）、所使用的设备类型以及如何登录。 port 含有描述各个存在端口的入口条目，以及线路所支持的速率和所用的拨号器。 dial 描述用于建立电话线路连接的拨号器。 call 含有呼叫一个系统时所用的登录名和密码。很少用到。 passwd 含有在登录时系统可能用到的登录名和密码。仅当uucico自己进行密码检查时才用到这个文件。 Taylor配置文件通常由含有关键字-值对的行组成。一个‘#’符号指定本行直到行尾都为注释。要使用‘#’符号本身，你就要和反斜杠一起使用它。
你可以使用很多的选项来调节这些配置文件。这里我们不能讨论所有这些参数，而将只是讨论几个很重要的参数。利用它们，你就可以配置一个基于modem的UUCP连接。其它的小节将描述当你想在TCP/IP或直接串行线上使用UUCP时所须作的必要修正。完整的参考资料已随同Taylor UUCP原代码以Texinfo文档给出。
当你认为你已经完全配置好你的UUCP系统以后，你可以使用uuchk工具（位于/usr/lib/uucp）来检查你的配置情况。uuchk读入你的配置文件，并打印出用于每个系统的配置值的详细报告。 12.3.5 常用配置选项 – config文件
除了你的UUCP主机名以外，这个文件通常并不包含其它信息。默认地，UUCP将使用你用hostname命令设置的名称，但是明确地设置UUCP名字将是一个好注意。下面示出了一个例子文件： # /usr/lib/uucp/config – UUCP main configuration file
hostname vstout 当然在这里也可以设置许多各种各样的参数，比如假脱机的目录、或匿名UUCP访问的权限。后者将在后面小节中讨论。 12.3.6 如何告知UUCP有关其它系统的信息 – sys文件
sys文件描述了你的机器要了解的远端系统的信息。一个条目由system关键字引入；随后的几行直到下一个system指令之间的信息详细描述了有关那个站点的参数。通常，一个系统条目将定义电话号码和登录对话等参数。
在头一个system行以前的各个参数设置了用于所有系统的缺省值。一般地，你要在缺省部分中设置协议参数等的信息。
下面，较详细地描述了几个很重要的字段。 系统名称（System Name）
System命令指定了远程系统。你必须指定远程系统的正确名字，而不是你虚构的别名，因为在你登录时uucico将拿它与远程系统所给出的作检查比较。[6]
每个系统名字只能出显一次。如果对同一个系统你想使用几种配置（比如uucico应该尝试的几个不同的电话号码），你可以指定alternates。Alternates将在下面讨论。 电话号码（Telephone Number）
如果远程系统是通过电话线路联系的，phone字段将指定modem将拨号的号码。它可以含有由uucico的拨号过程解释的标记。一个等于符号意思是指等待第二个拨号音，一个破折号产生一秒的暂停时间。比如，有些安装的电话当你在前导码与电话号码之间不暂停时就会止住。 [对此我并不知道适当的英语术语，就象一个公司内部私有安装的电话，当你要接外线时你首先必须拨一个0或9。] 任何内嵌的字符串可以用于隐藏与站点相关的信息，比如区位号。任何象这样的字符串使用dialcode文件都被转换成拨号代码。假如你有以下的dialcode文件： # /usr/lib/uucp/dialcode – dialcode translation
Bogoham 024881
Coxton 035119 利用这些转换，你可以在sys文件中使用Bogoham7732这样的电话号码，这使得号码变得清晰易读些。 端口与速率（Port and Speed）
port和speed选项用作选择用于呼叫远程系统的设备以及设备应该设置的最高速率。[7]一个system条目可以单独地使用这两个选项，或同时使用它们。当在port文件中查找适当的设备时，只有那些端口名以及/或者速度范围匹配的端口被选中。
通常，使用speed选项就足够了。如果在port中只定义了一个串行设备的话，uucico无论如何将总能选择到一个正确的，所以你只需给它一个所期望的速度即可。如果你的系统上连接了几个modem的话，你通常仍然无须指定一个特定的端口，因为在uucico发现有几个匹配时，它回逐个尝试每个设备直到找到一个未用的设备为止。 登录对话（The Login Chat）
上面，我们已经遇到过登录对话脚本，它告知uucico如何登录进远程系统。它由本地uucico进程指定的期望字符串和发送字符串的一个标记列表组成。目的是为了让uucico等待远程机器发送过来一个登录提示，然后返回登录名称，再等待远程系统发送密码提示，并发送密码。所期望的和发送的字符串是交替给出的。uucico自动地将回车符（carriage return character r）附加到任何发送的字符串上。这样，一个简单的对话脚本将象这样 ogin: vstout ssword: catch22 你会注意到所期望的字段并没有包含完整的提示。这是为了确信即使远程系统广播了Login:而不是login:时也能登录成功。
uucico同样也允许某些条件执行，例如，在发出提示之前远程机器的getty需要被复位的情况。对于此，你可以将一个子对话附加到一期望字符串上，用一破折号补偿。只有当主要期望失败时，例如超时，子对话才会被执行。使用这个特性的一种方法是在远程站点没有显示一登录提示时发送一BREAK。下面的例子给出了一个多用途的对话脚本，对于你必须在登录显示出来之前按回车的情况也同样能用。””告诉UUCP不要等待任何信息而立刻继续进行下一字符串发送。 “” n r d r n c ogin:-BREAK-ogin: vstout ssword: catch22 在对话脚本中会存在几个特殊的字符串和逃逸字符。下面是在期望字符串中合法的字符的不完整列表： “” 空字符串。它告知uucico不要等待任何事情，而立刻进行下个字符串的发送处理。 t Tab字符。 r 回车（Carriage return）字符。 s 空格字符。你需要它在对话串中加入空格。 n 换行符。 反斜杠字符。 对于发送的字符串，除了上面的字符以外，下面这些字符和字符串也是合法的： EOT 传输结束字符（^D）（End of transmission character）。 BREAK 中断字符。 c 在字符串尾压缩回车的发送。 d 延迟1秒发送。 E 允许响应（回送echo）检查。在uucico能继续进行对话之前，它要等待写出的所有信息的来自设备的响应被读取到。当用于modem对话时，这是非常有用的（我们将在下面遇到）。缺省地，响应检查是关闭的（off）。 e 禁止响应检查。 K 同BREAK。 p 暂停几分之一秒。 备用（Alternates）
有时，非常希望对于单个系统有多个条目，比如如果系统能通过不同的modem线路到达。对于Taylor UUCP，你可以通过定义一个所谓的alternate来做到。
为了对pablo使用两个电话号码，你要用以下方法修改它在sys中的条目： system pablo
phone 123-456
… entries as above …
alternate
phone 123-455 当呼叫pablo时，uucico现在将首先拨出号码123-456，如果失败了，就会试用备用的。备用条目维持与主要系统条目所有的设置，仅是电话号码不同而已。 限定呼叫时间（Restricting Call Times）
Taylor UUCP提供了许多方法允许你限制对远程系统呼叫的时间。这样做的原因或者是因为远端主机只在上班时间才提供此类服务，或者简单地只是为了避免高呼叫时间段的费用。注意，通过给uucico选项-S或-f，总是可以覆盖呼叫时间限制。
默认地，Taylor UUCP不允许任意时间的连接，所以你必须在sys文件中使用某些时间的规格说明。如果你不在乎呼叫时间限制的话，那么你可以在你的sys文件中把值Any指定给时间time选项。
限定呼叫时间的最简单的办法是利用time条目，它是由一个日子和时间子字段组成的字符串指定的。日子可以是任何Mo、Tu、We、Th、Fr、Sa、Su的组合，或者是Any、Never、或者平日Wk。时间由两个24小时时钟值组成，由短划线分隔。它们指定了呼叫的时间范围。这些标记的组合之间没有空格。任何数量的日子和时间的说明可以用逗号组合在一起。例如， time MoWe0300-0730,Fr1805-2000 允许在星期一以及星期三从早上3点到7点30分，以及星期五在18点05分到20点之间进行呼叫活动。当时间字段跨越午夜时，比如Mo1830-0600，它实际上表示星期一，在午夜到早上6点之间，以及在下午6点30分到午夜之间。
特殊的时间字符串Any和Never意思即是它们的本意：分别是指在任何时候都可以进行呼叫和在任何时候都不可以呼叫。
time命令有一个可选的第二个参数，用于描述以分钟计的重试时间。当建立一个连接的企图失败时，uucico在一定时间间隔内将不允许另一次拨号到远程主机的尝试。缺省地，uucico使用一种指数后退方案，这是指重复失败次数越多，那么重试间隔的时间就越长。例如，当你指定5分钟的重试时间时，uucico在距上次失败5分钟之内将拒绝呼叫远程系统。
timegrade命令允许你往时间表上附加一个最大假脱机级别。例如，假设在system条目中你有以下的timegrade命令： timegrade N Wk1900-0700,SaSu
timegrade C Any 这允许只要呼叫一被建立，那么假脱机级别C或更高的作业（通常，mail是以级别B或C排队的）即可立刻传输，而news（通常以级别N排于队列中）将只能在夜晚和周末传输。
和time一样，timegrade命令将一个以分钟计的重试间隔时间作为第三个可选的参数。
然而，有关假脱机级别的一个告戒是：首先，timegrade选项只应用于你的系统的发送；而远程系统仍然可以随心所欲地传输任何东西。你可以使用call-timegrade选项明确地请求远程系统只发送那些高于假脱机级别的作业；但并不能保证它一定会遵循这个请求。[8]
同样地，当远程系统呼叫进来时，并不会检查timegrade字段，所以任何排队等待这个远程系统的作业都将被发送出去。然而，远程系统可以明确地请求你的uucico来限制自身只发送一定假脱机级别的作业。 12.3.7 有些什么设备 – port文件
port文件告知uucico现有的端口。这些可能是modem端口，但其它类型的端口比如直接串行线路连接和TCP套接字也同样得到支持。
象sys文件一样，port文件由以关键字port开始后接端口名的各个条目构成。这个端口名可以被用于sys文件中的port语句中。这个名字无须是唯一的；如果几个端口有同样的名字，uucico将按顺序地试用每一个端口直到它找到一个空闲的端口。
port命令后必须紧跟描述端口类型的type语句。有效的类型有modem、直接连接的direct、和用TCP套接字的tcp。如果port命令不存在，那么端口类型的缺省值是modem。
在这一小节中，我们将仅讨论modem端口；TCP端口和直接线路连接将在后面的小节中讨论。
对于modem和直接端口，你必须使用device指令指定用于呼出的设备。通常，这是/dev目录中一个设备文件的名字，象/dev/cua1。[9]
对于modem设备的情况，端口条目也确定了那种类型的modem连接在端口上。不同类型的modem要求不同的配置。即使是那些声称Hayes兼容的modem也不一定是互相真正兼容的。因此，你必须告知uucico如何初始化modem以及如何让它拨出所希望的号码来。Taylor UUCP将所有拨号器的描述保存在一个称为dial的文件中。为了要使用其中任何一个，你必须使用dialer命令指定拨号器的名字。
有时候，你会想以不同的方式使用一个modem，这依赖于你呼叫的系统。例如，当一个高速modem试图以14400bps来连接时，某些老式的modem就不能理解；它们只是简单地中断线路而不是协商一个连接速度，比如说，9600bps。当你知道站点drop使用这样一个不灵光的modem时，那么在呼叫它们时，你就必须以不同的方式设置你的modem。针对于此，在port文件中你需要一个指定一个不同的拨号器的额外的端口条目。现在你可以给这个新端口一个不同的名字，比如说serial1-slow，并在sys文件的drop系统条目中用port指令。
一个更好的办法是通过他们所支持的速度来区分它们。例如，上面情况的两个端口入口条目看上去象这样： # NakWell modem; connect at high speed
port serial1 # port name
type modem # modem port
device /dev/cua1 # this is COM2
speed 38400 # supported speed
dialer nakwell # normal dialer # NakWell modem; connect at low speed
port serial1 # port name
type modem # modem port
device /dev/cua1 # this is COM2
speed 9600 # supported speed
dialer nakwell-slow # don’t attempt fast connect 对于站点drop的系统入口条目将给出serial1作为端口名，但只请求以9600bps使用它。此时，uucico将会自动地使用第二个端口入口条目。在系统条目中有38400bps速度的所有站点都将被使用第一个端口条目呼叫。 12.3.8 如何拨号 – dial文件
dial文件描述了各种拨号装置（拨号器）的使用方法。传统上，UUCP只谈及拨号器而非modem，因为在早期，只拥有一个（昂贵的）的拨号器来服务于一组modem是很现实的事。如今，大多数modem都有内置的拨号支持，因此这种区别有一些使人混淆。
然而，不同的拨号器或modem需要不同的配置。你可以在dial文件中来描述它们的每一种。dial中的每一个条目都以给出拨号器名字的dialer命令开始。
除此之外最重要的条目是由chat命令指定的modem对话条目。与登录对话类似，它是由一系列uucico发送到拨号器和它所期望的返回响应字符串组成。它通常用于将modem复位到某种已知状态并且进行拨号。下面的拨号器条目样本示出了Hayes兼容modem的一个典型modem对话： # NakWell modem; connect at high speed
dialer nakwell # dialer name
chat “” ATZ OK r ATH1EOQO OK r ATDT T CONNECT
chat-fail BUSY
chat-fail ERROR
chat-fail NO sCARRIER
dtr-toggle true modem对话过程以空字符串“”开始。接下来uucico将送出第一个命令（ATZ）。ATZ是Hayes命令用于复位modem。然后等待modem送回OK，接着送出下一个命令来关闭本地回显，等等。当modem再次返回OK以后，uucico发出拨号命令（ATDT）。该字符串中的逃逸字符序列 T将被从sys文件中的系统条目内的电话号码替换掉。此后，uucico等待modem返回字符串CONNECT，这个字符串表示与远程的modem已经成功地建立了连接。
常常，modem与远程系统的连接会失败，例如，远程系统正在与其它人通话并且线路忙的话。在这种情况下，modem将返回某些出错信息指出失败的原因。Modem对话是没有能力来识别出这种消息的；uucico将继续等待期望的字符串的到来直到超时。因此UUCP的日志文件将只显示出一模糊的“对话脚本超时（timed out in chat script）”信息而非真正的原因。
然而，Taylor UUCP允许你使用上面的chat-fail命令告知uucico有关此类出错消息。在执行modem对话时，当uucico检测出一个对话出错（chat-fail）字符串，它就会放弃这次呼叫，并且将错误消息记录在UUCP的日志文件中。
上面样本例子中所示的最后一个命令告知UUCP在开始modem对话之前转换DTR线的信号。大多数modem能够配置成当检测到DTR线路信号转换时挂断线路，并进入命令模式。[10] 12.3.9 TCP上使用UUCP
初听起来有些荒谬，然而使用UUCP在TCP上传输数据并不是一个坏主意，尤其是当传输象Usenet news这样的大量数据时。在基于TCP的链接上，news通常使用NNTP协议来进行交换的，请求和发送文章是分别进行的，没有压缩也没有进行任何的优化。尽管这适用于有着几个并行的喂信功能的大站点，这种技术对于使用ISDN等慢速连接来接收他们的news的小型站点并不合适。这些站点通常希望能结合TCP大批量发送news的优点，能够将数据压缩传输而只有非常小的过载。批量传输这些数据的一个标准方法就是在TCP上使用UUCP。
在sys中，你要以下面的方法来指定一个系统通过TCP来呼叫： system gmu
address news.groucho.edu
time Any
port tcp-conn
chat ogin; vstout word; clouseau address命令给出了主机的IP地址，或者是它的全资域名。相应的port条目将是： port tcp-conn
type tcp
service 540 这个条目表示当一个sys条目参考使用tcp-conn时将使用一个TCP连接，并且uucico将试图连接到远端主机的TCP网络端口540上。这个端口是UUCP服务的默认端口号。除了端口号，你也可以给service命令一个符号端口名。而与这个名字对应的端口号将在/etc/services中找到。UUCP服务的通用名称是uucpd。 12.3.10 使用直接连接
假设你使用线缆把你的系统vstout和tiny直接连接起来。与使用modem的情况非常相似，你必须在sys文件中写一个系统条目。确定串行端口tiny的port命令被连通起来。 system tiny
time Any
port direct1
speed 38400
chat ogin; cathcart word; catch22 在port文件中，你必须对直接连接描述这个串行端口。不需要dialer条目，因为无须拨号。 port direct1
type direct
speed 38400 12.4 UUCP能做与不能做的 – 调整权限
12.4.1 命令执行
UUCP的任务是将文件从一个系统拷贝至另一个系统，并且请求在远程主机上执行适当的命令。当然，你作为一个管理员会想要控制给予其它系统的权限 – 允许他们能够执行你的系统上的任何命令肯定不是一个好主意。
默认地，Taylor UUCP所允许其他系统在你的机器上执行的仅有的命令是rmail和rnews，它们通常是用于使用UUCP交换email和Usenet news。用于uuxqt的默认搜索路径是一个编译时的选项，通常包含有/bin、/usr/bin和/usr/local/bin。如果想要改变一个特定系统能执行的命令集的话，你可以在sys文件中使用commands关键字。类似地，可以用command-path语句改变搜索路径。例如，除了rmail和rnews命令，你可能还想允许pablo系统能执行rsmtp命令：[11] system pablo
…
commands rmail rnews rsmtp 12.4.2 文件传输
Taylor UUCP也允许你非常详细地微调文件的传输。在一个极端情况下，你可以禁止向/从某一特定系统的传输。只需设置request为no，远程系统就不能从你的系统中汲取文件也不能向你的系统发送任何文件。同样地，通过把transfer设置成no，你可以禁止你的用户向一个系统传输文件或从一个系统中传进文件。默认地，本地的和远程的用户是允许上载和下载文件的。
另外，你可以配置进行文件拷贝的目录。通常，你会想要限制远程系统的访问到某一个目录结构中，但仍然允许你的用户从他们的主目录中发送文件。常常，远程用户只被允许从公共的UUCP目录/var/spool/uucppublic中接收文件。这是放置公共文件的传统地方；非常象Internet上的FTP服务。它通常用~字符指示。
因此，Taylor UUCP提供了四种不同的命令用来配置发送和接收文件的目录。它们是local-send，它指定了用户可以要求UUCP从中发送文件的目录列表；local-receive，它给出了用户可以请求UUCP接收文件的目录列表；remote-send和remote-receive，它们针对外部系统做类似的工作。考虑下面的例子： system pablo
…
local-send /home ~
local-receive /home ~/receive
remote-send ~ !~/incoming !~/receive
remote-receive ~/incoming local-send命令允许你的主机上的用户将/home和公共UUCP目录中的任何文件发送到pablo。local-receive命令允许用户将接收到的文件放在uucppublic中的完全可写的receive目录中或/home下任何完全可写的目录中。remote-send命令允许pablo从/var/spool/uucppublic中获取文件，而除了incoming和receive目录下的文件。这是通过在相应的目录名前放置感叹号来指出的。末了，最后一行允许pablo往incoming中上载任何文件。
使用UUCP传输文件的严重问题之一是它仅允许将接收到的文件放到完全可写的目录中。这可能会引诱某些用户对其他用户设置陷阱等等。然而，并没有任何方法来阻止这个问题，除非完全禁止UUCP的文件传输。 12.4.3 转发（Forwarding）
UUCP提供了让其它系统依你的的要求执行文件传输的机制。例如，这允许你使得seci为你从uchile获取一个文件，并将它发送到你的系统。下面的命令将完成这个任务： $ uucp –r seci!uchile!~/find-ls.gz ~/uchile.files.gz 这种将一个作业通过几个系统传送的技术叫做转发（forwarding）。在上面的例子中，使用转发的原因可能是seci有对uchile的UUCP访问，而你的系统却没有。然而，如果你运行了一个UUCP系统，你会想要将转发服务限制到你可信任的很少几台主机，以免会为他们去下载一个最新的X11R6源程序版本而花费惊人的电话费用。
缺省地，Taylor UUCP完全不允许转发活动。为了对某一特定系统启动转发，你可以使用forward命令。这个命令指定了能够请求你的系统进行转发作业的站点的一个列表。例如，为了允许pablo能够从uchile请求文件，seci的UUCP管理员必须将下列几行内容加入到sys文件中： ####################
# pablo
system pablo
…
forward uchile
####################
# uchile
system uchile
…

北南南北 · 发表于 2002-4-24 11:17:31

Linux网络管理员手册(13)

 
第十三章电子邮件 自从第一个网络被设计出来，连网最显著的用途之一就是电子邮件（eletronic mail）。它是从将一个文件从一台机器拷贝到另一台机器的简单服务开始的，并将该拷贝的文件添加到接收者的mailbox文件中。本质上来说，这仍然是email所做的全部工作，尽管不断增长的网络及其复杂的路由需求以及它的不断增大的消息负载量已经促使要求更加精心制作的方案。
已设计出了各种邮件交换的标准。Internet上的站点始终坚持RFC 822中的设计，并被描述与机器无关的传输特殊字符方法的某些RFC所扩充，等等。对于“多媒体邮件”的更多思考目前也已作出，这涉及到有关在邮件消息中包含图形和声音。另一个标准，X.400，也已被CCITT定义。
有许多UN*X系统的邮件传输程序被实现。其中最为著名的是Berkeley大学的sendmail，它被用于很多平台上。最初的作者是Eric Allman，他现在又再次积极地工作于sendmail小组中。有两个sendmail-5.56c的Linux移植版本，其中之一将在第15章中讨论。目前正在开发的sendmail版本是8.6.5。
Linux最常用的邮件代理程序是smail-3.1.28，是由Curt Landon Noll和Ronald S.Karr编写和版权所有。在大多数Linux发行版中都包含这个程序。下面，我们将简称它为smail，尽管它还有其它完全不同的版本，但我们在这里并不讨论它们。
与sendmail相比，smail就显得非常简单。当对于一个没有复杂路由要求的小站点处理邮件时，这两者的性能就非常相近。然而，对于大型站点，sendmail总能高出一筹，因为它的配置方案是非常灵活的。
smail和sendmail两者够支持一族配置文件，它们都需要进行自定义（定制）。除了邮件子系统运行所必要的信息以外（比如象本地主机名），还有许多参数需要调整。Sendmail的主要配置文件开始是非常难理解的。它看上去就好象你的猫在按下了shift键的键盘上打过盹。smail的配置文件就非常结构化并且比sendmail的容易理解，但没有给予用户很强的调整邮件箱性能的能力。然而，对于小型的UUCP或Internet站点，它们的配置所需要的工作基本上是一样的。
在本章中，我们将讨论什么是邮件以及作为一个管理员你要涉及什么问题。第14章和第15章将对第一次设置smail和sendmail给出指导。那里所提供的信息已足够让一个小型站点工作起来，但是还有许多的选项，你可以在你的计算机旁花费很多快乐的时间来配置这些奇妙的特性。
在本章的最后，我们将概要地讨论elm的设置，这是一个许多UN*X系统（包括Linux）非常通用的邮件用户代理程序。
有关Linux上电子邮件方面问题的更多信息，请参考Vince Skahan的Electronic Mail HOWTO，这是定期投递到comp.os.linux.announce上的。Elm、smail和sendmail的源程序发行版同样也包含了非常广的文档资料，能够解答设置它们时所遇到的大多数问题。如果你在寻找有关电子邮件的一般性信息，有许多RFC涉及这个方面。它们列于本书后的参考书目中。 13.1 什么是邮件消息？
一个邮件消息是由消息体—它是发送者所写的文本、以及指明收信者的特定数据、传输介质等等组成，非常象信封上所见的信息。
这些管理用的数据可以分成两类；第一类是与特定传输介质相关的数据，就象发信者和收信者的地址。因此它们被称为envelope。在消息传输途径中，它们可能会被转换。
第二类是处理邮件消息所需的任何数据，它们并不是针对任何传输机制的，比如消息的主题行（subject line）、所有接收者列表、以及消息发送的日期。在许多网络中，将这些数据添置到邮件消息中已成为了标准，形成所谓的邮件头（mail header）。它与邮件体（mail body）之间相隔一空行。[1]
UN*X世界中的很多邮件传输软件使用一个RFC 822中指定的头[标题]格式。它的最初目的是在ARPANET上的使用指定一个标准，但是由于它被设计成是与任何环境都独立的，它很容易地被其它网络采纳，包括许多基于UUCP的网络。
然而，RFC 822仅是最伟大的公共奠基石。现有更多的标准已被构想出来以应付不断增长的需求，比如，数据加密、国际字符集的支持、以及多媒体邮件扩展（MIME）。
在所有这些标准中，标题[头]由几行组成，并由换行符来分割。每行是由从第一列开始的字段名、和由一个冒号和一个空格分割的字段本身组成。每个字段的格式和语义是随字段名的不同而有变化的。如果下一行是以一个TAB开始的，表示是标题字段的续行。各字段的顺序是随意的。
一个典型的邮件标题看上去象这样的： From brewhq.swb.de!ora.com!andyo Wed Apr 13 00:17:03 1994
Return-Path:
Received: from brewhq.swb.de by monad.swb.de with uucp
(Smail3.1.28.1 #6) id m0pqqlT-00023aB; Wed, 13 Apr 94 00:17 MET DST
Received: from ora.com (ruby.ora.com) by brewhq.swb.de with smtp
(Smail3.1.28.1 #28.6) id ; Tue, 12 Apr 94 21:47 MEST
Received: by ruby.ora.com (8.6.8/8.6.4) id RAA26438; Tue, 12 Arp 94 15:56 –0400
Date: Tue, 12 Apr 1994 15:56:49 –0400
Message-Id: 199404121956.PAA07787@ruby
From: andyo@ora.com (Andy Oram)
To: okir@monad.swb.de
Subject: Re: Your RPC section 通常，所有所需的标题字段都是由你所使用的邮件程序界面产生，象elm、pine、much或mailx。然而有些字段是可选的，可以由用户自己加上去。例如，elm允许你编辑部分消息头[标题]。而其它的则是由邮件传输软件加上去的。常用的标题字段以及它们的含义如下所示： From: 含有发送者的email地址，以及可能还有“真实名字”。这里使用了一个格式的完整zoo。 To: 这是接收者的地址。 Subject: 用几个词描述邮件的内容。起码这是应该做的。 Date: 邮件发送的日期。 Reply-To: 发送者指定接收者回信所发往的地址。对于你有几个帐号，但是只想在你常用的帐号下接收大量的邮件，此时这个字段是很有用的。该字段是可选的。 Organization: 产生邮件的机器所属的组织。如果你的机器是属于你个人的，你可以空着该字段，或者插入“个人”（“private”）或某些完全无意义的东西。这个字段是可选字段。 Message-ID: 产生邮件的系统的邮件传输程序生成的字符串。对于这条消息来讲是唯一的。 Received: 处理你的邮件的每一个站点（包括发送者和接收者的机器）在标题中插入的字段，给出它的站点名称、一个消息id、收到该消息的时间和日期、从哪个站点来的以及使用了哪个传输软件。根据此，你可以跟踪消息走过的路由，并且如果出了差错你可以抱怨的负有责任的相关人士。 X-anything: 以X-开头的标题行对任何邮件相关的程序都是不起作用的。它是用于实现还没有写入或不可能写入RFC的额外的特性的。例如，它用于Linux Activists邮件列表中，其中，是用X-Mn-Key: 标题字段来选择频道的。 这个结构的一个例外是最开头的一行。它以关键字From开始，紧接着是一个空格而是一个冒号。为了与普通的From:字段相区别，它通常被引用为From_。它包含消息所参与的UUCP大宗路径形式（下面将作解释）的路由、最后一台接收消息的机器处理消息的时间和日期以及一指明从哪台主机接收来的可选部分。由于每个处理过这个消息的系统都会生成这个字段，所以它通常包括在信封数据下。
因此From_字段与某些老式的邮件程序是向后兼容的，但已不再经常使用，除了邮件用户界面程序还要依靠它来确定用户邮件箱中一个消息的开始处。也是为了消除以“From ”开始的消息体中的行所带来的潜在问题，在它之前放置“>”以避免任何这样的现象出现，这已经成为一标准方法。 13.2 邮件是如何投递的？
一般来讲，你要使用一个邮件界面程序象mail或mailx来编写邮件；或者使用更为复杂的象elm、mush或pine。这些程序统称为邮件用户代理（mail user agents），或简称MUA。如果你发出了一个邮件消息，那么在大多数情况下界面（接口）程序会将它传递给另一个程序去进行投递。这个程序称为邮件传输代理（mail transport agent），或简称MTA。在某些系统中，对于本地的和远程的投递有不同的邮件传输代理程序；在其它系统上，仅有一个。远程投递的命令通常称为rmail，其它的称为lmail（如果存在的话）。
当然，本地邮件的投递仅仅是将进来的消息附加到接收者的邮件箱里。通常，本地MTA是懂得别名（将接收者的地址设置成指向其它的地址），和转发的（将用户的邮件重定向到某个其它的目的地）。同样，不能投递的消息通常必须反弹回来（bounced），也即，附带某些出错信息返回给发送者。
对于远程投递操作，所用的传输软件依赖于链接的属性。如果一个邮件必须在使用TCP/IP的网络上投递的话，常常会使用SMTP。SMTP表示简单邮件传输协议（Simple Mail Transfer Protocol），是在RFC 788和RFC 821中定义的。SMTP通常直接连接至接收者的机器上，与远端的SMTP后台程序（daemon）协商消息的传输。
在UUCP网络中，邮件通常不是直接投递的，而是通过一系列的中间系统转发到目的主机上的。为了在UUCP链接上发送一个消息，发送MTA通常将使用uux在转发的系统上执行rmail，并且将消息在标准输入上喂信给转发系统。
由于这是对每个消息分别操作的，这将在主要的邮件hub上产生可观的工作负载，以及耗费不成比例的大量磁盘空间的数百个小文件构成的混乱的UUCP假脱机队列。[2] 因此某些MTA允许你以一个批处理文件从远程系统收集几个消息。如果使用了直接SMTP连接，那么这个批处理文件通常含有本地主机要发出的SMTP命令。这称为BSMTP，或batched SMTP。此时这个批处理会被发送给远程系统中的rsmtp或bsmtp程序，远程系统将如正常的SMTP连接一样来处理输入。 13.3 Email地址
对于电子邮件，地址起码是由处理该人邮件的机器的名字，和这个系统能够识别的用户的代号组成。这可以是接收者的登录名，但也可以是任何别的代号。其它的邮件地址方案，象X.400，使用一个更为一般的“属性”集，用于在一个X.500目录服务器中查询接收者的主机。
一个机器名字被解释的方法，也即，在哪个站点你的消息将最终结束，以及如何将这个名字与接收者的用户名结合在一起，这很大程度上依赖于你上的网络。
Internet站点是符合RFC 822标准的，它需要user@host.domain这样的表示法，这里host.domain上主机的全资域名（fully qualified domain name）。当中的符号称作为“在”（“at”）符号。因为这个表示法不包含有到目的主机的路由，而是给出了（唯一的）主机名，这称为一绝对（absolute）地址。
在初始的UUCP环境中，流行的形式是path!host!user，这里path描述了在到达目的host之前消息经过的一系列的主机。这种结构称为bang path表示法，因为一个感叹号近似地被称为一个“bang”。今天，许多基于UUCP的网络已经采用了RFC 822，并且能够理解这种地址类型。
如今，这两种地址类型还不能很好地融合在一起。假设有一个地址hostA!user@hostB。这并不清楚在这个路径上‘@’符号是否是优先的；是否我们必须将消息发送到hostB，再邮递到hostA!user，还是先发送到hostA，再转发到user@hostB？
然而，存在一种以RFC 822一致的方法指定路由：<@hostA,@hostB:user@hostC>表示在hostC上user的地址，这里hostC将经过hostA和hostB到达（以这个次序）。这种地址类型常常称为route-addr地址。
而且，还有一个‘%’地址操作符：user%hostB@hostA将首先发送到hostA，它将最右边的（仅在这里的情况下）百分符号扩展成为一个‘@’符号。现在这个地址成为了user@hostB，邮件程序将很顺利地将你的消息转发到hostB，再而投递给user。这种类型的地址有时被称为“Ye Olde ARPANET Kludge”，它的使用是不赞成的。然而，许多邮件传输代理产生这种地址类型。
其它的网络还有不同的地址方案。例如，基于DECnet的网络使用两个冒号作为地址的分割符，产生一个host::user地址。[3] 最后，X.400标准使用了一个完全不同的方案，通过使用一族属性-值对描述一个接收者，就象国家和组织一样。
在FidoNet上，每个用户的确定是用一个代码象2;320/204.9，由四个数字组成，表示区zone（2表示欧洲）、网络net（320代表巴黎和郊区）、节点node（本地hub）和点point（个人的用户PC）。FidoNet的地址可以被映射到RFC 822上；上面的地址可以写成Thomas.Quinot@p9.f204.n320.z2.fidonet.org。现在我没有说过域名好记吧？
使用这些不同的地址类型有某些隐含方面，这将在以下几节中讨论。然而，在一个RFC 822环境中，除了象user@host.domain这样的绝对地址，你很少会用到其它的地址类型。 13.4 邮件路由是如何工作的？
定向一个消息到接收者主机的过程称为路由选择（routing）。除了寻找到一条从发送站点到目的地的路径以外，它还包括错误检测以及速度和代价优化。
UUCP站点处理路由选择的方法与Internet站点的有很大的不同。在Internet上，定向数据到接收者的主机（由它的IP地址确定）的主要任务是由IP的网络层来完成的，而在UUCP区中，路由必须由用户来提供，或者是由邮件传输代理生成的。 13.4.1 Internet上的邮件路由选择
在Internet上，它完全依赖于目的主机是否要执行任何特定的邮件路由选择。默认的是通过查找目的主机的IP地址，直接将消息投递到目的主机去，而将实际数据的路由选择工作给IP传输层去做。
许多站点通常会想要指引所有入站的邮件到一个高效稳定的邮件服务器中，这个服务器能够处理所有这些数据流量，并让它在本地分发邮件。为了宣告这种服务，站点在DNS数据库中为它们的本地域公布一个所谓的MX记录。MX代表邮件交换器（Mail Exchanger）基本的意思是表明服务器主机很愿意为本域中的所有机器充当一邮件转发器。MX记录也可以用于处理自己没有连接到Internet上的主机的交通流量，比如UUCP网络，或者是携带着机密信息的公司网络上的主机。
MX记录也有一个与之相关的优先权（preference）。这是一个正整数。对于一台主机如果存在几个邮件交换器的话，那么邮件传输代理将会试图把消息传输到具有最低优先权值交换器上，仅当这样做失败时才会尝试一台具有高一级优先权值的主机。如果本地主机本身就是目的地址的一个邮件交换器，它就不必将消息转发到优先权值比自己高的任何主机去；这是避免邮件循环（loops）的一个安全方法。
假设有一个叫Foobar Inc.的公司，想要他们所有的邮件由他们的称为mailhub的机器来处理。那么他们就应该在DNS数据库中有一个象这样的MX记录： foobar.com IN MX 5 mailhub.foobar.com 这宣告了mailhub.foobar.com是一个foobar.com上的有优先权值5的邮件交换器。一个希望把消息投递到joe@greenhouse.foobar.com的主机将检查foobar.com的DNS，会发现MX记录指向mailhub。如果此时没有优先权值小于5的其它MX存在，这个消息将被投递到mailhub，然后被分发给greenhouse。
上面实际上仅是MX记录如何工作的一个轮廓。有关Internet上邮件路由选择的更多信息，请参考RFC 974。 13.4.2 UUCP世界中的邮件路由选择
UUCP网络上的邮件路由选择就比Internet上的复杂得多，因为传输软件本身不执行任何的路由选择功能。在早期，所有的邮件得用bang paths来寻址。Bang paths指定了一张主机的列表，各主机名用感叹号分开，通过这些主机来转发消息，后接用户名。为了将一封信寻址到名为moria的机器上的Janet用户，你就得使用路径eek!swim!moria!janet。这将会把邮件从你的主机发送到eek，再从eek发送到swim最后到moria。
这种技术明显的不足之处是它需要你记住很多有关网络拓扑的细节、快速链接等等。更糟的是，网络拓扑的变化—象链接被删除了或主机被移走了—可能导致消息传输的失败，简单的原因只是由于你不知道网络结构变化了。还有，如果你移到了不同的地方，你很可能就要更新所有这些路由了。
然而，还有一件事使得源路由选择成为必需的是不明确的（多义的）主机名的存在：例如，假设有两个站点名字都叫moria，一个在U.S.，另一个在法国。那么moria!janet指的是哪一个呢？这可以通过指明到达moria的路径弄清楚。
消除多义主机名的第一步是UUCP映射计划组（The UUCP Mapping Project）的成立。它位于Rutgers大学，对所有官方的[正式]的UUCP主机进行登记注册，并记录下他们的UUCP邻居和他们的地理位置，确信没有那个主机名被使用了两次。由映射计划组收集的信息作为Usenet Maps公布出来，它会定期地通过Usenet进行发布。[4] Map中一个典型的系统条目看上去象这样的（在删除了注释语句之后）。 Moria
bert(DAILY/2),
swim(WEEKLY) 这个条目说明moria有一个至bert的连接--moria每天对它呼叫两次、和一个到swim的连接—moria每星期对它呼叫一次。下面我们将更详细地讨论映射文件的格式。
使用映射文件中提供的连接信息，你可以自动地生成从你的主机到达任何目的站点的全路径。这个信息一般存储在paths文件中，有时也被称为路径别名数据库（pathalias database）。假设映射表明你可以通过ernie到达bert，那么从上述映射中为moria生成路径别名条目看上去象这样的： moria ernie!bert!moria%s 如果你现在给出一个目的地址janet@moria.uucp，你的MTA就会取得上面的路由，并将消息用bert!moria!janet作为信封地址发送到ernie。
然而，从完整的Usenet影射来建立一个paths文件并不是一个好主意。其所提供的信息通常是有误导的，而且有时是过时的。因此，只有很少几个主要的主机使用完整的UUCP世界映射来建立它们的paths文件。大多数的站点仅仅维护着它们周邻站点的路由选择信息，并将需要发送到它们数据库中找不到的站点的任何邮件发到一个有更多完整路由选择信息的灵敏主机上。这种方案被称作灵敏-主机路由选择（smart-host routing）。只有一个UUCP邮件连接的主机（即所谓的页站点（leaf sites））本身不做任何的路由选择；它们完全依赖于它们的灵敏-主机。 13.4.3 混合UUCP和RFC 822
至今为止针对UUCP网络邮件路由选择问题最好的解决方案是在UUCP网络中采用域名系统。当然，你不能在UUCP上查询一个名字服务器。然而，许多UUCP站点已经在自己内部组成了与路由选择相协调的小型域。在映射中，这些域宣称一台或两台主机作为他们的邮件网关，所以在域中不需要对每台主机都有一个映射条目。网关将处理所有流入和流出域的邮件。在域中的路由选择方案对于外界世界来说是完全看不见的。
这个方法与上述的灵敏-主机路由选择方案配合的很好。全局路由选择信息仅由网关来维护；一个有很少主机的域将只有一个很小的手写paths文件，其中列出了他们域内部的路由，以及到邮件hub的路由。即使是邮件网关也不再需要有世界上每一台UUCP主机的路由选择信息，除了他们所服务的域的完整路由选择信息以外，现在仅需要在它们的数据库中含有至整个域的路由。例如，下面所示的路径别名条目（pathalias entry）将会把sub.org域中的所有站点的邮件路由到smurf： .sub.org swim!smurf!%s 任何寻址到claire@jones.sub.org的邮件将被用smurf!jones!claire作为信封地址发送到swim。
域名空间的层次化组织结构允许邮件服务器将非常特定的路由与一般的路由相混合。例如，一个在法国的系统可能有一个对fr子域的特定路由，但是将会把us域中任何主机的邮件路由到U.S.中的某个系统上。用这种方法，基于域的路由选择（就如这种技术所称的）大大地减小了路由选择数据库的大小和所需的管理负担。
然而，在UUCP环境中使用域名的主要好处是与RFC 822的兼容性使得UUCP网络和Internet之间的网关变得简单。现今许多UUCP域与Internet网关都有一个链接以作为它们的灵敏-主机。通过Internet发送消息更快，路由选择信息也更可靠，因为Internet主机能够使用DNS而不是Usenet映射。
为了从Internet能够传过来，基于UUCP的域通常有自己的Internet网关宣告了一个MX记录（上面已对MX作过讨论）。例如，假设moria属于orcnet.org域。gcc2.groucho.edu作为他们的Internet网关。因而moria使用gcc2作为它的灵敏-主机，所以发往外部域的所有邮件都通过Internet投递了出去。另一方面，gcc2会为orcnet.org宣告一个MX记录，并将进入orcnet站点的所有入站邮件投递到moria。
还有一个仅剩的问题是UUCP传输程序不能处理全资域名。大多数UUCP站点设计成应付多至八个字符的站点名，有些则更少，而使用非字母数字的字符比如象点（dot）则完全不可能了。
因此，就需要RFC 822名称与UUCP主机名之间的某些映射。映射的方法完全依赖于实现。映射FQDN到UUCP名字的一个常用方法是使用路径别名： moria.orcnet.org ernie!bert!moria!%s 这将从指明一全资域名的地址中产生一个纯UUCP风格的bang path。有些邮件程序为此提供了一个特殊的文件；例如，sendmail为此使用了uucpxtable。
当需要从UUCP网络发送邮件到Internet时，有时就需要反向转换（通俗地称为域名化）。由于邮件发送程序在目的地址中使用了全资域名，在转发消息给灵敏-主机时，通过不从信封地址上删除域名就可以避免这个问题。然而，仍有某些UUCP站点不属于任何域。它们通常通过附加伪域（pseudo-domain）uucp来进行域名化。 13.5 路径别名和映射文件格式
路径别名数据库在基于UUCP的网络中提供了主要路由选择信息。一个典型的条目看上去象这样（站点名和路径用制表符分开）： moria.orcnet.org ernie!bert!moria!%s
moria ernie!bert!moria!%s 这使得到moria的任何消息被通过ernie和bert进行投递。如果邮件程序没有在这些名字之间映射的独立方法，moria的全资名称和它的UUCP名字就都必须给出。
如果你想把发到某个域中主机的所有消息定向到它的邮件中继，你也需在路径别名数据库中指定一个路径，给出域名作为目标，域名前放置一个点。例如，如果在sub.org中的所有主机可以通过swim!smurf到达，那么路径别名就看上去象这样： .sub.org swim!smurf!%s 仅当你运行的是一个没有很多路由选择的站点时，编写一个路径别名文件才是可行的。如果你要为大量的主机进行路由选择的话，那么更好的方法是使用pathalias命令从映射文件中创建这个文件。映射能够很容易地维护，因为通过编辑系统的映射条目，你可以很容易地加入和移去一个系统，并重新创建映射文件。尽管由Usenet Mapping Project发布的映射不再用于路由选择，更小的UUCP网络仍可以在他们自己的映射集中提供路由选择信息。
一个映射文件主要是由站点的列表组成，列出每个系统查询和被查询的站点。系统名字从第一列开始，后跟用逗号分开的链接列表。列表可以跨行继续如果下一行以一个制表符开始。每个链接由站点名后跟一个用括号括住的代价组成。代价是一个算术表达式，由数字和符号代价构成。以hash符号开始的行将被忽略。
作为一个例子，考虑moria，它每天查询swim.twobirds.com两次，每星期查询bert.sesame.com一次。更有甚者，到bert的链接只使用一个低速2400bps的modem。Moria会发布下面的映射条目： moria.orcnet.org
bert.sesame.com(DAILY/2),
swim.twobirds.com(WEEKLY+LOW) moria.orcnet.org = moria 最后一行也使得它在它的UUCP名字下已知。注意，它必须是DAILY/2，因为每天呼叫两次实际上将这个连接的代价减半。
使用pathalias这样的映射文件中的信息可以计算出到达列于路径文件中任何目的站点的优化路径，并产生一个路径别名数据库，然后这个数据库可以用于到这些站点的路由选择。
pathalias还提供了象站点隐藏（也即，让站点只能通过网关来访问）等几个特性。详细信息和链接代价列表请参见pathalias手册页。
映射文件中的注释通常含有所描述站点的额外信息。注释有一固定的格式，所以这些信息可以从映射文件中抽取出来。例如，一个称为uuwho的程序使用从映射文件创建的数据库用精细格式化的方式来显示这些信息。
当你在会给自己的会员发布映射文件的组织登记你的站点时，通常你要填写这样一个映射条目。
下面是一个映射条目的样本（实际上，它是我的站点）： #N monad, monad.swb.de, monad.swb.sub.org
#S AT 486DX50; Linux 0.99
#O private
#C Olaf Kirch
#E okir@monad.swb.de
#P Kattreinstr. 38, D-64295 Darmstadt, FRG
#L 49 52 03 N / 08 38 40 E
#U brewhq
#W okir@monad.swb.de (Olaf Kirch); Sun Jul 25 16:59:32 MET DST 1993
#
monad brewhq(DALLY/2)
# Domains
monad = monad.swb.de
monad = monad.swb.sub.org 在头两个字符后面的空间是个制表符TAB。大多数字段的意思都是很显然的；你会从你注册的域那里收到详细的说明。L字段是非常有趣的：它以经纬度给出了你的地理位置用于画出显示每个国家所有站点的地图以及全世界的地图来。[5] 13.6 配置elm
elm代表“电子邮件”（“electronic mail”）的意思，是非常合理命名的UN*X工具之一。它提供了一个全屏幕界面并有一个很好的帮助特性。这里我们不讨论如何使用elm，而是详细叙述它的配置选项。
理论上讲，无须配置你就可以运行elm，并且样样工作的都很好 --- 如果你幸运的话。但是有几个选项是必须配置的，尽管只是有必要而已。
当elm开始运行时，它从/usr/lib/elm/中的elm.rc文件里读取一族配置变量。然后，它将试图在你的主目录中读取文件.elm/elmrc。这个文件一般不是你自己写的。它是当你从elm的选项菜单中选择了“save options”时被创建的。
私有elmrc文件的选项集也存在于全局elm.rc文件中。你的私有elmrc文件中的许多选项将覆盖全局文件中对应的选项。 13.6.1 全局elm选项
在全局elm.rc文件中，你必须设置属于你的主机名的选项。例如，在虚拟酿酒厂，vlager的这个文件将含有下面信息： #
# The local hostname
hostname = vlager
#
# Domain name
hostdomain = .vbrew.com
#
# Full quallified domain name
hostfullname = vlager.vbrew.com 这些选项设置elm的本地主机名的概念。尽管这个信息很少用到，但是你应该设置这些选项。注意，这些选项只有在全局配置文件中才有效；当存在于私有的elmrc中时，它们将被忽略掉。 13.6.2 国家字符集
近来，已有提议对RFC 822标准进行修正以支持各种类型的报文，比如无格式文本（plain text）、二进制数据、Postscript文件等等。有关这些方面的标准集和RFCs通常称为MIME，或多用途互连网邮件扩展（Multipurpose Internet Mail Extensions）。在其它方面，这也使得接收者在写报文时知道是否使用了非标准ASCII码，例如，使用法语重音符或德语变音符号。elm在某些程度上支持这些扩展。
Linux内部用来表示字符所使用的字符集通常称为ISO-8859-1，这是它所遵守的标准的名字。它也以Latin-1知名。任何使用这个字符集的报文应该在标题部分有下面这一行： Content-Type: text/plain; charset=iso-8859-1 接收系统会识别出这个字段并在显示信息时采取一定的措施。text/plain信息的默认值是一个值为us-ascii的charset。
为了显示非ASCII字符集的信息，elm必须知道如何打印这些字符。默认地，当elm接收到charset字段为非us-ascii（或者conten type不是text/plain）的信息时，它试着使用称为metamail的命令来显示信息。需要使用metamail来显示的信息在观察窗口的第一列显示一个‘M’。
由于Linux的本身的字符集是ISO-8859-1，调用metamail使用这个字符集来显示信息是不必要的。如果elm被告知显示能够理解ISO-8859-1，它就不会使用metamail，而是直接显示信息。这可以通过在全局elm.rc中设置下面选项来做到： displaycharset = iso-8859-1 注意，即使当你从不会发送和接收含有任何非ASCII的信息，你也应该设置这个选项。这是因为人们确实发送这样的信息时通常会配置他们的邮件程序将适当的Content-Type:字段默认地放入邮件的标题中，而不管他们是否只发送ASCII信息。
然而，在elm.rc中设置这个选项还不够。问题是当用它内建的分页程序显示信息时，elm针对每个字符调用一库函数来确定该字符是否可打印的。缺省地，这个函数将只能识别ASCII字符为可打印字符，并将所有其它字符显示为“^?”。你可以通过设置环境变量LC_CTYPE为ISO-8859-1来克服这个问题，该变量告知库函数接受Latin-1字符为可打印的。库从libc-4.5.8起支持这个和其它特性。
当发送含有ISO-8859-1中特殊字符的信息时，你应该确信在elm.rc文件中设置了起码两个变量： charset = iso-8859-1
textencoding = 8bit 这使得elm在邮件标题中报告字符集是ISO-8859-1，并将它作为8比特值来发送（缺省的是将所有字符剥成7比特）。
当然，这些选项中的任何一个除了可以在全局elm.rc文件中设置以外，都可以在私有elmrc文件中设置。 
注释
[1] 通常习惯上会给邮件消息附加上一个签名（signature）或.sig，通常包含有关作者的信息，以及一个笑话或者一座右铭。它与邮件消息之间相隔一含有“--”的一行。
[2] 这是因为磁盘空间的分配通常是以1024字节的块为单位的。所以，即使一个最多400字节的消息也要吃掉整整一KB的空间。
[3] 当从一个RFC 822环境试图到达一个DECnet地址时，你可以使用“host::user”@relay，这里relay是一个已知的Internet-DECnet中继。
[4] 在UUCP映射计划登记的站点的映射是通过新闻组comp.mail.maps发布的；其他的组织也会公布他们网络的映射。
[5] 它们定期地投递到news.lists.ps-maps。注意，它们非常巨大。

北南南北 · 发表于 2002-4-24 11:18:15

Linux网络管理员手册(14)

第十四章配置和运行smail 这一章将给你一个设置smail的快速入门，以及它所提供的功能概述。尽管smail的行为在很大程度上与sendmail相兼容，但是它们的配置文件却是完全不同的。
主要的配置文件是/usr/lib/smail/config。你一定要编辑这个文件以反映你的站点的特定的值。如果你只是一个UUCP的末端站点（leaf site），那么相应地你很少需要改动的。配置路由选择和传输选项的其它文件当然也可以使用；这些文件也将概要地论及。
缺省地，smail会立刻处理并分发所有入站的邮件。如果你有相应较大的流量，你可以先让smail将信息收集到所谓的队列（queue）中，并且仅在一定的间隔期间来处理它们。
当在TCP/IP网络上处理邮件时，smail会以后台模式（daemon mode）频繁地运行：在系统引导启动时，它是从rc.inet2被调用的，并且将自己置入后台以等待SMTP端口（通常是端口25）进入的TCP连接。当你可能会遇上较大信息流量时，这是非常有用的，因为smail不会针对每个入站连接而立即运行的。另外一种方法是让inetd来管理SMTP端口，并且每当这个端口有连接时，由它来调用smail。
smail有许多标志以控制自己的行为；在此详细讨论它们对你并不会有太大的帮助。幸运的是，smail支持一些标准的操作模式，当你通过一特定的命令名调用smail时这些模式会开启，如rmail和smtpd。通常，这些别名本身是对smail执行文件的符号连接。在讨论smail的各种特性时我们会遇到其中大多数特性。
在所有环境下，你应该有两个到smail的连接；它们是/usr/bin/rmail和/usr/sbin/sendmail。[1] 当你使用一个用户代理程序（如elm）撰写和发送一个邮件信息时，该邮件信息将输送给rmail去进行投递，而接收者列表要在命令行上给出。对于通过UUCP接收的邮件也会有同样的情况。然而，elm的某些版本会调用/usr/sbin/sendmail而不是rmail，所以你需要它们两者。例如，如果你将smail放在/usr/local/bin中，那么在shell提示下键入下面两行： # ln –s /usr/local/bin/smail /usr/bin/rmail
# ln –s /usr/local/bin/smail /usr/sbin/sendmail 如果你想更深入地研究配置smail的细节，请参阅手册页smail(1)和smail(5)。如果它没有包括在你中意的Linux发行版本中，你可以从smail的源程序中得到。 14.1 UUCP的设置
要想在只有UUCP的环境下使用smail，基本的安装过程是非常简单的。首先，你必须确信你已经有了上面所提到的两个符号连接rmail和sendmail。如果你还希望从其它站点接收到SMTP批处理信息，你也需要设定rsmtp为一个到smail的连接。
在Vince Skahan的smail发行版中，你会找到一个样本配置文件。它被命名为config.sample并存在于/usr/lib/smail中。你必须拷贝它到config并且编辑它以适用于你的站点。
假设你的站点名称是swim.twobirds.com，并在UUCP映射中以swim登记注册。你的灵敏主机是ulysses。此时你的config文件应该看上去象这样的： #
# Our domain names
visible_domain=two.birds:uucp
# Our name on outgoing mails
visible_name=swim.twobirds.com
#
# Use this as uucp-name as well
uucp_name=swim.twobirds.com
#
# Our smarthost
smart_host=ulysses 第一条语句告知smail有关你的站点所属的域。在这里插入它们的名字并用冒号分开。如果你的站点名在UUCP映射中注册过，那么你也应该加上uucp。在处理一个邮件消息时，smail使用hostname(2)系统调用来确定你的主机的名字，并且将接收者的地址和这个主机名作比较检查，依次添加上这个列表中的所有名字。如果该地址与这些名字或非正规主机名中的任何一个相匹配时，接收者就被认为是本地的，并且smail将试图将这个消息投递给本地主机上的一个用户或别名。否则的话，接收者被认为是远程的，并开始尝试投递到目的主机去。
visible_name应该含有单个、用于出站邮件上的你的站点的全资域名。当在所有出站邮件上生成发送者的地址时，将使用这个名字。你必须确信使用了一个smail能够识别为代表本地主机的名字（也即，列于visible_domain属性中域之一的主机名）。否则的话，对你的邮件作出的回复将弹出你的站点。
最后一条语句设置用于灵敏主机路由选择的路径（已在13.4节中作了描述）。对于这个样本设置，smail会把所有到远程地址的邮件转发给灵敏主机。由于消息将通过UUCP来投递，该属性必须指定一个你的UUCP软件认识的系统。请参阅第12章的让站点为UUCP知晓。
还有一个上面文件中用到的选项我们至今还没给出解释；这就是uucp_name。使用这个选项的理由是：默认地，smail使用hostname(2)返回的值给UUCP方面使用，比如在From_标题行中给出的返回路径。如果你的主机名没有在UUCP映射计划组注册过，你应该告诉smail另外使用你的全资域名取代之。[2] 这可以在config文件中加入uucp_name选项来做到。
在/usr/lib/smail中还有一个文件，叫paths.sample。它是paths文件的一个例子。然而，除非你有到多于一个站点的邮件连接，否则的话你并不需要它。如果你确实有多个邮件连接，你就需要自己写一个这个文件，或者从Usenet映射中生成一个。paths文件将在本章稍后讨论。 14.2 为局域网（LAN）进行设置
如果你正运行一个站点，具有两台或以上的主机构成了一个LAN，那么你就必须指定一台主机来处理你的UUCP与外部世界的连接。在你的LAN上的主机之间，你很可能会用SMTP在TCP/IP上交换邮件。假设我们现在再次回到虚拟酿酒厂，而且vstout被设置成为UUCP的网关。
在一个连网的环境中，最好将所有用户的邮件箱放在单个文件系统上，这个文件系统在所有其它主机上可以以NFS加载的。这允许用户从一台机器换到另一台机器，而不需要将他们的邮件带来带去（或者更糟的是，每天早晨检查三四台机器看看有没有新到的邮件）。因此你也希望发信者的地址是与编写邮件的机器无关的。在发信者的地址中一直使用域名而非主机名，就是一个非常实际有用的方法。例如，Janet用户将指定地址为janet@vbrew.com而不是janet@vale.vbrew.com。下面我们将解释如何让服务器将域名识别为一个你的站点的有效名字。
将所有邮件箱保持在一台中央主机上的另一种不同的方法是使用POP或者IMAP。POP代表邮局协议（Post Office Protocol）它能让用户通过一简单TCP/IP连接访问他们的邮件箱。IMAP，交互式邮件访问协议（Interactive Mail Access Protocol），与POP类似，但更通用。IMAP和POP的客户以及服务器程序都已经移植到Linux上，可以从sunsite.unc.edu中的/pub/Linux/system/Network下取得。 14.2.1 编写配置文件
酿酒厂的配置是按如下方式工作的：除了邮件服务器vstout本身的所有主机使用灵敏主机路由选择将所有出站邮件传递给服务器。vstout本身则将所有出站邮件发送给用以传递所有酿酒厂邮件的真正灵敏主机；这个主机叫作moria。
除了vstout，所有其它主机的标准config文件看上去象这样： #
# Our domain:
visible_domain=vbrew.com
#
# Whaat we name ourselves
visible_name=vbrew.com
#
# Smart-host routing: via SMTP to vstout
smart_path=vstout
smart_transport=smtp 这同我们用于UUCP站点的非常相似。主要的不同之处是用于发送邮件到灵敏主机的传输是SMTP。visible_domain属性使得smail在所有出站邮件上使用域名来代替本地主机名。
在UUCP邮件网关vstout上，config文件看上去稍有不同： #
# Our hostnames:
hostnames=vbrew.com:vstout.vbrew.com:vstout
#
# What we name ourselevs
visible_name=vbrew.com
#
# in the uucp world, we’re known as vbrew.com
uucp_name=vbrew.com
#
# Smart transport: via uucp to moria
smart_path=moria
smart_transport=uux
#
# we’re authoritative for our domain
auth_domains=vbrew.com 这个config文件使用了一个不同的方案来告诉smail本地主机叫什么。不是给它一个域列表并让它使用一个系统调用来找出主机名，而是明确地给出了一个列表。上面的配置本身含有全资和自由的主机名（fully qualified and the unqulified hostname），以及域名。这使得smail能将janet@vbrew.com识别为一个本地地址，并将消息投递给janet。
auth_domains变量命名一个域，对于这个域，vstout被认为是授权的。也即，在smail接收到任何到地址host.vbrew.com的邮件时，如果其中的host不是任何本地机器的名字，那么它就会拒绝这个邮件消息并将它返回给发信者。如果没有这个条目，那么任何这样的消息都将被送到灵敏主机，而灵敏主机将把它返回给vstout，一直这样循环下去直到该消息由于超过最大跳数而被丢弃。 14.2.2 运行smail
首先，你要决定是否将smail作为一个独立的后台程序（daemon）运行，或者是让inetd管理SMTP端口并且仅当某些客户请求一个SMTP连接时才调用smail。通常，在邮件服务器上，你将更喜欢后台程序操作的方式，因为这样不会对每个单独的连接不停地产生smail子进程而增加机器的负荷。由于邮件服务器也将大多数入站邮件直接投递给用户，在许多其它主机上你将选择inetd的操作方式。
对每台单独的主机，不管你选择了哪种操作模式，你必须确信在/etc/services文件中有下面的条目： smtp 25/tcp # Simple Mail Transfer Protocol 这定义了smail用于SMTP连接的TCP端口号。25是定义于Assigned Numbers RFC中的标准端口号。
当运行于后台模式时，smail将把自己放入后台，并且等待发生在SMTP端口的连接。当出现一个连接时，它用对等进程产生并引导一个SMTP对话。smail后台程序通常是使用下面命令通过从rc.inet2脚本中被调用而启动的： /usr/local/bin/smail –bd –q15m -bd标志打开后台模式，-q15m使得它每隔15分钟就处理一次堆积在队列中的消息。
如果你想另外使用inetd方式，那么你的/etc/inetd.conf文件中应该含有象这样的一行： smtp stream tcp nowait root /usr/sbin/smtpd smtpd smtpd应该是一个到smail执行文件的符号链接。记住，在作过改变之后你必须给它发送一个HUP信号让inetd重读inetd.conf。
后台模式（Daemon mode）和inetd模式是相互排斥的。如果你以后台模式运行了smail，你应该确信注释掉了inetd.conf中任何smtp服务的行。同样地，当让inetd管理smail时，请确信rc.inet2没有启动smail后台程序。 14.3 如果你没有顺利完成___
如果你在安装时碰到了问题，有几个特征可能可以帮助你找出问题的根源。第一个需要检查的地方是samil的日志文件。它们是放在/var/spool/smail/log中的，名字分别为logfile和paniclog。前者列出了所有事项，而后者仅用于存储与配置错误等相关方面的出错信息。
logfile中的典型条目看上去象这样的： 04/24/94 07:12:04: [mOpuwU8-00023UB] received
| from: root
| program: sendmail
| size: 1468 bytes
04/24/94 07:12:04: [mOpuwU8-00023UB] delivered
| via: vstout.vbrew.com
| to: root@vstout.vbrew.com
| orig-to: root@vstout.vbrew.com
| router: smart_host
| transport: smtp 这显示出从root到root@vstout.vbrew.com的消息已经通过SMTP正确地投递到主机vstout上去了。
smail不能投递的消息在日志文件中也产生类似的条目，但是用一错误信息取代了delivered部分： 04/24/94 07:12:04: [mOpuwU8-00023UB] received
| from: root
| program: sendmail
| size: 1468 bytes
04/24/94 07:12:04: [mOpuwU8-00023UB] root@vstout.vbrew.com … deferred
(ERR_148) transport smtp: connect: Connection refused 上面的错误对于smail已能正确地识别出消息应该投递到vstout但是却连不到vstout上的SMTP服务的情况是一种典型的错误。如果发生了这种情况，你或者是有个配置问题，或者是因为你的smail执行程序不支持TCP。
这个问题并没有人们想象的那么特殊。存在着很多已经编译好的smail执行程序都不支持TCP/IP连网，甚至是在某些Linux发行版中。如果你碰到的是这种情况，你就必须自己编译smail。如果已经安装了smail，你可以通过telnet远程登录到你的机器的SMTP端口来检查它是否支持TCP连网。到SMTP服务的一个成功连接如下面显示的（你的输入用这样表示的）： $ telnet localhost smtp
Trying 127.0.0.1…
Connected to localhost.
Escape character is ‘^]’.
220 monad.swb.de Smail3.1.28 #6 ready at Sun, 23 Jan 94 19:26 MET
QUIT
221 monad.swb.de closing connection 如果这个测试没有产生SMTP标题（以220码开头的行），首先在你自己进行smail编译之前确信你的配置是确实正确的，这在下面讨论。
如果你使用smail遇到了一个问题，而且从smail产生的出错信息不能确定问题的所在，那么你可以开启调试信息功能。你可以使用-d标志来做到，后跟一个指定调试信息长度的数字选项（在标志和数字之前可以不加空格）。smail将在屏幕上打印出它的操作报告，这可能会给你更多有关出错的线索。
[不知道，…人们可能不会觉得这有趣：] 如果一点也没帮助，你可能想要通过在命令行上给出-bR选项以Rogue模式调用smail。关于这个选项手册页说：“往敌方域发送巨量的邮件信息，以及RFC标准的资料。试图让它下到协议层26然后返回。”尽管这个选项不能解决你的问题，它可能为你提供某些舒适度和安慰。[3] 14.3.1 编译smail
如果你确实认为你的smail还没有TCP网络支持，你就必须取得源码。如果你是从CD-ROM中得到的，那么一般它是包括在你的发行版中的，否则的话你可以从网上FTP站点获得。[4]
当编译smail时，你最好用从Vince Skahan的newspak发行版的配置文件集开始。为了用TCP网络驱动程序编译，你必须设置conf/EDITME文件中的DRIVER_CONFIGURATION宏为bsd-network或arpa-network。前者适用于LAN的安装，但是Internet需要arpa-network。这两者的不同之处在于后者是能够识别MX记录的BIND服务专用的驱动程序，而前者却不是。 14.4 邮件投递模式
正如上面提到的，smail能够立刻将消息投递出去，或者排入队列稍后再作处理。如果你选择将消息排入队列，smail将把所有的邮件存储在/var/spool/smail目录下。smail不会去处理这些邮件直到明确地告知它去处理（这也称为“运行该队列（running the queue）”）。
通过在config文件中设置delivery_mode属性为foreground、background或queued，你可以选择三种投递模式之一。这将投递模式选择为前台的（对入站消息进行立即处理）、后台的（消息将有接收进程的子进程进行投递，而父进程则会在派生了子进程后立即退出）、以及排队的。如果config文件中设置了布尔变量queue_only，那么不管这个选项怎么设置，入站邮件将总是被排入队列中。
如果你打开了排队选项，你必须确信队列会被定期检查；一般是每个10或15分钟。如果你以daemon模式运行smail，你就必须在命令行上加上选项-q10m用以每隔10分钟处理一次队列。另外，你可以以这些间隔时间从cron来调用runq。runq应该是一个到smail的链接。
你可以通过用选项-bp来调用smail来显示当前的邮件队列。同样地，你可以作一个到smail的链接mailq，并调用mailq： $ mailq –v
mOpvB1r-00023UB From: root (in /var/spool/smail/input)
Date: Sun, 24 Apr 94 07:12 MET DST
Args: -oem –oMP sendmail root@vstout.vbrew.com
Log of transactions:
Xdefer: reason: (ERR_148) transport smtp;
connect: Connection refused 这显示了消息队列中的一个消息。事项日志（仅在你给mailq一个-v选项时才会显示）可能会给出为什么还在等待投递的额外原因。如果至今都没有试图投递这个消息，那么将不显示事项日志。
即使你不使用队列，那么当smail发现由于短暂的原因立即投递失败时偶然也会将消息放入队列中。对于SMTP连接来说，这可能是一个不可达的主机；但是当文件系统满时消息也会被延期投递的。因此你应该放置一个队列并且每隔1小时左右运行处理队列一次（使用runq），否则的话，任何延期的消息都将永远待在队列中了。 14.5 各种其它config选项
还有许多可以在config文件中设置的选项，这些选项尽管很有用，但对运行smail并不是必须的，所以我们在这里不讨论它们。而是仅提及几个你可能由于某种原因会使用的选项： error_copy_postmaster
如果设置了这个布尔变量，任何错误都会产生一条给邮件管理者的消息。通常，这样做只是为了检测配置中的错误。通过将它放入config文件，并在前面放一个加号（+）来开启这个功能。 max_hop_count
如果一个消息的跳数（也即，经过的主机数目）等于或超过这个数字时，在远程投递消息的企图将产生一个错误信息并被返回给发送者。这是用于防止消息不停地循环传输。跳数的计数一般是从邮件标题中的Received:字段的个数计算出的，但是也可以在命令行上使用-h选项手工设置的。
这个变量的缺省值是20。 postmaster 邮件管理者的地址。如果Postmaster不能解析成一个有效的本地地址，那么作为最后的手段。缺省值是root。 14.6 消息（报文）路由选择和投递
smail将邮件的投递分成了三个不同的任务，路由器、导向器和传输器模块（router，director，transport module）。
路由器模块用于解析所有远程地址，确定消息将被送到下一台哪台主机，以及必须使用哪种传输器。根据链接的特性，将使用不同的传输器，比如UUCP或SMTP。
本地地址将给予导向器任务，用于解析任何转发和别名使用。例如，地址可能是一别名或一个邮件列表，或者用户可能想将她的邮件转发到另外一个地址。如果所得到的地址是远程的，它将被传送给路由器模块进行额外的路由选择，否则的话它将进行本地投递传输。到目前为止，最普通的情况是投递到一个邮件箱中，但消息也可能被传送给一个命令，或者是附加到某些任意的文件中。
最后，传输器模块负责选择投递的方法。它试图投递这个消息，并且如果失败就将消息弹回，或将消息延迟投递。
使用smail，在配置这些任务时你有很大的自由度。对于每个任务，有许多驱动程序，你可以从中选取你所需的。要使用几个文件来向smail描述它们，它们是位于/usr/lib/smail中的routers、directors和transports。如果这些文件不存在的话，那么将采用合理的默认值，这些默认值对于使用SMTP或UUCP传输的许多站点来讲都是合适的。如果你想改变smail的路由选择策略，或者要修改某个传输，你应该从smail的源发行版中取得样本文件[5]，将样本文件拷贝到/usr/lib/smail目录下，并且按照你的需要来修改它们。在附录B中也给出了样本配置文件。 14.7 消息（报文）的路由选择
当给出一个消息，smail首先会检查它的目的地是否是本地的，还是一远程站点。如果目标主机地址是config中配置的本地主机名之一，就将消息传送到导向器模块。否则的话，smail将把目的地址送到一系列路由器驱动程序以找出将消息转发到的主机。可以在routers文件中对它们进行描述；如果这个文件不存在的话，就会使用一族缺省值。
接下来目的主机（名）将传给所有的路由器，并且将选择找到最为确定路由的路由器。考虑一个到joe@foo.bar.com的消息。那么，某个路由器可能知道一个到bar.com域中所有主机去的缺省路由，而另一个路由器却有foo.bar.com本身的信息。由于后者更为确切，就会选择后者。如果有两个路由器都提供了“最佳匹配”，那么就会选择routers文件中先出现的那个。
现在，这个路由器指定所使用的传输器，比如UUCP，并且生成一个新的目的地址。这个新的地址与主机（名）一起传给这个传输器以将消息转发过去。在上面的例子中，smail可能会发现通过使用路径ernie!bert的UUCP可以到达foo.bar.com。此时它会产生一个新的目标bert!foo.bar.com!user，并且让UUCP传输器将此目标用作信封地址传送到ernie。
当使用缺省设置时，就有下列路由器： &#61548; 如果目的主机地址可以使用gethostbyname(3)或者gethostbyaddr(3)库调用解析出来，那么消息就会用SMTP进行投递。唯一的例外是，如果发现该地址引用（涉及）到本地主机，那么消息也会被传到导向器模块。
smail也能识别点分四组写的IP地址作为一个合法的主机名，只要它们能够使用gethostbyaddr(3)调用来解析。例如，scrooge@[149.76.12.4]将是一个有效的地址，尽管在quark.physics.groucho.edu上这是一个非常与众不同的邮件地址。
如果你的机器是在Internet上的，那么这些路由器就不是你所要的，因为它们不支持MX记录。对于这种情况请看下面。 &#61548; 如果路径别名数据库/usr/lib/smail/paths存在，那么smail将试图在这个文件中查找目标主机（减去任何.uucp的结尾）。邮递到这个路由器匹配的地址去的邮件将使用UUCP和数据库中找到的路径来投递。 &#61548; 主机地址（去除任何.uucp结尾）将与uuname命令的输出相比较，以检查目标主机实际上是否是一个UUCP邻居。如果真是这种情况，那么消息将使用UUCP传输器投递。 &#61548; 如果地址用上面任何一个路由器都不能匹配的话，那么它将被投递到灵敏主机。到灵敏主机的路径以及所使用的传输器是在config文件中设置。 这些缺省设置对于许多简单设置来说是可工作的，但是如果路由选择的要求稍微复杂一些时就会失败。如果你面临下面描述的任何问题，那么你就需要安装你自己的routers文件以覆盖缺省的文件。附录B中给出了一个样本routers文件，你可以以它作为开始。某些Linux发行版也携带有一族配置文件，它们被编辑成克服这些困难的。
当你的主机有着双重的拨号IP和UUCP链接时，或许会产生最糟糕的问题。此时在你的hosts文件中有着你仅通过SLIP链接很少论及的主机名，所以smail将试图通过SMTP为这些主机投递任何邮件。这通常并不是你想要的，因为即使SLIP链接是定期激活的，SMTP要比通过UUCP发送邮件慢得多。对于使用缺省设置的情况，没有任何方法来逃避smail的。
通过在查询解析器之前让smail检查paths文件，你就可以避免这个问题，并且将所有你想迫使UUCP投递到的主机放入paths文件中。如果你再也不想通过SMTP发送任何消息，那么你也可以完全注释掉基于解析器的路由器。
另一个问题是缺省的设置并不是为真正的Internet邮件路由选择提供的，因为基于解析器的路由器没有估计（evaluate）MX记录。为了启用对Internet邮件路由选择的全面支持，注释掉这个路由器，并且去掉对使用BIND的路由器的注释。然而，包含在某些Linux发行版中的samil执行程序并没有编译进对BIND的支持。如果你启用BIND，但却在paniclog文件中得到一个信息指出“路由器inet_hosts：驱动程序bind没有找到”（“router inet_hosts: driver bind not found”），那么你就必须取得源代码并重新编译smail（见上面14.2节）。
最后，使用uuname驱动程序一般并不是一个好主意。首先是当你没有安装UUCP时，它将会产生一个配置错误，因为会找不到uuname命令。其次是当你有比实际有邮件链接多的站点列于你的UUCP Systems文件时。这些可能是你仅仅进行news交换的站点、或者是你偶尔使用匿名UUCP下载文件的站点，但除此以外没有任何交通流量了。
为了解决第一个问题，你可以用只做一简单exit 0的shell脚本来替换uuname。然而，更加常规的解决方案是编辑routers文件并且完全删除这个驱动程序。 14.7.1 paths数据库
smail期望在/usr/lib/smail下的paths文件中找到路径别名数据库（pathalias database）。而这个文件是可选的，所以如果你完全不需要执行任何路径别名路由选择的话，只需简单地删除任何存在的paths文件。
paths必须是一个排过序的ASCII文件，包含有映射目的站点名到UUCP bang paths的条目。因为smail使用二叉树搜索来查找一个站点，所以这个文件必须是排过序的。文件中不得含有注释，并且站点名与路径之间必须用制表符TAB分开。路径别名数据库已在第13章中详细讨论过。
如果这个文件是你自己编写的，你应该确信其中包含了一个站点的所有合法的名称。例如，如果一个站点已知有无格式UUCP名称和一个全资域名（fully qualified domain name），那么你就必须为这两个名字都加入一个条目。可以通过将此文件传给sort(1)命令来排序这个文件。
然而，如果你的站点仅仅是个页站点（a leaf site），那么就完全不需要paths文件；只要在你的config文件中设置灵敏主机属性，并让你的邮件馈送者来处理所有的路由选择。 14.8 往本地地址投递消息（报文）
非常一般地，一个本地地址只是一个用户的登录名，在这种情况下，消息被投递到她的邮件箱中，/var/spool/mail/user。其它的情况包括别名和邮件列表名、以及用户作的邮件转发。在这些情况下，本地地址被扩展成一个新的地址列表，这个新地址列表或者是本地的，也可能是远程的。
除了这些“普通的“地址以外，smail还可以处理其它本地消息目的的类型，象文件名和管道命令。这些本身并不是地址，所以你不可以将邮件发送到/etc/passwd@vbrew.com这样的地址去；仅当它们是从转发和别名文件中取得时，它们才是有效的。
一个文件名（file name）是以斜杠（/）或破折号（~）开始的任何字符串。后者表示用户的主目录，而且仅当文件名是从一个.forward文件或从一个在邮件箱（见下面）的转发条目中取得时才是可能的。当投递到一个文件时，smail将消息附加到这个文件上，必要时就创建这个文件。
一个pipe命令可以是前面加有管道符号（|）的任何UN*X命令。这使得smail将命令及其参数传递给shell，但是不包括前导‘|’。消息本身在标准输入上被馈送给这个命令。
例如，为了将邮件列表送入一个本地新闻组（newsgroup）中，你可以使用一个名为gateit的shell脚本，并且设置一个本地别名，这个别名会使用“—gateit”从这个邮件列表中投递所有的消息。
如果引用中包括有空格，就必须使用双引号包住。由于所涉及的安全因素，如果地址是以某些不可靠的方法获得的（例如，如果从中获取地址的别名文件是任何人可写的），就要避免执行这个命令。 14.8.1 本地用户
一个本地地址最普通的情况是表示一个用户的邮件箱。这个邮件箱位于/var/spool/mail中并且具有这个用户的名字。它是属于这个用户的，并有组名mail和属性600。如果它不存在，smail就会创建它。
注意，尽管/var/spool/mail目前是放置邮件箱文件的标准位置，某些邮件软件可能编译进了不同的路径，例如/usr/spool/mail。如果往你机器上的用户进行投递一直会失败，你应该试着作一个到/var/spool/mail的符号链接。
smail要求有两个地址存在：MAILER-DAEMON和Postmaster。当为一个不能投递的邮件产生一个反弹消息时，一个副本将被发送给postmaster帐号以作检查（以防万一这可能是由于配置方面的问题）。MAILER-DAEMON是在反弹消息上作为发送者地址的。
如果这些地址在你的系统上并没有有效的帐号，smail分别隐含地将MAILER-DAEMON映射到postmaster、postmaster到root。通常你应该通过为postmaster帐号建立别名来覆盖这个映射，将别名建立到负责维护邮件软件的用户去。 14.8.2 转发
用户可以使用smail支持的两种方法之一通过将邮件转发到另外一个地址来重定向她的邮件。一种选择是将 Forward to recipient，… 放在她的邮件箱文件的第一行。这会把所有入站的邮件发送到指定的接收者列表去。另一种方法是，她可以在她的主目录中建立一个.forward文件，该文件含有用逗号分开的接收者列表。对于各类转发，该文件的各行将被读取并作出说明。
注意，可以使用任何类型的地址。因此，对于休假的.forward文件的一个实际例子可以是 janet, “|vacation” 第一个地址不管怎样将会把入站消息投递到janet的邮件箱中，而vacation命令则会给发送者返回一个简短的通告。 14.8.3 别名文件
samil能够处理那些与Berkeley的sendmail兼容的别名文件。在别名文件中条目可以有如下的形式 alias: recipients recipients是一个用逗号分开的地址列表，它将被别名替代。接收者列表可以续行如果下一行以一个制表符开始。
有一个特殊的属性，允许smail从别名文件中来处理邮件列表：如果你指定“:include:filename”作为接收者，smail将读取指定的文件，并且替换它的内容作为一个接收者的列表。
主要的别名文件是/usr/lib/aliases。如果你选择使得这个文件是人人可写的，smail将不会把任何消息投递给该文件给出的shell命令。一个例子文件见如下所示： # vbrew.com /usr/lib/aliases file
hostmaster: janet
postmaster: janet
usenet: phil
# The development mailing list.
Development: joe, sue, mark, biff
/var/mail/log/development
owner-development: joe
# Announcements of general interest are mailed to all
# of the staff
announce: :include: /usr/lib/smail/staff,
/var/mail/log/announce
owner-announce: root
# gate the foobar mailing list to a local newsgroup
ppp-list: “|/usr/local/lib/gateit local.lists.ppp” 在投递给从aliases文件中产生的一个地址去时如果出现了一个错误，smail将试图把出错消息的一个拷贝发送到“别名拥有者”（“alias owner”）。例如，在把一个消息投递给development邮件列表时，如果投递给biff失败了，那么一个出错消息的拷贝将被邮递给发送者、以及postmaster和owner-development。如果拥有者的地址不存在，那么就不会生成额外的出错消息。
当投递给文件或者当调用aliases文件中给出的程序时，smail将成为nobody用户以避免任何安全方面的问题。特别是当投递给文件时，这将是非常麻烦的事。例如，在上面给出的文件中，nobody必须拥有这个日志文件并且对其可写，否则向他们进行的投递将会失败。 14.8.4 邮件列表
除了使用aliases文件，邮件列表也可以通过/usr/lib/smail/lists目录中的文件来管理。一个命名为nag-bugs的邮件列表是由lists/nag-bugs文件描述的，它应该含有用逗号分开的组员的地址。列表可以在多行上给出，注释使用hash符号来引出。
对于每个邮件列表，应该存在一命名为owner-listname的用户（或别名）；在解析一个地址时发生的任何错误会向这个用户报告。这个地址在所有出站消息的Sender：标题字段中也用作发送者的地址。 14.9 基于UUCP的传输器
有许多利用UUCP程序集的编译进smail的传输器。在一个UUCP环境中，消息通常通过在下一台主机上调用rmail来传递的，并需要在标准输入上给rmail消息和在命令行上给rmail信封地址。在你的主机上，rmail应该是一个到smail命令的链接。
当把一个消息递给UUCP传输器时，smail将目标地址转换为一个UUCP bang路径。例如，user@host将被转换成host!user。任何存在的‘%’地址操作符都将保留，所以user%host@gateway将转换成gateway!user%host。然而，smail自己不会生成这样的地址。
另一方面，smail可以通过UUCP发送和接收BSMTP批处理。使用BSMTP，一个或多个消息被包裹成单个批处理，这个批处理含有本地邮件程序在一个实际SMTP连接被建立时将发出的命令。BSMTP频繁地使用于存储-转发（例如，基于UUCP的）网络以节约磁盘空间。附录B中的样本transports文件含有一个在一队列目录中能够生成部分BSMTP批处理的配有bsmtp的传输器。以后，使用一个加入适当的HELO和QUIT命令的shell脚本，它们必须被合并入最终的批处理中。
对于指定的UUCP连接，为了启用bsmtp传输器，你必须使用所谓的method文件（详细信息请参阅smail(5)手册页）。如果你仅有一个UUCP链接并且使用灵敏主机路由器，你可以通过将配置变量smart_transport设置成bsmtp而非uux来启用发送SMTP批处理。
要在UUCP上接收SMTP批处理，你必须确信你有解批处理（unbatching）命令，远程站点会将自己的批处理发送到这个命令。如果远程站点也使用smail，那么你需要使得rsmtp为一个到smail的链接。如果远程站点运行sendmail，那么你应该额外地安装一个名为/usr/bin/bsmtp的shell脚本，这个脚本执行一个简单的“exec rsmtp”（符号链接是不能工作的）。 14.10 基于SMTP的传输器
目前smail支持一个SMTP驱动程序以在TCP连接上投递邮件。[6] 在主机名指定为一个能够使用网络软件解析的全资域名，或是用方括号括住的点分四组表示法时，在一单个主机上将消息投递到任何数量的地址去是可以的。通常，由任何BIND、gethostbyname(3)、或gethostbyaddr(3)路由器驱动程序解析的地址都将被投递给SMTP传输器。
SMTP驱动程序通过列于/etc/services中的smtp端口将试图立即连接至远程主机。如果它不能到达，或者连接超时，那么将在以后时间再次尝试投递。
在Internet上的投递，要求到目的主机的路由指定为第13章中描述的route-addr格式，而不是作为一个bang路径。[7]因此，smail将转换user%host@gateway（这里gateway是通过host1!host2!host3到达的）成为源-路由地址<@host2,@host3:user%host@gateway>，这将被作为消息的信封地址发送到host1。要开启这些转换（与内建的BIND驱动程序一起），你必须编辑transports文件中的有关smtp驱动程序的条目。附录B中给出了一个样本transports文件。 14.11 主机名限定（qualification）
有时找出在发送者或接收者地址中指定的无限定的主机名（也即，那些没有域名的主机名）是值得做的。例如，当在两个网络之间进行网关连接时，其中，一个网络要求全资域名。在一个Internet-UUCP中继上，缺省地无限定主机名应该被映射到uucp域。除此之外的其它地址修改都是不可靠的。
/usr/lib/smail/qualify文件告诉smail哪个域名附加到哪个主机名上。qualify文件中的条目由一个从第一列开始的主机名、和后跟的域名组成。以hash符号作为首个非空格字符的行被看作是注释行。各条目是根据它出现的先后次序进行搜索的。
如果qualify文件不存在，那么就完全不会执行任何主机名限定操作。
特殊的主机名*与任何主机名匹配，因而允许你在进入一个缺省的域之前映射所有未提及的主机。它应该仅用于最后一个条目。
在虚拟酿酒厂，所有的主机已被设置成在发送者地址中使用全资域名。无限定接收者的地址被认为是在uucp域中的，所以在qualify文件中只需要一单个条目。 # /usr/lib/smail/qualify, last changed Feb 12, 1994 by janet
#
* uucp 
注释
[1] 依照Linux文件系统标准，这是sendmail新的标准位置。另一个常用的位置是/usr/lib。
[2] 理由是：假设你的主机名是monad，但是并没有在映射中注册。然而，在映射中有一个站点叫做monad，所以每个到monad!root的邮件、甚至是从你的直接UUCP邻居来得邮件，都将被送到另一个monad去了。这对任何人来讲都是令人讨厌的。
[3] 如果你的情绪很坏时就不要使用它。
[4] 如果你是从销售商那里随同Linux发行版买来的，那么依照smail的拷贝条件，你就有资格“以最低的（极小的）运输费”得到源码。
[5] 可以从源目录的samples/generic下面找到缺省的配置文件。
[6] 作者称这种支持为“简单的”。对于smail的将来版本，他们预告了一个完整的能更有效处理的后端程序。
[7] 然而，在Internet中使用路由器是完全不赞成的。取而代之应该使用全资域名。

北南南北 · 发表于 2002-4-24 11:19:02

Linux网络管理员手册(15)
第十五章 Sendmail+IDA 15.1 Sendmail+IDA概述
有人曾说过只有编辑过一个sendmail.cf文件，你才是一个真正的Unix系统管理员。也有人说如果你试图这样编辑两次，那你一定是疯了&#61514;
Sendmail是一个难以置信的功能强大的程序。对大多数人来说它也是不可思义的难学。具有792页长的权威性参考资料（Sendmail，由O’Reilly and Associates出版）的任何程序不可辩驳地会吓跑大多数人。
Sendmail+IDA则不同，它删除了对编辑总是隐晦的sendmail.cf文件的需要并且允许管理人员通过相对简单易懂的称为tables的支持文件来定义与站点有关的路由选择和寻址配置。切换到sendmail+IDA上，可以节约你的许多工作时间和精力。
与其它邮件传输代理相比，使用sendmail+IDA几乎没有什么不可以做的更快和更简单的了。运行常规的UUCP或Internet站点所需的典型工作变得很容易完成。通常非常困难的配置也变得简单，易于建立和维护。
在编写本书的这个时候，当前版本sendmail5.67b+IDA1.5可以通过匿名FTP从vixen.cso.uiuc.edu取得。在Linux下，它的编译不需要任何补丁程序。
对于在Linux下的sendmail+IDA源程序编译、安装和运行所需的所有配置文件包括在newspak-2.2.tar.gz中，该压缩文件可以通过匿名FTP从sunsite.unc.edu的/pub/Linux/system/Mail下载。 15.2 配置文件—概述
传统的sendmail是通过一个系统配置文件进行设置的（典型的是/etc/sendmail.cf或者是/usr/lib/sendmail.cf），这个文件不是与你所见过的任何程序语言相近的。编辑sendmail.cf文件以提供定制的性能可能是一种卑下的经验技巧。
Sendmail+IDA通过将所有配置选项做成句法易于理解的表格驱动方式使得这种痛苦基本上成过时的情况了。这些选项经由源代码提供的制作文件（Makefiles）通过在许多数据文件上运行m4（一个宏处理程序）或者dbm（一个数据库处理程序）来配置的。
sendmail.cf文件仅仅定义了系统缺省的性能。事实上，所有特殊的定制操作是通过很多可选的表格做到的，而不是直接编辑sendmail.cf文件来做的。图15.1中列出了sendmail所有的表格。 mailertable 为远程主机或域定义特殊的性能。
uucpxtable 迫使UUCP邮件投递到具有DNS格式的主机。
pathtable 定义到远程主机或域的UUCP bang-paths。
uucprelays 短路路径别名路径到著名的远程主机。
genericfrom 将内部地址转换成外部世界可见的普通地址。
xaliases 将普通地址转换成有效的内部地址/或将内部地址转换成普通地址。
decnetxtable 将RFC-822地址转换成DECnet形式的地址。 图15.1: sendmail的支持文件。 15.3 sendmail.cf文件
用于sendmail+IDA的sendmail.cf文件不用直接编辑的，而是从一个本地系统管理员提供的m4配置文件中生成的。下面，我们将称它为sendmail.m4。
这个文件含有几个定义和其它一些仅仅是指向进行真正工作表格的连接。一般地，仅需要指明： 。在本地系统上所使用的路径名和文件名。
。用于e-mail目的的站点名称。
。哪个缺省邮件程序（也可以是灵敏主机）是所期望的。 有大量的参数可以被定义，用来设立本地站点的性能或覆盖编译进的配置项目。这些配置选项是在源代码目录中的ida/cf/OPTIONS文件中确定的。
对于最小配置的sendmail.m4文件（具有所有非本地邮件被中继到直接连接的灵敏主机去的UUCP或SMTP）如果不算注释行的话，能够短到只有10或15行。 15.3.1 一个sendmail.m4的例子文件
下面示出了在虚拟酿酒厂的vstout的sendmail.m4文件。vstout用SMTP与酿酒厂局域网上的所有主机对话，而将所有其它目的地的所有邮件通过UUCP发送到它的Internet中继主机moria。 15.3.2 用于sendmail.m4的典型参数
sendmail.m4文件中有几项是一直需要的；其它的可以被省略如果你使用缺省值侥幸成功的话。下面几节详细描述了sendmail.m4例子文件中的每个项。 定义路径的项（Items that Define Paths） dnl #define(LIBDIR,/usr/local/lib/mail)dnl # where all support files go LIBDIR定义了一个目录，在这个目录中，sendmail+IDA期望能找到各个配置文件、
dnl #------------------ SAMPLE SENDMAIL.M4 FILE ------------------
dnl # (the string ‘dnl’ is the m4 equivalent of commenting out a line)
dnl # you generally don’t want to override LIBDIR from the compiled in paths
dnl #define(LIBDIR,/usr/local/lib/mail)dnl # where all support files go
define(LOCAL_MAILER_DEF, mailers.linux)dnl # mailer for local delivery
define(POSTMASTERBOUNCE)dnl # postmaster gets bounces
define(PSEUDODOMAINS, BITNET UUCP)dnl # don’t try DNS on these
dnl #-------------------------------------------------------------
dnl #
define(PSEUDONYMS, vstout.vbrew.com vstout.UUCP vbrew.com)
dnl # names we’re known by
define(DEFAULT_HOST, vstout.vbrew.com) # our primary ‘name’ for mail
define(UUCPNAME, vstout)dnl # our uucp name
dnl #
dnl #-------------------------------------------------------------
define(UUCPNODES, |uuname|sort|uniq)dnl # our uucp neighbors
define(BANGIMPLIESUUCP)dnl # make certain that uucp
define(BANGONLYUUCP)dnl # make is treated correctly
define(RELAY_HOST, moria)dnl # our smart relay host
define(RELAY_MAILER, UUCP-A)dnl # we reach moria via uucp
dnl #
dnl #-------------------------------------------------------------------
dnl #
dnl # the various dbm lookup tables
dnl #
define(ALIASES, LIBDIR/aliases)dnl # system aliases
define(DOMAINTABLE, LIBDIR/domaintable)dnl # domainize hosts
define(PATHTABLE, LIBDIR/pathtable)dnl # paths database
define(GENERICFROM, LIBDIR/generics)dnl # generic from addresses
define(MAILERTABLE, LIBDIR/mailertable)dnl # mailers per host or domain
define(UUCPXTABLE, LIBDIR/uucpxtable)dnl # paths to hosts we feed
define(UUCPRELAYS, LIBDIR/uucprelays)dnl # short-circuit paths
dnl #
dnl #--------------------------------------------------------------------
dnl #
dnl # include the ‘real’ code that makes it all work
dnl # (provided with the source code)
dnl #
include(Sendmail.mc)dnl # REQUIRED ENTRY !!!
dnl #
dnl #------------- END OF SAMPLE SENDMAIL.M4 FILE ------- 图15.2：用于vstout的sendmail.m4例子文件。 各种dbm表格和特殊的本地定义。在一个典型的执行程序发行版中，这被编译进了sendmail的执行程序中，不需要在sendmail.m4文件中明确地设置。
上面的例子有一前导dnl，这表示该行基本上是一个作为信息的注释行。
为了将支持文件的位置改变到一个不同的地方去，从上面一行中去掉dnl注释，将路径设置到期望的位置，并且重建和重安装sendmail.cf文件。 定义本地邮件程序（Defining the Local Mailer） define(LOCAL_MAILER_DEF, mailers.linux)dnl # mailer for local delvery 许多操作系统提供了处理本地邮件投递的程序。对于许多主要的Unix变体来说，典型的程序早已制作进sendmail执行程序中了。
在Linux中，就需要明确地定义合适的本地邮件程序，因为本地投递程序并无必要一定会包括在你已经安装的发行版中。这是通过在sendmail.m4文件中指明LOCAL_MAILER_DEF来做到的。
例如，为了让通用的deliver程序[1]提供这个服务，你应该将LOCAL_MAILER_DEF设置成mailers.linux。
然后，下面的文件应该作为mailers.linux被安装在由LIBDIR指定的目录中。它明确地用适当的参数在内部Mlocal邮件程序中定义了deliver程序，以使得sendmail能正确地投递目标面向本地系统的邮件。除非你是一个sendmail专家，否则一般你不需要改变下面的例子。 # -- /usr/local/lib/mail/mailers.linux –
# (local mailers for use on Linux )
Mlocal, P=/usr/bin/deliver, F=SlsmFDMP, S=10, R=25/10, A=deliver $u
Mprog, P=/bin/sh, F=lsDFMeuP, S=10, R=10, A=sh –c $u 在包括在sendmail.cf文件中的Sendmail.mc文件里对于deliver也有一内建缺省值。为了指明它，你不能使用mailers.linux文件，而是要在你的sendmail.m4文件中进行如下定义： dnl --- (in sendmail.m4) ---
define(LOCAL_MAILER_DEF, DELIVER)dnl # mailer for local delivery 不幸的是，Sendmail.mc假定deliver被安装在/bin中，而对于Slackware1.1.1（它将其安装在了/usr/bin中）并不是这种情况。在那种情况下，你就必须用链接伪装它或者从源代码中重建deliver以使它驻留在/bin中。 处理反弹的邮件（Dealing with Bounced Mail） define(POSTMASTERBOUNCE)dnl # postmaster gets bounces 许多站点发现，确信邮件是以接近100%成功率发送和接收是很重要的。正如检查syslogd(8)日志是很有帮助的一样，本地邮件管理者通常需要观察反弹回来的邮件的标题信息，以确定邮件的不能投递是否是因为用户错误还是相关系统之一的配置问题。
定义POSTMASTERBOUNCE会导致对每个反弹回来的消息作一份拷贝，并被送到作为系统邮件管理者（Postmaster）的人那里。
不幸的是，设置这个参数也将导致消息的文本内容被送到了邮件管理者Postmaster，这潜在地会涉及到系统上使用邮件者的隐私问题。
一般地，站点邮件管理者应该尽力严格律己（或者通过使用shell脚本的技术方式来删除他们所收到的反弹回来的消息的内容），不阅读不是自己邮件的内容。 与域名服务相关的项（Domain Name Service Related Items） define(PSEUDODOMAINS, BITNET UUCP)dnl # don’t try DNS on these 由于历史原因有些著名的网络通常在邮件地址中参考引用，但它们对于DNS来说却是无效的。定义PSEUDODOMAINS是用于防止不必要的且总是失败的DNS查询企图。 定义本地系统公开的名称（Defining Names the Local System is Known by） define(PSEUDONYMS, vstout.vbrew.com vstout.UUCP vbrew.com)dnl
# names we’re known by
define(DEFAULT_HOST, vstout.vbrew.com)dnl # our primary ‘name’ for mail 常常，系统希望隐藏它们的真实身份、作为邮件网关的服务、或者是接收和处理寻址到曾经已知的‘老’名字的邮件。
PSEUDONYMS指定了本地系统将接收其邮件的所有主机的列表。
DEFAULT_HOST指定了本地主机产生的将出现在消息标题上的主机名。将这个参数设置为一个有效的值是很重要的，否则的话所有返回邮件都将不能被投递。 与UUCP相关的项（UUCP-Related Items） define(UUCPNAME, vstout)dnl # our uucp name
define(UUCPNODES, |uuname|sort|uniq)dnl # our uucp neighbors
define(BANGIMPLIESUUCP)dnl # make certain that uucp
define(BANGONLYUUCP)dnl # mail is trated correctly 常常，对于用于DNS时系统使用一个名字，而用于UUCP时系统则使用另外一个名字。UUCPNAME准许你定义出现在出站UUCP邮件标题中的不同的主机名。
UUCPNODES定义了为系统返回主机名列表的命令，而该系统是我们通过UUCP连接直接连接的。
BANGIMPLIESUUCP和BANGONLYUUCP确保用UUCP‘bang’句法寻址的邮件依照UUCP的性能来对待，而不是以现今用于Internet上最近的域名服务来对待。 中继系统和邮件程序（Relay Systems and Mailers） define(RELAY_HOST, moria)dnl # our smart relay host
define(RELAY_MAILER, UUCP-A)dnl # we reach moria via UUCP 许多系统管理员不想为确保他们的系统能够到达世界范围内所有的网络（因而还有系统）而需做的工作所捆扰。他们宁愿将所有的出站邮件中继到另一台已知确实“灵敏”的系统去，而不愿那样做。
RELAY_HOST定义了这样一个灵敏的邻接系统的UUCP主机名。
RELAY_MAILER定义了用于将消息中继到那里去的邮件程序。
请注意，设置这些参数将导致你的出站邮件都将被转发到这个远程系统去，这将影响他们系统的负荷，这点很重要。在配置你的系统使用另一个系统作为一般用途的中继主机之前，一定要从远程邮件管理者（Postmaster）那里取得明确协定。 各种配置表格（The Various Configuration Tables） define(ALIASES, LIBDIR/ALIASES)dnl # system aliases
define(DOMAINTABLE, LIBDIR/domaintable)dnl # domainize hosts
define(PATHTABLE, LIBDIR/pathtable)dnl # paths database
define(GENERICFROM, LIBDIR/generics)dnl # generic from addresses
define(MAILERTABLE, LIBDIR/mailertable)dnl # mailers per host or domain
define(UUCPXTABLE, LIBDIR/uucpxtable)dnl # paths to hosts we feed
define(UUCPRELAYS, LIBDIR/uucprelays)dnl # short-circuit paths 使用这些宏，你可以改变sendmail+IDA查找各种dbm表格的位置，这些表格定义了系统的“真正”性能。通常，将它们留在LIBDIR中是明智的。 主要的Sendmail.mc文件（The Master Sendmail.mc File） include(Sendmail.mc)dnl # REQUIRED ENTRY !!! sendmail+IDA的作者提供了Sendmail.mc文件，它含有成为sendmail.cf文件的真正的“内脏”。周期性地，新的版本会发行出来以修正错误或增加新功能，但并不需要有一个完整的版本和从源代码中对sendmail进行重新编译。
请不要编辑这个文件，这点是很重要的。 那么那些条目是真正必须的呢？ 当不使用任何可选的dbm表格时，sendmail+IDA通过定义在sendmail.m4文件中的DEFAULT_MAILER（还可能有RELAY_HOST和RELAY_MAILER）来投递邮件。sendmail.m4是用于生成sendmail.cf文件的。通过domaintable或uucpxtable中的条目可以很容易的覆盖这个特性。
在Internet上使用域名服务的一般站点，或者一个仅是UUCP的并且使用UUCP通过一个灵敏RELAY_HOST转发所有邮件的站点，很可能完全不需要任何特定的表格。
事实上，所有系统都应设置DEFAULT_HOST和PSEUDONYMS宏（这定义了公众已知的规范站点的名字和别名），以及DEFAULT_MAILER宏。如果所有的只是一个中继主机和中继邮件程序，那么你就不需要设置这些缺省值，因为它是自动工作的。
UUCP主机很可能也会需要将UUCPNAME设置成他们官方的（正式的）UUCP名字。他们可能也要设置RELAY_MAILER和RELAY_HOST，这通过一个邮件中继启用了灵敏-主机路由选择。所使用的邮件传输器是定义在RELAY_MAILER中并且对于UUCP站点来讲，通常应该是UUCP-A。
如果你的站点仅是SMTP的并且用‘域名服务’交谈，那么你应该将DEFAULT_MAILER改变成TCP-A并且还可以删除RELAY_MAILER和RELAY_HOST行。 15.4 Sendmail+IDA表格通览
Sendmail+IDA提供了几个表格，这些表格允许你覆盖sendmail（在sendmail.m4中指明）的缺省设置并且针对独特（单一）情况、远程系统、以及网络定义特定的行为，这些表格使用随发行版提供的Makefile利用dbm后处理的。[？]
绝大多数站点如果需要用到这些表的话，也将只需要很少几个。如果你的站点不需要这些表的话，那么最简单的方法很可能是让它们成为长度为零的文件（使用touch命令）并且使用在LIBDIR中的缺省Makefile而不是去编辑Makefile本身。 15.4.1 mailertable
mailertable根据远程主机或网络名称，对特定的主机定义特殊的处理。它常常用于在Internet的站点上选择一个中间的邮件中继主机或通往远程网络的网关，并且指定所用的特定协议（UUCP或SMTP）。UUCP站点通常不需要使用这个文件。
次序是很重要的。Sendmail从上至下读取文件并依照它所匹配的第一条规则来处理消息。所以通常是将非常明确的规则放在文件的开头部分，而一般的规则则放在文件的后面。
假设你想通过UUCP将Groucho Marx大学计算机系的所有邮件转发到一个中继主机ada。为了这样做，你需要有个看上去象下面这样的mailertable： # (in mailertable)
#
# forward all mail for the domain .cs.groucho.edu via UUCP to ada
UUCP-A,ada .cs.groucho.edu 假设想要将更大的groucho.edu域中所有邮件送到一个不同的中继主机bighub中用以进行地址解析和邮件投递。那么扩展后的mailertable条目看上去很象下面的样子。 # (in mailertable)
#
# forward all mail for the domain cs.groucho.edu via UUCP to ada
UUCP-A,ada .cs.groucho.edu
#
# forward all mail for the domain groucho.edu via UUCP to bighub
UUCP-A,bighub .groucho.edu 正如上面所提到的，顺序是很重要的。将上面的规则顺序反一下的话将导致所有邮递到.cs.groucho.edu的邮件穿过更一般的bighub路径而不是真正期望的确定的ada路径。 # (in mailertable)
#
# forward all mail for the domain .groucho.edu via UUCP to bighub
UUCP-A,bighub .groucho.edu
#
# (it is impossible to reach the next line because
# the rule above will be matched first)
UUCP-A,ada .cs.groucho.edu
# 在上面的mailertable例子中，UUCP-A邮件程序使得sendmail用指定的标题通过UUCP进行投递。
在邮件程序（mailer）和远程系统之间的逗号通知它将消息转发到ada以进行地址解析和投递。
Mailertable中的条目具有如下格式： mailer delimiter relayhost host_or_domain 有一些可用的mailer。它们之间的不同之处通常在于处理地址的方式。典型的mailer是TCP-A（TCP/IP和Internet形式的地址）、TCP-U（TCP/IP和UUCP形式的地址）、UUCP-A（UUCP和Internet形式的地址）。
在mailertable的一行上面将mailer从左边主机部分分割开来的字符定义了mailertable是如何修改地址的。要认识到的重要事情是这仅仅重写了信封（以使得邮件到远程系统中去）。要重写除信封以外的任何部分是不赞成的，因为这及有可能破坏邮件的配置。 ！一个感叹号使得在转发到mailer之前剥离接收者的主机名。当你想要迫使邮件进入一个配置错误的远程站点时，就可以使用这个符号。 ，逗号对地址不作任何改变。消息仅通过指定的mailer转发到指定的中继主机去。 ：仅在你与目的地之间有中间主机的情况下，冒号用于删除接收者的主机名。因此，对于foo!bar!joe，foo会被删除掉，而xyzzy!janet则将保持不变。 15.4.2 uucpxtable
通常，到具有全资域名主机的邮件是通过使用域名服务（DNS）的Internet形式（SMTP）邮递方式进行投递的，或通过中继主机进行投递。而uucpxtable则通过将有域的名字转换成UUCP形式的非域的远程主机名迫使使用UUCP路由选择来投递。
当你是一个站点的或一个域的邮件转发器时，或者当你希望通过直接的和可靠的UUCP链接来发送邮件而不想通过可能是多跳数的经过缺省mailer以及任何中间系统和网络来发送邮件时，这个表是经常使用的。
与使用有域邮件标题的UUCP邻居对话的UUCP站点将使用这个文件来迫使邮件的投递通过两系统之间直接的UUCP点对点链接，而不是使用间接的路由通过RELAY_MAILER和RELAY_HOST或者通过DEFAULT_MAILER来进行邮件的投递。
不使用UUCP对话的Internet站点通常不会用到这个uucpxtable。
假设你为一个在DNS中称为sesame.com而在UUCP映射中称为sesame的系统提供邮件转发服务。那么你会需要下面的条目以迫使它们主机的邮件通过你的直接UUCP连接来投递。 #============== /usr/local/lib/mail/uucpxtable ============
# Mail sent to joe@sesame.com is rewritten to sesame!joe and
# therefore delivered via UUCP
#
sesame sesame.com
#
#---------------------------------------------------------- 15.4.3 pathtable
pathtable用于定义到远程主机或网络的明确的路由选择。pathtable文件应该使用路径别名形式的句法，并以字母顺序排过序。每一行上的两个字段必须用实际的制表符TAB来分隔，否则的话dbm可能会有问题。
大多数系统都不需要任何pathtable条目。 #=============== /usr/local/lib/mail/pathtable ================
#
# this is a pathalias-style paths file to let you kick mail to
# UUCP neighbors to the direct UUCP path so you don’t have to
# go the long way through your smart host that takes other traffic
#
# you want real tabs on each line or m4 might complain
#
# route mail through one or more intermediate sites to a remote
# system using UUCP-style addressing.
#
sesame!ernie!%s ernie
#
# forwarding to a system that is a UUCP neighbor of a reachable
# internet site.
#
swim!%s@gcc.groucho.edu swim
#
# The following sends all mail for two networks through different
# gateways (see the leading ‘.’ ?).
# In this example, “uugate” and “byte” are specific systems that serve
# as mail gateways to the .UUCP and .BITNET pseudo-domains respectively
#
%s@uugate.groucho.edu .UUCP
bye!%s@mail.shift.com .BITNET
#
#=================== end of pathtable ======================== 15.4.4 domaintable
domaintable一般地用于在一个DNS查询发生后迫使进行一定的操作。它允许管理员通过自动地将简写名替换为合适的名字来为经常引用的系统或域建立一个简写名称。它也可以用于将不正确的主机或域名替换成“正确的”信息。
大多数站点不会需要任何domaintable条目。 # ============= /usr/local/lib/mail/domaintable =================
#
#
brokenhost.correct.domain brokenhost.wrong.domain
#
#
#================== end of domaintable ========================= 15.4.5 aliases
aliases允许很多事情发生： 。它们为邮件寻址提供了一个简写名或一个众所周知的名称以便发送给一个或多个人。
。它们调用一个程序并将邮件消息作为这个程序的输入。
。它们将邮件发送到一个文件。 所有的系统要求Postmaster和MAILER-DAEMON的别名是RFC兼容的。
当定义能够调用程序或能向程序进行写操作的别名时，要特别注意安全问题，因为sendmail通常是以setuid-root运行的。
对aliases文件所作的改变不会立即起作用的，只有在执行了命令 # /usr/lib/sendmail –bi 以建立要求的dbm表后它才起作用。这也可以通过执行newaliases命令来做到。通常是从cron中调用这个命令的。
有关邮件别名的详细信息可以从aliases(5)手册页中找到。 #--------------------- /usr/local/lib/mail/aliases -------------------
#
# demonstrate commonly seen types of aliases
#
usenet: janet # alias for a person
admin: joe,janet # alias for several people
newspak-users: :include:/usr/lib/lists/newspak
# read recipients from a file
changefeed: | /usr/local/lib/gup # alias that invokes a program
complaints: /var/log/complaints # alias that writes mail to a file
#
# The following two aliases must be present to be RFC-compliant.
# It is important to have them resolve to ‘a person’ who reads mail routinely.
#
postmaster: root # required entry
MAILER-DAEMON: postmaster # required entry
#
#---------------------------------------------------------------- 15.4.6 很少使用的表
还有以下一些表，但是很少使用。有关的详细信息请查阅随同sendmail+IDA源代码一起的文档。 uucprelays uucprelays文件是用于“短路”UUCP到著名站点的路径，而不是使用多跳数的或不可靠的由使用pathalias处理UUCP映射生成的路径。
Genericfrom and xaliases
genericfrom文件通过自动地将本地用户名转换成与内部用户名不匹配的一般发送者地址，来对外部世界隐藏用户名和地址。
相关的xalparse工具会自动地生成genericfrom和aliases文件，这样入站和出站用户名的转换从一个主xaliases文件中发生。
decnetxtable decnetxtable将有域地址重写为decnet形式的地址，这非常象domaintable可用于将非域的地址重写为SMTP形式的地址。 15.5 安装sendmail
在本节中，我们将观察如何安装一个典型的sendmail+IDA执行程序，并且讨论使它专用化和正常运行需要做些什么。
Linux的sendmail+IDA的最新的执行程序版可以从sunsite.unc.edu下的/pub/Linux/system/Mail中得到。即使你已有一个sendmail的早期版本，我强烈希望你使用sendmail5.67b+IDA1.5版本，因为所有Linux要求的补丁程序现在已经在vanilla的代码中并且几个重大的安全漏洞也已被补上，这些漏洞存在于约1993年12月1日以前的版本中。
如果你是从源代码来建立senmail，你应该按照包括在源代码发行版中的README指示来操作。最新的sendmail+IDA源代码在vixen.cso.uiuc.edu上有。要在Linux上建立（编译）sendmail+IDA，你也需要newspak-2.2.tar.gz中的Linux专用配置文件，在sunsite.unc.edu上的/pub/Linux/system/Mail目录中有这个文件。
如果你以前已经安装过smail或其它的邮件投递代理，那么出于安全的考虑，你可能需要从smail中删除（或改名）所有的文件。 15.5.1 提取执行程序发行版
首先你必须在某个安全的地方打开存档（archive）文件： # gunzip –c sendmail5.65b+IDA1.5+mailx5.3b.tgz | tar xvf – 如果你有一个“最新的”（“modern”）tar（例如从最近的Slackware发行版中取得的），那么你还可以只运行tar –zxvf filename.tgz就能得到相同的结果。
打开这个存档文件会创建一个名为sendmail5.65b+IDA1.5+mailx5.3b的目录。在这个目录中，你可以找到sendmail+IDA完整的安装程序和mailx用户代理的执行程序。在这个目录下的所有文件路径都对应着文件应该被安装的位置，所以逐步使用tar命令将它们移过去是安全的： # cd sendmail5.65b+IDA1.5+mailx5.3b
# tar cf - . | (cd /; tar xvvpoof -) 15.5.2 创建sendmail.cf
为给的站点创建一个定制的sendmail.cf文件，你必须写一个sendmail.m4文件，并且用m4对它进行处理。在/usr/local/lib/mail/CF中，可以找到一个称为sample.m4的样本文件。将它拷贝为yourhostname.m4，并对它进行编辑以反映你的站点的情况。
这个样本文件是为只使用UUCP的站点设置的。并需要这个站点具有有域标题（domainized headers）并与一个灵敏主机对话的。象这样的站点只需要改动很少的项。
在本节中，我将只对你必须改变的宏，给出一简略的概述。对于它们的功能的完整描述，请参阅前面对sendmail.m4的讨论。 LOCAL_MAILER_DEF
定义了详细说明本地邮件投递mailer（邮件程序）的文件。起功能参见上面小节“定义本地邮件程序”。
PSEUDONYMS
定义你的本地主机为人所知的所有名称。
DEFAULT_HOST
放入你的全资域名。这个名字将作为你的主机名出现在所有出站邮件中。
UUCPNAME
放入你的无限定（绝对的）主机名。
RELAY_HOST和RELAY_MAILER
如果你用UUCP与一个灵敏主机对话，将RELAY_HOST设置成你的‘灵敏中继’uucp邻居的名字。如果你想有有域的标题，那么就使用UUCP-A邮件程序。
DEFAULT_MAILER
如果你在Internet上并且使用DNS，你应该将它设置成TCP-A。这将通知sendmail使用TCP-A邮件程序，该邮件程序通过SMTP在信封上使用正规的RFC形式的寻址来投递邮件。Internet站点一般不需要定义RELAY_HOST或RELAY_MAILER。 要创建sendmail.cf文件，执行命令 # make yourhostname.cf 这将对yourhostname.m4文件进行处理并从中创建出yourhostname.cf。
下一步，应该测试你所创建的配置文件是否如你期望的去工作。这将在下两节中作出解释。
一旦你对它的性能感到满意，使用下面命令将它拷贝到/etc下。 # cp yourhostname.cf /etc/sendmail.cf 此时，你的sendmail系统已经为运行准备好了。将下面一行放入适当的启动文件中（一般是/etc/rc.inet2中）。你现在也可以手工执行它让程序现在就启动。 # /usr/lib/sendmail –bd –q1h 15.5.3 测试sendmail.cf文件
使用-bt标志调用sendmail将它置入‘测试’模式。安装在系统上的缺省配置文件是sendmail.cf文件。你可以使用-Cfilename选项来测试一个备用的文件。
在下面的例子中，我们对vstout.cf进行测试，这个配置文件是从图15.2中示出的vstout.m4文件生成的。 # /usr/lib/sendmail –bt –Cvstout.cf
ADDRESS TEST MODE
Enter [Note: No initial ruleset 3 call]
> 下面的测试确保sendmail能够将所有邮件投递给你的系统上的用户。在所有的情况下测试的结果都应该是一样的并且LOCAL mailer指向本地系统名。
首先测试一个到本地用户的邮件是如何被投递的。 # /usr/lib/sendmail –bt –Cvstout.cf
ADDRESS TEST MODE
Enter [Note: No initial ruleset 3 call]
> 3,0 me
rewrite: ruleset 3 input: me
rewrite: ruleset 7 input: me
rewrite: ruleset 9 input: me
rewrite: ruleset 9 returns: < me >
rewrite: ruleset 7 returns: < > , me
rewrite: ruleset 3 returns: < > , me
rewrite: ruleset 0 input: < > , me
rewrite: ruleset 8 input: < > , me
rewrite: ruleset 20 input: < > , me
rewrite: ruleset 20 returns: < > , @ vstout . vbrew . com , me
rewrite: ruleset 8 returns: < > , @ vstout . vbrew . com , me
rewrite: ruleset 26 input: < > , @ vstout . vbrew . com , me
rewrite: ruleset 26 returns: @# LOCAL $@ vstout . vbrew . com $: me
rewrite: ruleset 0 returns: @# LOCAL $@ vstout . vbrew . com $: me 输出结果显示出sendmail内部是如何处理地址的。地址被传给各种规则集（rulesets）并由这些规则集来分析它、轮流调用其它规则集并且将它分裂成为它的各个组件。
在我们的例子中，我们将地址me传给规则集3和0（这就是在地址前输入的3,0的意思）。最后一行显示出由规则集0返回的被分析过的地址，包含有用于投递消息的mailer、以及给予mailer的主机名和用户名。
接下来，使用UUCP句法测试将邮件投递到你系统上的一个用户。 # /usr/lib/sendmail –bt –Cvstout.cf
ADDRESS TEST MODE
Enter [Note: No initial ruleset 3 call]
> 3,0 vstout!me
rewrite: ruleset 3 input: vstout ! me
[...]
rewrite: ruleset 0 returns: $# LOCAL $@ vstout . vbrew . com $: me
> 下一步，使用Internet句法用你的全资主机名测试邮递到你的系统上一个用户。 # /usr/lib/sendmail –bt –Cvstout.cf
ADDRESS TEST MODE
Enter [Note: No initial ruleset 3 call]
> 3,0 me@vstout.vbrew.com
rewrite: ruleset 3 input: me @ vstout . vbrw . com
[...]
rewrite: ruleset 0 returns: $# LOCAL $@ vstout . vbrew . com $: me
> 你应该使用在sendmail.m4文件中PSEUDONYMS和DEFAULT_NAME参数上指定的每个名字，重复进行上面两个测试。
最后，测试你是否可以邮递到你的中继主机上。 # /usr/lib/sendmail –bt –Cvstout.cf
ADDRESS TEST MODE
Enter [Note: No initial ruleset 3 call]
> 3,0 fred@moria.com
rewrite: ruleset 3 input: fred @ moria . com
rewrite: ruleset 7 input: fred @ moria . com
rewrite: ruleset 9 input: fred @ moria . com
rewrite: ruleset 9 returns: < fred > @ moria . com
rewrite: ruleset 7 returns: < @ moria . com > , fred
rewrite: ruleset 3 returns: < @ moria . com > , fred
rewrite: ruleset 0 input: < @ moria . com > , fred
rewrite: ruleset 8 input: < @ moria . com > , fred
rewrite: ruleset 8 returns: < @ moria . com > , fred
rewrite: ruleset 29 input: < @ moria . com > , fred
rewrite: ruleset 29 returns: < @ moria . com > , fred
rewrite: ruleset 26 input: < @ moria . com > , fred
rewrite: ruleset 25 input: < @ moria . com > , fred
rewrite: ruleset 25 returns: < @ moria . com > , fred
rewrite: ruleset 4 input: < @ moria . com > , fred
rewrite: ruleset 4 returns: fred @ moria . com
rewrite: ruleset 26 returns: < @ moria . com > , fred
rewrite: ruleset 0 returns: $# UUCP-A $@ moria $: < @ moria . com > , fred
> 15.5.4 综合 – 集中测试sendmail.cf和各个表
到现在为止，你已经检验过了邮件系统已有了期望的默认性能，并且你将能够收发具有有效地址的邮件。为了完成安装，还需要创建适当的dbm表以取得期望的最终结果。
在创建了你的站点所需的各个表之后，你必须在包含表的目录中运行make通过dbm来对这些表进行处理.
如果你是仅使用UUCP的，那么你就不需要创建在README.linux文件中所提到的任何表了。你只需要touch这些文件以使得Makefile能顺利工作。
如果你是仅使用UUCP的并且你除了与你的灵敏主机对话以外还与其它站点有来往，那么你就需要为每个站点增加uucpxtable条目（否则的话邮个它们的邮件也将通过灵敏主机传递了）并且针对修改过的uucpxtable运行dbm。
首先你必须确定经过你的RELAY_HOST的邮件是通过RELAY_MAILER发送给它们的。 # /usr/lib/sendmail –bt –Cvstout.cf
ADDRESS TEST MODE
Enter [Note: No initial ruleset 3 call]
> 3,0 fred@sesame.com
rewrite: ruleset 3 input: fred @ sesame . com
rewrite: ruleset 7 input: fred @ sesame . com
rewrite: ruleset 9 input: fred @ sesame . com
rewrite: ruleset 9 returns: < fred > @ sesame . com
rewrite: ruleset 7 returns: < @ sesame . com > , fred
rewrite: ruleset 3 returns: < @ sesame . com > , fred
rewrite: ruleset 0 input: < @ sesame . com > , fred
rewrite: ruleset 8 input: < @ sesame . com > , fred
rewrite: ruleset 8 returns: < @ sesame . com > , fred
rewrite: ruleset 29 input: < @ sesame . com > , fred
rewrite: ruleset 29 returns: < @ sesame . com > , fred
rewrite: ruleset 26 input: < @ sesame . com > , fred
rewrite: ruleset 25 input: < @ sesame . com > , fred
rewrite: ruleset 25 returns: < @ sesame . com > , fred
rewrite: ruleset 4 input: < @ sesame . com > , fred
rewrite: ruleset 4 returns: fred @ sesame .com
rewrite: ruleset 26 returns: < @ sesame .com > , fred
rewrite: ruleset 0 returns: $# UUCP-A $@ moria $: < @ sesame . com > , fred
> 除了RELAY_HOST外，如果你还有UUCP邻居，那么你必须确保邮递给它们有着正确的操作。以UUCP形式句法寻址的邮件到一个与之用UUCP对话的主机必须是直接递送给它的（除非你用domaintable条目明确地指出不这样做）。假设主机swim是你的一个直接UUCP邻居。那么给sendmail输入swim!fred将产生下面的结果： # /usr/lib/sendmail –bt –Cvstout.cf
ADDRESS TEST MODE
Enter [Note: No initial ruleset 3 call]
> 3,0 swim!fred
rewrite: ruleset 3 input: swim ! fred
[...lines omitted ...]
rewrite: ruleset 0 returns: $# UUCP $@ swim $: < > , fred
> 如果你有uucpxtable条目来迫使UUCP投递到一个UUCP邻居（这个邻居使用Internet形式的有域标题发送它们的邮件），就也需要对其进行测试。 # /usr/lib/sendmail –bt –Cvstout.cf
ADDRESS TEST MODE
Enter [Note: No initial ruleset 3 call]
> 3,0 dude@swim.2birds.com
rewrite: ruleset 3 input: dude @ swim . 2birds .com
[...lines omitted ...]
rewrite: ruleset 0 returns: $# UUCP $@ swim . 2birds $: < > , dude
> 15.6 重复性的邮件处理工作和愚蠢的邮件技巧
既然我们已经讨论了sendmail+IDA系统的配置、安装和测试的原理，让我们再花一点时间来看一下在邮件管理员的工作中天天会需要做些什么事。
远程系统有时会中断，Modem或电话线路会不通，由于人为的因素DNS的定义可能会不正确，网络会突然失去作用。在这些情况中，邮件管理者需要知道如何迅速、有效、安全地作出反应，以保持邮件能够从备用的路由传递，直到远程系统或服务提供者能恢复正常服务为止。
本章接下来的部分打算为你提供最常碰到的“电子邮件紧急事件”的解决方案。 15.6.1 将邮件转发到一个中继主机
为一个特定的主机或域转发邮件到一个指定的中继系统，你一般要使用mailertable。
例如，为了转发backwood.org的邮件到它们的UUCP网关系统backdoor去，你要将以下条目放入mailertable中

北南南北 · 发表于 2002-4-24 11:20:08

Linux网络管理员手册(16)
第十六章网络新闻（Netnews） 16.1 Usenet的历史
网络新闻（network news）的观念产生于1979年，当时有两位研究生Tom Truscott和Jim Ellis考虑在UN*X用户之间使用UUCP来连接各台机器以进行信息的交换。他们在北卡罗莱纳州用三台机器组成了一个小网。
最初，信息传输是通过很多shell脚本来处理的（后来用C语言改写），但是这些脚本从未向外界公布过。它们很快就被“A”news替换掉了，这是第一个向外界发布的news软件版本。
“A”news只设计成处理每天每个组很少的文章。当新闻组的容量继续在增大时，该软件由Mark Horton和Matt Glickman进行了重写，他两人称其为“B”发行版（又名Bnews）。Bnews第一个公开发行版是1982年的2.1版。它被不断地扩充，增加了几个新特性。目前它的版本是Bnews 2.11。现在它已慢慢地被舍弃，最后一个正式维护者也转向了INN。
另一次重写是由Geoff Collyer和Henry Spencer在1987年完成并发行的；这是版本“C”，或称C News。在接下来的一段时间内出了许多针对C News的补丁程序，最为显著的是C News Performance版本。在有着大量新闻组的站点上，由于频繁地调用relaynews（该程序负责将入站文章分发到其它站点去）而造成的系统开销是很大的。Performance版本给relaynews加了一个选项，该选项允许它以后台模式（daemon mode）来运行，将自己置入后台。
Performance版本是目前包括在大多数Linux版中的C News版本。
一直到“C”的所有news发行版基本上都是用于UUCP网络的。尽管它们也能用于其它的环境。在象TCP/IP、DECNet或其它相应的网络上进行有效的新闻传输要求一个新的方案。这就是为什么在1986年引进“网络新闻传输协议”（“Network News Transfer Protocol”），NNTP的原因了。它是基于网络连接的，并且指定了许多进行交互传送和收取文章的命令。
网上有许多基于NNTP的应用程序。其中之一就是Brian Barber和Phil Lapsley的nntpd软件包，你可以使用这个软件以及其它软件在一个局域网内为许多主机提供新闻阅读服务。nntpd是被设计成补足象Bnews或C News这样的news软件包的，为它们提供NNTP的特性。
另一个不同的NNTP软件包是INN，即Internet News。它不仅仅是一个前端程序，它自己就是一个news系统。它是一个能够有效地同时维护几个并行NNTP链接的复杂的news中继后台程序，因而许多Internet站点选择它作为news服务器。 16.2 总之，什么是Usenet？
有关Usenet最显著的事实之一是它不属于任何组织，也没有任何集中的网络管理特权。实际上，这是Usenet学问的一部分，除了技术说明以外，你定义不了它到底是什么，你只能指出它不是什么。如果你手头有本Brendan Kehoe的出色的“禅和Internet艺术”（网上和Prentice-Hall有售，见[Kehoe92]），你会找到一张有趣的有关不属于Usenet的列表。
冒着让人听上去感觉很蠢的风险，人们可以把Usenet定义为交换Usenet News的独立站点的集合。要成为一个Usenet站点，你全部所需做的是找到另一个Usenet站点，并与它的拥有者和维护者达成和你交换news的协议。为另一个站点提供news也称为给它喂信，这起源于另一个Usenet哲学的公理：“Get a feed and you’re on it.”
Usenet news最基本的单元是文章。这是用户写作并“投递”到网上的。为了让news系统能够处理，这些文章附带了管理信息，即所谓的文章标题（头）。它与符合Internet邮件标准RFC 822的邮件的标题格式非常相似，它也是有几行文本组成，每行用一个以冒号结尾的字段名开始，其后带有字段的值。[1]
文章被提交给一个或更多个新闻组（newsgroups）。人们可以将一个新闻组看作是有关一个共同主题文章的论坛。所有的新闻组以层次结构组成，每个组名指出了自己在这个层次结构中的位置。这使得一个组能够很容易地被看出是有关哪方面的。例如，从新闻组的名称上任何人都可以看出comp.os.linux.announce是用于有关名为Linux的操作系统公告的。
然后这些文章在所有乐意从这个组中传递news的Usenet站点之间进行交换。当两个站点同意互相交换news时，他们可以自由地交换所喜欢的任何新闻组，甚至可以加上他们自己本地news层次结构。例如，groucho.edu可能与branyard.edu（这是一个主要的news喂信机）有一个news链接，还与几个它要喂信的小站点有链接。现在，Barnyard大学可能接收了所有的Usenet组，而GMU却只想传送几个象sci、comp、rec等的主要的层次结构。某些下游的站点，比如说一个称为brewhq的UUCP站点，甚至想传送更少的组，因为它们没有这种网络或硬件资源。另一方面，brewhq可能想要从fj层次结构中接收新闻组，而这个层次结构GMU没有传送。因此，它就与gargleblaster.com维持另一个链接，这个站点却传送了所有fj组，并将这些组喂给brewhq。这些news的流动见图16.1中所示。
图16.1 Usenet news在Groucho Marx大学中的流动 尽管很清楚，从brewhq发出的箭头上的标签可能还是需要作些解释。默认地，它会要所有本地产生的news被送到groucho.edu。然而，由于groucho.edu没有传送fj组，所以从这些组给它发送任何消息中没有箭头指向。因此，从brewhq给GMU的喂信操作被标上了all,!fj，表示除了fj下的所有组都发送给它。 16.3 Usenet是如何处理News的？
如今，Usenet已经增长到占有巨大的比例。传送整个网络新闻的站点通常每天传输六十兆字节已不足为奇。[2] 当然这比任意摆布文件需要更多的处理。所以让我们看看大多数UN*X系统处理Usenet news的方法。
News是通过各种传输渠道经由网络来发布的。传统的传输媒介曾经是UUCP，但是如今主要的数据流量是由Internet站点来传送的。所用的路由选择的算法称为扩散法（flooding）：每个站点都维护着许多到其它站点的链接（news feeds）。任何由本地news系统产生的或接收到的文章都被转发给它们，除非文章已在那个站点上，在这种情况下文章将被丢弃。通过观察Path：标题字段，一个站点可以发现文章已经穿过的所有其它站点。这个标题含有文章已经被其转发过的以bang path标记的所有系统的一张列表。
为了区别各篇文章和识别重复文章，Usenet文章必须要携带一个消息id（在Message-Id：标题字段中指明），它将投递站点的名字和一个序列号组合在一起形成“”。对于所处理的每篇文章，news系统将这个id记录进history日志文件中，据此，检查所有新到的文章。
任何两个站点之间的文章信息流动可以通过两个准则来加以限制：其一，文章被指派一个发布信息（在Distribution：标题字段），该信息可用于将该文章归入站点内适当的组中。另一方面，被交换的新闻组可以通过发送或接收系统两者来加以限制。允许往一个站点传送的新闻组和分类的集合通常保存在sys文件中。
纯粹的文章数量通常要求对上述方案进行改进。在UUCP网络上，平常要做的是每隔一段时间收集一次文章，并将收集来的文章组合成一单个文件，进行压缩并发送到远程站点去。这称为批量处理（batching）。[3]
另外一种技术是ihave/sendme协议，这个协议在文章最初的地方就避免重复发送文章，这样就节约了网络带宽。不是把所有的文章放入一个批处理文件中并将它们一起发送出去，而是只将文章的消息id组合成一个巨大的“ihave”消息并发送到远程站点。远程站点读取这个消息，与它自己的history文件比较，然后返回在“sendme”消息中想要的文章的列表。此后，只有这些文章将被发送。
当然，ihave/sendme只有在涉及两个大站点时才显得有意义，这两个大站点各自从几个独立的喂信者那里接收news，并且经常相互选取对方作为有效的news流动目的地。
在Internet上的站点通常依赖于基于TCP/IP，使用网络新闻传输协议NNTP的软件[4]。它在喂信者之间传送news并且为远程主机上的单独用户提供Usenet访问。
NNTP可以用三种方法来传递news。一种是ihave/sendme的实时版，也被称为推信（pushing news）操作。第二种技术称为拉信（pulling news）操作，在这种方法中，客户就向服务器索取指定新闻组或层次结构中文章的列表清单，并选择那些在它的history文件中没有的文章，这些文章是在指定日期以后到达服务器站点的。第三种方式是用于交互式新闻阅读的，允许你或你的新闻阅读者从指定的新闻组中抽取文章，以及投递标题信息不完全的文章。
在每个站点上，news被放置在/var/spool/news下的目录结构中，每篇文章为一个文件，而每个新闻组在一个单独的目录中。目录名由新闻组名构成，新闻组名中的每个部分构成路径部分。因此，comp.os.linux.misc上的文章是放在/var/spool/news/comp/os/linux/misc中的。一个新闻组中的文章被按到达的次序分配了一个号，这个号就作为文件名。当前在线文章号的范围放置在一个称为active的文件中，这个文件同时用作你的站点所已知的新闻组的清单。
由于磁盘空间是有限的资源，[5] 在一段时间以后，你就需要开始丢弃一些文章了。这叫做过期操作（expiring）。通常，从一定的组和结构中来的文章在到达站点经过一固定天数以后就过期了。投递者若在文章标题字段Expires：中指定一过期的日期，就可以覆盖固定天数了。 
注释
[1] Usenet news消息的格式是在RFC 1036中指定的，“USENET消息交换的标准”（“Standard for interchange of USENET messages”）。
[2] 等一下，以9600bps传输60 Megs，那是6千万乘1200，那是…咕哝，…嘀咕，咳！那需要34小时！
[3] 根据Geoff Collyer所言，网络新闻的黄金规则是“你需批处理你的文章。”
[4] 在RFC 977中作了讨论。
[5] 某些人宣称Usenet是modem和硬盘厂商的共同阴谋。

anny · 发表于 2003-3-2 13:33:11

有了北南兄弟,linuxsir就有了活力了啊，兄弟在此谢了!北南兄弟辛苦了

Snoopy · 发表于 2003-3-2 17:27:14

看了一小段，，头晕了，，老大，有付出有回报的！

faint · 发表于 2003-3-3 13:18:09

呵呵，太长了。不过，有得你看。

I-like · 发表于 2003-3-3 13:39:28

我打印了！留着慢慢看！

Linux网络管理员手册［共16章节］[转帖]

＊＃！＆＊Linux网络管理员手册［共16章节］[转帖]

＊＃！＆＊Linux网络管理员手册［共16章节］[转帖]

＊＃！＆＊Linux网络管理员手册［共16章节］[转帖]

＊＃！＆＊Linux网络管理员手册［共16章节］[转帖]

＊＃！＆＊Linux网络管理员手册［共16章节］[转帖]

＊＃！＆＊Linux网络管理员手册［共16章节］[转帖]

		自动登录	找回密码
密码			注册