本文根据IBM研发中心研究员，Postfix的创始人Wietse Venema在2010年LISA大会上的课程资料总结形成。
【51CTO精选译文】对于Postfix，想必大家都不会陌生。Postfix是历史悠久的电子邮件系统，目前全球很多大型邮件服务商提供的上亿个电子邮箱都是运行在Postfix之上，如国外常用的Outblaze，UOL，国内的263等。
1998年，全球大约70%的电子邮箱都运行在Sendmail之上。当时在IBM研发中心工作的Wietse Venema开发了一个叫做Secure Mailer的程序，也就是Postfix的前身。这个程序希望做到比Sendmail更加安全，更容易配置，并且有更高的性能。同样在1998年，IBM加入了Apache开源项目，而Secure Mailer也以Postfix的名称在IBM Public License下开源。
Postfix没有采取BSD/Unix上的Sendmail那种一体式的设计思路，而是采取了分布式安全架构的设计。这两种设计的区别可以参考下面两张图：
在Sendmail中，所有的接收和文件处理的过程都通过sendmail和/bin/mail这两个服务进行，而这两个服务都是在root权限下执行的。也就是说，远程用户可以轻易的以root权限执行任意命令或读写任意文件，而内部系统中隔离层的缺失，也意味着系统非常容易被入侵。
而在Postfix当中，整个系统分为了input，core和output三层，而在每一层中，不同的任务都通过不同的子模块来完成，如通过SMTP协议接收一个消息，发送一个消息，本地传递一个消息等，共计十多个子模块。除了最终需要执行系统命令和读写文件的两个模块是在root权限下运行之外，其他的模块都是在postfix权限下运行，这就避免了上述Sendmail的安全问题。后来的TIS防火墙、qmail、Apache和路由器都参考了这个架构思路，而Sendmail后来也根据这个架构进行了改良。
Postfix在性能优化方面参考了Web服务器的思路。按照Wietse的话来说，当服务器被放置在互联网上，那么原本最糟的情况会变成正常的情况，而正常的情况则会变成最遭的情况。比如说，Postfix可以被设计为尽可能快的传递邮件，但是在90%的邮件都是垃圾邮件的情况下，这样的设计就变成了一场灾难。又好比Postfix可以被设计为按顺序处理所有的SMTP客户端请求，但事实上，SMTP客户端端口可能会被无数个僵尸堵死。所以对于Postfix的优化而言，需要针对互联网上“最糟的情况”进行。
1999年，Melissa病毒席卷全球。Linux系统虽然不会感染病毒，但是Postfix服务器们却成为了病毒传播的载体。Postfix开发团队决定寻找一个长久的解决办法。这个方案必须基于已经成为标准的SMTP协议，而避免使用当时如雨后春笋般冒出的CVP、Milter等特殊的协议。
最简单的方式莫过于用两个Postfix，中间用一个专门用于过滤的服务来进行垃圾邮件清理，过滤器前后各有一个邮件队列（见下图）。
这样做的优点是配置简单，性能也不错，但是问题在于过滤器之后的那台Postfix只能通过quarantine（隔离）或discard（丢弃）来处理垃圾邮件，而无法采取reject（拒绝）的方式。这个倒也不是什么大问题，只是在一些欧洲国家会禁止邮件服务提供商在接收了邮件之后自行discard的做法。因此，Postfix的另一个过滤机制就是在邮件队列建立之前进行过滤（如下图）：
根据2007年O'Reilly Sysadmin针对全球40万家企业的调查报告数据，共有12.3%的企业采用Sendmail，8.6%的企业采用Postfix。
从Google Trend的趋势看来，过去几年间，无论是Sendmail也好还是Postfix也好，人们对邮件服务器的关注度一直在降低。
事实上，随着信息全球化的发展，更多个人和企业会选择大型的邮件服务提供方的邮件方案，一方面省却了自己配置的麻烦和成本，另一方面无论是跨国沟通的可靠性、安全性和反垃圾方面，大邮件服务提供方都有着天然的优势。
自己维护一个邮件服务器并不容易。从1999年到2009年，对互联网上的邮件服务器最大的威胁一直是安全。
1999年，你会在UNIX系统上建立一个邮件系统，不用烦恼服务器中病毒之类的问题，但是你那基于UNIX系统的邮件系统却成为了Windows病毒最大的传播源；
2009年，你在Linux系统上搭建了一套性能优秀的邮件系统，但是这个性能优秀的系统在92%的时间都在发送来自僵尸网络的垃圾邮件。
大量的僵尸拥挤在邮件服务器的端口处，阻塞整个交通。
在最糟的情况下，服务器会被僵尸网络所淹没。根据RFC 5321的建议，服务器端的timeout设置为5分钟为宜，而设置成5分钟timeout的postfix在遭遇僵尸网络的情况下，可能会造成所有的SMTP服务器端口都被堵死的结果。
遇到这种情况，如果置之不理，那么很大的可能是僵尸网络堵塞的情况越来越糟糕。解决方法分为两种，临时性的和持久性的。
临时性解决方法，无非就是减少每个SMTP客户端的处理时间，如减少time limits和rejected命令数量等。
#将Postfix master(8)守护进程定义为过载状态
smtpd -o stress=yes
#默认参数
smtpd_timeout = ${stress?10}${stress:300}s
smtpd_hard_error_limit = ${stress?1}${stress:20}
这样的处理方式可能会造成正常邮件发送的延迟，不过延迟总比完全发不出去要好多了。
持久性的解决方法有两个，一个就是配置更多的邮件服务器进程，上更多的带宽、内存、硬盘、CPU等等（前提是你有钱）；另一个很简单，就是在僵尸们到达服务器之前将它们过滤掉，即所谓的before-smtpd连接过滤器：postscreen。
postscreen(8)的很多理念来自Michael Tokarev在OpenBSD spamd和MailChannels Traffic Control当中的工作。postscreen的工作流程如下图描述：
简单来说就是根据白名单/黑名单决定每个流程中如何处理一个连接。为了防止被列入黑名单，僵尸们一般会避免在一段时间内重复骚扰同一个站点，所以除了本地名单之外，还会用到DNS上的黑名单/白名单。postscreen(8)能够将被认为是僵尸的连接在几个小时内列入黑名单，但是在此之前，它需要辨认究竟哪些是僵尸，哪些是正常的客户端。这点要如何实现？
Wietse将这个过程描述为一个捉狗的游戏。假设你是一个捉狗人，来到一个大房子外面，如何才能最快的确认房子里面是否有狗？答案就是，按下门铃，如果有狗的话就会立刻听见狗叫声。
postscreen(8)采用了类似的思路。SMTP连接建立的过程中，服务器端会发送欢迎信息，而客户端则在接收欢迎信息之后返回信息。好的SMTP客户端会等待完整的欢迎信息：
mail server: 220–server.example.com ESMTP Postfix<CR><LF> mail server: 220 server.example.com ESMTP Postfix<CR><LF> good client: HELO client.example.org<CR><LF>
而大多数僵尸则会提前说话，即pregreet：
postscreen: 220–server.example.com ESMTP Postfix<CR><LF> spambot: HELO i-am-a-bot<CR><LF>
结果证明这一个方法很有效。根据2010年9月间针对mail.python.org的一次数据收集，有超过70%的僵尸都会进行pregreet。
根据在不同邮件服务提供方的数据收集，发现的结论是，全球大部分垃圾邮件都来自少数几个国家，但针对不同邮件服务商来自不同国家的垃圾邮件流量是各自不同的。
另外一个发现是，垃圾邮件是个24小时持续不断的行为，但僵尸们的活动是有规律可循的。
2011年1月发布的Postfix 2.8.0中内置了postscreen守护进程，支持DNS白名单/黑名单以及相应的模式匹配。目前Postfix最新版本是5月7日发布的2.8.3版本。
结论
Postfix已经是一个相当成熟的系统，其模块化的设计可以允许维护人员/开发者在仅仅修改或添加一个小程序的情况下添加功能。这种可扩展性避免了用户修改Postfix本身的烦恼，并给予用户更多的选择。在未来很长一段时间内，僵尸网络仍然难以断绝，需要更加智能的连接过滤机制来维持邮件服务器的可运行性。Postfix和僵尸们的斗争仍在继续。
【编辑推荐】
