一個開源軟件做者和郵件通知奮鬥的血淚史

序章：

9月18日，禪道發佈了7.3版本，這是禪道五年內發佈的第65個開源版本，也是咱們和郵件通知鬥爭五年的「血淚史」。這個版本咱們最終集成了一個大招，來完全解決郵件通知的問題。先賣個關子，後面詳細講咱們的大招是啥。

背景：

禪道(http:/www.zentao.net)是咱們團隊開發的一款開源項目管理軟件，主要定位是研發項目管理。面向的用戶羣體主要是研發團隊，部署場景主要是企業內部的私有服務器。這是咱們這個故事的大背景。而後悲慘的故事就開始了。

打不死的小強：Email

禪道軟件在使用過程當中的一個需求是須要將軟件裏面的各類動態消息通知到相關的人員。解決這個問題能夠有不少種手段：客戶端軟件的提醒，QQ的提醒， 微信的提醒，短信的提醒，郵件的提醒，瀏覽器的桌面提醒等等。每種手段都有各自的優劣，而後咱們與之奮鬥了五年之久的郵件就粉墨登場了。在上述的各類通知 手段中，以郵件通知最爲普遍，和用戶的使用習慣契合度也最爲密切。說到這兒，也許有的朋友說，咱們團隊郵件早都不用了。其實咱們仍是低估了郵件頑強的生命 力。郵件系統做爲自互聯網初期就存在的基礎服務系統，有着普遍的用戶基礎。一直有各類各樣的協同軟件試圖幹掉郵件，但很遺憾的是，到如今尚未成功的案 例。

天真的想法：程序員應該搞得定smtp

故事的背景之一就是禪道主要的用戶是研發團隊，因此咱們在最開始的時候天真的覺得配置一個smtp發信服務器對於作軟件研發的人來說，應當是很簡單的事情。

因此咱們最開始的版本是提供了基於文件的配置參數，用戶須要本身設置下smtp服務器的地址，端口，是否須要登陸，若是登陸還須要設置用戶名，密碼等參數。

$config->mail->fromAddress = '';            // The from address.
$config->mail->fromName    = '';            // The from name.
$config->mail->mta         = 'smtp';        // The send mail type.
$config->mail->smtp->debug    = 0;          // Debug level, 0,1,2.
$config->mail->smtp->charset  = 'utf-8';    // Charset 
$config->mail->smtp->auth     = true;       // Need auth or not. true|false
$config->mail->smtp->host     = 'localhost';// The smtp server host address.
$config->mail->smtp->port     = '25';       // The smtp server host port.
$config->mail->smtp->secure   = '';         // The type to encode datas, 'ssl' or 'tls' allowed
$config->mail->smtp->username = '';         // The smtp user, may be a full email adress.
$config->mail->smtp->password = '';         // The smtp user's password.

結果就是咱們很快就發現咱們實在是太天真了。太多的用戶搞不懂什麼是smtp服務器，什麼是端口，什麼是加密，什麼是不加密，必須想其餘的辦法。

整理名片的意外收穫

有一次我在整理名片的時候，觀察了下名片中所留的郵箱，發現無外乎分爲兩種：公共郵箱和私有域名後綴的郵箱。公共郵箱好比gmail，qq郵箱等。 私有域名的郵箱又分爲兩種啓動，自建郵件服務和使用第三方的企業郵箱服務。這樣分類下來，自建郵件服務的企業其實只佔不多的比例。因而就有了咱們進一步的 解決方案：經過模板來把80%左右的配置問題解決掉。咱們整理了騰訊郵箱，163，263，gmail，新浪等國內常見的郵件服務商smtp服務器參數的 模板。並把用戶輸入的配置參數簡化爲只須要輸入一個郵箱地址，咱們會自動推測其對應的配置參數。

咱們會嘗試查找該域名對應的mx解析記錄，而後得出它背後使用的服務商，而後再根據相應的模板來設置參數。

到了這一步，對於大多數用戶來說，能夠把郵箱的配置簡化爲只須要輸入一個發信的地址，而後再輸入下密碼就能夠了。終於咱們清淨了好長一段時間。

風雲變幻，問題再出

解決了配置參數的問題，實際使用過程當中的問題開始突出了。這些問題從分類來說能夠分爲如下四大類：

1. 內部環境限制問題：好比沒法作域名解析，php環境缺乏ssl支持，安全級別太高等等。
2. 第三方郵件服務商額外增長了不少限制，好比smtp服務默認關閉，開啓須要驗證碼等等。
3. 發信速度慢致使影響操做體驗的問題。咱們嘗試提供了異步發信功能，這是另一個大坑了。
4. 郵件達到率的問題：如今禪道,zentao已經成了敏感詞，直接被幹掉的概率很大。

這時候咱們注意到了sendcloud的郵件通知服務，大招開始醞釀。

跳出圈外解決問題

sendcloud是一家專門提供郵件發送服務的廠商，我想應該有不少廠商在使用他們的服務了。禪道的saas服務也採用了sendcloud來發 送郵件，效果仍是槓槓的，速度快，達到率高。出於防垃圾郵件的考慮，sendcloud的郵件服務還須要不少的設置，我想用過的朋友應該都有體會。這些設 置仍是有必定的挑戰的。直接向咱們的用戶推薦並不合適。sendcloud的郵件發送服務主要是面向的公網用戶，因此他們對防垃圾郵件的要求會比較高。但 若是具體到一個企業內部管理的場景來說，這些限制就能夠忽略了。

因而我嘗試和sendcloud的同窗發了一封郵件，解釋了下咱們的應用場景和訴求，諮詢他們有沒有可能作一種專門面向企業內部應用場景的通知服 務。不須要其餘的各類配置，用戶只須要開通服務，設置發信的白名單，而後拿到一個id和私鑰，而後經過http接口就能夠發信了。很開心地是 sendcloud的同窗們很快就給了迴應，很快他們的notice.sendcloud.net服務就推出來了。咱們也很快地將這個服務集成到了禪道里面。因而就有文章開頭所說的大招：

發信的時候能夠選擇是smtp發信仍是sendcloud發信。

故事講到了今天，終於能夠告一段落了。但故事不會結束，和郵件的鬥爭仍然會繼續，明天的故事，明天再繼續講吧。並且我相信，隨着計算機的迅速發展，以及隨之而來的系統愈來愈複雜，以及隨之而來的用戶的動手能力愈來愈差。故事會愈來愈精彩，精彩程度確定會超過「個人機器ping不通smtp服務器，我怎麼發信呢？」