9月18日，禅道釋出了7.3版本，這是禅道五年内釋出的第65個開源版本，也是我們和郵件通知鬥争五年的“血淚史”。這個版本我們最終內建了一個大招，來徹底解決郵件通知的問題。先賣個關子，後面詳細講我們的大招是啥。
禅道軟體在使用過程中的一個需求是需要将軟體裡面的各種動态消息通知到相關的人員。解決這個問題可以有很多種手段：用戶端軟體的提醒，qq的提醒， 微信的提醒，短信的提醒，郵件的提醒，浏覽器的桌面提醒等等。每種手段都有各自的優劣，然後我們與之奮鬥了五年之久的郵件就粉墨登場了。在上述的各種通知 手段中，以郵件通知最為廣泛，和使用者的使用習慣契合度也最為密切。說到這兒，也許有的朋友說，我們團隊郵件早都不用了。其實我們還是低估了郵件頑強的生命 力。郵件系統作為自網際網路初期就存在的基礎服務系統，有着廣泛的使用者基礎。一直有各種各樣的協同軟體試圖幹掉郵件，但很遺憾的是，到現在還沒有成功的案 例。
天真的想法：程式員應該搞得定smtp
故事的背景之一就是禅道主要的使用者是研發團隊，是以我們在最開始的時候天真的以為配置一個smtp發信伺服器對于做軟體研發的人來講，應當是很簡單的事情。
是以我們最開始的版本是提供了基于檔案的配置參數，使用者需要自己設定下smtp伺服器的位址，端口，是否需要登入，如果登入還需要設定使用者名，密碼等參數。
結果就是我們很快就發現我們實在是太天真了。太多的使用者搞不懂什麼是smtp伺服器，什麼是端口，什麼是加密，什麼是不加密，必須想其他的辦法。
整理名片的意外收獲
有一次我在整理名片的時候，觀察了下名片中所留的郵箱，發現無外乎分為兩種：公共郵箱和私有域名字尾的郵箱。公共郵箱比如gmail，qq郵箱等。 私有域名的郵箱又分為兩種啟動，自建郵件服務和使用第三方的企業郵箱服務。這樣分類下來，自建郵件服務的企業其實隻占很少的比例。于是就有了我們進一步的 解決方案：通過模闆來把80%左右的配置問題解決掉。我們整理了騰訊郵箱，163，263，gmail，新浪等國内常見的郵件服務商smtp伺服器參數的 模闆。并把使用者輸入的配置參數簡化為隻需要輸入一個郵箱位址，我們會自動推測其對應的配置參數。
我們會嘗試查找該域名對應的mx解析記錄，然後得出它背後使用的服務商，然後再根據相應的模闆來設定參數。
到了這一步，對于大多數使用者來講，可以把郵箱的配置簡化為隻需要輸入一個發信的位址，然後再輸入下密碼就可以了。終于我們清淨了好長一段時間。
風雲變幻，問題再出
解決了配置參數的問題，實際使用過程中的問題開始突出了。這些問題從分類來講可以分為以下四大類：
内部環境限制問題：比如無法做域名解析，php環境缺少ssl支援，安全級别過高等等。
第三方郵件服務商額外增加了很多限制，比如smtp服務預設關閉，開啟需要驗證碼等等。
發信速度慢導緻影響操作體驗的問題。我們嘗試提供了異步發信功能，這是另外一個大坑了。
郵件達到率的問題：現在禅道,zentao已經成了敏感詞，直接被幹掉的幾率很大。
這時候我們注意到了sendcloud的郵件通知服務，大招開始醞釀。
跳出圈外解決問題
sendcloud是一家專門提供郵件發送服務的廠商，我想應該有很多廠商在使用他們的服務了。禅道的saas服務也采用了sendcloud來發 送郵件，效果還是杠杠的，速度快，達到率高。出于防垃圾郵件的考慮，sendcloud的郵件服務還需要很多的設定，我想用過的朋友應該都有體會。這些設 置還是有一定的挑戰的。直接向我們的使用者推薦并不合适。sendcloud的郵件發送服務主要是面向的公網使用者，是以他們對防垃圾郵件的要求會比較高。但 如果具體到一個企業内部管理的場景來講，這些限制就可以忽略了。
于是我嘗試和sendcloud的同學發了一封郵件，解釋了下我們的應用場景和訴求，咨詢他們有沒有可能做一種專門面向企業内部應用場景的通知服 務。不需要其他的各種配置，使用者隻需要開通服務，設定發信的白名單，然後拿到一個id和私鑰，然後通過http接口就可以發信了。很開心地是 sendcloud的同學們很快就給了回應，很快他們的notice.sendcloud.net服務就推出來了。我們也很快地将這個服務內建到了禅道裡面。于是就有文章開頭所說的大招：
發信的時候可以選擇是smtp發信還是sendcloud發信。
故事講到了今天，終于可以告一段落了。但故事不會結束，和郵件的鬥争仍然會繼續，明天的故事，明天再繼續講吧。而且我相信，随着計算機的迅速發展，以及随之而來的系統越來越複雜，以及随之而來的使用者的動手能力越來越差。故事會越來越精彩，精彩程度肯定會超過“我的機器ping不通smtp伺服器，我怎麼發信呢？”