19.18.6  7  sendmail的配置

在8.12版之前，sendmail的操作是由/etc/mail/sendmail.cf这一个配置文件控制的（以前可以在/etc或者/usr/lib下找到它）。我们把它简称为配置文件。版本8.12引入了第二个配置文件，它叫做submit.cf（也在/etc/mail目录下）。启动sendmail所采用的标志决定了它将使用哪一个配置文件：如果有submit.cf文件，那么-bm、-bs和-bt就使用它，而其他所有模式都使用sendmail.cf文件。当然，还可以用命令行参数和配置文件选项改变配置文件的名字，但最好保持这两个名字不变。配置文件决定了sendmail的如下方面的以下几个方面：

—  投递代理程序的选择；

—  地址重写的规则；

—  邮件信头的格式；

—  选项；

—  安全预防；

—  垃圾邮件抵抗力。

原始配置文件的格式是专为分析方便而设计的。这种着眼点导致它有点儿缺乏一种热情友好的形象。维护这个配置文件是和电子邮件有关的管理工作中最重要的，而且甚至难倒了一些有经验的系统管理员。

sendmail的每个版本都使用一个配置文件，但是现代的版本通过使用m4宏，让配置过程变得更容易了，因为它隐藏了大部分下层的复杂性。可以说原始的配置文件位于汇编语言的层次，而m4配置更像是多地位于处于Perl的层次^[36]。

当第一次引入m4宏时，曾经希望它能处理80%~90%的情况。而实际上，覆盖的范围要高得多，可能接近98%。在本书中，我们只讨论基于m4的“简装版配置”。只有当您要调试棘手问题，或者以一种奇怪的方式扩展邮件站点时，才需要钻研底层的配置文件。

最关键的2份文档是：Eric Allman发表的论文Sendmail Installation and Operations Guide（位于sendmail软件发布的doc/op目录下），以及README文件（位于目录下）。我们经常把讲解安装的论文叫做“the installation guide（安装指南）”，而把README文件叫做cf/README。

19.6.18.7.1  使用m4预处理器

我们先描述m4的一些功能，然后演示如何从一个m4主控文件构建一个配置文件，最后描述sendmail发布所带的预装m4宏中比较重要的部分。Red Hat和SuSE虽然有m4命令，但都没有在它们的发行版本中包含m4的man手册页。在您用apt-get安装sendmail时，Debian既安装了m4，也安装了它的man手册页。

我们用3个不同站点的配置例子来总结本节的内容：

—  一个计算机系学生的家用Linux系统；

—  一个知道如何适当地配置sendmail的中等规模的公司；

—  一个处理大量web主机托管的站点。

我们还会给出Red Hat、SuSE和Debian Linux发行版本提供的默认配置。

m4原打算用作程序设计语言的前端，让用户编写可读性更好（或者也许是更隐晦）的程序。但现在m4很强大，在许多输入转换的场合之下使用一点儿问题都没有，而且很适合处理sendmail的配置文件。

m4宏的形式是：

name(arg1,  arg2,  ..., argn)

 

在name和左括号之间应该没有空格。作为参数的字符串要用左和右单引号引起来。m4采用的引号习惯不同于您可能用过的其他那些语言，因为左引号和右引号是不同的字符^[37]。引号也可以嵌套。有了今天的编译器构建工具，句法严格而奇异的m4能生存下来真是个奇迹。

m4有一些内置宏，用户还可以定义他们自己的宏。表19.18.68列出了在sendmail的配置中最常见的内置宏。

表19.18.86                      sendmail常用的m4宏

一些站点在每一行的结尾添加一个dnl宏，以使转换后的.cf文件整齐。没有dnl，m4会给配置文件添加额外的空行。这些空行不影响sendmail的表现，但是它们使得配置文件很难读。在我们的例子中省略了dn1。其他站点在想作为注释行的开头处使用其他站点在想用作注释行的开头处使用dnl。

m4实际上并不理会文件中的注释。像下面这样的注释：

#  And  then  define  the  ...

不会完成您所期望的任务，因为define是一个m4关键字，它会被展开。请改用m4的dnl关键字（代表“delete to newline[删除至换行]”）。例如，

 

dnl  #  And  then  define  the  ...

会起作用。必须在dnl和注释本身之间包含一个空格，好让它被当作是一条m4命令。

 

19.6.18.7.2  sendmail的配置片段

sendmail软件发布包括一个cf子目录，其中包含m4配置所必需的所有部分：一个README文件和表19.18.97中列出的几个子目录。

表19.18.79                           配置子目录

续表

cf/cf目录包含.mc文件的例子。实际上，它包含的例子多到了会把您给搞糊涂的地步。我们建议您把cf目录改为cf.examples，并为自己的本地.mc文件创建一个新的cf目录。如果您这样做了，请把Makefile和Build脚本复制到新的目录下，以便README文件中的指导仍然有效。最好把所有的.mc配置文件也复制到一个集中的位置，而不是把它们留在sendmail软件发布中。如果您试图从一个.mc文件建立.cf文件，而且不在软件发布的层次结构中，那么将不得不对Build脚本的相对路径名做些修改。

19.6.18.7.3  从.mc样本板文件构建配置文件

在深入有关各种配置宏、功能和选项的长篇累牍的详细资料之前，我们将前后颠倒，创建一个“不加修饰”的配置来举例说明这一过程。我们的例子用于一个叶节点foo.com，而主配置文件名为foo.mc。

我们将把foo.mc放在我们新建的cf目录下。（通过m4）转换后的配置文件将是同一目录下的foo.cf，最后将把它作为sendmail.cf安装在/etc或者/etc/mail下。/etc/mail是sendmail配置文件的标准位置，但是有许多发行版本用了/etc。

有些样板文件应该每个新的.mc文件中都加：

 

如果希望在文件的开头加上注释，第一行必须是一个divert语句，它将丢弃m4输出流中所有似是而非的无用信息，而且不需要dnl就可以有#风格的注释。接下来是注释，然后是另一个divert。用VERSIONID行（在这里是RCS格式）结束这个样板文件。这在下一个小节中有详细说明。

用VERSIONID行（在这里是RCS格式）结束这个样板文件。这在下一个小节中有详细说明。

在许多情况下，指定一个OSTYPE（参见19.18.8.27节），引进与操作系统相关的路径或参数，再指定一组MAILER（参见18.8.4节），配置就完成了。

 

在这里，我们还设置了一个选项（confCOPY_ERRORS_TO），它会把任何被弹回邮件的信头副本发送给本地postmaster。当本地站点出现问题时，这项声明就能让postmaster介入。

要构建真正的配置文件，只需复制到新cf目录下的Build命令即可。

# ./Build  foo.cf

或者

# make  foo.cf

最后，把foo.cf安装到适当的位置—通常在/etc/mail/sendmail.cf，但是Red Hat和SuSESUSE都把它藏到了/etc/sendmail.cf。

较大的站点可以创建一个单独的m4文件，把站点范围的默认值存放在cf/domain目录中，这样单个主机可以包括这个文件的内容。不是每台主机都需要一个单独的配置文件，但是每组相似的主机（相同的体系结构和相同的角色：服务器、客户机等）可能需要其自己的配置。

19.6.18.7.4  改变sendmail的配置

您经常会发现自己现有的sendmail配置几乎全部都对，但您只想尝试一下一项新的功能，加入一条新的垃圾邮件规则，或者做一次简单的改动。要做到这一点，您就要：

—  编辑.mc文件，输入您的改动；

—  用配置目录下的Build脚本重新构建配置文件；

—  把得到的cf文件安装为正确目录下的sendmail.cf；

—  向sendmail发送一个HUP信号，让它重新读取配置文件^[38]。

哪怕采用的是sendmail很容易的最新配置系统，您仍然必须针对您的站点做出几项配置决定。在您阅读下面介绍的功能的同时，考虑一下怎样才能把它们融入您的站点结构中。小规模的站点或许只需要一个枢纽结点和几个叶子结点，因而只需要两个配置文件的版本。较大规模的站点可能需要几个用于传入和传出邮件的邮件枢纽主机，或许还有一台单独的POP/IMAP服务器。

无论您的站点有多复杂，也无论它要面对怎样的外部世界（例如，完全暴露在外、在防火墙之后、或者在一个VPN上），很可能cf目录已经包含了一些现成的合适配置片段，正等着对它进行定制，然后投入工作呢。