delphij's Chaos

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

19 Mar 2024

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

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

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)
Read more...
16 Feb 2024

备份小故事一则

原载于 Telegram 频道。 今天来讲个关于备份的小故事。 以前有个同事之前在某使用UNIX的传统行业干了多年,他们的系统可用性要求不算高,但数据非常重要, 所以备份自然也是必不可少的。为了确保备份的安全性, 他们还雇了一家专门的保全公司定期把备份磁带从办公室拿走到该保全公司的仓库。 一切看起来万无一失,直到有一天他们的系统出现了问题,需要从备份中恢复数据。 自然,有那么多份不同时间的磁带的系统管理团队是不觉得有什么可慌的, 可是等到他们拿回了一大摞磁带的时候却傻了眼。 从磁带中恢复的只有一个符号链接 (symbolic link)。 不仅如此,之前更早的磁带里也都是同一个符号链接。最终他们成功恢复了半年之前的数据, 配合数据恢复公司恢复的硬盘数据,在几个星期之后终于把东西七七八八地怼回看起来是正确的样子了。 这是怎么回事呢?原来,他们在备份的时候选择了一个目录,然后慢慢的这个目录越来越大, 直到有一天有个大聪明表示不如这样吧,我们把数据搬到一块新的、更大的盘上,然后建个符号链接。 系统运行一切正常,甚至于备份也变得快了很多呢。 这个故事告诉我们,做了自动化备份之后,时不时的就得试试看备份出来的数据是不是真的能恢复成希望的样子。 Read more...
16 Jan 2024

大规模裁员:如何做好准备

简介

目前的经济形势下,许多公司都在进行裁员。大部分情况下,作为雇员对于公司是否进行裁员所能做的影响极为有限, 因此有必要提前对可能发生的裁员进行准备,以免仓促之下做出错误决策,或是在大规模裁员导致的踩踏事故面前束手无策。

本文主要是针对在美国境内工作的普通雇员,家里没矿,也暂时还没攒够足够退休的钱。 内容主要来自近期的阅读和想到的一些东西,算是给自己留下一些笔记。

Read more...
13 Jan 2024

备忘:如何知道 USPS PO Box 续费的价格

周三的时候,USPS发来了一封电子邮件,内容如下:

Read more...
02 Jan 2024

SMTP Smuggling

最近没怎么关注安全方面的进展,结果错过了去年年底披露的 SMTP Smuggling。 这是 Timo Longin 发现的一个全新的针对 SMTP 协议的攻击手法, 现在的年轻人真是蛮厉害的。

Read more...
31 Dec 2023

用 rspamd 来实现反垃圾邮件

我搞邮件服务器有二十多年了,最开始是在学校做社团的邮件服务, 后来有几年和 老房东 在某领先网络媒体公司做了多年针对公众提供的邮件服务,因此前同事群的名字也是「老邮条」。 我个人的域名是2002年注册的,自从那时起我就一直在自己运行邮件服务。

在过去二十年中的大部分时间,我采用的是 amavisd-new, 与直接使用 SpamAssassin 相比, 它还增加了病毒扫描等一系列功能和 milter 接口,这让它与 MTA 更容易集成。

Read more...
26 Dec 2023

这次的 ZFS 数据损坏问题

12月1日,FreeBSD 发布了 FreeBSD-EN-23:16.openzfs, 用于修正近期发现的 ZFS 数据损坏问题。 这个问题是由 Rob Norris 最终修正的,这里记一笔。

Read more...
20 Nov 2023

FreeBSD 14.0-RELEASE 发布了

上周末抽时间把服务器升级到了 FreeBSD 14.0-RELEASE。 软件的发布中存在许多的工序,大致上,在 releng/ 分支上的代码树会正式命名为 -RELEASE, 同时由一位 Release Engineer 开始最终的 build(对应的文件会发布到 FTP 上, 并在 网站 上提供链接),并在适当的时候将 releng/ 分支上的代码 tag 成 release。此后, Security Team 需要将 Release Engineer 签名的 -RELEASE 放到 freebsd-update builder 上再次 build、签名,并生成二进制更新所需的文件。

由于安装用的 ISO 映像文件都比较大,传统上将这些映像文件分发到全球的镜像站点上需要一些时间。 现时,云服务提供商往往还有自己的 QA 步骤,因此最终宣布 -RELEASE 的时间往往会比 FTP 上出现的时间晚上一周左右。技术上这段时间这个 build 依然只是一个发布候选版本(Release Candidate), 因此普通用户不应使用这些版本,因为在这一周的时间如果遇到一些突发状况的话可能会需要将这个版本撤回 (例如原本应发布为 FreeBSD 4.6.1 的 FreeBSD 4.6.2 就是这样的情况)。

Read more...
28 Oct 2023

换回了 Comcast

上回书 说到我换到了一个采用微波通讯技术的小型本地 ISP,然而经过将近两年的时间, 我最终还是换回了 Comcast。正如张师傅说的,南湾乡下的居民不配有好东西,经过这么久, 我家这边依然没有 5G 互联网服务,也没有光纤到府,至于 cable 也很自然地也没有 DOCSIS 4.0,也不想想看,您配吗?

为什么要换回 cable 呢?Sail 声称他们采用的设计可以避免雨季带来的干扰,事实来看确实是这样, 但是他们的服务稳定性在过去几个月出现了灾难性的下降,此外延迟由于一些未知的原因增加了不少。 我为此收集了一些数据,发现去大河以及 Google 的延迟有时竟然超过了 500ms,这个就实在是太难受了。

Read more...
15 Oct 2023

记录一下当年把 FreeBSD 中 zlib 砍到只剩一份的过程

软件项目中,实现同一功能的源代码只保留一份是一项十分重要的最佳实践,这种做法可以带来许多显而易见的好处:

  1. 简化依赖关系管理。 对于 C/C++ 项目来说,如果同一个函数库有不同的版本,意味着必须设法确保其中不包含同一符号的多个变体。
  2. 减少技术债的积累。 只保留一个版本意味着参与项目的所有开发者都使用最新版本的库,或是从一个接近最新版本的库升级到最新版本,这要比把技术债留给后人去解决要容易许多。尽管升级时需要考虑的问题会更多一些,但这也意味着更好的一致性。只留一份版本意味着在升级时必须通盘考虑全局的影响,配合持续集成测试的使用,这也会带来更好的代码品质,并让整个团队能够更快地进行迭代。
  3. 节省各类存储占用
  4. 改善整体安全性。问题只需在一处进行修正。

2009年的时候 kmacy@ 做了 一些初步的工作,但后续没有继续推进。 这之后 考虑重新把这个事给做掉,但苦于平时比较忙因此未能如愿。最终, Yoshihiro Ota 完成了大部分的工作。

Read more...