Email
今天在家里的票务系统上修改某个票的状态（该操作会出发点一封邮件）时，
我正好另一个窗口开着邮件服务器的日志，观察到一些奇怪的现象：
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
| Mar 19 20:17:12 XXXXXX postfix/smtp[XXXXX]: certificate verification failed for
gmail-smtp-in.l.google.com[2607:f8b0:4023:1c03::1a]:25: self-signed certificate
Mar 19 20:17:12 XXXXXX postfix/smtp[XXXXX]: Untrusted TLS connection established
to gmail-smtp-in.l.google.com[2607:f8b0:4023:1c03::1a]:25: TLSv1.3 with cipher
TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS
(2048 bits) server-digest SHA256
Mar 19 20:17:12 XXXXXX postfix/smtp[XXXXX]: XXXXXXXXXX: Server certificate not verified
Mar 19 20:17:13 XXXXXX postfix/smtp[XXXXX]: certificate verification failed for
gmail-smtp-in.l.google.com[142.250.142.26]:25: self-signed certificate
Mar 19 20:17:13 XXXXXX postfix/smtp[XXXXX]: Untrusted TLS connection established
to gmail-smtp-in.l.google.com[142.250.142.26]:25: TLSv1.3 with cipher TLS_AES_256_GCM_SHA384
(256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256
Mar 19 20:17:13 XXXXXX postfix/smtp[XXXXX]: XXXXXXXXXX: Server certificate not verified
Mar 19 20:17:13 XXXXXX postfix/smtp[XXXXX]: certificate verification failed for
alt1.gmail-smtp-in.l.google.com[142.250.115.27]:25: self-signed certificate
Mar 19 20:17:13 XXXXXX postfix/smtp[XXXXX]: Untrusted TLS connection established
to alt1.gmail-smtp-in.l.google.com[142.250.115.27]:25: TLSv1.3 with cipher
TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS
(2048 bits) server-digest SHA256
Mar 19 20:17:13 XXXXXX postfix/smtp[XXXXX]: XXXXXXXXXX: Server certificate not verified
Mar 19 20:17:14 XXXXXX postfix/smtp[XXXXX]: certificate verification failed for
alt1.gmail-smtp-in.l.google.com[2607:f8b0:4023:1004::1b]:25: self-signed certificate
Mar 19 20:17:14 XXXXXX postfix/smtp[XXXXX]: Untrusted TLS connection established to
alt1.gmail-smtp-in.l.google.com[2607:f8b0:4023:1004::1b]:25: TLSv1.3 with cipher
TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS
(2048 bits) server-digest SHA256
Mar 19 20:17:14 XXXXXX postfix/smtp[XXXXX]: XXXXXXXXXX: Server certificate not verified
Mar 19 20:17:14 XXXXXX postfix/smtp[XXXXX]: Verified TLS connection established to
alt2.gmail-smtp-in.l.google.com[2607:f8b0:4003:c15::1b]:25: TLSv1.3 with cipher
TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA
(prime256v1) server-digest SHA256
Mar 19 20:17:15 XXXXXX postfix/smtp[XXXXX]: XXXXXXXXXX: to=<XXXXXXX@gmail.com>,
relay=alt2.gmail-smtp-in.l.google.com[2607:f8b0:4003:c15::1b]:25, delay=2.8,
delays=0.06/0.1/2/0.66, dsn=2.0.0, status=sent (250 2.0.0 OK XXXXXXXXXX
XXXX-XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX.XX - gsmtp)
|
最近没怎么关注安全方面的进展，结果错过了去年年底披露的 SMTP Smuggling。
这是 Timo Longin 发现的一个全新的针对 SMTP 协议的攻击手法，
现在的年轻人真是蛮厉害的。
阅读全文…(
本文约 1493 字，阅读大致需要 3 分钟
)我搞邮件服务器有二十多年了，最开始是在学校做社团的邮件服务，
后来有几年和 老房东
在某领先网络媒体公司做了多年针对公众提供的邮件服务，因此前同事群的名字也是「老邮条」。
我个人的域名是2002年注册的，自从那时起我就一直在自己运行邮件服务。
在过去二十年中的大部分时间，我采用的是 amavisd-new，
与直接使用 SpamAssassin 相比，
它还增加了病毒扫描等一系列功能和 milter
接口，这让它与 MTA 更容易集成。
阅读全文…(
本文约 1021 字，阅读大致需要 3 分钟
)这里简单记一笔。我有一个域名使用的是 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。
阅读全文…(
本文约 1412 字，阅读大致需要 3 分钟
)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 签名向外发出的邮件。
阅读全文…(
本文约 953 字，阅读大致需要 2 分钟
)今天无意中看了一眼服务器日志，结果发现了一些奇怪的消息：
1
2
3
4
5
6
7
8
9
| warning: unknown[122.168.199.151]: SASL LOGIN authentication failed: UGFzc3dvcmQ6
warning: unknown[176.8.89.240]: SASL LOGIN authentication failed: UGFzc3dvcmQ6
warning: unknown[185.232.21.42]: SASL LOGIN authentication failed: UGFzc3dvcmQ6
warning: unknown[206.217.216.13]: SASL LOGIN authentication failed: UGFzc3dvcmQ6
warning: unknown[220.196.249.145]: SASL LOGIN authentication failed: UGFzc3dvcmQ6
warning: unknown[5.253.204.74]: SASL LOGIN authentication failed: UGFzc3dvcmQ6
warning: unknown[70.45.212.49]: SASL LOGIN authentication failed: UGFzc3dvcmQ6
warning: unknown[93.177.73.82]: SASL LOGIN authentication failed: UGFzc3dvcmQ6
warning: unknown[93.177.75.66]: SASL LOGIN authentication failed: UGFzc3dvcmQ6
|
这里的 UGFzc3dvcmQ6 是什么呢？从直觉上看似乎是个 base64 编码的字符串。解码试试看，果然：
阅读全文…(
本文约 221 字，阅读大致需要 1 分钟
)