第18章 Linux 电子邮件.docx
- 文档编号:10294494
- 上传时间:2023-02-09
- 格式:DOCX
- 页数:153
- 大小:173.15KB
第18章 Linux 电子邮件.docx
《第18章 Linux 电子邮件.docx》由会员分享,可在线阅读,更多相关《第18章 Linux 电子邮件.docx(153页珍藏版)》请在冰豆网上搜索。
第18章Linux电子邮件
第18章电子邮件
很难记起没有电子邮件的世界是个什么样子了。
从学校里的孩子到老奶奶,再到公司里最落伍的员工,每个人现在都会例行公事般地使用电子邮件联系家人、同事、伙伴、客户甚至政府。
真是一个电子邮件的疯狂世界[14]。
电子邮件之所以流行,是因为公众能够轻而易举地理解发一则消息的概念,这个概念的模型与传统的书面信件非常近似。
电子邮件就“那么简单”,如果您知道某个人的电子邮件地址,您就可以敲一则消息,写上他们的地址,然后按“发送”。
哇!
几秒之后,这则消息就送到了他们的电子邮箱里,不管他们就在隔壁还是半个地球以外。
从用户的角度来看,没有比这更容易的了。
遗憾的是,事情不总是这样的容易,即使在今天,保证在这样大的范围内实现电子邮件通信所依靠的下层基础设施的任务仍然相当繁重。
您可以在Linux上运行几种软件包来传输和管理电子邮件(本章后面讨论其中的3种),但是它们都要求做一定程度的配置和管理。
此外还有一点很重要,就是您要理解与电子邮件相关的底层概念和协议,从而不会给自己的用户养成错觉,以为在单位之间跨平台的电子邮件是老天送来的礼物,每次都能奇迹般地做到。
现如今,理解和管理电子邮件基础设施还有另外一些方式。
现在一些服务提供商提供了“被管”电子邮件服务,电子邮件实际上托管在很远之外的数据中心里提供商的服务器上,您按月或者按年(可能还要按人)支付访问费用。
类似地,还有一些免费的“托管”服务,如Yahoo!
Mail、MSNHotmail和Google的Gmail都已经在个人中非常流行。
如果您正在为个人找一个电子邮件账号,或者在为一家(非常)小的公司找一个账号,那么这些都可供您选择。
这些服务卸掉了若干负担,举例来说包括存储、服务器管理、软件升级、配置、垃圾邮件过滤和保持安全警惕。
作为对其“免费”服务的回报,或许您要看到一些广告。
这似乎在许多情况下都很理想,如果这样的选择适合于您,那么您至少能得益于不用读本章余下的内容啦。
不过,托管的电子邮件并不是每个人的解决方案。
商业公司,以及其他依靠电子邮件服务来运行的大型机构,往往都不会冒风险去把电子邮件托管到异地。
这样的机构可能有各种不同的理由运行自己的电子邮件系统,包括安全、性能和可用性。
本章的内容就是面向这些人的。
本章篇幅较长,这也印证了电子邮件系统的复杂性。
本章既包含了背景知识,也包含了软件配置的细节信息,讲述的顺序也大致如此。
我们曾试着把这一章分成较短的几章(邮件系统、sendmail配置、垃圾邮件、Exim和Postfix),但这样写会在内容上充满了死循环问题,令人不好理解,而且我们以为,这样做用处不大。
我们代之以在表18.1中给出带注释的目录。
表18.1 本章的编排
小 节
内 容
背景知识
1
邮件系统及其各个组成部分
2
寻址、地址语法、邮件信头
3
原理、客户机/服务器的设计、邮件之家
4
别名、邮件路由、邮递列表软件、LDAP
5
邮递列表软件
sendmail的配置
6
sendmail:
安装、启动、邮件队列
7
配置sendmail初探,m4宏
8
基本的sendmail配置原语
9
高级的sendmail配置原语
10
垃圾邮件,sendmail访问数据库
11
配置案例学习
12
安全
13
性能
14
收集统计信息、测试和调试
其他
15
Exim,sendmail的替代软件
16
Postfix,sendmail的另一种替代软件
17
更多的资料来源
在依次阅读本章的内容时,这样的组织会使读者觉得内容更顺畅一些,但有时会被某些内容给打散了,这些内容介绍了某种与电子邮件相关的特定任务。
对于中等规模单位的邮件服务负责人来说,可能需要阅读整章内容。
如果只是为一般的公司客户设置PC支持电子邮件,对于这样的系统管理员来说,就没必要这么做了。
表18.2为一些常见的系统管理工作提供了一份引导指南。
表18.2 工作索引
工 作
小 节
工 作
小 节
升级sendmail
6,7
为一个站点设计邮件系统
3,4,5,6,7,8,9,10,11
第一次配置sendmail
3,6,7,8,9,10,11,12
反垃圾邮件
10
改变配置文件
7
审计安全性
12
续表
工 作
小 节
工 作
小 节
设置PC收邮件
1,3
虚拟主机
9
设置邮递列表
5
使用Exim代替sendmail
15
性能调优
3,9,13
使用Postfix代替sendmail
16
本章的大部分内容都是在讲述sendmail的配置,它是分析和传递电子邮件的标准程序。
sendmail最初是加州大学伯克利分校(UniversityofCalifornia,Berkeley)的EricAllman编写的。
sendmail有3个主要的版本:
版本5、IDA以及版本8。
最近,全新设计的版本sendmailX已经发布了一个早期的beta版,但还没有准备好可以供生产环境使用(根据圈内人透露,它可能永远也代替不了sendmail8)。
版本5和IDA已经不常使用,而由版本8取代了它们。
在本章中我们讨论版本8(精确地说是8.13)。
sendmail正在由Sendmail,Inc公司进行商业开发,该公司还维护着一个免费的、开放源代码的版本。
商业版本的特色是图形化的用户配置界面以及中央监控和报告功能(这是对于用户数量庞大的邮件站点来说特别有用的功能)。
18.1 邮件系统
从理论上说,一个邮件系统由4个不同的部分组成。
— 让用户阅读和撰写邮件的“邮件用户代理”(mailuseragent,MUA)。
— 在机器之间发送消息的“邮件传输代理”(mailtransportagent,MTA)。
— 把消息放到本地消息库[15]中的“投递(delivery)代理”;它有时叫做本地投递代理(LocalDeliveryAgent,LDA)。
— 可有可无的“访问代理(accessagent)”,它可以把用户代理连接到消息库(例如,通过IMAP或POP协议)。
有些站点还使用一种邮件提交(submission)代理,这种代理使用SMTP(simplemailtransportprotocol,简单邮件传输协议),并完成传输代理的一些工作。
图18.1显示了这些组成部分的相互关系。
图18.1 邮件系统的组成部分
18.1.1 用户代理
电子邮件用户使用用户代理来阅读和撰写消息。
电子邮件消息最初只由文本组成,但现在用一种称为MIME(MultipurposeInternetMailExtensions,多用途网际邮件扩充协议)的标准可以把文字格式和附件(包括许多病毒)编码后加入到电子邮件中。
大多数用户代理都支持它。
因为它并不影响邮件的寻址或传送,所以我们不在本章中对它作进一步讨论。
用户代理的一项工作是确保在邮件消息的内容中嵌入的任何可能被邮件系统误解的文字得到保护。
用作消息之间记录分隔符的字符串“From”就是一个例子。
/bin/mail是最初的用户代理,对于从shell提示符下阅读文本类的电子邮件消息来说,仍然是个随时能用的好工具(译者注:
原文ol’standby的意思是onlinestandby,即“在线待命”。
自从知名网站AOL诞生之后,OL在网上就成了ONLINE的流行缩写)。
不论这是好是坏,Internet上电子邮件已经超越了文本时代,所以对大多数用户来说,基于文本的用户代理不再实用了。
图形用户界面支持以“鼠标指点”方式访问邮件消息,并且能很好地处理诸如图片、微软Word文档和电子表格之类的附件。
图18.1显示出的优秀特性之一就是,一个用户代理不必和邮件系统的其余部分运行在相同的系统,乃至相同的平台上。
用户可以在登录到Linux台式机的时候,运行Linux带的许多用户代理中的一种,但他们也可以通过访问代理(AA)协议(例如IMAP或者POP),从自己的Windows笔记本电脑访问他们的电子邮件。
迄今为止,这是最常见的配置方式。
为什么说Windows和Linux不能和睦共处呢?
下面列出了常用的用户代理及其最初的来源。
— RedHat和Fedora上的/bin/mail是原UNIX命令mail的BSD版本;在SUSE、Debian和Ubuntu上,它变成了/usr/bin/mail[16]。
这个用户代理只支持文本,并且需要在本地保存邮件。
— Mozilla的Thunderbird,有Linux、Windows和MacOS的版本。
— Evolution(也叫做NovellEvolution,以前叫XimianEvolution),有Linux、Windows和MacOS的版本。
— 华盛顿大学(UniversityofWashington)的pine,www.washington.edu/pine。
— Qualcomm的Eudora,用于Mac机或者运行Windows的PC。
— 微软的Outlook,也用于Windows。
18.1.2 传输代理
传输代理必须接受从用户代理那里来的邮件,读懂收件人的地址,并设法把邮件交给正确的主机进行投递。
大多数传输代理还担当消息提交代理的角色,完成把新消息发送到邮件系统的功能。
传输代理使用RFC821中定义的SMTP协议(SimpleMailTransportProtocol,简单邮件传输协议),或者使用RFC1869、RFC1870、RFC1891和RFC1985中定义的ESMTP协议(ExtendedSMTP,扩展的SMTP协议)。
UNIX和Linux系统有好几种传输代理(主要有PMDF、Postfix、smail、qmail、Exim和zmailer),但是sendmail是最全面、最灵活和使用范围最广的传输代理。
2001年进行的一项有关邮件系统的调查[17]显示,sendmail占据了60%的份额,Exim为8%,MicrosoftExchangeServer为4%,以及Postfix为2%,其他(它们大约有50种)则占据剩下的份额。
RedHat、Fedora和SUSELinux自带装好的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节。
类似地,如果您运行Cyrusimapd作为AA(访问代理),它还包括自己的本地投递代理。
18.1.4 消息库
消息库是本地计算机上保存电子邮件的地方。
它过去常常是目录/var/spool/mail或/var/mail,其中邮件被保存在以用户的登录名命名的文件中。
这仍然是最常见的消息库,但拥有数千或数百万电子邮件客户的ISP们正在寻找用于消息库的其他技术(通常是数据库)。
在使用/var/spool/mail或/var/mail库的系统中,邮件目录是在操作系统的安装过程中创建的。
除非您使用mail.local作为您的本地邮寄程序(在这种情况下,它的权限设置可能为755),否则应该把它的权限设置为模式775,属组为mail[18]。
在我们举例的Linux平台上稍微有一点儿不同。
SUSE的权限要宽松一点儿,但是在邮件缓存目录中的文件模式为660,属组为root。
设置了粘附位的目录(在权限位中的t)不允许用户彼此删除对方的文件,即便他们有这个目录的写权限也不行。
不过,恶意的用户可以填满邮件缓存目录,把它当作一个乱写乱画的分区,或者创建另一个用户的邮箱。
参考5.5.3节了解有关粘贴附件的更多信息。
18.1.5 访问代理
像imapd和spop这样的程序是PC、Mac或者Linux用户的访问代理,这些用户的邮件先投递到一台Linux服务器上,然后再分别用IMAP(InternetMessageAccessProtocol,Internet消息访问协议)或者POP(PostOfficeProtocol,邮局协议)下载。
IMAP和POP在18.3.3节介绍。
18.1.6 邮件提交代理
邮件领域的另一个新产品是高容量站点所必需的,这就是邮件提交代理(mailsubmissionagent)。
在繁忙的主邮件枢纽上的传输代理要花费大量时间进行邮件消息的预处理:
确保所有主机名是完整的,修改从已损坏的邮件用户代理(MUA)那里得到的信头、日志记录错误、重写信头等。
RFC2476引入的思路是:
将邮件提交代理(MSA)从邮件传输代理(MTA)中分离出来,以便分担工作负荷并获得最佳性能。
这种想法就是使用MSA,它在另一个端口上运行,作为处理由本地用户代理注入到邮件系统中的新消息的一种“招待员”。
MSA负责消息由传输代理发送之前必须完成的所有预备工作和错误检验。
它有点像在MUA和MTA之间插入一个头脑清楚的检验员。
特别地,MSA可确保所有的主机名都是完整的,它验证本地主机名在加上本地域部分之前是合法的。
如果消息头部丢失或不一致,MSA还会修复它们。
通常,MSA会添加一个From或Date头部,或调整Message-Id的头部。
MSA能做的最后一项工作是把发件人的地址从登录名改写为更可取的外部形式,比如First_Last(译者注:
这是按照西方人的习惯,“firstname”也就是名在前,“lastname”也就是姓在后)。
为了让这个方案生效,必须把用户代理配置成在端口587而不是端口25上连接MSA,后者是用于邮件的传统端口。
如果用户代理不能识别端口587,您仍然可以在端口25上运行MSA,但是得在和MTA不同的另一台服务器。
您还必须配置MTA,使得它不会重复MSA已完成的工作。
重复处理不会影响邮件处理的正确性,但它确实意味着无用的额外工作。
在默认情况下,sendmail既可以担当MSA的角色也可以担当MTA的角色。
从sendmail8.10开始,运行一个单独命令就能监听25端口和587端口。
用户代理经常直接带标志来调用sendmail,要求它接受一则邮件消息(-bs或者-bm),或者根本就不带标志,在后一种情况下,sendmail默认以-bm标志运行。
sendmail进程跟踪调用它的方式,如果用-bs或者-bm标志调用它,它就变成MSA,如果用-bd标志调用它,它就变成MTA。
直接打开SMTP连接的用户代理必须进行修改,使用587端口来调用MSA。
18.2 剖析邮件消息
在深入研究sendmail配置之前,我们必须理解邮件消息的3个不同部分:
— 信封(envelope);
— 信头(header);
— 消息主体(bodyofmessage)。
信封确定消息将投递到哪里,或者如果消息不能投递出去的话,应该把它返回给谁。
对于单个收件人来说,信封地址通常与信头的From和To行一致,如果消息是发送给一个邮递列表的,那么就不一致了。
地址是单独提供给MSA的。
信封对用户不可见,它不是消息本身的一部分,它供sendmail在内部确定把这则消息发送到哪里。
信头是一组格式遵循RFC822的属性/值。
它们记录与消息有关的各种信息,比如发送的日期和时间、它在旅程中经过哪些传输代理传递等。
信头是邮件消息的一个真实部分,只不过用户代理向用户显示消息时通常会隐藏一些不太引人注意的项。
消息的主体是将要发送的实际内容。
它必须由纯文本组成,虽然文本经常表示各种二进制内容,但此时采用了对邮件来说是安全的编码方式。
当我们在介绍配置的小节时,有时会谈到信封发件人和收件人,有时则会谈到信头发件人和收件人。
我们总是试图在上下文中不能确定的地方指出我们正在谈论的是哪种地址。
18.2.1 邮件寻址
本地寻址很简单,因为用户的登录名就是一个唯一的标识符。
Internet地址也很简单:
user@host.domain或者user@domain。
在电子邮件和Internet的早期时代,表18.3列出的地址形式是很常见的。
表18.3 过时的地址类型举例
地址类型
地址的例子
现代的形式
UUCP
mcvax!
uunet!
ucbvax!
hao!
boulder!
lair!
evi
evi@lair
基于路径
<@site1,@site2,…,@siteN:
user@final-site>
user@final.site
“百分号扩展”
user%host1%host2@host3
user@host1
sendmail配置中的复杂性大多源自早期对处理这样的地址的要求。
这些寻址形式都依赖于中继转发(relaying),而幸亏有了发垃圾邮件的家伙(spammer),各站点逐渐关闭了中转功能。
spammers企图隐藏自己的身份,或通过您的机器中转邮件,“百分号扩展(percenthack)”(表18.3中最后一行)是他们最喜欢的一种工具。
如果您需要处理这里面的任何一种地址形式,请参考sendmail文档,寻求帮助。
18.2.2 阅读邮件信头
每一则邮件消息都从称为信头(header)的若干行开始,信头中包含着有关这则消息的信息。
每个信头以一个关键字打头,比如To、From或Subject,后面跟着一个冒号和该信头的内容。
标准信头的格式在RFC822中定义,不过,自定义信头也是允许的。
任何以“X-”打头的信头都将被邮件系统忽略,但会随着消息传送。
因此,您可以给电子邮件消息添加一个信头,比如X-Joke-of-the-Day,这不会干扰邮件系统发送它们的能力[19]。
有些信头是由用户代理添加的,另一些则是由传输代理添加的。
有些信头会记录下消息通过邮件系统的路径。
许多用户代理会对您隐藏这些“人们不感兴趣”的信头,但通常可以选择让代理把它们全部显示出来。
当我们被垃圾邮件轰炸,而有时必须回溯一则消息的来源时,阅读信头就成为了一项重要的技巧。
下面是来自一则简单消息的信头部分:
这则消息完全停留在本地计算机上,发件人是trent,而收件人是ned。
第一个From行是由mail.local添加的,mail.local此时是本地投递代理。
信头中的Subject和Cc两行是由trent的邮件用户代理加的,它可能还会加上信头中的To、From和Date行。
如果MUA没有提供信头中的To、From和Date行的话,那么邮件传输代理sendmail会加上它们。
每台接触到这则消息的机器(或者更精确地说,是每个MTA)都会添加一个Received信头。
邮件消息中的信头包含着有关这则消息到过哪里,它在那里停留了多长时间,以及它最终是何时投递到其目的地等大量信息。
下面是通过Internet发送的一则邮件消息的更完整的剖析。
其中穿插了注释,用来描述各种信头的用途并标识出添加它们的程序。
左边的行号是为了方便在下面的讨论中引用,而并非消息的一部分。
某些行折成了好几行,这是为了让例子能在一页里显示得下。
1:
Fromeric@knecht.sendmail.org
第1行由/bin/mail或mail.local在最后一次投递的过程中添加,用于将这则消息与收件人邮箱中的其他消息区分开。
有些邮件阅读器是通过寻找后面跟着字符“From”的空行来辨认出消息边界的,请注意后缀的空格。
在这则消息投递之前,这一行并不存在,它不同于“From”信头行。
许多邮件阅读器不会显示这一行,因此您可能根本看不到它。
2:
Return-Path:
eric@knecht.Neophilic.COM
第2行指定一条返回路径,它可能与邮件信头中稍后的From行上显示的地址不一样。
出错信息应该发送到Return-Path信头行中的地址,里面信封上有发件人地址。
3:
Delivery-Date:
Mon,06Aug 2001 14:
31:
07–0600
第3行显示了邮件投递到Evi的本地邮箱中的日期。
它包括从本地时区(MDT,美国山地时区时间)到UTC的偏移量。
第4~7行记录下这则消息在到用户邮箱的路上经过的各种系统的通道。
每台处理邮件消息的机器都会在消息的信头中添加一个Received行。
新的行添加在顶端,所以在阅读它们时,您是从收件人到发件人跟踪消息的。
如果正在查看的消息是一则垃圾邮件,那么您真正可以相信的唯一一个Received行就是由您本地计算机生成的那行。
每个Received行包含发送它的机器的名称、接收它的机器的名称、接收机器上sendmail(或使用的任何传输代理)的版本、接收机器上这则消息的唯一标识号、收件人(如果只有一项的话)、日期和时间、最后是本地时区与UTC(UniversalCoordinatedTime,世界协调时间,以前叫做GMT,即GreenwichMeanTime,格林威治标准时间)的偏移量。
这一数据是从sendmail的内部宏变量那里收集的。
在接下来的几段中,我们将从发件人到收件人跟踪这则消息(从信头行的角度说,就是反过来看)。
第7行说明这则消息从knecht的localhost接口(Eric[译者注:
这是sendmail的作者EricAllman]写的特殊邮件用户代理选择这个接口用于其初始连接)通过内核的伪设备loopback到达knecht的外部接口。
第6行记录的是:
knecht随后将这则消息发向mroe.cs.colorado.edu,虽然消息的地址是evi@anchor.cs.colorado.edu(请参见信头第9行)。
用nslookup或dig快速检查一下可以看到,主机anchor有一个MX记录指向mroe,正是它使得投递被转了方向。
knecht这台机器正在运行的sendmail版本是8.12.0Beta16。
有关MX记录的更多信息请参考15.7.6节。
机器mroe运行sendmail的版本是8.10.1,当消息位于队列中时,这则消息用队列标识ID号f76KV5Q17625标识出来。
随后mroe把这则消息按地址(第5行)转发给anchor.cs.colorado.edu,这可能看上去显得有点儿意外。
由于MX记录的缘故,原来knecht发出要到anchor的邮件,却转到了mroe。
之所以出现这种明显不一致的现象,原因是cs.colorado.edu这个域使用了“分离式DNS(splitDNS)”的配置。
从外界能够看到的anchor的MX记录指向了内部的邮件主控机(mroe)。
不过,在cs.colorado.edu域的内部看到的则是不同的一个记录。
内部版本的记录首先指向anchor自己,然后把mroe作为一个备份。
一
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 第18章 Linux 电子邮件 18