安全与隐私simonandrews.ca
用一堆愚蠢标准防止邮件伪造：SPF、DKIM、DMARC
How to prevent email spoofing, using an unholy combination of silly standards
2021 — 2024，它一次次回到首页
黑点是上首页（≥ 50 分）的那次投稿，空心点是没冲上去的投稿，点越大分数越高。
导读
这篇文章讲解如何通过配置 SPF、DKIM 和 DMARC 三套 DNS 记录来防止邮件伪造，并把这类标准的组合形容为“邪恶的愚蠢标准组合”。作者从 DNS 配置讲到自建邮件服务器的实际步骤，兼顾原理与操作。
为什么经久不衰：邮件伪造和自建邮件的配置十年来都是自托管者最头疼的问题，而文中涉及的 SPF/DKIM/DMARC 至今仍是邮件送达的核心机制，因此值得反复阅读。
HN 评论精选
这些标准其实不难，难的是邮件服务器本身，用 Mailcow 可以简化自托管。
我不同意 SPF、DKIM 和 DMARC 很难的说法。它们都是 DNS 配置里的一行命令，不想读标准的话用在线工具就能生成。我的经验是，正确配置邮件服务器软件比配置 DNS 让邮件可靠送达难得多，晦涩的配置格式几乎是所有邮件服务器的常态。我用 Mailcow 搞定自托管邮件：一台便宜 VPS 加 Docker 就够了，它会生成你需要的所有 DNS 记录。
jeroenhd查看英文原文
I disagree with the idea that SPF, DKIM and DMARC are somehow hard. They're all one-liners in DNS config that can easily be generated with some online tools if you don't want to read the standard. In my experience, correctly configuring mail server software is a lot harder than configuring the DNS to make your email arrive as reliably as possible. Obscure configuration formats are par for the course for almost every mail server setup. I've personally had a much harder time getting DNSSEC to work than I ever had issues with the various email DNS records. Even that is manageable if you're willing to Google around for a while. My solution to getting self-hosted email right is using Mailcow. A cheap VPS (Contabo FTW) plus Docker is all you need to get it to work, and it spits out all the DNS records you might need to add. That also includes autoconfig records for tons of software, which is nice.
SPF 有每条记录最多 10 次 DNS 查询的硬限制，include 过多会导致验证永久失败。
“想要多少条 include 都行”并不准确，因为 SPF 有一个（在我看来）很蠢的硬性限制：每条记录最多 10 次 DNS 查询。RFC 7208 规定 include、a、mx、ptr、exists 等机制在评估时的查询总数不得超过 10 次，超出就返回 permerror。在 Fastmail 我们经常遇到客户报 DMARC 验证失败，原因就是 SPF 里 include 太多导致 SPF 永远失败。
mmcclimon查看英文原文
> Normally, this means that spf.messagingengine.com has its own SPF DNS record, which will probably list some valid IP addresses that emails can be sent from. There's also one for Mandrill, for transactional emails. You can have as many of these as you want. This isn't strictly true (that you can have as many as you want), because SPF has a (IMO) very silly hard limit of 10 DNS lookups per record. From RFC 7208: > Some mechanisms and modifiers (collectively, "terms") cause DNS queries at the time of evaluation, and some do not. The following terms cause DNS queries: the "include", "a", "mx", "ptr", and "exists" mechanisms, and the "redirect" modifier. SPF implementations MUST limit the total number of those terms to 10 during SPF evaluation, to avoid unreasonable load on the DNS. If this limit is exceeded, the implementation MUST return "permerror". We see this not infrequently at Fastmail, when customers report DMARC validation problems, and the answer turns out to be that they've got too many includes in their SPF records, so SPF always fails.
从不发邮件的域名可以用这些记录显式拒绝所有邮件，并附了 gov.uk 指南。
补充一点：如果某个域名你根本不打算发邮件，也可以配置这些记录来让接收方拒绝一切邮件。这里有一份指南：https://www.gov.uk/guidance/protect-domains-that-dont-send-email
azornathogron查看英文原文
Related: if you have a domain from which you never want to send email, you can also set up these records to tell receivers to reject everything. Here is a guide: https://www.gov.uk/guidance/protect-domains-that-dont-send-email
自建邮件服务器并不简单，这套标准都是为互信环境设计的 50 年老技术的补丁。
每当有人说“自建邮件服务器很简单”时，我都会引用这篇文章。如果你已经熟悉所有环节，那当然简单；但如果你有个问题要解决，而你以为答案是自建邮件服务器，那你就有了两个问题。“邪恶的愚蠢标准组合”这个说法很贴切，但问题可追溯到 1970 年代：SMTP 最初基于匿名 FTP，只为发文本而设计，至今也只能做这个。感谢 Base64，让二进制附件比原始大小膨胀 30%。邮件是个问题，而且永远是，因为它是 50 年前为几百台互相信任的服务器设计的技术，SPF、DKIM、DMARC 全是事后补丁。
geocrasher查看英文原文
I'm going to refer to this post whenever says "running your own mail server is easy!". I suppose that if you already know how to run your own mail server and are familiar enough with all the moving parts, sure, it's easy. But if you have a problem that needs to be solved, and you think the answer is running your own mail server, you now have two problems. The "unholy combination of silly standards" is an excellent way of putting it, but it goes back to the 1970's. SMTP was originally based on FTP. Anonymous FTP, at that. It was designed to send text- nothing more. And really that's all it can do still. We can thank Base64 for binary attachments that are at 30% bigger than their unattached size. Yeah, mail is a problem. And it always will be because it's a 50 year old technology that was designed for a collection of a few hundred servers ran by technologists who trusted each other. SPF, DKIM, and DMARC (and literally everything after except for "send text to so and so") is an afterthought.
历次讨论
同类还值得读
非法素数
Illegal prime
维基百科条目，介绍“非法素数”：某些素数之所以被称为“非法”，是因为它们经特定编码后，恰好对应一段被法律禁止传播的数据——最著名的是 DVD 解密程序 DeCSS 的代码，有人把…
安全与隐私上首页 5 次 · 2010–2021en.wikipedia.org编辑精选关于 /dev/urandom 的常见误区
Myths about /dev/urandom
（Thomas Hühn 撰写，2014 年首发并持续更新）逐条反驳关于 /dev/urandom 的常见误解：它与 /dev/random 使用的是同一个 CSPRNG，一旦完…
安全与隐私上首页 5 次 · 2014–20202uo.de编辑精选AES 高级加密标准火柴人图解
A Stick Figure Guide to the Advanced Encryption Standard (AES)
一篇用火柴人漫画形式讲解 AES（高级加密标准）算法的经典科普文章。
安全与隐私上首页 5 次 · 2009–2022moserware.com编辑精选指纹是用户名，不是密码
Fingerprints are Usernames, not Passwords
作者（eCryptfs 维护者、Ubuntu 安全工程师）认为指纹等生物特征是公开、不可更改的标识，应视作用户名而非密码，不能当作秘密凭据用于认证。
安全与隐私上首页 4 次 · 2013–2017blog.dustinkirkland.comHTTPS 连接的最初几毫秒（2009）
The First Few Milliseconds of an HTTPS Connection (2009)
逐毫秒拆解一次 HTTPS 连接建立时发生了什么，重点讲 TLS 握手、证书验证、RSA 签名与密钥协商等机制，面向不熟悉该领域的读者。
安全与隐私上首页 4 次 · 2009–2020moserware.com编辑精选