postfix 的 SNI 支持与 gmail 的兼容问题
今天在家里的票务系统上修改某个票的状态（该操作会出发点一封邮件）时， 我正好另一个窗口开着邮件服务器的日志，观察到一些奇怪的现象：
| |
SMTP Smuggling
最近没怎么关注安全方面的进展，结果错过了去年年底披露的 SMTP Smuggling。 这是 Timo Longin 发现的一个全新的针对 SMTP 协议的攻击手法， 现在的年轻人真是蛮厉害的。
用 rspamd 来实现反垃圾邮件
我搞邮件服务器有二十多年了，最开始是在学校做社团的邮件服务， 后来有几年和 老房东 在某领先网络媒体公司做了多年针对公众提供的邮件服务，因此前同事群的名字也是「老邮条」。 我个人的域名是2002年注册的，自从那时起我就一直在自己运行邮件服务。
在过去二十年中的大部分时间，我采用的是 amavisd-new， 与直接使用 SpamAssassin 相比， 它还增加了病毒扫描等一系列功能和 milter 接口，这让它与 MTA 更容易集成。
关于 Google Workspace 的 SPF / DMARC 设置
这里简单记一笔。我有一个域名使用的是 Google Workspace 的邮件服务。 昨天，一位用户使用该域名向中国的 QQ 邮箱用户发送邮件时被退回了。
退信中给出的线索是：
550 DMARC check failed [XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
IP: 2607:f8b0:4864:20::112b]. https://service.mail.qq.com/detail/124/61.腾讯给出的那个链接是一篇关于 DMARC 如何配置的文章。 从上下文来看，应该是由于腾讯的服务器认为 Google Workspace 的 IP 地址不在允许发信的范围内。
退信确实是 Google Workspace 的邮件服务生成的，数据来源是和对方(腾讯) MX 之间的 SMTP 会话。
我的这个域名确实启用了 DMARC。我的DMARC记录 (域名下的 _dmarc TXT 记录) 设置如下：
v=DMARC1; p=reject; rua=mailto:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX@dmarc-reports.cloudflare.net;
pct=100; adkim=s; aspf=s此配置要求对方检查 DKIM 和 SPF，并拒绝不匹配的邮件。
其 SPF 记录 (域名的 @ 的 TXT 记录) 设置如下。这是 Google 官方文档中推荐的设置：
v=spf1 include:_spf.google.com -all主要的区别是，我使用的是 -all，即拒绝 SPF 不匹配的邮件，而不是更为常见的、表示即使发现 SPF
不匹配，也仅仅做标记但允许接收的 ~all。
这里需要说一下背景：在 2004 年左右，一些业内人士认为应该推荐采用
~all 而不是 -all，因为当时许多大型邮件系统的架构中存在多层邮件服务器分别进行不同的过滤处理，
而在 SMTP 会话阶段直接回一个永久性拒绝 (5XX) 代码可能会让一些不适任的邮件系统管理员如此配置的邮件系统将一些伪造了来源的邮件退到不希望的地方。
我并不赞同这样的观点。事实上，在会话阶段进行退信要比在收件方服务器上生成退信并将退信退给发件人或对方域名的 postmaster 要更好：
对于垃圾邮件的发送者，这意味着他们的邮件服务器会立即知道自己的行为被直接地丑拒，
接收方明确告知他们吞下垃圾邮件，而不是继续发送。对于正常的邮件服务器，
这意味着发件人可以立即收到退信从而找到自己的邮件系统管理员，而不是告诉收件人去翻垃圾箱看看是否有自己的邮件。
另一方面，回应永久性拒绝并不妨碍收件服务器对邮件内容进行进一步分析：它完全可以在 DATA
阶段结束时再回拒绝，从而将邮件完整地接收下来但不递给收件人。
当然，历史无法假设，并已经无数次地证明人类根本不配拥有美好的事物。
DomainKey 记录 (域名下的 google._domainkey TXT 记录) 由于与此问题无关，故在此处略去。
该域名启用了 DNSSEC。
采用 Ed25519 的 DKIM 签名
Ed25519 是一种高性能的公钥签名系统。和 RSA 相比， 同等强度的 Ed25519 的密钥长度要比 RSA 短很多，此外，软件实现的 Ed25519 的验证速度也比同等强度的 RSA 快很多。
尽管早在2018年 RFC 8463 Section 5 就已经将 RFC 6376 Section 3.3 修正为要求验证者必须支持 Ed25519 验证，然而时至今日主要的邮件服务提供商中， 包括 Google 的 Gmail 和 Microsoft 的 Outlook.com 以及 Apple 的 iCloud 都还不支持验证 Ed25519 DKIM 签名。ProtonMail 支持 Ed25519 的 DKIM 签名，但它并不使用 Ed25519 签名向外发出的邮件。
UGFzc3dvcmQ6 是什么？
今天无意中看了一眼服务器日志，结果发现了一些奇怪的消息：
| |
这里的 UGFzc3dvcmQ6 是什么呢？从直觉上看似乎是个 base64 编码的字符串。解码试试看，果然：
dovecot的全文搜索
试了一下这个基于 CLucene 的全文搜索，似乎还不错。这里记一下过程。
首先是给 dovecot 安装 Lucene 插件，用 FreeBSD port 来安装的话，只需 make config，选择 LUCENE 然后 portmaster dovecot 即可。
配置也还算容易，我之前已经做了索引与数据分开，因此并不需要单独的配置，只需在 dovecot.conf 中增加：
奇怪的钓鱼信
今天收到一封奇怪的钓鱼信，它声称来自 Domain Registration of America，准确地说出了我的名字和拥有的域名中的两个，并建议我立即把域名转移到他们那里。
开价是……一年$30。
垃圾电邮30周年了
一段鲜为人知的历史。
据考证，世界上公认的第一封垃圾电邮，是1978年5月3日由 DEC 公司的销售代表 Gary Thuerk 发出的，两个行业随后相继诞生。
关于邮件的安全
今天在 车东 的 blog 上看到一篇说 关于邮件安全的文章，这里也说说我对这个问题的看法。
基于邮件的 XSS 问题其实是困扰 Webmail 供应商的一个很严重的问题。其实，未必是 XSS，有时可能是更简单的内存泄露问题。比较简单的是我 1999 年左右在某国内邮件服务提供商提供的邮件服务发现的一个问题，即，一方面我可以发脚本，获得 cookie；另一方面，我可以用 HTML 去构造一个特殊的 GET 请求（通过 IMG tag）来把这些cookie拿到。
接下来的故事就很简单了，攻击者通过在本地种这些 cookie，便可以访问收到并打开邮件的用户的邮件。严格地说，这甚至算不上一个跨站脚本攻击。解决方法也很简单，在服务器端的session中保存用户的登录 IP 地址。
然而，新一代的攻击变得越来越复杂了。一种典型的攻击是，发送垃圾邮件的人通过各种方法令你访问某个特定的 URL，并借此确认你的邮件地址有效。