![使用第三方电子邮件服务时,SPF 是否存在核心弱点?](https://linux22.com/image/722914/%E4%BD%BF%E7%94%A8%E7%AC%AC%E4%B8%89%E6%96%B9%E7%94%B5%E5%AD%90%E9%82%AE%E4%BB%B6%E6%9C%8D%E5%8A%A1%E6%97%B6%EF%BC%8CSPF%20%E6%98%AF%E5%90%A6%E5%AD%98%E5%9C%A8%E6%A0%B8%E5%BF%83%E5%BC%B1%E7%82%B9%EF%BC%9F.png)
SPF 记录是一种 DNS 记录,它主要指出哪些 IP/域被允许代表该域发送电子邮件。
当使用第三方电子邮件服务时,该服务通常建议对其所有服务器使用“catch-all”SPF 记录。Sendgrid 的建议如下:
v=spf1 include:sendgrid.net ~all
与此记录关联的域(例如 example.com)将“允许”来自所有 sendgrid.net 域的所有电子邮件。
在我看来,攻击者只需注册一个 Sendgrid 帐户并代表 example.com 发送电子邮件即可“通过”SPF 检查。
这是真的?
我知道 SPF 并非旨在验证消息的真实性。但在适当的情况下,如此广受赞誉的技术却存在如此容易被利用的弱点,这似乎有点奇怪。是的,我确实意识到从第三方电子邮件服务请求私有 IP 可以缓解这种担忧。
答案1
您提到的 DNS 记录显示:
我,该域名的所有者,相信 Sendgrid 将
From:
验证全部留下的电子邮件全部SMTP 服务器在其 IP 池中,并且 Sendgrid 将阻止未经授权的内容。
这不是 RFC 所说的,但这是实际意义。
这就是 SPF 的架构。称其为缺陷虽然可以理解,但毫无建设性。确实,在 DMARC 保护下,SPF 仅作为 DKIM 失败时的后备机制(DKIM 在统计上往往容易出错)。事实上,批量邮件服务将 SPF 作为主要机制,通常根本不提及 DKIM,而且通常彻底失败授权标题From:
说明了他们的无知核心业务。
面对这种情况,我总是建议使用 ,这可以在一定程度上减轻冒充 CEO、CFO、HR 等的影响。不过,无论谁想让我设置该域名记录,我总是要求他们接受风险。(我插入了他们 CEO 的真实姓名。他们通常会接受这一点。呵呵。)From: [email protected]
From: [email protected]