了解现代 SMTP 和电邮 Anti Spam 协议(SPF, DKIM, DMARC)

注:本文于2024-01-21首发于https://v2ex.com/t/1010618

SMTP 协议

具体的协议本身就不多介绍了,各位可以参考维基百科: https://en.wikipedia.org/wiki/Simple_Mail_Transfer_Protocol

这里只指出一个重点:SMTP 将电邮区分为 Envelope 和 Data 两部分。通常我们在邮件客户端里见到的所有东西都属于 DATA ,包括 From:和 To:字段(也就是我们通常见到的收件人发件人)。然而所谓 Envelope 也有 MAIL FROM 和 RECP TO 数据,并且这二者和 DATA 里的 FROM/TO 一般并不一致!下文将详细展开。

Agents

现代 SMTP 把一封电邮送达的过程中的处理程序分为很多 Agent:

一个标准送达流程是:

MUA –> MSA –> MTA –> ... –> MTA –> MDA –> MUA

除了最后 MDA 到 MUA 以外,其实所有 agent 之间都通过 SMTP 协议联系。因此协议的行为其实因为 agent 的不同而有产生了区别:

MUA –> MSA:

可以理解为邮件进入互联网的第一站。MSA 负责验证邮件的真实性( Authentication ),也就是验证对应的 MUA 确实有权利发送这封邮件。通常这里会用到 SMTP Auth 来实现,也就是邮件服务商向用户要求一组用户名和密码。以及,MSA 会对电子邮件进行 DKIM 签名。

MSA –> MTA, MTA –> MTA, MTA –> MDA:

在邮件 relay 的过程中,这三者其实是等价的(也就是说存在 MSA 直接联系到 MDA 的情况。如果邮件再同一个服务商内中转,譬如 gmail 发送给 gmail ,那甚至此时 MSA 和 MDA 可以是同一个程序)。接受邮件的 Agent 也会检查送来邮件 Agent 的真实性,但并不是通过用户名和密码(下文会详细描述)。

值得注意的是,在所有的这些 Agent 中,程序是通过 Envelope 的 MAIL FROM 和 RECP TO 来决定如何邮件的来龙去脉的。DATA 里的 FROM 和 TO 并不决定邮件的去向。我们下面分开讨论。

MAIL FROM

通常来说,除了 MUA 以外,所有的 Agent 都会将 Mail From 设置成一个自己控制的值。举一个具体的例子,我拥有的 c7.io 域名配置了 CF 的 mail forward ,也就是发送给任何 [email protected] 的电邮都会被转发到我的 gmail 邮箱。

那么,如果一个 outlook.com 信箱向 [email protected] 发邮件,信件会如此传递:

可见,MAIL FROM 每次都会被改变,而且其中 identification 仍然能 uniquely identify 对应的这封电子邮件。这么做的目的是允许邮件服务商对 bounce-back 的邮件做额外的处理,并对接下来 Anti spam 的协议提供了机会。

RECP TO

既然说到了 MAIL FROM 就提一下 RECP TO 。这里和 spam 没什么关系,RECP TO 一般来说和 DATA 里的 TO+CC 一致,除非有 bcc 的情况。如果是 bcc 那么目标邮件地址不会存在于 DATA 中(所以才叫 blind ),只会出现在 RECP TO 里。

Anti spam

SMTP 协议本身设计的时候并没怎么考虑到 SPAM 的问题。所以协议本身有很多补丁。上面已经说过 MUA 到 MSA 时 MSA 会检查用户的用户名和密码,并且会很显然地检查 DATA 里的 FROM 字段确保这个登录进来的用户有权利以这个 FROM 的身份发邮件。然而在 MSA ,MTA 和 MDA 交流的过程中,大家都是不同服务商等价的程序,因此不存在谁事先在另外一方设置密码的可能性。所以,SPF 和 DKIM 就出现了。

SPF

https://en.wikipedia.org/wiki/Sender_Policy_Framework

当邮件在 MSA ,MTA 和 MDA 之间传输时,SPF 是一个很简单明了的协议。接收方会去 query 发送方域名的 SPF 字段。这个字段会指明哪些 IP 是这个域名允许的 sender 。譬如,当 c7.io MTA 向 gmail MDA 发邮件时,gmail 服务器会 query 到 c7.io 拥有 SPF record:v=spf1 include:_spf.mx.cloudflare.net ~all 。那么如果送邮件来的 IP 并不属于 mx.cloudflare.net ,那就 fail 了 SPF 。

DKIM

https://en.wikipedia.org/wiki/DomainKeys_Identified_Mail

SPF 只关注每个 agent 前一跳的身份,却并不能阻止一个恶意的 MTA 伪造邮件。所以出现了 DKIM 。当一封邮件进入到每一个 Agent 时( MUA 除外),这个 Agent 都会对邮件的数个 Header 和 Body (都处于 DATA 字段)进行签名并将签名内容也放在 DATA 字段里。Agent 签名会使用一个私钥,而其对应的公钥会在对应的域名的 dkim 记录里公布。从 DKIM 的精神来看,这个协议的目的是为了验证 DATA 中描述的邮件没有在传输中被篡改,也就是说,MSA 生成的 DKIM 签名是最有价值的。但实践中,似乎每一个 agent 插入到签名都会被接收者验证。

举个具体的例子:还是 outlook->c7.io->gmail ,outlook MSA 会插入一个用 outlook 私钥签字的签名。当 c7.io MTA 收到后,它会去 query outlook.com 的 DKIM record ,也就是 outlook 的公钥,并且用它来验证签名是否有效。然后 c7.io MTA 也会将现有的 DATA 再一次用 c7.io 的私钥签名。当 gmail MDA 收到邮件后,它会 query both outlook and c7.io 的公钥(譬如 k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDckJFiBtn29uLex8LM2DG4zvZ9doM9v8veISK5rAoS2yU517rqZN/gYGwhKVuvfmp86OJGKG2Z6SQG9JmcNQ7rGiVE6X99M71hm449ShkF29hG65lI9sFpjf/67bjnQcgwwj6q4aNKb9Rh3zc/gV4jtz+vfzaMTTcAdZbd8hKX3wIDAQAB ),然后验证两个签名是否都有效。一旦发现签名错误,就是 DKIM fail 。

DMARC

https://en.wikipedia.org/wiki/DMARC

DMARC 的目的是告诉 Agent ,如果 SPF 或者 DKIM fail 了,该如何处理这封邮件。DMARC 也存在于域名 DNS 记录中。DMARC 可以要求 agent 继续放行电邮(可能不会被遵守),但更通常是要求 agent 把邮件设为 spam ,并通知某个指定的地址。

其它

很多 Agent 会增加别的验证。譬如 Gmail 要求所有来信的 IP 的 reverse DNS 和其 MAIL FROM 的域名必须对应。这似乎和 SPF 正好是镜像。

用自己的域名收发邮件

总结上面的内容,如果想用自己的域名收发邮件,需要做到:

需要正确配置 SPF ,DKIM ,DMARC 不是必须的但是推荐。并且要和一个拥有对应 DKIM 私钥的 MSA 配合使用(这也是为什么现代不通过一个 mail relay (譬如 AWS SES ,Mailgun)直接发送一封邮件如此之难)。

仅需要配置域名的 MX ,指向 MDA 。一般来说大家都是用第三方的服务,所以 MX 指向第三方的服务器就行。

总结

SMTP 是一个典型的设计时没有考虑周全从而不断打补丁的例子。目前至少 Gmail 和 Outlook 都提供了”View Original”的功能,可以详细看到邮件原始的 DATA 部分。里面都会详细描述每一个 MTA 所插入的内容,包括 Agent 得到的 Envelope 的地址,其所做的 SPF ,DKIM 检查,和新的 DKIM 签名。大家可以去自己的邮箱里看看,和文章的内容对照一下。

本文在某些细节上讲的比较粗略,因为某些复杂的地方很难用白话语言说清楚。我希望这篇文章能起到一个提纲的作用。具体生产中如果遇到了问题还是要去读协议标准。

#email #spf #dkim #dmarc #antispam

You can reach out to me at [email protected], or via Mastodon.