問題描述:
Linux系統下開發郵件系統的技術依據、實際意義、應用前景，外部環境概況、水平和發展趨勢等怎樣？現在在業界有沒有前途？
如果開發的話需要解決的重要問題有哪些？
解析:
Linux會是未來社會的主流,如果微軟的產品還是很貴的話,所以說開發LINUX是很有前途的
支持多傳輸域:sendmai支持在Inter, DEC, X.400及UUCP之間轉發消息。 Postfix則靈活的設計為無須虛擬域(vistual domai)或別名來實現這種轉發。但是在早期的發布裏僅僅支持STMP和有限度地支持UUCP,但對於我國用戶來說，多傳輸域的支持沒有什麽意義。
虛擬域:在大多數通用情況下，增加對壹個虛擬域的支持僅僅需要改變壹個Postfix查找信息表。其他的郵件服務器則通常需要多個級別的別名或重定向來獲得這樣的效果。
UCE控制(UCE,unsolicited mercial email): Postfix能限制哪個主機允許通過自身轉發郵件，並且支持限定什麽郵件允許接進。Postfix實現通常的控制功能:黑名單列表、RBL查找、HELO/發送者DNS核實。基於內容過濾當前沒有實現。
表查看: Postfix沒有實現地址重寫語言，而是使用了壹種擴展的表查看來實現地址重寫功能。表可以是本地 dbm或 db文件等格式。
Postfix體系結構及與Sendmail的比較
Postfix是基於半駐留，互操作的進程的體系結構，每個進程完成特定的任務，沒有任何特定的進程衍生關系(父子關系)。而且，獨立的進程來完成不同的功能相對於“單塊”程序具有更好的隔離性。此外，這種實現方式具有這樣的優點:每個服務如地址重寫等都能被任何壹個Postfix部件所使用，無須進程創建等開銷，而僅僅需要重寫壹個地址，當然並不是只有postfix采用這種方式。
Postfix是按照這種方式實現的:壹個駐留主服務器根據命令運行Postfix守護進程，守護進程完成發送或接收網絡郵件消息，在本地遞交郵件等等功能。守護進程的數目由配置參數來決定的，並且根據配置決定守護進程運行的次數(re-used times)，當空閑時間到達配置參數指定的限度時，自動消亡。這種方法明顯地降低了進程創建開銷，但是單個進程之間仍然保持了良好的隔離性。
Postfix的設計目標就是成為Sendmail的替代者。由於這個原因，Postfix系統的很多部分，如本地投遞程序等，可以很容易地通過編輯修改類似id的配置文件來替代。
Postfix的核心是由十多個半駐留程序實現的。為了保證機密性的原因，這些Postfix進程之間通過Unix的socket或受保護的目錄之下的FIFO進行通信。即使使用這種方法來保證機密性，Postfix進程並不盲目信任其通過這種方式接收到的數據。
Postfix進程之間傳遞的數據量是有限制的。在很多情況下，Postfix進程之間交換的數據信息只有隊列文件名和接收者列表，或某些狀態信息。壹旦壹個郵件消息被保存進入文件，其將在其中保存到被壹個郵件投遞程序讀出。
Postfix采用壹些通常的措施來避免丟失信息:在收到確認以前通過調用flush和fsync()保存所有的數據到磁盤中。檢查所有的系統調用的返回結果來避免錯誤狀況。
大多數構建郵件服務器者都會選擇sendmail，公平的來講sendmail是壹個不錯的MTA(Mail Transfer Agent)，最初開發時Eric Allman的設計考慮主要放在了郵件傳遞的成功性。不幸的是，Sendmai開發時沒有太多的考慮Inter環境下可能遇到的安全性問題。Sendmail在大多數系統上只能以根用戶身份運行，這就意味著任何漏洞都可能導致非常嚴重的後果，除了這些問題之外，在高負載的情況Sendmail運行情況不是很好。當然，Sendmail具有壹些缺點，其特色功能過多而導致配置文件的復雜性。當然，通過使用m4宏使配置文件的生成變的容易很多。但是，要掌握所有的配置選項是壹個很不容易的事情。Sendmail在過去的版本中出現過很多安全漏洞，所以使管理員不得不趕快升級版本。而且Sendmail的流行性也使其成為攻擊的目標，這有好處也有壞處:這意味著安全漏洞可以很快地被發現，但是同樣使Sendmail更加穩定和安全。另外壹個問題是Sendmail壹般缺省配置都是具有最小的安全特性，從而使Sendmail往往容易被攻擊。如果使用Sendmail，應該確保明白每個打開的選項的含義和影響。壹旦妳理解了Sendmail的工作原理，就Sendmail的安裝和維護就變的非常容易了。通過Sendmail的配置文件，用戶實現完成壹切可以想象得到的需求。
Qmail是壹個選擇，其在設計實現中特別考慮了安全問題。如果妳需要壹個快速的解決方案如，壹個安全的郵件網關，則Qmail是壹個很好的選擇。Qmail和Sendmail的配置文件完全不同。而對於Qmail，其有自己的配置文件，配置目錄中包含了5-30個不同的文件，各個文件實現對不同部分的配置(如虛擬域或虛擬主機等)。這些配置說明都在man中有很好的文檔，但是Qmail的代碼結構不是很好。
Qmail要比Sendmail小很多，其缺乏壹些現今郵件服務器所具有的特色功能。如不象Sendmail，qmail不對郵件信封的發送者的域名進行驗證，以確保域名的正確性。自身不提供對RBL的支持，而需要add-on來實現。，而Sendmail支持RBL。同樣Qmail不能拒絕接收目的接收人不存在信件，而是先將郵件接收下來，然後返回查無此用戶的的郵件。Qmail最大的問題就出在發送郵件給多個接收者的處理上。若發送壹個很大的郵件給同壹個域中的多個用戶，Sendmail將只向目的郵件服務器發送壹個郵件拷貝。而Qmail將並行地連接多次，每次都發送壹個拷貝給壹個用戶。若用戶日常要發送大郵件給多個用戶，使用Qmail將浪費很多帶寬。可以這麽認為:Sendmail優化節省帶寬資源，Qmail優化節省時間。若用戶系統有很好的帶寬，Qmail將具有更好的性能，而如果用戶系統的帶寬資源有限，並且要發送很多郵件列表信息，則Sendmail效率更高壹些。Qmail不支持.forward(.forward在很多情況下對用戶很有用處);不使用/var/spool/mail，而是將郵件存放在用戶home目錄。下面是壹些使用Qmail不容易完成的工作，要使用Qmail完成這些工作，可能需要用戶自己動手實現或者使用第三方提供的不夠可靠的模塊。
Qmail的源代碼相對於Sendmail來說要更加容易理解，這對於希望深入到內部了解MTA機制的人員來說是壹個優點。Qmail在安全性方面也要穩定壹些。Qmail有很好的技術支持，但是沒有象Sendmail那樣被廣泛地應用和大量的管理員用戶群。Qmail的安裝不象Sendmail那樣自動化，需要手工步驟。而且Qmail的文檔不如Sendmail那樣完整和豐富。
Qmail的add-ons比Sendmail要少壹些。壹般來說對於經驗稍微少壹些的管理員，選擇Qmail相對要好壹些。Qmail要簡單壹些，而且其特色功能能滿足壹般用戶的需求。Sendmail類似於Office套件，80%的功能往往都不被使用。這就使Qmail在壹些場合可能被更受歡迎壹些，其具有壹些Sendmail所沒有的更流行和實用的特色功能，如mail具有內置的pop3支持。Qmail同樣支持如主機或用戶的偽裝、虛擬域等等。Qmail的簡單性也使配置相對容易壹些。