电子邮件

团队介绍文案

我们是一个致力于用云计算技术改变现有企业IT模式的团队，希望您能认可这个技术趋势，让我们一起为改变世界而努力。当前我们专注于企业基础办公领域，提供SaaS模式的企业邮箱 产品，以及围绕邮箱的扩展增值服务。

1. 提供可靠的邮件传输服务。保障跨多个网络运营商的邮件顺畅传输，在外发和接收两个方向上均进行严格的垃圾邮件发送识别，以避免资源被滥用。
2. 提供POP、IMAP、SMTP等邮箱访问服务。尤其是基于浏览器的，以收件箱和联系人为核心，方便用户进行办公协同的 WebMail 系统；我们也在计划移动设备上的相应方案；这是我们整个"big story"的核心。
3. 为我们日常运营支撑而提供的一系列管理和运维平台；以及同客户自身的业务集成等的系列开发工作。

技术的挑战是，应对复杂的IDC和网络环境，如何构建出，并运维好一套分布式高可用的系统。电子邮件是现代企业办公的最最最基础组件，用户无法容忍哪怕是非常短暂的服务不可用， 这给我们的技术工作带来了诸多要求和限制条件，亦是艰苦工作背后的乐趣和价值体现。

Topic: 电子邮件

关于 Proxy Protocol

在生产环境中，Load Balancer 相当重要。常见硬件有 F5，软件有 LVS，或者更偏应用层的 HAProxy。

但实际运用中，怎么把 source ip/port 传递给后端的 real server 是一个大问题。因为realserver通常是需要这些信息用来记日志，或者安全防护策略应用之类。。。

如果是 F5，需要 real server 把自己的 default gateway 指向过去；如果是 LVS/HAProxy 也类似，需要LB服务器打开 TPROXY 内核选项，同时 realserver 有网段的限制。

上述的方案虽然透明，但是对网络结构有特殊要求，所以后来 HAProxy 的作者提出了 Proxy Protocol

现在至少 Postfix 2.10，甚至 Haraka 都能支持这个协议了。

HAProxy 很值得尝试

关于消费者邮箱使用的想法

从注册的角度来讲, 使用 QQ/Weibo 等第三方认证服务是符合逻辑的.

但是从客服的角度来讲, 让用户留下一个邮件地址, 或者留下一个电话号码也是符合逻辑的.

邮箱理应成为一个很好的客服平台(当然, 某种程度上客服也是最好的营销)

我们 SendCloud 在强调触发邮之余, 也应该宣传Email对于客服的意义. 触发邮不是这件事的目的, 共同为用户提供好的服务才是我们的目的.

以前可能因为社会习惯, 因为企业的意识, 因为缺乏好用的工具, 等等...我们对邮箱的客服作用发掘得不够. 更多的把邮箱当成了一个营销平台. 希望透过我们的努力, 可以改变这一点, 或者至少可以说我们为改变这一点提供基础服务.

目前 SendCloud 的用户里面, 应该有不少是把 Email 作为服务的一部分或者延伸来使用. 好的案例我们必须进行收集和推广.

换个角度, 为什么中国的在线 CRM 没有做起来? 再说说更近的例子, 微信的服务号最终会是个什么模式?

我觉得在从帐号服务, 到 EDM 之间, 应该还是有一个 CRM 的产品空间. 跨越 CRM 去做邮件营销, 尤其是意识上的跨越, 一定会出问题. 我们做触发邮也不会真正成功

解决 Outlook 2007 脱机通讯簿同步的 0x8004010F 错误

如果机器没有加入 AD 域，且管理员没有配置 autodiscover 的 DNS 记录，Outlook 2007 就无法同步脱机通讯簿了。

Outlook 同步中具体的流程见：http://www.cnblogs.com/maple/archive/2007/04/02/697491.html

解决方法很简单，询问IT同事后，知道我们的 autodiscover 服务就是在 mail.sohu-inc.com 上，然后配置 hosts 指向 autodiscover.sohu-inc.com 到服务器IP就行了

两个团队如何协同开发电子邮件系统？

从报导上看，最知名的例子可能是Coremail和163之间的关系。最近我也开始碰到这个问题了，武汉和北京之间怎么去协同？

f. Mobile App，甚至 Desktop App，这个需要再积累积累

IMAP 服务器重定向

这两天一直在思考公有云服务体系里面 zone、IDC 等概念，突然想邮件这一块：

4. 那标准协议呢？去搜索了一下，果然 IMAP 里面是有 MAILBOX-REFERRALS 和 LOGIN-REFERRALS 的。但据说没有客户端实现过对该能力的支持。囧

在公有云环境下，要想最大化保证客户邮件访问体验，自己做客户端看起来是必须的。over

如何做好一个 Mailbox Provider

至少需要做好4件事：

1. 一套好的信件存储服务和邮件索引服务（以及全文索引），及相关运维保障
2. 一套好的 MTA 运维体系及相关技术保障
3. email app
   • 二十年前，提供SMTP和POP3即可
   • 十五年前，还需要 web access
   • 五年前，IMAP4，对移动设备更加友好
   • 如今，有了ActiveSync还不够，还得考虑诸如 Mailbox 这样的独立 app provider 竞争
4. 数据服务

N年前，我看Gmail的招聘广告，工程师大概就是分成这4类。但是从知其然到知其所以然，需要很长的时间跨度。

--2016.01.11 Update，应该再加一个定语 free mailbox provider；企业邮箱服务至少不需要做数据服务（开展营销业务以完成闭环）

关于触发式邮件

我在和人谈起云的时候，常常这样比喻：云计算之于传统IT就好比发电厂取代蒸汽机一样，能源能够廉价地获取，极大得刺激了工业发展，然后反过来推动了对电力的需求，最终成长出新的能源行业；同样云计算虽然降低了IT拥有成本，但这会进一步推动计算应用的无所不在，最终云计算会是一个比传统IT更大的行业。

今天突然想到，类似 SendCloud 这样基础服务提供商的出现，是否也会推动触发邮市场的进一步扩展呢？

传统做邮件发送，量大了就会很麻烦。要去了解MTA，了解邮件队列管理，各种各样的协议，和不同的 MP 沟通，等等等等，然后就是数据分析，查询等等。如果每天邮件发送量到了1万封，就不是普通的企业邮箱能处理，而需要专用的服务器托管来发送；到了10万封这个级别，肯定需要有专门的工程师来花相当的精力做这个事，而且是经验非常丰富的工程师才能做明白。这在北上广深，就意味着每年要在这个项目上投入好几万甚至几十万，并承担巨大的风险——因为一旦这个工程师离职，想找个能替换的人还真麻烦。

于是要么三心二意地做，要么去寻求外包。但，在 SendGrid 打响 Transactional Email 这个名称之前，还真缺乏专业的服务提供商。我觉得 SendGrid，包括 MailChimp 等，一个很大的作用是让用户从事业起步开始，就以很小的成本体会到了这种专业化电子邮件运营服务为其带来的收益。

有这么一种可能，就是相当部分的触发邮，包括许可订阅的邮件需求，因为上述巨大的成本，以及缺乏针对性的、安全可靠的服务提供商（最后再加一个形容词，可弹性扩展的吧），被抑制住了。我们期望能够以优质的产品，把背后的需求释放出来。

关于 DSN/ESC

SMTP 协议除了 2XX,4XX,5XX 这些 status codes，后来又发展出一套 Enhanced Status Codes，最基本的在http://tools.ietf.org/html/rfc3463，后来又有 RFC 3886, 4468, 4865, 4954, 5248 不断补充。

除了仔细阅读 RFC 学习之外，微软 Exchange 有份文档描述了若干 ESC 的情况：http://technet.microsoft.com/zh-cn/library/bb232118%28v=exchg.150%29.aspx

也有人针对 Postfix 日志写了一个 DSN 翻译脚本：http://melinko2003.blogspot.com/2009/10/centos-postfix-dns-status-script.html

MailChimp 2012

http://mailchimp.com/2012/

期待 SendCloud 2013