18.11  配置文件举例

 

作为学习在现实世界里如何配置sendmail的一个例子，我们来看一个很小但是非常了解sendmail的公司—Sendmail，Inc.（Sendmail有限公司）—所用的配置文件。他们的邮件系统设计方案包括一台主邮件枢纽主机（master mail hub），它同时负责传入邮件和发出邮件的处理任务。传入的所有邮件都由它接受，并立即传送给一组内部的IMAP服务器，这些服务器在把每则消息投递到用户的邮箱之前，先要检查病毒。邮件枢纽主机也能检查每一条传出的消息是否有病毒，这样一来，Sendmail，Inc.就不会因为通过电子邮件散布病毒而负责任。我们先看客户的配置，然后再查看更复杂的邮件主机。

 

在这些例子中，我们都对原始文件进行了轻微修改，删去版权说明，添加临时注释，并删除行尾的m4 dnl指令。如果您把我们的任何例子用作自己的.mc文件的模板，请一定要删除行尾的注释。

我们确实没有介绍完所有的配置选项（下面会有一节介绍垃圾邮件、一节介绍安全、一节介绍性能），但现在是看一些配置文件例子的时候了。这种顺序可能有点儿前后颠倒，但它似乎是我们尝试过的效果最好的安排了。我们尚未介绍的基本配置功能是访问数据库，它主要用于过滤和控制垃圾邮件。我们将在19.10.2节介绍它。

在建立有关各种站点上使用的配置文件的文档时，我们总是会遇到一些过去留下的文件，它们不是有错误就是不再需要了。在使用这些配置文件作为例子之前，我们已经清除了不一致的地方和拼写错误等，所以它们在这里显示时不完全是它们出现在原来服务器上的样子。虽然如此，它们仍然能反映出真实世界的配置。

 

19.9.1  计算机科学系学生家里的机器

我们的第一个例子是个学生Rob Braun，他家里有一台Linux主机（gw.synack.net），并且虚拟托管了一些朋友的域：xinetd.org、teich.net和cubecast.com。

他在主机上也有自己的域，synack.net。Rob用LDAP把所有的传入邮件映射给适当的人。他用virtusertable来处理虚拟主机映射，用genericstable来处理发出的邮件。在许多对发出邮件产生影响的表的类型中，genericstable是唯一一个既能重写用户名也能重写目的主机的表。

Rob的genericstable文件（他实际上把它称为outmap）包含：

 

bbraun      rob@synack.net

stabilej    jon@synack.net

teach       oren@teich.net

 

Rob使用DNS Realtime Blackhole List（dnsbl）对垃圾邮件进行控制。他还使用伪装功能给尚未由genericstable重写的发出邮件盖戳，让这些邮件看来好像来自user@synack.net而不是user@gw.synack.net。以下是完整的gw.mc文件：

 

/etc/mail/local-host-names文件中包含由这台主机为其接受邮件的那些主机和域。调用这个文件的use_cw_file功能就隐藏在一般的域文件（generic domain）中；参见19.9.2节。默认情况下中转功能（relaying）被关掉了，因为文件/etc/mail/relay-domains通常为空。在这里，该文件包含的域由gw.synack.net担当虚拟主机。LDAP数据库是用一个ldap.conf文件配置的，这个文件负责设置LDAP根的区别名、服务程序主机和端口：

 

BASE  dc=synack,  dc=net

HOST  gw.synack.net

PORT  389

 

随后，从一个文本文件建立LDAP数据库，文件中的项如下：

 

 

前3项把登录名rob、webmaster和oren映射到他们的别名。第4项是一个邮递列表，它映射为一个本地别名，并由Majordomo根据/etc/mail/aliases文件中的以下各项从那里开始处理：

 

 

我们已经给出了这个例子的几个支持文件和示范内容。我们的下一个例子会更进一步举例说明sendmail的配置如何工作，并且不再给出外围文件。

请记住，在任何sendmail的例子中，DNS MX记录扮演着关键性的角色，它需要符合配置所假定的情况。

19.9.2  善用sendmail的小公司

作为下一个例子，我们来看一个很小但是非常了解sendmail的公司——Sendmail有限公司（Sendmail, Inc.）——所用的配置文件。他们的邮件系统设计方案包括一台主邮件枢纽主机（master mail hub），它同时负责传入邮件和发出邮件的处理任务。传入的所有邮件都由它接受，并立即传送给一组内部的IMAP服务器，这些服务器在把每则消息投递到用户的邮箱之前，先要检查病毒。邮件枢纽主机也能检查每一条传出的消息是否有病毒，这样一来，Sendmail, Inc.公司就不会因为通过电子邮件散布病毒而负责任。我们先看客户的配置，然后再查看更复杂的邮件主机。

在所有的例子中，我们都对原始文档进行了轻微修改，删去版权说明，添加临时注释，并删除行尾的m4 dnl指令。如果您把我们的任何例子用作自己的.mc文件的模型，请一定要删除行尾的注释。

18.11.1  sendmail.com的邮件客户机

sendmail.com的客户机

用于客户机的smi-client.mc文件相当简单。它使用邮件主机smtp.sendmail.com，这其实只是机器foon.sendmail.comkatroo.sendmail.com的一个别名。使用一条MX记录（或者一条CNAME^[44]记录）来指向邮件服务器是个好主意，当您希望移动自己的邮件主机时，这样改起来很容易。

请注意这个文件中的日期是1998年10月。自那时以来sendmail已经升级了许多次，但这个配置文件却不需要修改。

 

MAIL_HUB和SMART_HOST行把传入和发出的邮件定向到主机smtp.sendmail.com。对DNS中的MX记录应该予以配合，列出比单个客户机拥有更高优先级的主机（在MX记录中的编号较低）。.forward文件的路径被设置为空，别名文件也被设置为空，所有别名扩展都在这台主邮件枢纽主机（master）上进行。在这里指定了nocanonify功能以节省时间，因为无论如何在主邮件枢纽主机（master）上都要进行DNS查找的。

18.11.2  sendmail.com的邮件主机

sendmail.com的主机

sendmail.com的主邮件枢纽主机（master）可能是被攻击得最多的sendmail软件安装之一。它必须尽可能好地处理垃圾邮件，在攻击者们搞出的所有狡猾的邮寄程序邮寄程序的攻击之下保证安全，并保护它身后的机器。下面是它的配置文件：

 

 

 

主邮件枢纽主机（master）的任务就是把传入的邮件路由到正确的内部服务器上，并且作为传出邮件的中继转发主机。

因为有下面两行：

FEATURE(‘accept_unqualified_senders')

FEATURE(‘accept_unresolvable_domains')

故主邮件枢纽主机（master）要接受传入的所有邮件，哪怕邮件是从没有全名的发件人和不能解析的域发来的也要接受。这样一来，把sendmail或者DNS配错了的客户仍然有可能通过。这些规则撤销了能够捕捉大量伪造信头的垃圾邮件的默认设置。身份识别功能被关闭了（超时时间设为0），从而加快了投递传入邮件的速度。

 

这台主邮件服务器首先检查传入的消息是否有某些类型的MIME附件，这些附件经常被病毒利用（INPUT_MAIL_FILTER语句）。那里调用的mime-filter包含下面这样的几行：

MIME附件的.vba、.dot、.exe、.com、.reg等类型都被拒绝，但是这里并没有做全面的病毒扫描，因为这样做会减慢传入邮件的处理速度。主邮件枢纽主机（master）使用LDAP（带有一个针对站点的特定方案）来查找每个消息的收件人，并把它传送到正确的内部IMAP/POP服务器上。如果没有在LDAP数据库中找到收件人，那么邮件就被发送给一台内部的主机（MAIL_HUB语句）做进一步的处理。IMAP/POP服务器和内部主机都会在把消息投递到用户的邮箱之前对它做全面的病毒扫描处理。

根据客户机上的SMART_HOST语句，传出的邮件也通过这台主邮件枢纽主机（master）进行发送。要通过邮件服务器sendmail.com发送一则消息，在sendmail.com域之外的机器必须提供一个由sendmail.com证书服务签发的证书。本公司雇员在到客户方的现场工作时，就可以采用这种机制通过sendmail.com向第三方中转（relay）发送邮件，而其他人却没有办法这样做。这种约定验证每个用户的身份，防止假造的邮件经sendmail.com中转发出。

在接受了发往Internet的邮件之后，这台主机（master）就把它传给SMART_HOST进行病毒检查。主邮件机器不太忙，可以自己来完成病毒扫描工作，但是如果在那里完成扫描的话，在邮件确实发出之前，发出邮件的用户不得不等着扫描完成。把它排入队列进行病毒扫描的机器会让用户更惬意一些—他们觉得消息似乎是转眼就发出去了。

在配置文件结尾处的LOCAL_CONFIG的几条规则就是通常检查信头、查找各种病毒和已知的发送垃圾邮件者的地方。在sendmail软件发布中的样本文件knecht.mc里，就能找到很好的例子。我们在下面包含了一个样本。

在2001年夏天，颇具破坏性的SirCam蠕虫到处肆虐。下面的片段是从sendmail软件发布中的knecht.mc文件里节录出来的，它能捕获这个蠕虫病毒。SirCam是首次能够产生随机信头内容的恶意病毒之一。如果不是它的作者犯了一个错误，使SirCam消息和真正的Outlook Express消息有了区别，那么用通常的工具都抓不到它。消息的内容相当常见（它请您就附带的附件给出意见），因此成了8.12版sendmail中新加的libmilter过滤机制的使用对象。在软件世界里没有产品级的可靠保障，似乎解决所有这些Microsoft病毒和蠕虫的做法就是卸载Windows并安装Linux！参考19.18.10.75节了解有关libmilter的更多信息。

 

在sendmail.com公司客户机上，它们自己的配置文件里都没有垃圾邮件控制机制，因为所有传入这个站点的邮件都是通过外部的邮件枢纽主机和一台内部的枢纽主机来传送的，垃圾邮件都在那里给挑出来了。本例中的有些功能和其他结构没有在我们介绍配置的章节里讲过，但是可以在cf/README文件里找到它们的文档说明。

19.9.3  另一个邮件主机/客户机的例子

XOR有限公司（XOR Inc.）是一家中等规模的公司，它拥有一台单独的邮件主机。虽然XOR公司整个的邮件系统设计类似于sendmail.com的设计，但是实现它所用的配置原语稍有不同。

下面是客户机的配置：

 

这一配置确实是最少的，但对于由服务器完成所有复杂事务，而客户机只能发邮件的这么一种邮件系统设计来说，已经够用了。甚至连发送给本地用户的邮件也被转发到xor.com，就是在nullclient功能中指定的那台机器。没有指定邮寄程序；sendmail没有运行在守护进程模式。

下面是与客户机设置相匹配的邮件主机的配置。XOR托管着许多web网站的主机，代替许多虚拟域接受和管理邮件。我们的第一个例子，即学生的机器，用LDAP和genericstable管理3个虚拟域。XOR用virtusertable管理大约1000个虚拟域。它使用genericstable为发出邮件把登录名映射为first.last（名.姓）。它用标准的别名文件来实现别名，该文件有3000行长，包含许多邮递列表，某些列表有好几千个收件人（有一个超过了100,000）。所有这些都是在一台有点劳累的老的SunOS sun4m主机上完成的，之所以没有把它换成出色的Linux新机器，只是因为那条“如果它能用，就别动它！”的原则。

请注意，在这里缺少通常出现在.mc文件开头的divert语句和注释。只有当您在配置文件的开头使用shell风格的注释时（#）它们才是必要的。

这个站点运行的是sendmail 8.9.3，在配置行中还用了一些老（早于8.10）结构。它的邮件负荷已经导致许多性能参数设置得比它们的默认值高一些。

 

 

在.mc文件末尾的病毒和垃圾邮件处理规则根据消息的标题行来拒绝特定的消息。既然这些规则效果还不错，就没有必要有大小写的变化；规则集是大小写敏感的。有些针对标题行的规则（例如，$*Jokes）有可能会匹配合法的邮件。

这些规则稍微给sendmail的性能造成了一点儿影响，而且因为垃圾邮件增速，可能最终造成很大的配置文件。如果您已经有一个非常繁忙的站点，那么或许最好在另一台机器上做垃圾邮件过滤处理，而不是在主邮件网关上做。

要丢弃从某些特定站点来的所有邮件，可以使用访问数据库和关键字REJECT。xor.com上的访问文件包含要拒绝其邮件的800多个域，根据域名判断，大多为色情或者垃圾邮件站点。下面是一个片段：

 

 

正如您从这些例子的多样性可以看到的那样，不存在某种惟一正确的方法来设置您的配置文件。sendmail包含许多种用于传递邮件和修改信头的结构。您的选择多多少少取决于个人的喜好或取决于您从他那儿复制得到文件的那个人所做的事情。

现在我们已经看到了一些现实中配置的例子，让我们看看随我们举例的Linux发行版本所带的默认配置是怎样的。

19.9.4  Red Hat的sendmail配置

Red Hat直接安装了sendmail。在默认情况下，它使用从/etc/mail/sendmail.mc构建的一个配置，而把配置文件树的其他部分放到了/usr/lib/sendmail-cf里（译者注：从Red Hat 7.3起到目前的Red Hat 9.0，这个目录又变为/usr/share/sendmail-cf），而它们在sendmail软件发布里原本是放在cf目录下的。

Red Hat的.mc文件使用了sendmail文件的老名字和位置，而不是/etc/mail下的当前默认值。这个配置包括几个控制邮件路由的数据库。不过，这些文件需要用本地数据进行填充；mailertable、virtusertable和access都有，但都是空的。有个文件userdb配置了，但是却没有这个文件。

我们删除了一些注释（以dnl开头的行）好节省地方，又在特殊的行上加了注释（以###开头）。把这个例子作为一个实际的.mc文件来用之前，一定要删掉我们加的注释。下面是2002年早些时候Red Hat的.mc文件。

confAUTO_REBUILD选项已经被废弃不用了，而且在将来的版本中会消失。如果sendmail在处理任何邮件之前，别名数据库已经变了，这个选项就让sendmail重新构建别名数据库。

定义confDONT_PROBE_INTERFACES的做法很奇怪；它让sendmail不要在它的w类中列出本地主机的接口（/etc/mail/local-host-names）。于是，邮件必须由mailertable项来特别处理，否则就会被弹回，并附有配置错误的消息。即使设置了confDONT_PROBE_INTERFACES，也一定要包含loopback（环回接口），这样才能发本地邮件（因此，没有定义本地邮件的邮寄程序，或许没有本地邮件吧）。

Red Hat 7.1指定sendmail.st作为STATUS_FILE，但是又创建了statistics文件，所以它从来都不会收集任何统计信息。Red Hat 7.2纠正了文件名，但是又把这行给注释掉了。

userdb功能已经废弃不用了，而且这个配置中也没有用到，所以confUSERDB_SPEC一行显得很奇怪，或许是早先残余下来的吧。如果可能的话，accept_unresolvable_domains和relay_based_on_MX功能都应该删除掉；前者给垃圾邮件创造的天堂，而后者则让垃圾邮件制造者有机可乘。

19.9.5  SuSE的sendmail配置

SuSE带有两种配置，它们都在/etc/mail下：linux.mc和linux.nullclient.mc。一种配置用于主邮件机器，另一种配置用于客户机器。SuSE版本所带的配置中最大的不同就在于OSTYPE文件suse-linux.m4，它包含的内容实在太多了。

.mc文件和数据库样本文件包含了许多注释，有助于理解其中包括的功能以及本地信息的格式。下面给出的linux.mc文件经过我们删除注释之后从220行缩短到22行。

邮寄程序的列表包括了一些不是sendmail软件发布正规部分的种类。它们可以在SuSE带的sendmail版本中/usr/share/sendmail/mailers文件里看到。

SuSE的.mc文件违反了sendmail所期望的配置语句顺序，它把DOMAIN语句（通常靠近配置文件开头）放在了邮寄程序（通常在配置文件最后）之后。如果DOMAIN文件中的语句修改了邮寄程序的参数，那么由于语句顺序的原因，修改不会起作用。最好遵照cf/README文件所建议的顺序。虽然SuSE文件看上去还不错，简单明了，但大多数配置都隐藏在了OSTYPE文件suse-linux里。下面是linux.mc文件：

 

下面是linux.nullclient.mc文件；您必须用实际邮件枢纽主机的名字替换mailhub.domain.notused。我们已经把行尾的dnl删除了，好让这个例子的可读性更好一些。

 

 

OSTYPE文件一般有大约10行内容，其中包括各种程序的目录，这些程序的位置和操作系统有关。SuSE Linux已经误入歧途了；我们再次给特殊的行增加一些以###开头的注释。仅OSTYPE(`suse-linux')这一行就可以把下面的文件包括进这些简单的配置里面。

 

文件的老名字

 

这可真够乱的。它大部分都应该呆在.mc文件（或者您站点上配置原语的域文件）里，您在那个文件里看它就容易一些，不会被隔着的OSTYPE这一层隐藏起来。OSTYPE文件应该是与操作系统有关的参数，比如到特殊程序的路径等而保留的。sendmail软件发布中的cf/README文件包含了一系列应该在OSTYPE文件中出现的定义——或许有人应该给SuSE发一份有更多说明的README文件。

尽管这个OSTYPE文件显得很滑稽，但SuSE的确还是提供了一个相当合理的初始配置文件。所有被引用到的表都在/etc/mail下有相应的文件，还带有注释，指出了格式以及典型的配置项。这个配置只需要做一点儿重新组织工作，插入正确的OSTYPE文件，或许还有一个SuSE的DOMAIN文件，只要真正的“干货”——用得到的功能——呆在.mc文件中它们应该呆的位置上就行了。no_default_msa功能有点儿奇怪；它禁用了587端口，所有新的用户代理都要用这个端口来向邮件系统提交消息。不清楚SuSE为什么要这样做。

注意，在定义统计文件和查询目录的位置上，采用了条件定义（由m4关键字ifelse引入的部分）方式。因为不存在/etc/SuSE-release文件，所以m4指令syscmd执行成功，并在sysval里返回0，从而在m4的ifelse结构中选择了第一个选择分支，而不是第二个选择分支。SuSE没有在他们的发行版本中包含m4的man手册页，所以您可能不得不到另一台机器上搞清楚这些条件的真实用意是什么。

19.9.6  Debian的sendmail配置

Debian的sendmail.mc文件是由安装脚本生成的，而且在默认情况下包括伪装功能，其他就没有什么了。它使用OSTYPE(debian)，将下面给出的文件拉进配置当中，这个文件就是/usr/share/sendmail/sendmail.cf/ostype/debian.m4。

 

 

 

 

这种方法在OSTYPE文件中隐藏了太多的内容——它几乎和有90行的SuSE文件一样过分。特别地，DOMAIN行应该在.mc文件里，就像许多影响到sendmail行为的定义应该的那样。如果Debian所带的是sendmail的一个更新的版本，而且利用了sendmail给出的默认值的话，那么OSTYPE文件里的许多行都是没有必要的。

DONT_BLAME_SENDMAIL一行也很奇怪。它彻底毁掉了安全性，做得非常过分；这些配置项中大多数都在home目录上无所作为。这个文件也使用#作为注释符，但它根本不起作用。

下面是安装脚本生成的.mc文件。除了我们要求有的smrsh和always_add_domain之外，每一行都是脚本的默认结果。

 

 

 

 

这个.mc文件有各种各样的问题，包括一些似乎不该有的奇怪语句以及一些顺序列错了的语句。m4仍然能处理它并产生的结果真是让人感到惊异。

一般而言，把大多数配置隐藏到OSTYPE文件的做法增加了复杂性，而且在您试图搞清楚没有打开的所有功能究竟是怎样魔术般地成了最终配置文件的一部分时，让调试工作变得更加困难。例如，安装脚本没有选择包括REDIRECT功能，但是它仍然列在了DOMAIN文件里。即使您在配置过程中对脚本说“不”，您最终还是会得到这项功能。

 

 

19.10.7  垃圾邮件举例

虽然我们并不建议把分析垃圾邮件当作一件理所当然的事，但知道如何去做有时还是有用的。例如，可能会有人请您解释为什么贵公司的CEO收到黄色书刊的招揽邮件（并验证它并非出于某个公司职员之手）。

在接下来的几页中，我们将分析最近一些垃圾邮件的信头。这些例子举例说明了确定实际的发件人有多难，而伪造邮件信头有多容易。首先给出一些要点：

—  Received信头应该从消息的顶部到底部都是环环相扣的。

—  Date信头下面的任何Received信头都是伪造的。

—  请注意两个主机名不匹配的Received信头。邮件可能是通过第一个主机（加上括号的主机才是真实来源）转发的。

—  日期在很久以前的Received信头可能是伪造的。

—  From信头的主机部分应该与最后一个Received信头一致。

—  Message-Id信头的域应该与From信头的域一致。

—  检查Received信头，看看是否显示出这则消息是通过无关主机转发的。有时候这是对的；例如，一家允许雇员家里的机器进行中继转发，或者反之亦然。

—  检查所有列出的主机以确定它们在DNS中都存在。要使用一次MX查找操作，而不是一次A记录查找操作，因为本地防火墙或者split DNS可能会让A记录查找失败。

我们的第一个例子是一则销售CD的消息，CD上有10,000,000个电子邮件地址可供未来的发送垃圾邮件者使用。这张垃圾邮件CD很有趣——它保证决无重复的地址，也没有“毒药”地址（这大概是指会把发件人自动提交给某个黑洞列表的地址）。

我们给信头的每一行编号以方便解释；编号其实是不存在的。

 

 

第1行是由/bin/mail在本地投递过程中添加的。域msk.ru存在，但主机kayak.msk.ru并不存在；如果在那个站点上用了split DNS的话，这种情况也是合法的。第2行是一个有效的Received行——它是精确性有保证的唯一一个Received行，因为它是由我们自己的主机（在本例中是xor.com）添加的。第3行是由sendmail顺路加上的一个From信头，因为此消息最初没有From信头。

第4行是一个有效的Received行，来自不受怀疑的替罪羊主机（gaia.es），这台主机运行着sendmail 8.8，默认情况下允许转发（Sun公司的产品就是这样的）。第4行里的“from default”暗示出下一个Received行是伪造的。

第6行是一个伪造的Received行。它位于Date行之下，它要么没有，要么在sendmail进程得到此消息之前就已经在那儿了。另外，格式也有错，这经常能很好地预示出有窜改行为。IP地址233.214.241.87没有反向的DNS项。在Internet还在用于研究和学术的时代，这也表明发生了问题。现如今，许多主机都没有反向DNS项。

第7行，即To行，是伪造的。收件人的地址只在信封上才会有。

第9行的意义在于标识已确认的发件人，它有时是消息起源的一条线索。这一行暗示发件人来自wgukas.com，可是并不存在这个域。这一行实际上是由一个PC机邮件用户代理程序添加的，所以很容易伪造。

第10行暗示发送机器实际上是sa_ghklo.um.de，但它的格式错了（缺少尖括号<>），所以可能是伪造的。

要分辨出这则消息出自哪里是不可能的。它曾通过gaia.es转发，可能未经后者的许可。gaia.es尚未被列在MAPS黑洞列表中，但也许很快就会被列入了。greg1148可能是发送垃圾邮件者本人，也可能是一个抱怨前面垃圾邮件的用户。在后一种情况下，greg1148在这个消息中扮演了受害人角色，可能会收到数百或数千封愤怒的消息，请求从该列表中删除自己。

消息的主体要求您给某个800号码打电话或传真您的订单。典型情况下回复发送垃圾邮件者并购买其产品所需要的所有信息都放在消息的实际主体中。请注意From行上的地址与To行上的地址相同；两者都可能是伪造的。

同一天收到的另一段垃圾邮件表示，愿意让您发财，只要您在11月15日之前给他们传真一张40美元的支票，15日之后价格将升到195美元。传真支票的副本是合法的支付手段吗？或者他们只是想获得您的银行账户汇款号码和您的签名，以便打印他们自己的支票呢？请保护您的身份信息吧。

 

 

第2行是一个有效的Received信头。第3行也是有效的，但从目的地xor.com到hamilton（168.191.61.20）和saturn.globalcon.com（209.5.99.8）的traceroutes（路由跟踪）说明，这两个站点彼此毫无关系，168.191.61.20是Sprint的拨号网络，从时区的表示来判断，它可能位于欧洲。209.5.99.8 是加拿大安大略省的一家公司。saturn.globalcon.com可能是一个开放中继。他们并没有运行sendmail，而是运行来自Openwave.com （以前的software.com）的邮件传输代理程序Post.Office 3.1.2版。

在第4行上，由发件人的用户代理程序添加的数据是欧洲时间大约凌晨2:00，即机器saturn.globalcon.com收到它之前的2个小时。也许收件人列表非常长，进程花了2个小时。或者也许这则消息是在发送垃圾邮件者的PC机上离线撰写的，在一个稍后的时间才投递到Internet。时区显示（如果它不是伪造的话）有5个小时的差异——正好是欧洲和美国东海岸之间的时差。

在第6行上，Message-Id的主机部分应该是一个完整的域名，而不只是本地部分“hamilton”。这可能是发垃圾邮件的人的机器，它或许不叫hamilton。典型情况下，@符号左边的Message-Id部分由数字组成，但也允许有字母，所以它可能是对的。

第8行显然是伪造的。实际的收件人地址只在消息的信封上才有，不会出现在信头中的任何地方。

这则消息实际上可能来自F.Pepper@pmail.net。主机名pmail.net可解析为一个有效的IP地址，并且whois说pmail.net是一家英国电讯公司。我们在本节研究过的差不多20条垃圾邮件消息中，这可能是其包含的信息足以进行合理投诉的惟一一条（请向信头第3行上的IP地址在DNS中所指出的hostmaster投诉）。决不要直接向发送垃圾邮件者或发送垃圾邮件者所在的域投诉。

SpamCop是个软件包，它可以分析邮件信头并辨别哪些行是真实的，哪些可能是伪造的，哪些完全是伪造的。它向通过电子邮件或网站（spamcop.net）提交垃圾邮件的用户提供一份极为详尽的信头说明，并告诉用户哪些片段是合格的，哪些不是。这个站点还方便您提交垃圾邮件的投诉。投诉中包括了从您提供的信头分析得来的所有相关信息。SpamCop是由Julian Haight编写的。

我们对上面的第一个垃圾邮件示例运行SpamCop，就是那封企图卖给我们一张装满地址列表的CD的垃圾邮件。它确定gaia.es的Received行没问题，而域wgukas.com是伪造的。然后它确定gaia.es没有邮件中所说的地址，真正的罪犯可能在一个名为ttd.net的站点上。很显然，SpamCop的分析比我们的分析要好得多，而且它只需要几秒钟。

下面是SpamCop对一些更新的垃圾邮件所做分析的小片断：

 

 

每一个[show]单词都链接到SpamCop的网页。它们会向您显示实际执行的命令及其输出。