Postfix簡史：與病毒、垃圾和僵尸斗爭到底
原創本文根據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和僵尸們的斗爭仍在繼續。
【編輯推薦】
