苹果在8月24日的开发者公告里改了口:新申请的Sign in with Apple匿名邮箱地址,今年晚些时候会换成private.icloud.com域名;但iCloud+的Hide My Email邮箱,不会跟着搬家,继续留在icloud.com下面。已经存在的privaterelay.appleid.com老地址照常转发,不受影响。
这份公告本身写得像一条普通的技术勘误,但它其实是对6月15日那份原计划的一次公开回撤——苹果最初的方案是把Sign in with Apple和Hide My Email一起迁到新域名,现在只迁了一半。开发者页面没解释为什么改主意,但答案并不难猜:域名一旦独立,就成了一张可以被批量识别和拦截的标签。
从"一起搬"到"分开搬",中间少了什么
对比一下时间线就能看出这次改口的分量。
苹果自己没解释动机,但逻辑摆在明面上:Hide My Email的价值,恰恰在于它藏在icloud.com这个巨大的通用命名空间里,网站的邮箱校验规则很难专门针对它写一条拦截规则。一旦独立出一个子域名,拦截成本瞬间降到几行代码。开发者社区在6月的原计划公布后就提出了这个顾虑,这次算是苹果少见的一次公开让步。
- 风险.Sign in with Apple仍然要换成新域名,开发者的账户系统、邮箱校验逻辑和白名单该改的还是要改,不是零成本的公告撤回。
匿名邮箱这行,大家都在打"域名可识别性"的仗
Apple不是第一个,也不会是最后一个碰到这个问题的公司。第三方匿名邮箱服务几乎都在用同一个办法绕开"域名即标签"的陷阱——支持自定义域名,把匿名邮箱的后缀交还给用户自己控制。
Fastmail的Masked Email和Proton Pass背后的SimpleLogin,都允许用户挂自己的域名,拦截规则等于失效——网站没法把"所有用SimpleLogin的人"和"所有用某个人自己域名的人"划等号。Firefox Relay承认过,部分网站会直接拒收它的Relay子域名邮箱。Apple两个产品加起来,连自定义域名的口子都没开,只能靠"藏进大池子"这一招保命,而这次公告说明,苹果自己也清楚这一招一旦失效就没有备用方案。
开发者该盯的不是公告本身,是兼容清单
对普通用户来说,这次调整几乎无感——不管是老邮箱还是新邮箱，转发都不会中断。真正要动手的是开发者:凡是接入了Sign in with Apple的App和网站，都得把邮箱校验逻辑、注册白名单和反欺诈规则里加上private.icloud.com,同时保留对privaterelay.appleid.com的兼容,苹果的私密邮件中继本身还要求发件方做SPF/DKIM认证并注册发送域名，这条并没有因为这次改口而放松。
域名一旦独立,隐身衣就变成了工牌
接下来值得盯的,是苹果会不会像Fastmail、SimpleLogin那样,某天开放自定义域名选项。如果不开,private.icloud.com迟早会走到今天privaterelay.appleid.com同样的处境——被网站认出来,被单独拿出来讨论要不要拦。