Cloudflare 推出域名注册服务 Cloudflare Registrar 并且开放早期申请支持免费 DNSSEC

更新:2018年12月27日

  • 大约在 2018年12月5日 开放域名转移了,当前只能转入不能注册;
  • 现在已经修复了 DNSSEC 生效的问题了,直接启用即可不用对 DNS 做任何设置会自动设置并生效;
  • 只能使用 Cloudfalre DNS,如果需求使用其他 DNS 不建议转入;
  • 官网帮助页面写着可以转出,但是当前可能由于功能不够完善,还没有找到相关的按钮;
  • 12月7日有 tg 网友说他昨天刚注册的账号也可以转入域名,所以没有必要为了“提前”而去捐款;

是谁?

主角地表知名 CDN 服务商 Cloudflare 有新动作了!

哪儿?

访问测试控制面板 https://dash.cloudflare.com/

产品页面 https://www.cloudflare.com/products/registrar/

介绍页面 https://dash.cloudflare.com/domains

做啥?

Cloudflare 推出域名注册服务 Cloudflare Registrar 打算走起域名注册的蛋糕了!

何时?

Estimate: Mid November

特点?

价格低廉,数百后缀,免费支持 DNSSEC,二次认证,批量转移,API,集成其他 Cloudflare 服务。

价格?

价格超级低廉,有多便宜呢?一般的注册商给用于的价格是 注册价格=批发价+利润。而胆儿肥的 Cloudflare 直接承诺不会高于批发价,也就是说以批发价卖给最终用户,没错这的确会改变全球域名注册的格局(估计 GoDaddy 老板暗杀 Cloudflare 老板的心都有了~)。最终价格是什么呢?请看上图。所以,做好把域名转入的准备了么?

其他?

如果你是用 Cloudflare 年限越久,加入测试后的时间越早比如我比较晚现在是 Wave 7。当然,如果你想略微提前一些时间当然也是可以的。参加一个 【Girls Who Code】最低 $1.00 的捐款活动就可以了。地址在【这里】页面中部,捐款之前需要添加一个支付方式如果你之前没有添加过的话,当然,支持信用卡也支持你爱的 PayPal。

更多?

官方博客介绍 https://blog.cloudflare.com/using-cloudflare-registrar/

You’re in Wave 7

Estimate: Mid November

Thank you! You’re now signed up for early access to Cloudflare Registrar. We’ll let you know when it’s time to transfer your domains to Cloudflare Registrar.

推荐 FastMail :优秀邮箱服务

网上介绍/推荐 FastMail 的大佬和文章已经比较多了,最近我的 FastMail 一年付费周期快到了要续费了,想了想这个服务简直6到起飞所以我再来推一波。之前的帖子可能无法说清楚 FastMail 的方方面面,我说点(可能)其他大佬(可能)没有提到的东西。

我自己使用 FastMail 截至目前接近两年。

起源

网上有一小撮人说使用个人域名的邮箱是增加逼格,好的!

我想问问如果这波人如果之前使用的是【雅虎中国】的邮箱 @yahoo.cn @yahoo.com.cn 的话这玩意儿被阿里巴巴关闭之后他们是挨个修改邮箱了么?

还有,假设你使用的是某个服务商的邮箱,比如网易邮箱,你每次登陆都要看烦人的广告这个你看了很多很多年。如果有一天网易出现了安全事故(又不是没出现过)你想搬家,你不再用网易了,你能么?过去很多年的数据导出就是个很大的问题,更不用说放弃网易邮箱后缀了,一旦放弃意味着你要修改所有你使用这个邮箱地址的其他服务,你想一下现在让你更换一个手机号你的第一反应是什么?同理。

使用域名邮箱的话,服务商服务不爽?搬家走人!服务商看着奄奄一息了?搬家走人!广告?抱歉一般都没有!用了多年想换换口味?搬家走人!开始收费/涨价了接受不了了?搬家走人!。。。?搬家走人!


概要

Gmail 千好万好中的大多数都适用于 FastMail 。而且!自从 1999年 以来专门做邮箱业务至今没有倒闭而且被众多大佬发帖推荐的邮箱服务商,地表一只手都数的过来(如果还有其他的请告诉我一下。)!

所有你对邮箱的期望,什么稳定,安全,快速,无广告,绑定域名,各种导入导出数据,别名,大容量,日历,通讯录,同步,推送,IMAP,二次认证,支持 Yubikey ,转发,过滤。。。只要你能想到的,基本上,都支持了。SPF,DKIM,DMARC 支持 。同时,十分注重安全和隐私,十分注重邮件相关标准。

SPF DMARC DKIM 这种一看名字就高端到不行的东西。(SFP 很多国内大厂都支持了,但是后面两个别人都已经支持了很多年了,有些还只是表象上支持而已(腾讯邮箱帮助页面是写上了,可是真的支持了么?))但是,SPF 已经不推荐设置了。你等国内邮箱支持 Yubikey ?恐怕你还得至少再活 500 年!


详细介绍

价格

官网页面很清楚了。可以免费试用一个月,国内手机如果无法注册请直接联系客服邮箱帮你注册一个账号。试用账号限制了可潜在造成滥用的功能,比如限制了邮件发送数量无法创建静态网站无法使用转发规则。年付有优惠具体请看价格页面。另外,使用个人邀请 (https://www.fastmail.com/?STKI=16759801) 首年可以打九折!就是标准版首年 $45 。

容量额度

25GB,如果邮箱容量用完了,购买容量等于购买了一次当前套餐。单个用户最大容量 300GB。

安全

用户数据,访问权限,加密收发,图片载入等等等等,他们写了一篇文章《How FastMail provides a secure service》来介绍。FastMail 至今没有出现过安全事故。

速度

用过都说快,移动端客户端,邮箱页面和你打开官网一样都很快。中国大陆访问没有障碍。

客户端

支持 iOS iPad 安卓 客户端。速度没的说。

主题

主题不是和QQ邮箱一样一身华丽的衣服,而是基于颜色的,总体来看界面有点高端大气(科幻片镜头里的黑客使用的电脑屏幕那种调调。)

语言

多国语言默认英语,简体中文?有,但是翻译似乎不全面,而且翻译也不是很地道。不推荐使用!

支付方式

支持 Visa MasterCard American Express PayPal 和 比特币。但是!没有说只接受信用卡,如果你有 Visa MasterCard 借记卡(中国银行长城跨境通国际借记卡了解一下?)理论上也是可以的但是我没有试,又但是!没说不接受虚拟卡,我也没试过。支持 PayPal 中国版(绑定银联卡是可以的)。有过 Gift Card 叫做 Gift Certificate 但是现在不支持了!

续费策略

对于个人,我推荐使用 Standard Plan 否则的话不能绑定域名。注意这个续费策略有点不同于我们接触的大多数:你元旦买了一年服务,过了半年你想再续费一年,那么你仍然需要支付一年的费用你的使用期限延长一年,没错吧?这是我们接触到的绝大多数的订阅服务(什么 QQ会员啊 爱奇艺会员啊 等等等等的)策略。但是!!! FastMail 不是这样的,如果你过半年后要续费一年,那么你续费的一年从你续费的当天开始计算,时间上时间只延长了半年而你的费用也只需要支付半年即可。即:续费时长从今天开始计算!

域名

可以绑定多个域名,也可以用系统给你的多达 120+ 域名创建别名邮箱,你无论使用什么域名,你在任何时候都只有一个收件箱。当然你可以建立文件夹使用 rules 把内容分开。是不是有 Gmail 熟悉的感觉?

导入导出

支持各种,邮箱,联系人,日历的导入和导出。邮件导入服务是我见过最靠谱最6的没有之一。邮箱搬家无忧零障碍。

DNS

支持托管你的域名的 DNS,当然相比专业的 DNS 服务商来说就有点欠缺了但是对个人使用足够没有问题。

邮件路由

支持设置子域名策略和邮件路由策略。比如如何处理 [email protected] 这种邮件。详细内容 帮助页面

账户恢复

密保邮箱,密保手机,还有 Recovery Code 备用!

二次验证

支持各种你想得到的软件,硬件,短信验证。支持 Yubikey !!! 足见专业!他们自己也说安全是他们的重中之重。帮助页面

App Passwords

使用任何客户端都必须创建一个临时密码而不是用自己的邮箱密码。什么时候,谁用,给什么权限(仅邮件?给联系人?只有 IMAP?等等)都可控!

邮件读写

支持从自带网盘和 Dropbox 上传文件,本地上传当然也支持了。

文件夹

支持层次组织,支持拖放排序。什么重命名之类的~不在话下!

规则

支持收件规则,支持转发规则,支持邮件组织规则。无与伦比强大,你想得到的基本都有!你想不到的也有~你还可以自己编辑过滤脚本!!!

垃圾邮件保护

这还用说,当然!什么“Forwarding hosts”什么“Backscatter”的都支持啦~你常见的贝叶斯分类器?当然!什么设置自定义阈值当然也支持!

自动回复

自动回复必须和垃圾邮件保护一起配合使用!是不是很酷炫?就这点就秒杀别人几条街了。为什么呢?可以自己思考下。

联系人

分组,共享,导入导出你知道的想得到的都支持。

日历

支持添加订阅,支持一切 CalDAV 日历,可以和 Google Calendar 同步。

Notes

附带一个记事本功能,类似 Google Keep 这种。默认纯文本,支持富文本。当然没有 Evernote 和 Dropbox Paper 强大。

Files

网盘!叫做 FastMail Files ,有点强大!但是没有 Dropbox 强大了。除了基本的保存上传下载文件这种以外,还支持各种域名映射,可以做静态网站使用,有个自带的相册模板可以嗖一下生成一个简单的相册。而且!静态网站还支持自动管理续期使用 Let’s Encrypt 签发证书的 HTTPS 呢!这部分后来可能会专门写个帖子介绍一下。

帮助文档

相当全面,相当专业,English Only.

博客

https://fastmail.blog/ 是他们的官方博客,专业!English Only. 我偶尔会翻译一些有意思的文章(能力学识有限,有错误也不要喷我。)

客服

专业不废话响应速度快。可以直接用你的邮箱给 [email protected] 发邮件就等于快速开了个工单!而且,支持推特上对话帮助~


最后

缺点

有没有发现不支持 PGP 呢?他们又专门写了一篇文章《Why we don’t offer PGP》 来解释。

FastMail Files 不支持 IPv6

写信不支持 MarkDown (有谁支持麻烦告诉我一下)

对比

了解完了是不是觉得简直强大专业了一脸?回头一想我们的网易邮箱腾讯邮箱简直……注册一个月免费试试吧~别忘了使用我的个人邀请 (https://www.fastmail.com/?STKI=16759801) 在你付费的时候打九折~

那么问题来了,你觉得是 Gmail 强大呢还是 FastMail 更酷呢?

改进

发送给QQ邮箱的问题有大佬说已经没有了,我自己也没遇到;

使用科学上网和中国手机注册的问题有大佬说也没有了,这个我自己没有试。

其他中文资源

域名邮箱

当前(2018年9月),市场上的域名邮箱无非就那么几个了:

对于这种基础服务,一定要选择大厂!明天可能冒出来一个各种优秀免费或收费很低的服务商,但是你敢把过去多年的邮箱数据搬过去么?

本文最后更新:2018年12月28日

G Suite

免费没了,现在只有收费,如果你以前有还可以用。付费的话 $5/月 or $50/年 起步。地表最强之一,如果你在中国大陆生活,则要考虑另一方面的东西了。另外,对于谷歌扫描邮件内容(我记得谷歌承诺不扫描商业邮箱内容但是已有的免费邮箱怎么对待则不清楚了,而且实际上有没有扫描你我都不知道)很多人不满。

Yandex.Mail for a domain

免费,没有广告,没有收费服务。靠谱是靠谱,安全方面也好像没出过问题但你总感觉不够强大而且好像是万年不更新的一个产品,无论是界面还是功能感觉都好像一般般。追求不高可以用用。

Zoho Mail

免费,没有广告,也有收费版(价格列表)界面奇怪而且丑,印度人做的(没有歧视印度人的意思),总感觉怪怪的,功能一般般吧,在中国北京有分公司,主要做在线企业服务全家桶。追求不高可以用用。

QQ域名邮箱

免费,没有收费版,无广告,QQ邮箱给添加一个自定义域名的别名,其他和QQ邮箱一样,最大的优势是可以直接从QQ面板一键进入。追求不高可以用用。提示:不要多次添加删除域名,否则你会被提示“由于系统原因验证域名失败,请稍后再试。”。

腾讯企业邮免费版

免费,无广告,有收费版就是腾讯企业邮了(价格列表)需要验证手机号(我知道你想说什么,但是!你躲不过让你绑定微信这一关!)容量有点小只有 2GB。追求不高可以用用。

阿里云免费版企业邮箱

免费,当然也有收费版(价格列表)但是当前很多时候会和阿里云的其他产品打包以很便宜的价格比如一块钱或者六块钱这种方式卖给你。其实就是阿里云拉个新人头~界面奇丑!功能一般般。我记得还有广告?追求不高可以用用。

网易免费企业邮箱

免费,需要验证手机号码,追求不高可以用用。

Migadu

免费,也有收费版(价格列表)。免费版只有1GB容量而且有小尾巴广告。看着很不靠谱的样子,感觉每注哪天就翻车了。随便玩玩就好,付费也不要给这个付费。

新浪企业邮箱免费版

下线了!当然以前也需要验证手机号码。

搜狐免费企邮

下线了!

ProtonMail

号称端到端加密的电子邮件,这个是卖点。免费版只有 500MB 容量而且不能绑定域名。收费版可以绑定域名而且容量也大了。收费版是 4欧元/美元/法郎 起(价格列表)。

Openmailbox

好像翻车了?(帖子)邮箱一定要选靠谱的大厂!邮箱一定要选靠谱的大厂!邮箱一定要选靠谱的大厂!

Update:2018-12-28

好像又复活了页面可以打开了,但是页面上有个横幅写个一句话“Why we were down”看起来这句话应该有个链接但是又没有链接。

Pawnmail

好像翻车了?邮箱一定要选靠谱的大厂!邮箱一定要选靠谱的大厂!邮箱一定要选靠谱的大厂!

LINE WORKS

大名鼎鼎 Line 推出的产品!刚刚出来的时候有免费域名邮箱,后来估计是被薅太狠了,免费套餐的邮箱服务没有了!现在有邮箱的最低套餐是 600日元/月,约合人民币 36元/月。

Gandi Mail

没错,就是法国那家域名注册商,口碑还可以。如果你在 Gandi 有域名或者转入域名才可以使用他们的免费电子邮件服务。免费配额只有两个邮箱。当然你可以付费购买更多,价格也很便宜。(价格列表

Amazon WorkMail

Amazon AWS 产品的一部分,企业邮箱,没有免费套餐,价格为 $4/用户/月,可以试用一个月。这个产品是相对来说比较新的 AWS 产品,只所以提一下是因为作为地表最强云计算厂商,按照 AWS 的节奏来看它不会差,只是需要时间去完善。当前功能相对来说比较简单,当然安全稳定是肯定的。

139企业邮箱免费版

中国移动139邮箱的企业版的免费版。有趣的是 产品介绍页面 https://qiye.mail.10086.cn/introduce.do 写着“12年的专注”,我理解的是“自从2012年开始专注”不知你怎么理解?如果你理解的和我不一样可以告诉我。

Mail.Ru

有一小部分人推荐,毕竟算是老牌了。俄语界面,理解全靠翻译和猜测。大多数人是通过客户端来使用这个的,好像没有英文和其他语言界面。

Amazon Route 53 使用指南

Amazon Route 53 是什么?


Amazon Route 53“ 看名字就知道是 亚马逊 Amazon 提供的一项服务,它属于 Amazon AWS(Amazon Web Services) 众多服务中的一个,它是一个高可用的弹性 DNS 服务,这项服务主要包括三大功能:

  • 域名注册
  • 域名解析
  • 检查资源运行状况

Route 53 为什么要叫 Route 53 呢?网上有答案了:Quora 【这个帖子】表明了原因:It refers to the TCP/UDP port 53, where DNS server requests are addressed.

这篇帖子针对普通用户,只说域名注册和域名解析。学识有限,如果有错误烦劳指出。

域名注册


作为云计算全球头把交椅服务商,亚马逊当然也有域名注册服务。但是亚马逊自己只提供三个后缀的域名注册即最常见的 .com .net .org 其他后缀都是和 Gandi.net 合作,任何除了这三个之外的其他后缀的注册商都会在 whois 信息里显示 “Registrar: Gandi SAS” 。

注册特性

转移锁定(Transfer lock):当然支持,保护域名不会被所以转出当前注册商;打开之后域名状态里面会多一条 “Status: clientTransferProhibited” 这个大家都清楚;

转移密码(Authorization code):自助获取,如果域名要转出必须;历史上,国内的域名注册奸商就是在这个环节各种限制以此限制域名转出,当年我就是写了各种纸质材料送去了北京万网总部才得以转出域名(继续在此差评并且鄙视之);

隐私保护:免费,所有域名免费提供隐私保护;但是!我记得如果是除了 .com .net .org 以外的注册在 Gandi.net 的域名是不能隐藏所有人名称的,详细看【这里】 。

DNSSEC status:DNSSEC 启用需要 DNS 服务本身支持和域名注册商支持,注册在 Amazon Route 53 的域名解析服务截止当前(2018-09-23)不提供 DNSSEC 相关功能但是如果你使用的是支持 DNSSEC 的解析服务(比如 ns1.com)那么是可以在这里设置相关信息以启用 DNSSEC 的。

域名价格

后缀注册和续费转移恢复转入
.com$12.00$0.00$66.00$12.00
.net$11.00$0.00$67.00$11.00
.org$12.00$0.00$69.00$12.00

其他域名价格请参考【这个文档】。

域名注册不能用任何代金券抵扣注册费用,其他的 Route 53 服务费用是可以抵扣。

题外:对于老牌域名注册商 Gandi.net 网络上有两大派别,一大派别极力支持,另一大派别极力反对说各种坑。我个人建议是否要使用这个注册商还需要每个人自己去琢磨它的长处和短处。

域名转入

域名从其他注册商转入 Route 53 流程是自动的,一般情况下如果是国外的注册商转入会当天完成,有的自动处理的甚至半小时就可以完事就是收发几封邮件的事情。同其他注册商一样,转入域名需要支付一年域名费用并且会延期一年,转入以后两个月内不可以转出。

域名解析


Amazon Route 53 域名解析包括两部分:

公共域名解析(Public Hosted Zone):大家理解的传统的域名解析,域名到 IP 地址转换。作用于整个互联网的查询;

私有 Amazon VPN 解析(Private Hosted Zone for Amazon VPN):也是解析,但是仅限于 AWS VPC 内的资源响应,公网无法访问。

先前文章《2017年 DNS 解析服务商列表》当中粗略介绍过 Amazon Route 53 这个优秀的互联网 DNS 解析服务。

品质

高可用,AWS SLA 服务承诺中说明了 Route 53 提供 100% 可用。

根据 Datanyze 统计,Alexa top 1K 中有 21.10% 使用了 Route 53,第二名 Cloudflare 占有 18.87%,而第三名 Dyn 则占了 12.48%。而第二名则是由于优秀的 CDN 服务带动了 DNS 占有率,而第三名的互联网老牌服务商如今被 Oracle 收购了的 Dyn 也没有这么高的占有率。市场足见品质。

特性

优点

Route 53 是当前地表数一数二的优秀的域名解析服务商,基本上一般所有的用户诉求都能满足。常规的域名解析服务商只是做一个域名到 IP 地址的映射,稳定速度快的就已经很难得了。而 Route 不但如此,而且:

  • 可编程,提供各种语言支持的 API 可以编程动态改变路由;
  • 是弹性的,可扩展的提供海量查询服务的 DNS 解析服务;
  • SOA 可以编辑,一般的大多数的 DNS 服务商 SOA 是不可编辑的;
  • 提供流量控制,你的流量怎么路由完全可控;
  • 提供基于基于延迟的路由;
  • 提供基于地理位置的 GEO 解析;
  • 提供 Failover 故障转移确保解析服务高可用;
  • 如果您使用 AWS CloudFront CDN 服务时支持裸域;
  • 如果你使用 AWS S3 支撑网站部分资源,那么支持裸域;
  • 支持 Amazon ELB(Elastic Load Balancing) 集成;
  • 提供加权轮询(WRR)路由功能;
  • Route 53 还是截至目前为止(2018年09月25日)地表屈指可数的提供 DNS 查询日志的服务商(Google Cloud DNS 目前还不提供)而且日志提供导出到 S3 可做各种深度分析;
  • 当然也支持 Anycast 任播;
  • 当然 CAA 也是支持的;

缺点

不支持 DNSSEC 相关,这点比不上 Google Cloud DNS 了,参看上文相关部分介绍。

定价

Route 53 解析的价格由多个因素组合而成:

  1. 托管的域名数量
  2. Traffic Flow 记录数
  3. 标准查询数
  4. 基于延迟的路由查询数
  5. Geo DNS 和临近地理位置查询
  6. 运行状况检查

价格计算还有一些细节的规则,具体请查看 Amazon Route 53 定价 页面。

这里举几个例子:

  • 个人博主,只有一个域名一台主机也没有特别针对的用户,每个月查询50万次,那么每月 0.5 + 0.4 * (50/100) = 0.7
  • 个人开发者,有多个域名假设手里有10个设置各种乱七八糟的只是自己知道的指向几乎没有人访问,有上面同款博客一个,那么每月大约 0.5 10 + 0.4 (50/100) = 5.2
  • 米农,手里持有100个域名但是都只做了指向,有几个爆款指向每月大概加起来有25万次查询,那么每月 0.5 25 + 0.1 (100 – 25) + 0.4 * (25/100) = 20.1

以上计算还要注意区分资源的指向是谁,建立了多长时间等等价格页面的细则。大概的套路就是每项资源使用量*单价-符合免费或折扣策略的价格=总价,除了第一个托管以外其他的都是按比例收取,托管则有一个 12 小时的免费时间窗口。

设置

公共域名解析(Public Hosted Zone)

公共解析和其他的常规 DNS 解析没有什么区别,选择合适的类型在文本区域内会有格式例子给出照着写就可以了,解释一下有别于其他常规 DNS 解析的名词:

Alias(别名):可以理解为一类特殊的 cname 类型,但是指向的对象只能为 aws 资源或者是同类型的同域的其他资源才可以。 aws 资源可以是 CloudFront,Elastic Beanstalk 环境,ELB 负载均衡器,S3 资源。比如给一个 A 记录 hosta 创建一个 alias 叫做 hostb

TTL:如果是别名并且指向的是 aws 资源,则无法指定 TTL 值,一切由 aws 帮你搞定。如果别名指向的是同域的其他相同类型记录,则使用目标记录的 TTL 值。如果不是 alias 的话 TTL 可以设置为你想要的值,默认 300

Routing Policy(路由策略):

  • Simple:一般策略。Route 53 只根据记录值相应查询;这更像是普通的其他常规 DNS 解析,一般用于将流量路由到单个资源;
  • Weighted:加权路由,权重路由,基于权重的流量路由策略。资源的权值是一个 0 到 255 的整型值。思路:把多个资源关联到同一个域名上(可以是单域名或者是子域名),可以认为是一个资源组,然后根据权重(占该组中所有记录总权重的比例)指定向每个资源路由多少流量。如果某个资源的权重为0则不向这个资源路由流量这个特性可以用作测试或者临时停机之类的用途。如果将所有资源的权重都设置为0则会以相同的概率向所有资源路由流量。比如你有3个资源权重费别为 5 10 15,那么分到第一个的流量则为 5/(5+10+15)= 5/30 = 1/6 ,第二个则为 10/(5+10+15)= 10/30 = 1/3,第三则为 15/(5+10+15) = 15/30 = 1/2. Set ID 是一个在加权记录组中唯一标识当前记录的值,可以认为是当前资源名称的一个描述或者备注之类。
  • Latency:Latency-based- Routing(LBR) 基于延迟的路由策略。简单来说就是谁延迟低把流量给谁处理;创建多个同名记录的同时指定响应区域,当 DNS 查询被路由到 Route 53 以后 Route 53 会以一段时间内执行的延迟测量给出路由响应。值得注意的是,网络延迟是动态的,不是一定不变的,也可能和地理位置没有太大关系,例如:不一定香港连接台湾就比香港连接新加坡块。
  • Failover:故障转移路由。这个必须和 Health checks 配合使用,就是 Health checks 发现你的第一个资源如果挂了就把请求路由到第二个资源上。系统推荐为了更高的可用性而把此类记录的 TTL 设置为 60 或更低。
  • Geolocation:传说中的 GEO 路由,地理位置路由。根据用户的地理位置来选择提供流量的资源。位置可以精确到大陆、按国家/地区或者按美国各州指定地理位置。如果您为重叠的地理区域创建了单独的记录 (例如,北美一个记录,加拿大一个记录),则最小的地理区域具有更高的优先级。系统推荐为了更高的可用性而把此类记录的 TTL 设置为 60 或更低。地理位置的路由不仅有利于提高响应速度,而且可以根据地理位置提供本地化内容,还可以控制应用权限,还可以以可预测可控的方式在终端节点进行负载均衡。地理位置路由还可以配合 Traffic Flow 使用达到更加较为精确的流量控制的目的,这部分内容参看【官方文档】。
  • Multivalue Answer:多值应答路由。多值应答记录的值只能设置一个。大部分记录类型都可以设置多个值,比如 A 记录可以指定多个 IP 地址,那为什么还要使用多值应答?为了配合使用状态检查 Health checks 来提高可用性和负载均衡性。如果您没有为多值应答记录关联运行状况检查,则 Route 53 始终认为记录正常。

提示:

如果要设置裸域/顶级域,则不要输入“@”符号,保持空白即可;

三流的邮箱服务商还没上 SPF 的时候二流的服务商还在拿 SFP DKIM 和 DMARC 为骄傲的时候一流的服务商现在已经不推荐设置 SPF 记录了,文档表达的理由是:

RFC 7208 中的 Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1 (在电子邮件中授权使用域的发件人策略框架 (SPF),版本 1) 已更新为:“…[I]ts existence and mechanism defined in [RFC4408] have led to some interoperability issues. Accordingly, its use is no longer appropriate for SPF version 1; implementations are not to use it.“(…在 [RFC4408] 中定义的其存在和机制已导致一些互操作性问题。因此,它已不再适合 SPF 版本 1;实施方案中不应再使用它。) 在 RFC 7208 中,请参阅第 14.1 节 The SPF DNS Record Type

一般情况下创建了一条 DNS 记录以后这条记录大概 60秒 内传播到所有 Route 53 服务器。

私有 Amazon VPN 解析(Private Hosted Zone for Amazon VPN)

如要使用 Route 53 解析 aws VPC 资源,请参考【官方文档】

记录检查(Test Record Set)

要知道某条记录的生效情况可以选中该条记录以后单击菜单栏上的“Test Record Set”来测试,还可以指定特定的其他 DNS 服务器或者客户端 IP 地址来判断 Route 53 给他们返回了什么。

这里的检查只适用于公共域而不能用于私网。

DNS response code 状态可以参考【这个文档

DNS 查询日志(DNS query logging)

前面说了 Route 53 是当前地表屈指可数的提供查询日志的服务商,大厂里面更是几乎唯一的一个。如何配置查看 DNS 查询日志呢?

访问【这个页面】,也就是点击 Route 53 页面左侧的 “Hosted zones”这里会看到你的已经创建了解析记录的域名列表,点击你要配置查询日志的域名前面的单选框(小圆点)(不是点击域名),右侧弹出一个面板叫做“Hosted Zone Details”。页面最下方点击“Configure query logging”按钮。

查询日志只能放在 US East(N. Virginia) 不能放在其他地方。

建议为每一个域名建立一个 log group。那么选择 “New log group in US East(N. Virginia) “即可,下面的”New log group name”为了方便管理建议写成 /aws/route53/example.com 这种。

下一步,配置权限,根据需要配置完成后测试,测试成功创建即可。

查看日志:如同上面一样点击域名前面的小圆点右侧弹出面板里面点击前面写的日志组名称就可以查看了。会跳转到 CloudWatch 页面的“日志”标签。

处理日志:选中日志组名称,上面菜单按钮“操作”里面选择。


SPF, DKIM & DMARC email anti-spoofing technology history and future

这篇文章翻译自 FastMail 官方博客
原文:https://blog.fastmail.com/2016/12/24/spf-dkim-dmarc/
这是第二十四篇也是 2016 FastMail Advent Calendar 系列的最后一篇文章。谢谢大家阅读也一如既往地感谢大家使用 FastMail

看看这封邮件是从谁发给谁的呢?

From: PayPal <[email protected]>
To: Rob Mueller <[email protected]>
Subject: Receipt for your donation to Wikimedia Foundation, Inc.

事实上,这些邮件头根本没有告诉你这封邮件真正地是从哪儿发到哪儿的。主要有两个彼此分开的电子邮件标准。RFC5322(旧版RFC822/RFC2822)规定了电子邮件格式,包括邮件头比如 发件人/收件人/邮件标题 和电子邮件正文。然而,它并没有规定电子邮件如何在不同的电子邮件系统之间传递。RFC5321(旧版RFC821/RFC2821)中规定了 简单邮件传输协议(SMTP),它详细地规定了电子邮件在不同系统之间的传递方式。
这种标准分开设计的结果是:邮件消息的格式不需要和邮件的发件人或收件人有任何关系。意思是,你在电子邮件中看到的 发件人/收件人/抄送 这些邮件头也许和这封邮件在 SMTP 传递过程中使用的真正的发件人或者真正的收件人没有关系。
当电子邮件标准制定的时候,互联网是一些人们互相之间认识的一些大学的计算机组成的网络。标准制定的假定情况是邮件用户和其他发送者是互信的。
所以,发件人 字段应该就是这个电子邮件地址的主人。当你要指定收件人的时候,收件人地址应该写在收件人字段并且以 SMTP 为协议发送给收件人(通过 SMTP 的 RCPT TO 命令)。这种分离邮件格式和传递也允许类似秘送(Bcc, blind carbon copy)。任何秘送字段中的地址将不会出现在邮件头中,但是SMTP可以用来把邮件发送到正确地目的地。
随着时间的推移,这种互信的友善的网络环境变得越来越不那么可信了。我们现在的网络环境更多的是恶意和不可信的。我们现在迫切需要保护我们的系统远离垃圾邮件和钓鱼邮件的侵害,因为他们大多数都是为了欺诈用户。
从使用 实时黑名单 (RBLs Realtime Blackhole Lists)判断已知的垃圾邮件发送服务器到邮件内容分析确定是否为垃圾邮件,已有多种层次的垃圾邮件控制手段。在这里,我们将讨论主流的反垃圾邮件技术。

SPF

反欺诈邮件最早期的一个成果是 SPF(Sender Policy Framework 发送方策略框架),SPF 的主导思想是指定通过域名的邮件发送方,通过 DNS 记录来指明特定的域名允许发送邮件的服务器。比如,只允许服务器 x,y和z 发送 @fastmail.com 的邮件。
不幸的是,SPF存在许多问题。起初,SPF只能用于 SMTP 发送协议的域名,也就是 MAIL FROM 这样的信封地址。甚至没有电子邮件软件显示这个地址。(它的主要用途是当邮件发送失败的时候发送错误/退回邮件而使用。)如今,没有必要非得 MAIL FROM 地址匹配发件人字段。所以实际上,邮件反欺诈的对象其实是一个跟本没有人看到过的地址(the only thing youʼre protecting against is the spoofing of an email address no one ever sees)
在这种理论之下,它却是有效地防范了大量的垃圾邮件。它减少了退信(backscatter email),退信就是当你不能收到仿冒邮件的时候看到的邮件。
实际的情况是,只有在如果人们确实挡住了 SMTP 阶段的 SPF 检查的邮件时才有效。很少由于 SPF 有许多问提而有效。它完全打破了传统的邮件转发。当系统转发一封邮件的时候,系统假定 MAIL FROM 被保存用来当邮件转发失败的时候退回给发送者。不幸的是,这意味着某人从 Hotmail 发送了一封邮件给 FastMail,然后你从 FastMail 转发到了 Gmail,在从 FastMail 转发到 Gmail 这个过程中就有了问提。其中 MAIL FROM 地址是一个 @hotmail.com 的域名,但是 SPF 将表明的是 FastMail 是不能被允许用来发送以 @hotmail.com 为域的邮件的。
有种方法 发送者重写策略(SRS, Sender Rewriting Scheme)试图完善这个问提,但是它过于复杂。它让 SFP 提供的保护被相对地降低了,并没有太多地方选择使用 SRS。这种方案以本着对发送方对邮件的签名的尊重就这样终止了。如果 SPF 检查通过,那么或许这封邮件是 MAIL FROM 中的域的合法的邮件。如果 SPF 检查失败,好吧,也不能说明很多问提。有可能这是一封被转发的邮件,也可能是 SPF 记录没有配置,或者许多其他的可能。

DKIM

DKIM(DomainKeys Identified Mail 域名密钥识别邮件标准)是一个明显相比 SPF 符合和有意思的标准。它允许域所有者(同样的,通过 DNS 记录的方式)加密地签名邮件的部分内容以便收件人验证它们是否被修改了。
DKIM is a bit fiddly at the edges and took a while to get traction,但是现在它已经被广泛使用了。发送到 FastMail 的邮件大约有 80% 都是经过 DKIM 签名的。
让我们来看看开始的时候那封邮件中添加的 DKIM 签名:

DKIM-Signature: v=1; a=rsa-sha256; d=paypal.com.au; s=pp-dkim1; c=relaxed/relaxed;
    q=dns/txt; [email protected]; t=1480474251;
    h=From:From:Subject:Date:To:MIME-Version:Content-Type;
    bh=Vn79RZZBrNIu4HFwGMOOAezyw/2Ag+w+avW1yscPcUw=;
    b=...
From: PayPal <[email protected]>
To: Rob Mueller <[email protected]>
Subject: Receipt for your donation to Wikimedia Foundation, Inc.

使用公钥加密和 DNS 查询,邮件接收者可以判断域“paypal.com.au”签名了邮件正文和一些邮件头(这个例子中有 发件人,标题,日期,收件人 等等)。如果签名有效,则认为这封邮件的邮件头和正文在传输过程中没有被修改过。
虽然这很有效,但是仍然有一个很大的问题。
那些以 @paypal.com.au 结尾的没有经过签名的邮件呢?或许不是 PayPal 的每个部门的邮件都正确设置了 DKIM 签名。那我们是否觉得这些没有签名的邮件就是不可信的呢?
并且,我如何知道我能信任这封经过签名的邮件?在这个例子中,paypal.com.au 很可能是属于 Australian division of PayPal Holdings 公司,但是,paypal-admin.com 呢?这并没有明确我应该信任哪个域不信任哪个域。在这个例子中,发件人字段匹配域的 DKIM 签名,但事实情况不一定如此。你可以给任何域都签名 DKIM 信息。这并不能阻止骗子使用签署了 paypal-admin.com 的 DKIM 签名的 @paypal.com.au 发件人地址。
尽管如此,DKIM 提供了正确的信息。它可以使邮件接收方去 associate 域名(或者多个,由于同一封邮件拥有多个 DKIM 签名是可以的并且很多情况下是有用的)和它签名的邮件。随着时间的推移,邮件接收者可以为域和/或和它关联的 IPs 建立一个可信的衡量,发件人地址,和其他邮件特性。这对区别“可信的”邮件和“不可信”的邮件是有帮助的。

DMARC

DMARC (Domain-based Message Authentication, Reporting & Conformance) 试图解决 SPF 和 DKIM 二者遗留的可信问提。仍然,通过 DNS 记录,域所有者可以定义邮件接收者接受到邮件后的行为。就 DMARC 来说,我们通过查看发件人字段认为邮件来自一个特定的域:–当你收到邮件的时候看到的地址。
基本上,在你设置一个 DMARC 记录后邮件接收者应该:

  1. 检查发件人字段的域是否匹配 DKIM 签名的域(这个过程叫做 校验(alignment))以及 DKIM 签名是否有效;
  2. 检查发件人域头字段是否匹配 SMTP 的 MAIL FROM 域以及发件人的 IP 地址是否被 SPF 所允许;

如果有其一(either)检查通过,则这封邮件的 DMARC 则通过检查。如果都检查失败, DMARC 的 DNS 记录规定了接收方应该采取的行为,包括隔离邮件(发送到你的垃圾邮件箱)或者拒收。此外, DMARC 记录可以指定一个电子邮件地址来接受 DMARC 报告。 DMARC 还允许发送方指定 DMARC 记录生效的邮件百分比,所以可以以一种逐渐地可控地方式进行 DMARC 的配置。
回到我们的例子邮件中:

DKIM-Signature: v=1; a=rsa-sha256; d=paypal.com.au; s=pp-dkim1; c=relaxed/relaxed;
    q=dns/txt; [email protected]; t=1480474251;
    h=From:From:Subject:Date:To:MIME-Version:Content-Type;
    bh=Vn79RZZBrNIu4HFwGMOOAezyw/2Ag+w+avW1yscPcUw=;
    b=...
From: PayPal <[email protected]>
To: Rob Mueller <[email protected]>
Subject: Receipt for your donation to Wikimedia Foundation, Inc.

在这个例子中,发件人域是 paypal.com.au 我们来看看是否被配置了 DMARC 规则。

$ dig +short _dmarc.paypal.com.au TXT
"v=DMARC1; p=reject; rua=mailto:[email protected]; ruf=mailto:[email protected],mailto:[email protected]"

是的,得到了 DMARC 配置信息。我们来进行分析!发件人域是否匹配 DKIM 签名域 paypal.com.au?匹配,我们完成了校验。如果这封邮件没有被 DKIM 签名,或者如果它被签名了但是被签名的是 paypal-admin.com(假设被不法之徒签名了),这样的话将不会完成校验,因此 DMARC 校验将会失败。在这点上,我们已经了解过 DMARC 规则了,它指定了 p=reject 我们应该拒收这封仿冒邮件。
在这个例子中(我没有写出完整的 DKIM 签名,但我可以告诉你签名是有效的),这封电子邮件通过了 DMARC 验证。所以我们可以接受它。通过校验,我们清楚了发件人地址的域也和 DKIM 签名中的域是匹配的。这一点可以让用户确信当他们看到一个发件人:@paypal.com.au 地址的时候,他们知道这确实是一封来自 paypal.com.au 的邮件而不是仿冒邮件。
这就是为何 DMARC 被认为是反仿冒邮件的未来。意思就是发件人的域不能被仿冒(至少域有 DKIM 签名并且发布了 DMARC 规则)。所有的这一切,某种程度上仅仅是保证了发件人地址的域不会被仿冒。(All that, just to ensure the domain in the From address canʼt be forged, in some cases.)
不幸的是,按照套路来说,这个特性当然也会带来一些问提。
DMARC 允许你使用 SPF 或 DKIM 来验证一封邮件。如果你没有 DKIM 签名但是仅仅 依赖 SPF 的话,如果一封邮件从一个邮件服务商转发到另一个邮件服务商,DMARC 校验将会失败。如果你设置了 p=reject 规则的话,这个转发将会失败。不像 SPF 中那样校验失败更像是一种“弱签名”, DMARC 规则是假定告知接收者更严格的规则,使退信是一种更大的可能性。
解决方案:如果你有 DMARC 规则则确保总是用 DKIM 签名了邮件。如果你的邮件被转发,SPF 规则将被破坏,但是 DKIM 签名应该仍是可用的(should survive)。SRS 对 DMARC 没有帮助,因为用你自己的域替换 MAIL FROM 意味着 MAIL FROM 的域将不匹配发件人头标签中的域。这会导致校验失败,会导致 DMARC 校验失败。
我说仍是可用的(should survive),因为,再次地,并不是所有地电子邮件服务商都完美支持。这个理论之下,转发保证了你地邮件地完整结构。不幸的是,并不总是如此。甚至大的电子邮件服务商也会不经意间略微地改变电子邮件的内容/结构(基于微软 Exchange 的邮件系统(包括 outlook.com)和苹果 iCloud 在这方面做的更差一些)。甚至一个微小的修改都会导致 DKIM 签名失败,而且,结合 DMARC 的 p=reject 规则的话,会导致这封转发邮件被目标服务商拒收。
解决方案如下:

  1. 给这些邮件服务商反馈 bug 让他们完善他们的转发系统以便在传输过程中邮件保持完整性。DKIM 目前已经是一个标准了,电子邮件服务商应该确保他们的转发不破坏邮件签名。
  2. 转而使用 POP 协议从远端获取邮件。我们不对通过 POP 方式获取的远端邮件做 SPF/DKIM/DMARC 检查。
  3. 不要使用邮件转发。不管邮件从哪里来,改变你的邮件服务商所在的邮件地址让它直接指向 FastMail 的邮件地址,避免转发。

DMARC 还有个大问题:邮件列表。邮件列表被认为是个邮件转发的特例:你发了一封邮件,这封邮件被转发给了其他地址(邮件列表中的地址)。然而,邮件列表转发邮件的时候普遍都会修改邮件,在每一封邮件的底部加入一些取消订阅邮件的链接或者标准标准签名和/或在标题加入[list-id]标签。
DKIM 签名标题和正文是非常普遍的。改变它们就会破坏 DKIM 签名。所以,那么当邮件列表软件尝试转发邮件给所有的列表用户的时候,收取邮件的系统将会破坏 DKIM 签名从而导致邮件被拒收。(有件具有代表性的事情是 许多年前雅虎和AOL邮件系统都启用 p=reject (Yahoo and AOL both enabled p=reject on their user webmail service domains a few years ago!
幸亏,有个相对直接的解决方案。邮件列表软件可以重写邮件的发件人,并且重新对这个域进行 DKIM 签名。这一点和其他解决方案( couple of other solutions )可以在 DMARC 网站上有说明。目前,大多数邮件列表软件系统已经实现了对这些解决方案的兼容,那些还没有解决这个问题的邮件列表系统将不得不面对类似 Gmail明年的某个时候将启用 p=reject 规则。(Gmail enables p=reject on gmail.com sometime early next year )这样的问题。不能从世界上最大的邮件系统转发邮件将明显对你的邮件列表造成影响。
这些认证体系对 FastMail 来说影响个我们收邮件和我们发邮件方面的工作。

SPF, DKIM & DMARC for email received at FastMail

当前,FastMail 对通过 SMTP 协议收取的远端服务器的邮件进行 SPF, DKIM 和 DMARC 检查(但不影响 POP 协议收取的邮件)。
SPF 和/或 DKIM 验证通过或失败仅仅会影响这封邮件的垃圾邮件指数(spam score).我们不想对来自一个重要的域的邮件因为 DKIM 签名验证失败而歧视,我们也不会因为垃圾邮件黑名单中的域通过的 DKIM 签名而把它移除黑名单加入白名单。 DKIM 签名只是当作邮件上下文信息对待,并不是对它进行白名单/黑名单判定的重要依据。
DMARC呢,是域的所有者对来自于他自己的域的邮件的处理方式的一个表述。对于使用了 p=quarantine 规则的域,我们对失败的邮件一个比较高的垃圾邮件指数(spam score)来确保它能到达用户的垃圾邮件文件夹。对于使用了 p=reject 规则的域,我们当前不在 SMTP 阶段拒收但是仍然给它一个比较高的指数然后隔离。未来我们希望加入一些已知的会导致问题的服务条款来改变这一点。
我们给所有收到的邮件加入了一个标准的 Authentication-Results 邮件头标签用来说明 SPF, DKIM 和 DMARC 规则的生效情况。不可思议的是现有的软件在这方面并没有做到很好的优化(not well maintained )或者存在 bug,所以我们发起了一个开源项目希望别人使用( open source solution we hope others will use
再次回到我们的例子当中。下面是那个 PayPal 邮件相应的 Authentication-Results 头标签。

Authentication-Results: mx2.messagingengine.com;
    dkim=pass (2048-bit rsa key) header.d=paypal.com.au [email protected] header.b=PVkLotf/;
    dmarc=pass header.from=paypal.com.au;
    spf=pass [email protected] smtp.helo=mx2.slc.paypal.com
DKIM-Signature: v=1; a=rsa-sha256; d=paypal.com.au; s=pp-dkim1; c=relaxed/relaxed;
    q=dns/txt; [email protected]; t=1480474251;
    h=From:From:Subject:Date:To:MIME-Version:Content-Type;
    bh=Vn79RZZBrNIu4HFwGMOOAezyw/2Ag+w+avW1yscPcUw=;
    b=...
From: PayPal <[email protected]>
To: Rob Mueller <[email protected]>
Subject: Receipt for your donation to Wikimedia Foundation, Inc.

大家可以看到 SPF,DKIM 和 DMARC 都通过了验证。
邮件头信息被 FastMail 系统的其他部分使用。举个例子,如果你把地址 [email protected] 加入了通讯录以便使它进入白名单。如果这类邮件的 DMARC 验证失败的话我们将忽略它的白名单属性。这保证了坏人不能用创建一个以 [email protected] 为发件人的诈骗邮件,因为你已经将它加入白名单了。

SPF, DKIM & DMARC for FastMail and user domains

所有的 FastMail 域名当前都有较为宽泛的 SPF 规则(如此设计是为了兼顾老的系统,看下文的 DMARC)并且我们对所有发出的邮件都采用 DKIM 签名。事实上我们签名两个域名,一个是发件人地址的域还有就是众所周知的 messagingengine.com。这和那些用 DKIM 签名来判断邮件来源的系统的反馈环路设计( Feedback Loops )有关。
对于使用自定义域,如果你在我们这里托管 DNS 的话(host the DNS for your domain ),我们仍然有较为宽泛的 SPF 规则和 DKIM 签名。如果你使用了其他 DNS 服务商解析的话,你需要确保在你的 DNS 解析李设置了正确的 DKIM 签名(DKIM record at your DNS provider ) 。一旦我们检测到 DKIM 记录,我们就会使用它来签署你通过我们发出的邮件。
当前,FastMail 自己的域没有 DMARC 规则,也没有对自定义域发布默认的规则。这意味着用户可以用 @fastmail.com 从任何地方发送邮件。这种做法是有点过时了。当 FastMail 16年前刚创立的时候,这些身份认证标准还都不存在。人们使用各种复杂的他们想发送邮件的各种发件人信息来发送邮件。(老的联网传真/扫描仪是这种做法的典型代表。)
随着时间的推移,这种情况变得越来越少,并且越来越多的人们期望电子邮件是通过了 DKIM 签名并且/或者通过了 SPF 验证并且/或者有 DMARC 规则。未来的某个时候,很可能我们的域名也会启用 p=reject 规则。要发送以 @fastmail.com/@sent.com/等等为发件人的邮件,你必须通过我们的系统发送。这种方式可以通过 SMTP 可以完美认证,如今一些基础的东西都已经完美支持了。

Ongoing problems

虽然通过 DMARC 我们可以验证发件人域名是否被允许发送邮件还可以验证邮件内容,是个很有效的方法欺诈邮件的特性,但反欺诈仍然有很长的路。虽然我们在这方面很有经验但是用户一般不会持怀疑态度去检查邮件。我们经常看到这样的欺诈邮件:

From: No Reply <[email protected]> 
To:[email protected] 
Subject: Urgent! Your account is going to be closed!

Click [here](http://example.com) right now or your account will be closed

很多用户就点开了链接,在一个伪造的页面上输入了登陆信息(甚至包括那些看起来都不是 FastMail 的页面的页面),我们每天都能遇到各种各样的账号被盗。不幸的是,试图教用户(educate users )貌似并不奏效。
电子邮件的一个主要的有点是它是一个真正的开放的消息系统。世界上的任何人都可以创建一个电子邮件账号和其他的邮件系统开始通讯。它不是一个受制于某个个体公司或者网站的围城。这种开放也是最大的弱点,这意味着合法的发件人和仿冒邮件发送者是同等的。这意味着未来电子邮件的发展将继续它在合法收件人和仿冒邮件发送者之间的这种竞争,试图判定每一封邮件是合法的有很多很多种因素。不幸的是,这意味着误判是在所难免而且一直会有的(仿冒邮件合法地进入了收件箱或者合法的邮件被标记为仿冒邮件)。世界上没有一个“完美的”邮件系统,无论系统里被投递进来了什么,我们都将努力变得更好。

Email authentication in the future

虽然邮件列表和 p=reject 规则不兼容这个主要的问题已经被大部分解决了,它产生了一个新的问题那就是收件方对邮件列表的域名的信任问题。这刺激了垃圾邮件发送者把目标转向邮件列表,希望更宽松的垃圾邮件判定规则以便把垃圾邮件发送到信任邮件列表域名的那些邮件系统中。一个新的叫做 (ARC,Authenticated Received Chain)的标准让邮件接收者以同等的情况去返回去信任他们能看到信任结果的前置的接受系统并且把先前多个阶段的投递路径的域名相关联。
我们愿意看到的是域名和一些现实世界相关联。其中一个重任被 SSL 扩展验证证书(SSL Extended Validation (EV) Certificate )系统担任了。申请 EV 证书需要提供实际的合法的身份证明。当你在访问一些使用了 EV 证书的网站时你可以在浏览器中看到。比如我们的网站使用了 EV 证书https://www.fastmail.com),浏览器在地址栏会现实“FastMail Pty Ltd”。清楚地在合法地发件人旁边显示 PayPal 的“PayPal, Inc”或其他财务类网站对用户来说看起来是个 significant win(modulo the slightly sad results we already found regarding users falling for phishing emails 。
不幸的是,这方面没有标准并且也没有其他关于这方面的起色的事情,and it’s not entirely obvious how to do this without support from the senders.一个不需要发件人参与的方法是从发件人地址中提取域名并且试图使用 https:// 去连接。但是这样会有其他一些副作用,比如 PayPal 用国别域名签名 DKIM 信息(比如 paypal.com.au),但是如果你在浏览器中访问 http://paypal.com.au ,将会跳转到 https://www.paypal.com 。我们不能简单地仅仅跟网站跳转因为不法分子可以建立一个 paypal-scam.com 的网站并且指向 https://paypal.com .Working out what redirects should actually be followed is entirely non-trivial.

Coda

这篇文章比我计划的内容要多了许多,它指出了如何在现代的电子邮件系统上下文中完成电子邮件认证这个主题。FastMail 努力试图让这些不但能让其他系统的发件人而且也能让自定义域的发件人“just work”。如果你把 DNS 托管在我们这里的话,我们为你自动配置 SPF 和 DKIM 签名规则。我们当前没有设置 DMARC 记录(还有其他不同的邮件发送方式),but we hope in the future to allow easier construction and rollout of DMARC records for user domains.