qyb的博客

IMAP 服务器对 XAPPLEPUSHSERVICE 扩展的支持

翻去年邮件的时候,无意中看到 XAPPLEPUSHSERVICE 这个关键词,搜索一下加深知识记忆:

2011 年的时候 Apple OS X Server 的 dovecot 修改部分就开源了

http://www.opensource.apple.com/source/dovecot/dovecot-239.8/dovecot/src/imap/cmd-x-apple-push-service.c

2012 年 dovecot 就讨论是否增加支持,但显然除了 IMAP 之外,还得有一个 APSd 的东东

http://www.dovecot.org/list/dovecot/2012-August/067682.html

...到了2014年,还在讨论

http://dovecot.org/pipermail/dovecot/2014-April/095653.html

但也就是在 2014 年,出现了两个项目让 dovecot 可以支持 Apple Push 了
https://github.com/st3fan/dovecot-xaps-plugin

https://github.com/st3fan/dovecot-xaps-daemon

2015 年,cyrus imapd 支持了这个扩展

https://git.cyrus.foundation/rIa4470bf0f79de49030b3d66d2b385a1345c1a040

dup2.com 将提供企业邮箱服务

邮箱是一个去中心化的消息系统,具备复杂内容的携带和展现能力,悠久的历史使其成为文化符号并发展出邮件地址隐含商业权威目录的意义。企业邮箱在长期的演化中最终成为西方企业基础IT设施中的核心。

考虑到接下来中国的经济转型进程,在传统的财务、销售、市场人员之外,会有更多种类的知识工作者加入到信息协同办公流程中去;未来中国企业的IT基础设施核心会是什么?

今目标?销售易?微信?Slack?还是邮箱?

按照 Marc Andreessen 的 unbundle 理论,创新的最佳途径是从现有巨头提供的产品服务中找到一个细分的市场进行改进。SendCloud 就是这么做的,它成功的从企业邮箱服务中,切下了程序化投递这个细分需求,同时在定价和顾客关系上采取了和传统 EDM 供应商完全不同的发展路径,最终获得了如今的市场地位。
SendCloud 获得成功后,在不同场合多次碰到人问我:SendCloud 提供邮箱服务吗?

终于,在2015年底的一次询问后,我意识到也许我可以再次在这个领域做出一点创新,再次unbundle一块服务内容出来

dup2.com 将提供的是一个全功能的 MTA/MSA 服务,或者换句话,一个邮件转发和办公邮件投递的服务。更多细节会在接下来的 blog 中逐步透露,预计将在本月底可以提供试用(必须能忍受相当老式的交互界面);如果您有兴趣,可以和我们联系试用事宜。

情人节快乐,I Love Email

Topic: 电子邮件

尝试一下免费的 Let's Encrypt 证书

从知乎上看到相关的讨论:https://www.zhihu.com/topic/19568370,周末晚上尝试了一下

按照文档上(https://letsencrypt.readthedocs.org/en/latest/using.html)所描述,Apache服务器是可以用脚本自动完成证书申请和配置全过程的。但我最终参考的还是一个通用的方案,https://www.digitalocean.com/community/tutorials/how-to-secure-nginx-with-let-s-encrypt-on-ubuntu-14-04,手工完成申请和创建,然后再自己配置

非常简单,除了一开始我填写了5个域名反馈DNS超时;最后改成2个域名(dup2.org www.dup2.org)就平稳完成,得到了4个相关的文件

然后配置证书,包括参考 http://stackoverflow.com/questions/16200501/http-to-https-apache-redirection 设置了把 HTTP 自动重定向到 HTTPS.

最后看看 google 会不会给我加权了.. 以及三个月后再重新延长证书

Topic: 技术

什么是 SRS (Sender Rewriting Scheme)

有人问我什么是 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

Topic: 电子邮件

发布者 API(Publisher API)

早上简单做了一些调研

1.因为 dup2 一直用的是 Drupal,所以先从它家的BlogAPI看起:https://www.drupal.org/project/blogapi 、https://www.drupal.org/documentation/modules/blogapi(2013年更新) 。BlogAPI Module 支持"Blogger API (outdated), MetaWeblog API, and most of the Movable Type API",基本上可以认为这些 API 对应的 Publisher 也不再推广
2. Drupal 的 Blog API 是基于 XML-RPC 的,安全问题不少。现在的潮流是 OAuth + RESTful API,历史上也有 Content APIRESTful Web Services 这样的项目;到了 D8 时代已经全面在底层支持 RESTful,慢慢的应该会有一些成熟的项目出来
3. WordPress 现在已经有了一套很全面的 API,不错!https://developer.wordpress.com/docs/api/
4. Google Blogger API 升级到了 3.0:https://developers.google.com/blogger/
5. Medium,就在 2 个月前发布了 API!!!The Medium API is now open to everyone
6. 意外的发现了 Apple News 也有了 API,好大的一盘棋:https://developer.apple.com/news-publisher/ ,而 Drupal,则支持了这个 API https://www.drupal.org/project/publish_to_apple_news

7. 国内的博客托管平台,研究了一下 CSDN,发现已经失效,顿时失去了兴趣...有时间再调研国内的各个所谓 Medium Platform 的情况吧。现在的感觉是微信公众号的素材 API 可能还稍微靠点谱

Topic: 技术

Nylas N1 和 Sync Engine

果然是术业有专攻,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

Topic: 电子邮件

一个新的想法

上周,学习某公司Blog的时候跳到另一个公司的业务介绍。觉得还蛮有意思,有点当初看到 Mad Mimi 的感觉;就如同 Marc Andreessen 所介绍的 unbundle 理论 —— 从某个巨型服务上切下一块。

周六晚上因为某事无意中想到 dup2.com 这个域名已经被注下好多年了,4 字母域名如今能卖多少钱呢???然后猛然一惊:刚刚看到的这个业务模式其实和 dup2.com 还蛮搭配的啊~~

周末和 dup2.com 域名持有人 qyt 同志简单讨论了一下,也许 2016 年 dup2.com 就会蹦出来和大家见面了 :)

不卖关子,是企业服务方向,看得到的一个路径上2015年国内也有创业者开搞了。SaaS 产品征途漫漫,适合作为一个业余项目运作

Topic: 商业

调试华为荣耀6 Lollipop(EMUI 3.1)中 framework 相关功能

关于 Lollipop 下如何处理 boot.oat, services.odex, services.jar 的方法可参考上一篇http://dup2.org/node/1625

因为我们没有华为 framework 的源代码,只有 google 自己的 AOSP tree,不过不要紧,只要华为不是丧心病狂的对 AOSP framework 做了大幅度的修改,经过简单的 patch 也能达到我们的目的

首先拿到华为原厂ROM里面的 boot.oat 和 services.odex,在 /system/framework/arm 目录下;经过一番处理,反编译 samli 文件到 services 目录

然后在 AOSP tree 的 5.1.1 最新分支(写作本文的时候用的是 android-5.1.1_r14)编译,按上述步骤换个工作目录同样处理 WORKING_DIRECTORY/out/target/product/generic/system/framework/arm 目录下的 boot.oat 和 services.odex

视需要 patch 原厂的 samli 文件,然后打包成 classes.dex,压缩为 services.jar,覆盖机器上 /system/framework/services.jar,重启

祝你好运

Topic: 技术

知乎:你有过「我要死了吗」的体验吗?

有!待我仔细回忆一下过程:

2010年的时候去爬岗什卡,成功登顶。因为同帐篷的一个队友体能不太好,登顶后回到冲锋营直接就睡了,所以其它队友早就集体下撤,而我被队长分配等他恢复以后i一起走,落在了最后面。

岗什卡的问题是冰裂缝很多,尤其是冲锋营到最后大坡的那一段,必须大家穿在一条绳上蛇行前进。行进路上亲眼看到走在第一个位置的协作掉到冰裂缝里幸好紧跟他后面的搭档经验丰富且机警立刻卧倒在地,避免第一个人掉进去太深,然后大家一起把他拽出来。大本营和冲锋营之间的路途比较安全,不用结绳走,但靠大概每100米打一个小旗来确认路径。上山的时候天气很好,走到一个小旗后,看雪地另外一头的小旗,沿直线走过去

从冲锋营下撤回大本营的那段路很长,除了我们俩还有一个协作,只不过这位协作是农大的学生可能还没毕业。队长下撤的时候天气还好,所以他放心留我们三个最后。可是走着走着,天气变坏,从小雪变成大雪,几处小旗完全被淹没在雪里;协作同学有点慌,到处找路;几段路径基本上雪到了小腿深;而队友因为体能不行控制不住身体吧,若干次甚至踩下去整个大腿都陷下去;我帮着他把腿刨出来也消耗了大量的体能。

随着天色渐晚,气温下降更厉害,风雪更大,体能也接近为零,走着走着就觉得特别丧气,心想“这一趟要是走不回去可毫不奇怪呢”。也没有什么太多关于生死、亲人的念头在脑海里盘旋,也许是体能真的消耗太大,人体的自我保护机制已经启动大脑自动降频了。就是想着走,以及一个可能这次就挂在这里的念头。平时夜深人静时有时想起死亡还是挺毛骨悚然的;当时除了坚持走这个念头,情绪上没有恐惧,只有丧气

最后走出雪地,也没有什么欣喜若狂。丧气的念头没有了,继续走呗。

后来想,如果我不是留在最后,就他们俩(协作是必须要陪最后客户的),凭自己的力量应该是走不下来的。未必丧命,估计也会被冻得大病一场

Topic: 生活
订阅 RSS - qyb的博客