delphij's Chaos选择chaos这个词是因为~~实在很难找到一个更合适的词来形容这儿了……

Debug

共 105 篇文章。

postfix 的 SNI 支持与 gmail 的兼容问题

• Networking

今天在家里的票务系统上修改某个票的状态（该操作会出发点一封邮件）时，我正好另一个窗口开着邮件服务器的日志，观察到一些奇怪的现象：

 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)
阅读全文… ( 本文约 1916 字，阅读大致需要 4 分钟 )

关于 Google Workspace 的 SPF / DMARC 设置

• Security

这里简单记一笔。我有一个域名使用的是 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。

阅读全文… ( 本文约 1438 字，阅读大致需要 3 分钟 )

UGFzc3dvcmQ6 是什么？

• Security

今天无意中看了一眼服务器日志，结果发现了一些奇怪的消息：

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 编码的字符串。解码试试看，果然：

阅读全文… ( 本文约 224 字，阅读大致需要 1 分钟 )

记一件糗事：术后清理要做好

• Postmortem

今天和 Henry Hu 聊起 iichid 已经进了 FreeBSD 的主线，想起自己之前鼠标啥的还是都在用 sysmouse，觉得既然来都来了就索性都改成 evdev 的输入设备算了？改了 /boot/loader.conf 并增加了下列设置：

iichid_load="YES"
usbhid_load="YES"
hms_load="YES"
hw.usb.usbhid.enable="1"    # 防止uhid(4)接管

重启。等等，一闪而过的那是什么？

ntpd is not allowed to log in on /dev/console
阅读全文… ( 本文约 1449 字，阅读大致需要 3 分钟 )

GNU libtool 和 FreeBSD 10

• Development

FreeBSD 开始用 10 以上的版本号有一段时间了。这个变动立刻导致了大量 ports 无法编译，多数情况下是因为开发者采用了较早版本的 libtool 导致的，具体来说，是类似下面的代码：

阅读全文… ( 本文约 198 字，阅读大致需要 1 分钟 )

SMB协议 vs TCP的延迟ACK特性

• Networking

之前一直没什么概念，今天看了微软的 KB 321169 的解释，大致如此：

  • 客户端 (SMB Redirector) 如果启用了 security signature，则必须等待命令处理完成才会发出下一条SMB；
  • 服务器端如果启用了延迟ACK，则可能需要过200ms (Windows 2000)才会给出ACK回应

不过感觉这个解释依然不是很有说服力—-文档上说，SMB服务器端是需要对 NT_TRANSACT_NOTIFY_CHANGE 给出回应的，那么这种情况下ACK不就回应回来了吗？或者说，只要收到了 ACK 就说明服务器端已经处理了这条 SMB？哪位帮忙理解一下？

参与评论

备忘：OpenSSL valgrind报"Conditional jump or move depends on uninitialised value(s)"的解决

• Security

最近改一个用到 OpenSSL 的程序，顺手用 valgrind 抓了一下，发现很多「Conditional jump or move depends on uninitialised value(s)」的错误。发现 OpenSSL 的 FAQ 提到，在生成随机数时会将输入缓冲区（未初始化）的内容直接混入 entropy pool，使用 valgrind 时便会导致警告。

阅读全文… ( 本文约 396 字，阅读大致需要 1 分钟 )

.svn目录

• Development

今天同事跑来问我为什么没办法checkout一个子目录，发现svn提示说某个目录已有既有的、未有版本的副本（这是一个新的checkout）。

删除重新checkout，问题依旧。

阅读全文… ( 本文约 304 字，阅读大致需要 1 分钟 )

记一笔，关于 syslogd

• Development

syslogd 的 -8 参数可以让汉字通过。以下摘自 manual page：

1
2
3
4
5
6

     -8      Tells syslogd not to interfere with 8-bit data.  Normally syslogd
             will replace C1 control characters (ISO 8859 and Unicode
             characters) with their "M-x" equivalent.  Note, this option does
             not change the way syslogd alters control characters (see
             iscntrl(3)).  They will always be replaced with their "^x" equiv‐
             alent.

不过这事有点坑人，为啥默认不 -8 呢？出于安全方面的原因吗？差点就开始改代码了……

参与评论
搜索文章… (按 ESC 退出)