网络管理员指南 -15.Sendmail+IDA -5>Administrivia 和愚蠢的邮件诡计
/ns/wz/net/data/20020808041006.htm
网络管理员指南 -15.Sendmail+IDA -5>Administrivia 和愚蠢的邮件诡计
本文出自:http://www.linpus.com.tw 作者: Andrew Anderson (
既然我们讨论了设置，安装，和测试一个 sendmail+IDA 系统的理论,让我们花一些时间调查习惯性地发生在一个邮件主管上的事情。
远程系统有时暂停。调制解调器或电话线失败, DNS 定义由于人的错误而不正确地被设置。网络出人意料地下沉。在如此的情况中，邮件主管需要知道怎么快速地，有效地，并且安全地让邮件通过交替的线路流动，直到远程系统或服务供应商能恢复正常的服务。
这章余下的部分打算向你提供最经常遇见了“电子的邮件紧急情况”的解决方法。
--------------------------------------------------------------------------------
把邮件提交给一位继电器主机
为一台特别的主机或域提交邮件到一指定继电器系统,你通常使用 mailertable 。
例如,为 backwood.org 提交邮件到他们的 UUCP 网关系统后门,你将把下列入口放进 mailertable ：
--------------------------------------------------------------------------------
强迫邮件进入 Misconfigured 远程地点
经常,因特网主机对于把邮件放进 misconfigured 远程地点有点困难。有几种这个问题变体，但是一般的症状是,邮件被远程系统弹回或根本不到那里。
因为你的用户通常不在乎你不亲自管理每一个系统范围，这些问题能使本地的系统主管处于一个坏位置(或知道怎么让远程主管解决这个问题)。他们就知道他们的邮件没有通过希望的接收器到达其他终端,并且你可能是有抱怨。
一个远程地点的配置是他们的问题,不你的问题。在所有的情况中，确保不打破你的地点以便与一个 misconfigured远程地点联系。如果你不能在远程地点上与 Postmaster 联系让他们用一种及时的方式修理他们的配置，你有两个选择。
成功地强迫邮件进入远程系统，通常是可能的,尽管遥远的系统是 misconfigured ，在远程终端上的答复可能不工作...但是那是远程主管的问题。
你只能修改你即将发出信息信封上的信头,使用一个为他们的host/domain的domaintable入口,这导致发自你的地点的邮件中的错误信息正在被改正：
经常, misconfigured 地点“弹起”邮件寄回到发送的系统,并且有效地说“那个邮件不适合这个地点",因为他们没有 PSEUDONYMNS 或在他们的配置中等价的设置。完全删去从你的地点发送到他们的信息中的主机名和域信息,是可能的。
The！在下列 mailertable 把邮件发送到他们的远程地点,使它在他们的 sendmail 上看来好像它局部地发自他们的系统。注意到,这仅仅改变信封地址,因此,合适的返回地址将仍然在信息上面显示出。
不考虑,就算你把邮件装入他们的系统，不保证他们能答复给你信息(他们被打破,记得...)但是然后他们的用户在他们的主管而上大叫,非你的用户叫喊你。
--------------------------------------------------------------------------------
强迫邮件经由 UUCP 被转移
在理想的世界(从因特网前景),所有的主机在域名服务中有记录( DNS )并且将用充分合格的域名发送邮件。
如果你碰巧经由 UUCP 谈话到如此的一个地点，你能强迫邮件通过点对点的 UUCP 连接，而非通过实质上通过 uucpxtable 的“undomainizing"它们的主机名的你的缺省邮件发送程序。
迫使UUCP发送sesame.com，你将把下列各项放在你的 uucpxtable中 ：
结果是，然后 sendmail 将决定(经由在 sendmail.m4 文件的 UUCPNODES )你直接被连结到远程系统并且将为用 UUCP发送的邮件排队。
--------------------------------------------------------------------------------
经由 UUCP阻止邮件发送
相反的状况也会发生。经常,系统可以有不经常被使用的直接的UUCP连接，或不作为可靠的并且总是作为缺省邮件或继电器主机可获得的直接的UUCP连接。
例如,在西雅图区域有很多系统，它们当分区被释放时，经由匿名的 UUCP 交换各种各样的分区。这些系统仅仅在必要时谈论 UUCP ,因此通过多重很可靠的跳跃和普通(并且总是可得到)中继主机发送邮件通常更快并且更可靠。
阻止UUCP发送邮件到你直接被连结的一个主机，是可能的。如果远程系统有充分合格的域名，你能象这一样增加一个入口到 domaintable ：
这将与 FQDN 代替 UUCP 名字的任何出现，并且这样在 sendmail.m4 文件由 UUCPNODES 行阻止一个匹配。结果通常是邮件将经由 RELAY_MAILER 和 RELAY_HOST发送(或 DEFAULT_MAILER )。
--------------------------------------------------------------------------------
在需求上运行Sendmail 排队
很快地处理排队的信息,仅敲打'/usr/lib/runq'。这与适当的选择调用 sendmail，引起 sendmail 很快地运行过未解决的工作的排队，而非等待下一个安排的运行。
--------------------------------------------------------------------------------
报导邮件统计
许多地点主管(以及他们为之工作的人)对过去到的邮件的体积、格式、及通过本地地点感兴趣。有很多方法量化邮件通信量。
Sendmail 处理一个被称为mailstats的实用程序，它读一个叫 /usr/local/lib/mail/sendmail.st 的文件，并且报导信息的数字和使用 sendmail.cf 文件中的每个邮件发送程序所转移了的字节的数字。这个文件必须被本地的主管手动地创建，从而为 sendmail记录去发生。运行的总数被移动和再创造 sendmail.st 文件而清除。一种方法做下列事情：
可能最好的方法是，做一份关于谁使用邮件和多少体积传送过去，格式，以及通过本地的系统用syslogd（8）打开邮件调试的报告。通常,这意味着，从你的系统开始文件运行/etc/syslogd后台程序(不论怎样你应该正在做它),并且把行加到 /etc/syslog.conf ( 5 )看起来象下面这样：
如果你使用 mail.debug 并且得到任何媒介到高邮件体积, syslog 输出能变得相当大。从 syslogd 的输出文件通常需要从 crond 在一个例程基础上被旋转或清除( 8 )。
有很多通常可得到的实用程序能总结从 syslogd 中记载的邮件的产量。众所周知的实用程序之一是 syslog-stat.pl ,一个 perl 手迹，与 sendmail+IDA 来源散布了。