Apple 修复 Hide My Email 漏洞
Apple Fixes Hide My Email Vulnerability After 404 Media Coverage
Apple 的 Hide My Email 功能本应保护用户隐私，却存在一个严重漏洞，让任何人都能轻易获取用户的真实邮箱地址。尽管 Apple 早在 2025 年 6 月就收到 EasyOptOuts 创始人 Tyler Murphy 的报告，但直到 404 Media 在 7 月初曝光此事后，Apple 才在 7 月 3 日真正修复了问题。该漏洞利用邮件被自动标记为垃圾邮件的机制，导致隐藏邮箱地址泄露。目前，已有针对 Apple 的集体诉讼，要求退还订阅费用并指控其“欺骗行为”。尽管漏洞已修复，但 Tyler Murphy 警告称，此前创建的地址可能仍暴露在第三方日志中，风险并未完全消除。
我们不知道隐藏邮箱地址在邮件日志中泄露的频率有多高，但对于许多主要邮件服务商来说，只要邮件被自动拒绝为垃圾邮件，就会触发泄露，即使这封邮件本身是合法的。
HN 评论区
29- satvikpendem
但 Apple 尚未收回他们曾希望为私密邮件设立一个专用域名（privacy.icloud.com）的说法，这会让任何邮件服务商都很容易屏蔽这些邮件。
- argee
我有个问题，不确定该怎么在 HN 上问，虽然和这个话题有点关联。我是某款应用的开发者，用户可以通过邮箱将其他人添加到他们的工作区。目前的机制是：将对方的邮箱加入工作区，然后对方用该邮箱登录时即可获取访问权限。
显然，这在“Hide My Email”面前行不通。处理这种情况的合适或标准做法是什么？我应该改用带邀请码的 URL，而不是直接将邮箱与访问权限绑定吗？我有点犹豫，因为邀请码需要在会话中持久化，且业务逻辑必须放在登录门户上，毕竟移动端和桌面端应用不共享 Web Cookie。深度链接（deep linking）是解决方案吗？
- js2
> 现在 Apple 称漏洞已修复，简单来说，这涉及向目标 Hide My Email 用户发送一封被标记为垃圾邮件的邮件。
这说法令人沮丧地模糊。我在原文发布时未能复现该问题。我虽未进行 exhaustive 测试，但确实尝试了多种方式让 HME 拒绝邮件（主要是发送超大邮件），但没有任何一种泄露了我的真实地址，因为邮件在重写为最终地址之前就被拒绝了。检查已送达的邮件时，我也没看到路径中有任何额外的 SMTP 服务器会拒绝该邮件。
我最多只能泄露出一个显示我真实域名的 DMARC 头，但这也仅发生在我用真实（非 icloud.com）域名回复 HME 邮件时。当我把 HME 更新为使用我的 icloud.com 地址后，连这个泄露也消失了（但这确实表明 HME 并未清理邮件头）。
也许如果你将 HME 设置为转发到非 icloud.com 域名，而该域名的 SMTP 服务器将邮件拒为垃圾邮件，这种情况确实可能发生。但如果是转发到 icloud.com 地址，理论上根本不该发生这种事。
真希望他们能提供一个包含完整邮件头的示例消息，让我们亲眼看看漏洞是如何触发的。退信是在投递路径的哪个环节生成的？
我需要更多细节。