postfix 的 SNI 支持与 gmail 的兼容问题
今天在家里的票务系统上修改某个票的状态(该操作会出发点一封邮件)时,我正好另一个窗口开着邮件服务器的日志,观察到一些奇怪的现象:
| |
共 107 篇文章。
今天在家里的票务系统上修改某个票的状态(该操作会出发点一封邮件)时,我正好另一个窗口开着邮件服务器的日志,观察到一些奇怪的现象:
| |
最近没怎么关注安全方面的进展,结果错过了去年年底披露的 SMTP Smuggling。这是 Timo Longin 发现的一个全新的针对 SMTP 协议的攻击手法,现在的年轻人真是蛮厉害的。
我搞邮件服务器有二十多年了,最开始是在学校做社团的邮件服务,后来有几年和 老房东 在某领先网络媒体公司做了多年针对公众提供的邮件服务,因此前同事群的名字也是「老邮条」。我个人的域名是2002年注册的,自从那时起我就一直在自己运行邮件服务。
在过去二十年中的大部分时间,我采用的是 amavisd-new,与直接使用 SpamAssassin 相比,它还增加了病毒扫描等一系列功能和 milter 接口,这让它与 MTA 更容易集成。
这里简单记一笔。我有一个域名使用的是 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 是一种高性能的公钥签名系统。和 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 是什么呢?从直觉上看似乎是个 base64 编码的字符串。解码试试看,果然:
很久以前在 macOS 上配置了一次,然后具体怎么配给忘了一个干净,所以这次写一个作弊条。
许久不碰反垃圾邮件的事情了,一来前段时间垃圾邮件确实也没有那么多,加上spamassassin确实相当有效,二来也是因为犯懒。
不过,最近几天垃圾邮件明显比平时多了许多,所以决定坐下来仔细处理一下。
试了一下这个基于 CLucene 的全文搜索,似乎还不错。这里记一下过程。
首先是给 dovecot 安装 Lucene 插件,用 FreeBSD port 来安装的话,只需 make config,选择 LUCENE 然后 portmaster dovecot 即可。
配置也还算容易,我之前已经做了索引与数据分开,因此并不需要单独的配置,只需在 dovecot.conf 中增加:
之前用的邮件系统是基于 postfix、Cyrus IMAPd、amavisd-new等软件在2006年搭建的,跑了5年多,作为不折腾会死星人,对这套系统一直有相当多的不满意,举例来说: