电子邮件

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

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

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

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

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

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

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

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

如果机器没有加入 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之间的关系。最近我也开始碰到这个问题了，武汉和北京之间怎么去协同？

按照上篇文章列出的1/2/3，计划是这样，
a. MTA 体系双方各自建设
b. 武汉负责反垃圾邮件引擎的支持，但对外发送方面，两边也是各用各自的方案
c. 每次持久数据结构大变动是一次Major版本升级，小变动算Minor升级。Major升级应该主要是由北京这边推动的
d. web access 双方各自发展
e. 标准协议北京主导
f. Mobile App，甚至 Desktop App，这个需要再积累积累

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

1. web 访问由于有 301/302 跳转，是容易的
2. 自己做客户端访问，也是容易的
3. 微软的体系，Exchange 里面有 ExternalURL，想来 ActiveSync 应该有类似的协议机制
4. 那标准协议呢？去搜索了一下，果然 IMAP 里面是有 MAILBOX-REFERRALS 和 LOGIN-REFERRALS 的。但据说没有客户端实现过对该能力的支持。囧

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

至少需要做好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 等，一个很大的作用是让用户从事业起步开始，就以很小的成本体会到了这种专业化电子邮件运营服务为其带来的收益。

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

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

http://mailchimp.com/2012/

期待 SendCloud 2013

武汉除了 SendCloud 之外，个人邮箱的团队也开始建设了。继上次立鹏同学之后，本晚我又进行了一次技术的讲解，内容包括：

• sohumc package，立马有同学指出用现在 kan.sohu.com 使用的是 python-virtualenv
• sohu 的 Maildir 内容，以及 deliver
  • tmp->new，隔离 deliver 逻辑
  • new->cur，隔离 mua 逻辑
  • 过滤器的一个小细节
  • SQL索引和搜索索引
• MX 的几个要点
  • tcptable、milter 协议
  • 队列、磁盘性能
  • 尽可能早地发现 spammer，断开连接
  • postfix 并发能力限制，以及将来的资源隔离保护的设想
  • 包括向后台投递在内，任何一个环节故障，都会导致 MX 的不良反应
• tcptable ，以及企邮团队在2012年踩的坑
• 在 postfix 外发层面做过的修改
• Berkeley DB，以及我们封装的 SMDB

说来也奇妙，本来这个团队刚刚开始招聘的时候——大概是2011年11月份左右——我就是计划着做邮件，因此从CPyUG找人；虽然中间有变化，但最终还是落在了这些同学身上，可见真是命运冥冥安排。
下一次来武汉计划会详细介绍 Milter 和 Antispam 相关的知识，再加上 SMTP、Nginx 吧

北京计划从邮件周边着手，配合移动端再想想办法启动一组人马

一手是围绕Email、云存储来深化运营；另一手是云计算平台和大数据的技术积累。就是这样了

这句话合适做 slogan 么？我从 mailgun 对自己的定义：“Mailgun is a set of powerful APIs...” 得到启发

mailgun 就是要做 sendmail 的 IaaS，正如 S3 是存储设备的 IaaS。这也是为什么 mailgun 和 Rackspace 一拍即合的原因。

我们在到达率方面做了很多功夫，但归根结底，到达率是要靠开发者自己来保证的，正如他们使用 sendmail 一样。

这个定位需要再实践中继续摸索。

不保证到达率能吸引用户吗？？当然，我们要想想开发者为什么会选择 Amazon S3，而不是本地块设备。需要在市场上给开发者再教育