Google

这里简单记一笔。我有一个域名使用的是 Google Workspace 的邮件服务。昨天，一位用户使用该域名向中国的 QQ 邮箱用户发送邮件时被退回了。

退信中给出的线索是：

550 DMARC check failed [XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
IP: 2607:f8b0:4864:20::112b]. https://service.mail.qq.com/detail/124/61.

腾讯给出的那个链接是一篇关于 DMARC 如何配置的文章。从上下文来看，应该是由于腾讯的服务器认为 Google Workspace 的 IP 地址不在允许发信的范围内。

退信确实是 Google Workspace 的邮件服务生成的，数据来源是和对方(腾讯) MX 之间的 SMTP 会话。

我的这个域名确实启用了 DMARC。我的DMARC记录 (域名下的 _dmarc TXT 记录) 设置如下：

v=DMARC1; p=reject; rua=mailto:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX@dmarc-reports.cloudflare.net;
pct=100; adkim=s; aspf=s

此配置要求对方检查 DKIM 和 SPF，并拒绝不匹配的邮件。

其 SPF 记录 (域名的 @ 的 TXT 记录) 设置如下。这是 Google 官方文档中推荐的设置：

v=spf1 include:_spf.google.com -all

主要的区别是，我使用的是 -all，即拒绝 SPF 不匹配的邮件，而不是更为常见的、表示即使发现 SPF不匹配，也仅仅做标记但允许接收的 ~all。

这里需要说一下背景：在 2004 年左右，一些业内人士认为应该推荐采用~all 而不是 -all，因为当时许多大型邮件系统的架构中存在多层邮件服务器分别进行不同的过滤处理，而在 SMTP 会话阶段直接回一个永久性拒绝 (5XX) 代码可能会让一些不适任的邮件系统管理员如此配置的邮件系统将一些伪造了来源的邮件退到不希望的地方。我并不赞同这样的观点。事实上，在会话阶段进行退信要比在收件方服务器上生成退信并将退信退给发件人或对方域名的 postmaster 要更好：对于垃圾邮件的发送者，这意味着他们的邮件服务器会立即知道自己的行为被直接地丑拒，接收方明确告知他们吞下垃圾邮件，而不是继续发送。对于正常的邮件服务器，这意味着发件人可以立即收到退信从而找到自己的邮件系统管理员，而不是告诉收件人去翻垃圾箱看看是否有自己的邮件。另一方面，回应永久性拒绝并不妨碍收件服务器对邮件内容进行进一步分析：它完全可以在 DATA 阶段结束时再回拒绝，从而将邮件完整地接收下来但不递给收件人。

当然，历史无法假设，并已经无数次地证明人类根本不配拥有美好的事物。

DomainKey 记录 (域名下的 google._domainkey TXT 记录) 由于与此问题无关，故在此处略去。

该域名启用了 DNSSEC。

最近， Google 账户新增了一种叫做 passkey 的登录方式。

传统的采用密码登录的登录方式中，用户需要用某种方式证明自己知道密码，而绝大多数实现中这意味着网站必须保存用户的密码，或是密码的 hash 值（通常是HMAC），这意味着网站如果发生了拖库的情况，有可能会将用户的密码或其 hash 值泄漏出去。此外，用户可能必须输入密码，并将密码通过某种方式传输到服务器上，这样一来在这个过程中便有可能由于本地的木马，或是网站采用的 SSL/TLS 实现的漏洞导致密码泄漏。除此之外，即使用户十分小心地在每一个不同的网站都使用了不同的密码，他们仍然需要担心被「钓鱼」的问题，所谓「钓鱼」是这样一种攻击方式：攻击者架设一个看起来很像是用户希望登录的网站的网站，并诱骗用户输入密码。

详情参见 Google Online Security Blog。

说两个我认为比较有意思的事情：

第一个是 Google 并没有公布作为证据的证书。由于证书是以 CA 的私钥签署，因此这类未经授权的证书本身就可以作为证据。但是，Google这样做（不公布证书）意味着签发者不得不销毁全部签发的证书，而不仅仅是被公布的那些。

📜 历史文件已不具备现实意义

连 Google+ 都没了。

Google 在一篇关于 Google Maps 更新的 blog 中提到， Google Latitude 即将关闭 并转入 Google+。（另外话说，这事有必要这么偷偷摸摸的吗？）

霍总几天前发表了一篇blog， Google的社会化梦想与Reader。我仔细想想，似乎也不全是 Google 的问题。

有人说，Google要做的是大众产品，而Reader是小众产品，哪怕它已经成为了半专业的工具，也并不会改变这个事实，甚至于，这反而是件火上浇油的事情。我基本上认同这个说法。

我认为很大程度上，用户的心态也是有问题的。 Google 做出强推 Google+，砍掉 Google Reader 的决定，背后自有其商业方面的考量，至于这决定是对，是错，从用户的角度你很难有立场说"Google这样做对了，或是这样做错了"，能说的，最多也就是"Google这么做哥们很不爽"吧？

还有人去白宫网站发请愿。靠去白宫网站发个请愿，召集几万人签名是根本没用的，至少在我看来就是这样—-想要改变一个公司基于商业考量做的决定，最有效的方法就是让这个决定看起来不那么符合其商业利益，其他一切一切的手段都是无关紧要的。

纯转发，不评论。(存档防止将来有人删贴反悔。)

来自 新浪科技

新浪科技讯 9月18日下午消息，阿里云公司总裁王坚今日发表公开信，就谷歌与阿里之间的手机操作系统纷争发表看法。王坚认为，谷歌利用自己形成的优势，强迫合作伙伴限制对手，这一做法背离了谷歌坚持的开放原则。

📜 历史文件已不具备现实意义

本文内容是关于 Movable Type 的评论系统，目前已经不再使用。

最近不知道为什么这个 blog 被某个垃圾评论团伙盯上了。 Movable Type 的 captcha 比较弱，于是先换了 Google 的 reCaptcha。通过 Google、 Facebook 或 OpenID 以及其他方式登录的用户还是可以直接发表评论。

如 quakelee 所说，这类手机应该当作上网本而不是手机。是的，非常费电。

功能方面基本上和之前希望的一致，没有超过太多，也没有太失望。性价比方面感觉比 iPhone 要好一些，当然更重要的原因是 iPhone 完全不支持 Verizon Wireless 使用的 CDMA 网络。

之前在水木社区发过，这里也发一下。

我们目前正在寻找有意参加这次活动的在校学生。Google Summer of Code 是由Google公司赞助的供在校学生参与开源项目的暑期活动。目前，FreeBSD已经被选为符合资格的 mentoring organization，这是 FreeBSD 第 5 年参与 GSoC。

重要的日期：

• 3月23日 - 开始接受申请
• 4月 3日 - 申请截止日期
• 4月15日 - 对申请的审核结束
• 4月20日 - 正式宣布赞助的学生
• 5月23日 - 项目正式开始
• 7月 6日 - 开始提交中期评估
• 7月13日 - 中期评估最后日期
• 8月10日 - 推荐的项目完成时间，接下来的一周时间建议用于修正代码、完善文档等。
• 8月17日 - 开始提交最终评估
• 8月24日 - 最终评估deadline

Google将为获得资助的学生提供每人 $4,500 的资助，分3次支付；同时，对于每个项目，Google还会为对应的开源项目提供 $500 的资助。

关于 FreeBSD 本次 SoC 活动的 网站。

MeetBSD 2008聚会将于11月15－16日在Mountain View的Google Campus举行。本次活动同时是为了庆祝FreeBSD成立15周年，活动报名费为$50。