电子邮件

有人问我什么是 SRS，这里简单解释一下

首先是要理解 SPF，https://en.wikipedia.org/wiki/Sender_Policy_Framework
就是域名拥有者通过 DNS TXT 记录，声明哪些IP地址发出来的标记Sender为本域的邮件是可以被信任的
SPF很好的过滤了伪造Sender的行为，从而Sender的信誉可以被积累和建立

但是SPF对 autoforward 这种配置造成了困扰
一封邮件从Google发送到Hotmail，然后Hotmail将其转发到Sohu
转发过程中Hotmail将如何声明Sender？
如果是原始发件人的话，就违背了Google的SPF声明

所以需要重写Sender，让Sohu信任这封看起来是来自Hotmail的邮件
不过Hotmail除了重新Sender，还得支持当这封信soft-bounce之后，能正确的将弹回邮件再弹给Google
于是还得有一个防重写伪造的机制，确认这封弹回的邮件的确是从Google来的然后重写转发的

最终专业从事 email gateway/forwarding 的人提出了 SRS，https://en.wikipedia.org/wiki/Sender_Rewriting_Scheme
希望采用 SPF 验证的服务器，上面的例子中是Sohu，能认可Hotmail的这种重写行为，http://www.openspf.org/SRS

果然是术业有专攻，FastMail 的 JMAP 提出快有 2 年了吧，但这里已经有另外一家公司搞了一个类似的协议 Nylas Sync Engine https://github.com/nylas/sync-engine，Python 开发的，这个我喜欢

而且，人家也实现并开源了一个看起来很棒的 Email Client：Nylas N1 https://github.com/nylas/n1，JavaScript App，打包基于 Atom，所以目前支持的平台包括了 Windows、Linux、Mac；框架基于 React，所以我甚至在想是不是能山寨到 React Native 框架上。。。

按照我以前的分类，FastMail 主要是一家 Inbox + SMTP 服务提供商，Nylas 是一家 Email App 服务提供商。JMAP 协议的竞争优势是将在 Cyrus IMAP 3.0 里被支持（FM看起来是Cyrus的支持者），Nylas 以后怎么发展不太好说，毕竟成立时间有限.

我去年产生一个观点：Email App Provider 独立价值是有疑问的，从各个免费邮件客户端纷纷被 Google（Sparrow）、微软（Acompli）、Dropbox（Inbox）等巨头收购就能看出来。很可能 Email App Provider 只能在企业邮箱市场开发 Groupware 客户端才能生存

Nylas 的模式没有仔细看，回头再研究

--
以前的Blog
如何做好一个 Mailbox Provider.2013-06-07
Mark 一下 JMAP 和 switchboard.2014-06-18
JMAP .2015-03-04

JMAP 是一家我非常景仰的公司 FastMail 搞的协议，目标是在这个移动互联的时代，基于 IMAP 的逻辑，的公开邮件服务器协议。相关的信息包括：
1. https://groups.google.com/forum/#!forum/jmap-discuss
2. https://proxy.jmap.io/

去年12月，$20M，http://www.prnewswire.com/news-releases/sendgrid-announces-over-20m-in-n...

这次融资没有像2012年的B轮那样宣传广泛，另外值得注意的是它几乎同时更换了 CEO

mail {
    auth_http 127.0.0.1:9999/auth;

    server {
        pop3_capabilities "TOP" "USER" "UIDL";
        listen 110;
        protocol pop3;
        proxy on;
    }

    server {
        listen 995;
        protocol pop3;
        proxy on;
        ssl                  on;
        ssl_certificate      mail.sohu.net.crt;
        ssl_certificate_key  mail.sohu.net.key;
    }

    server {
        xclient on;
        server_name sohu.net;
        listen 25;
        protocol smtp;
        proxy on;
    }

    server {
        listen 465;
        protocol smtp;
        proxy on; 
        ssl                  on;
        ssl_certificate      mail.sohu.net.crt;
        ssl_certificate_key  mail.sohu.net.key;
    }

    server {
        imap_capabilities "IMAP4" "IMAP4rev1" "UIDPLUS" "AUTH=LOGIN" ;
        imap_client_buffer 8K;
        listen 143;
        protocol imap;
        proxy on;
    }

    server {
        listen 993;
        protocol imap;
        proxy on; 
        ssl                  on;
        ssl_certificate      mail.sohu.net.crt;
        ssl_certificate_key  mail.sohu.net.key;
    }
}

今天第一次听说 JSON-LD 这个东西，Google Inbox 背后使用（或者说想去推广）的规范之一。值得研究研究

http://googledevelopers.blogspot.com/2014/10/make-your-emails-stand-out-...

规范这个东西，比如 RSS，比如二维码，不知道什么时候就爆发一下

http://jmap.io/
http://switchboard.spatch.co/examples/

企业电子邮件的未来到底是被一个新工具替代？还是邮件的自我进化？Contatta 是后面这条道路的一种尝试

注意到这个公司首先是看到了它制作的一个专题，觉得设计挺用心。于是好奇去网站上看了一眼，Demo 还算吸引人；最有意思的还是三个创始人完全没有计算机工程背景——2名销售+1名设计师，这种完全不符合一般认知的团队，很期待能给市场带来新的活力。

它制作的专题见下：

Courtesy of: Contatta

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

我们在服务器端使用的主要的开发语言是 Python，技术工作包括：

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

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

在生产环境中，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 很值得尝试