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服务器，我怎么发信呢？”