18.1 邮件系统

第18章  电子邮件

很难记起没有电子邮件的世界是个什么样子了。从学校里的孩子到老奶奶，再到公司里最落伍的员工，每个人现在都会例行公事般地使用电子邮件联系家人、同事、伙伴、客户甚至政府。真是一个电子邮件的疯狂世界 。

电子邮件之所以流行，是因为公众能够轻而易举地理解发一则消息的概念，这个概念的模型与传统的书面信件非常近似。电子邮件就“那么简单”，如果您知道某个人的电子邮件地址，您就可以敲一则消息，写上他们的地址，然后按“发送”。哇！几秒之后，这则消息就送到了他们的电子邮箱里，不管他们就在隔壁还是半个地球以外。从用户的角度来看，没有比这更容易的了。

遗憾的是，事情不总是这样的容易，即使在今天，保证在这样大的范围内实现电子邮件通信所依靠的下层基础设施的任务仍然相当繁重。您可以在Linux上运行几种软件包来传输和管理电子邮件（本章后面讨论其中的3种），但是它们都要求做一定程度的配置和管理。此外还有一点很重要，就是您要理解与电子邮件相关的底层概念和协议，从而不会给自己的用户养成错觉，以为在单位之间跨平台的电子邮件是老天送来的礼物，每次都能奇迹般地做到。

现如今，理解和管理电子邮件基础设施还有另外一些方式。现在一些服务提供商提供了“被管”电子邮件服务，电子邮件实际上托管在很远之外的数据中心里提供商的服务器上，您按月或者按年（可能还要按人）支付访问费用。类似地，还有一些免费的“托管”服务，如Yahoo！Mail、MSN Hotmail和Google的Gmail都已经在个人中非常流行。

如果您正在为个人找一个电子邮件账号，或者在为一家（非常）小的公司找一个账号，那么这些都可供您选择。这些服务卸掉了若干负担，举例来说包括存储、服务器管理、软件升级、配置、垃圾邮件过滤和保持安全警惕。作为对其“免费”服务的回报，或许您要看到一些广告。这似乎在许多情况下都很理想，如果这样的选择适合于您，那么您至少能得益于不用读本章余下的内容啦。

不过，托管的电子邮件并不是每个人的解决方案。商业公司，以及其他依靠电子邮件服务来运行的大型机构，往往都不会冒风险去把电子邮件托管到异地。这样的机构可能有各种不同的理由运行自己的电子邮件系统，包括安全、性能和可用性。本章的内容就是面向这些人的。

本章篇幅较长，这也印证了电子邮件系统的复杂性。本章既包含了背景知识，也包含了软件配置的细节信息，讲述的顺序也大致如此。

我们曾试着把这一章分成较短的几章（邮件系统、sendmail配置、垃圾邮件、Exim和Postfix），但这样写会在内容上充满了死循环问题，令人不好理解，而且我们以为，这样做用处不大。我们代之以在表18.1中给出带注释的目录。

表18.1 本章的编排

在依次阅读本章的内容时，这样的组织会使读者觉得内容更顺畅一些，但有时会被某些内容给打散了，这些内容介绍了某种与电子邮件相关的特定任务。对于中等规模单位的邮件服务负责人来说，可能需要阅读整章内容。如果只是为一般的公司客户设置PC支持电子邮件，对于这样的系统管理员来说，就没必要这么做了。

表18.2为一些常见的系统管理工作提供了一份引导指南。
表18.2 工作索引

续表

本章的大部分内容都是在讲述sendmail的配置，它是分析和传递电子邮件的标准程序。sendmail最初是加州大学伯克利分校（University of California，Berkeley）的Eric Allman编写的。sendmail有3个主要的版本：版本5、IDA以及版本8。最近，全新设计的版本sendmail X已经发布了一个早期的beta版，但还没有准备好可以供生产环境使用（根据圈内人透露，它可能永远也代替不了sendmail 8）。版本5和IDA已经不常使用，而由版本8取代了它们。在本章中我们讨论版本8（精确地说是8.13）。

sendmail正在由Sendmail,Inc公司进行商业开发，该公司还维护着一个免费的、开放源代码的版本。商业版本的特色是图形化的用户配置界面以及中央监控和报告功能（这是对于用户数量庞大的邮件站点来说特别有用的功能）。

18.1  邮件系统

从理论上说，一个邮件系统由4个不同的部分组成。

让用户阅读和撰写邮件的“邮件用户代理”（mail user agent，MUA）。

在机器之间发送消息的“邮件传输代理”（mail transport agent，MTA）。

把消息放到本地消息库 中的“投递（delivery）代理”；它有时叫做本地投递代理（Local Delivery Agent，LDA）。

有可无的“访问代理（access agent）”，它可以把用户代理连接到消息库（例如，通过IMAP或POP协议）。

有些站点还使用一种邮件提交（submission）代理，这种代理使用SMTP（simple mail transport protocol，简单邮件传输协议），并完成传输代理的一些工作。图18.1显示了这些组成部分的相互关系。

图18.1  邮件系统的组成部分

 

18.1.1  用户代理

电子邮件用户使用用户代理来阅读和撰写消息。电子邮件消息最初只由文本组成，但现在用一种称为MIME（Multipurpose Internet Mail Extensions，多用途网际邮件扩充协议）的标准可以把文字格式和附件（包括许多病毒）编码后加入到电子邮件中。大多数用户代理都支持它。因为它并不影响邮件的寻址或传送，所以我们不在本章中对它作进一步讨论。

用户代理的一项工作是确保在邮件消息的内容中嵌入的任何可能被邮件系统误解的文字得到保护。用作消息之间记录分隔符的字符串“From”就是一个例子。

/bin/mail是最初的用户代理，对于从shell提示符下阅读文本类的电子邮件消息来说，仍然是个随时能用的好工具（译者注：原文ol’standby的意思是online standby，即“在线待命”。自从知名网站AOL诞生之后，OL在网上就成了ONLINE的流行缩写）。不论这是好是坏，Internet上电子邮件已经超越了文本时代，所以对大多数用户来说，基于文本的用户代理不再实用了。图形用户界面支持以“鼠标指点”方式访问邮件消息，并且能很好地处理诸如图片、微软Word文档和电子表格之类的附件。

图18.1显示出的优秀特性之一就是，一个用户代理不必和邮件系统的其余部分运行在相同的系统，乃至相同的平台上。用户可以在登录到Linux台式机的时候，运行Linux带的许多用户代理中的一种，但他们也可以通过访问代理（AA）协议（例如IMAP或者POP），从自己的Windows笔记本电脑访问他们的电子邮件。迄今为止，这是最常见的配置方式。为什么说Windows和Linux不能和睦共处呢？下面列出了常用的用户代理及其最初的来源。

Red Hat和Fedora上的/bin/mail是原UNIX命令mail的BSD版本；在SUSE、Debian和Ubuntu上，它变成了/usr/bin/mail 。这个用户代理只支持文本，并且需要在本地保存邮件。
Mozilla的Thunderbird，有Linux、Windows和Mac OS的版本。
Evolution（也叫做Novell Evolution，以前叫Ximian Evolution），有Linux、Windows和Mac OS的版本。
华盛顿大学（University of Washington）的pine，www.washington.edu/pine。
Qualcomm的Eudora，用于Mac机或者运行Windows的PC。
微软的Outlook，也用于Windows。

18.1.2  传输代理

传输代理必须接受从用户代理那里来的邮件，读懂收件人的地址，并设法把邮件交给正确的主机进行投递。大多数传输代理还担当消息提交代理的角色，完成把新消息发送到邮件系统的功能。传输代理使用RFC821中定义的SMTP协议（Simple Mail Transport Protocol，简单邮件传输协议），或者使用RFC1869、RFC1870、RFC1891和RFC1985中定义的ESMTP协议（Extended SMTP，扩展的SMTP协议）。

UNIX和Linux系统有好几种传输代理（主要有PMDF、Postfix、smail、qmail、qmail和zmailer），但是sendmail是最全面、最灵活和使用范围最广的传输代理。2001年进行的一项有关邮件系统的调查 显示，sendmail占据了60%的份额，Exim为8%，Microsoft Exchange Server为4%，以及Postfix为2%，其他（它们大约有50种）则占据剩下的份额。
Red Hat、Fedora和SUSE Linux自带装好的sendmail。Debian表面上好像是带了sendmail，但是如果您仔细一看，会发现sendmail实际上是到Exim这个邮件传输代理的链接。Exim经过仔细地调整开发，已经能够理解sendmail的命令行标志。直接调用“sendmail”的用户代理应该是不知情的。Ubuntu默认带Exim。

18.1.3  投递代理

投递代理从传输代理那里接受邮件，并把它真正投递给适当的本地收件人。邮件可以投递给某个人、一个邮递列表、一个文件、甚至投递给一个程序。

每种类型的收件人可能需要一个不同的代理。/bin/mail是用于本地用户的投递代理。/bin/sh是发给文件或程序的邮件最初的投递代理，投递到文件则在内部处理。sendmail的新近版本附带了更安全的本地投递代理，名为mail.local和smrsh（念做“smursh”）。www.procmail.org的procmail也可以用作本地投递代理，参见18.9.16节。类似地，如果您运行Cyrus imapd作为AA（访问代理），它还包括自己的本地投递代理。

18.1.4  消息库

消息库是本地计算机上保存电子邮件的地方。它过去常常是目录/var/spool/mail或/var/mail，其中邮件被保存在以用户的登录名命名的文件中。这仍然是最常见的消息库，但拥有数千或数百万电子邮件客户的ISP们正在寻找用于消息库的其他技术（通常是数据库）。

在使用/var/spool/mail或/var/mail库的系统中，邮件目录是在操作系统的安装过程中创建的。除非您使用mail.local作为您的本地邮寄程序（在这种情况下，它的权限设置可能为755），否则应该把它的权限设置为模式775，属组为mail 。在我们举例的Linux平台上稍微有一点儿不同。

SUSE的权限要宽松一点儿，但是在邮件缓存目录中的文件模式为660，属组为root。设置了粘附位的目录（在权限位中的t）不允许用户彼此删除对方的文件，即便他们有这个目录的写权限也不行。不过，恶意的用户可以填满邮件缓存目录，把它当作一个乱写乱画的分区，或者创建另一个用户的邮箱。参考5.5.3节了解有关粘贴附件的更多信息。

18.1.5  访问代理

像imapd和spop这样的程序是PC、Mac或者Linux用户的访问代理，这些用户的邮件先投递到一台Linux服务器上，然后再分别用IMAP（Internet Message Access Protocol，Internet消息访问协议）或者POP（Post Office Protocol，邮局协议）下载。IMAP和POP在18.3.3节介绍。

18.1.6  邮件提交代理

邮件领域的另一个新产品是高容量站点所必需的，这就是邮件提交代理（mail submission agent）。在繁忙的主邮件枢纽上的传输代理要花费大量时间进行邮件消息的预处理：确保所有主机名是完整的，修改从已损坏的邮件用户代理（MUA）那里得到的信头、日志记录错误、重写信头等。RFC2476引入的思路是：将邮件提交代理（MSA）从邮件传输代理（MTA）中分离出来，以便分担工作负荷并获得最佳性能。

这种想法就是使用MSA，它在另一个端口上运行，作为处理由本地用户代理注入到邮件系统中的新消息的一种“招待员”。MSA负责消息由传输代理发送之前必须完成的所有预备工作和错误检验。它有点像在MUA和MTA之间插入一个头脑清楚的检验员。

特别地，MSA可确保所有的主机名都是完整的，它验证本地主机名在加上本地域部分之前是合法的。如果消息头部丢失或不一致，MSA还会修复它们。通常，MSA会添加一个From或Date头部，或调整Message-Id的头部。MSA能做的最后一项工作是把发件人的地址从登录名改写为更可取的外部形式，比如First_Last（译者注：这是按照西方人的习惯，“first name”也就是名在前，“last name”也就是姓在后）。

为了让这个方案生效，必须把用户代理配置成在端口587而不是端口25上连接MSA，后者是用于邮件的传统端口。如果用户代理不能识别端口587，您仍然可以在端口25上运行MSA，但是得在和MTA不同的另一台服务器。您还必须配置MTA，使得它不会重复MSA已完成的工作。重复处理不会影响邮件处理的正确性，但它确实意味着无用的额外工作。

在默认情况下，sendmail既可以担当MSA的角色也可以担当MTA的角色。从sendmail 8.10开始，运行一个单独命令就能监听25端口和587端口。用户代理经常直接带标志来调用sendmail，要求它接受一则邮件消息（-bs或者-bm），或者根本就不带标志，在后一种情况下，sendmail默认以-bm标志运行。sendmail进程跟踪调用它的方式，如果用-bs或者-bm标志调用它，它就变成MSA，如果用-bd标志调用它，它就变成MTA。

直接打开SMTP连接的用户代理必须进行修改，使用587端口来调用MSA。