今天在家里的票务系统上修改某个票的状态（该操作会出发点一封邮件）时，
我正好另一个窗口开着邮件服务器的日志，观察到一些奇怪的现象：
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)
|
原载于 Telegram 频道。
今天来讲个关于备份的小故事。
以前有个同事之前在某使用UNIX的传统行业干了多年，他们的系统可用性要求不算高，但数据非常重要，
所以备份自然也是必不可少的。为了确保备份的安全性，
他们还雇了一家专门的保全公司定期把备份磁带从办公室拿走到该保全公司的仓库。
阅读全文…(本文约 491 字，阅读大致需要 1 分钟)简介
目前的经济形势下，许多公司都在进行裁员。大部分情况下，作为雇员对于公司是否进行裁员所能做的影响极为有限，
因此有必要提前对可能发生的裁员进行准备，以免仓促之下做出错误决策，或是在大规模裁员导致的踩踏事故面前束手无策。
本文主要是针对在美国境内工作的普通雇员，家里没矿，也暂时还没攒够足够退休的钱。
内容主要来自近期的阅读和想到的一些东西，算是给自己留下一些笔记。
阅读全文…(本文约 2918 字，阅读大致需要 6 分钟)周三的时候，USPS发来了一封电子邮件，内容如下：
阅读全文…(本文约 998 字，阅读大致需要 2 分钟)最近没怎么关注安全方面的进展，结果错过了去年年底披露的 SMTP Smuggling。
这是 Timo Longin 发现的一个全新的针对 SMTP 协议的攻击手法，
现在的年轻人真是蛮厉害的。
阅读全文…(本文约 1493 字，阅读大致需要 3 分钟)我搞邮件服务器有二十多年了，最开始是在学校做社团的邮件服务，
后来有几年和 老房东
在某领先网络媒体公司做了多年针对公众提供的邮件服务，因此前同事群的名字也是「老邮条」。
我个人的域名是2002年注册的，自从那时起我就一直在自己运行邮件服务。
在过去二十年中的大部分时间，我采用的是 amavisd-new，
与直接使用 SpamAssassin 相比，
它还增加了病毒扫描等一系列功能和 milter
接口，这让它与 MTA 更容易集成。
阅读全文…(本文约 1016 字，阅读大致需要 3 分钟)12月1日，FreeBSD 发布了 FreeBSD-EN-23:16.openzfs，
用于修正近期发现的 ZFS 数据损坏问题。
这个问题是由 Rob Norris
最终修正的，这里记一笔。
阅读全文…(本文约 3514 字，阅读大致需要 8 分钟)上周末抽时间把服务器升级到了 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 就是这样的情况)。
阅读全文…(本文约 1097 字，阅读大致需要 3 分钟)上回书 说到我换到了一个采用微波通讯技术的小型本地 ISP，然而经过将近两年的时间，
我最终还是换回了 Comcast。正如张师傅说的，南湾乡下的居民不配有好东西，经过这么久，
我家这边依然没有 5G 互联网服务，也没有光纤到府，至于 cable 也很自然地也没有 DOCSIS 4.0，也不想想看，您配吗？
为什么要换回 cable 呢？Sail 声称他们采用的设计可以避免雨季带来的干扰，事实来看确实是这样，
但是他们的服务稳定性在过去几个月出现了灾难性的下降，此外延迟由于一些未知的原因增加了不少。
我为此收集了一些数据，发现去大河以及 Google 的延迟有时竟然超过了 500ms，这个就实在是太难受了。
阅读全文…(本文约 429 字，阅读大致需要 1 分钟)软件项目中，实现同一功能的源代码只保留一份是一项十分重要的最佳实践，这种做法可以带来许多显而易见的好处：
- 简化依赖关系管理。 对于 C/C++ 项目来说，如果同一个函数库有不同的版本，意味着必须设法确保其中不包含同一符号的多个变体。
- 减少技术债的积累。 只保留一个版本意味着参与项目的所有开发者都使用最新版本的库，或是从一个接近最新版本的库升级到最新版本，这要比把技术债留给后人去解决要容易许多。尽管升级时需要考虑的问题会更多一些，但这也意味着更好的一致性。只留一份版本意味着在升级时必须通盘考虑全局的影响，配合持续集成测试的使用，这也会带来更好的代码品质，并让整个团队能够更快地进行迭代。
- 节省各类存储占用。
- 改善整体安全性。问题只需在一处进行修正。
2009年的时候 kmacy@ 做了 一些初步的工作，但后续没有继续推进。
这之后 我 考虑重新把这个事给做掉，但苦于平时比较忙因此未能如愿。最终， Yoshihiro Ota
完成了大部分的工作。
阅读全文…(本文约 2128 字，阅读大致需要 5 分钟)