比较新的版本的 postfix 除了 milter 之外还可以用 policy delegation 做 content filtering；后者的优势在于简单容易实现，但是只能读取有限的 email attributes。

policy delegation 实现上也有三种：

1. 基于 tcp 的 policy server
2. 基于 unix domain socket 的 policy server
3. 基于 master daemon spawn 的 policy server

第三种实现上最简单，并且虽然文档上说它也是基于 unix domain socket 实现通信，但是这部分通信实际上对 policy server 是透明的。

第三种情况下，只需要提供一个简单的 binary，能够读写 stdin/stdout 即可完成通信：

• 从 stdin 读出 request attributes
• 将判断结果往 stdout 写

文档上虽然没有明确写出这点，但是通过附带的 example 用例可以证实。

不过使用这种方式要注意一个坑：stdin/stdout 的读写必须不能使用 fread()/fwrite() std::cin/std::cout 这种带有应用层缓存的 IO 设施。

虽然这里是对 stdin/stdout 读写，但是实际上底下通讯还是会经过 unix domain socket，使用带应用层缓存的库函数读写时会导致阻塞。

相应的，这里要么使用 read(2)/write(2) 这种 syscall，要么手动屏蔽标准库的应用层缓存。

对于没有经验的人来说，这里是一个很容易掉的坑

背景

amavisd 是 MTA（例如 postfix）流行的 content-filtering 模块，可以提供垃圾邮件试别过滤、病毒邮件检测隔离等功能。

spamassassin 则是 amavisd 使用的垃圾邮件模块。

在目前主流的 Linux 发行版上，这两个系统都会以 systemd 管理的服务运行。

在系统集成过程中遇到一个神奇的问题：amavisd 和 spamassassin 服务会定期挂掉，journalctl -fu 的日志都提到了

• config: no rules were found! Do you need to run sa-update​?

的错误内容

处理

解决步骤：

1. 检查 /var/lib/spamassassin/ 目录下是否有一个对应版本的目录，例如 3.00402
2. 如果有的话，删除这个目录
3. 然后先后重启 spamassassin 和 amavisd 服务

在阿哔呆了 1860 天（2016/04/11 – 2021/05/14）之后终于完成了跑路，跑路到现在也一个多月了，也可以从一个“前任”的角度吐一吐槽了。

其实一开始我预期至少在阿哔待到2022年下半年再考虑是否跑路，主要原因是当初和媳妇儿（那会儿还是女朋友）约定是30岁之后再考虑回杭州工作，毕竟那会儿杭州能叫的上名号的互联网公司给我的印象都不好，印象里也没有什么知名的外企。

作为一个曾经的资深 Windows developer，Windows HANDLE 一个不引人注意的但是绝对值得引起注意的地方是，它的无效值表示是不唯一的。

除了最常见的 NULL 之外还有一个 INVALID_HANDLE_VALUE，并且即使是在数值上这两个东西也不一样。

如果要为 HANDLE 写一个 C++ RAII Wrapper 那么必须要考虑这个点，比如 Chromium 就是这么做的。

Chromium 的这个设施早在 C++ 11 之前就有了，并且经过多年来的迭代已经变得异常复杂；如果你自己需要这样一个东西，又无法从 Chromium 这种工业项目中抽取一个组件的话，只能考虑自己实现。

但是要写对一个工业强度的 handle-wrapper 并不容易，同时还要考虑到通用性和实用性，比如可能后续要支持 fd/socket，Windows HDC 等各种奇奇怪怪的东西。

所以能否用 std::unique_ptr 来作为基础实现，针对一些特定细节做泛化？

这就引出一个问题：如果希望用 std::unique_ptr 来作为 HANDLE 的一个 RAII 包装，如何正确判断一个 handle 是否 valid？

更进一步，问题还可以变为：如何用 std::unique_ptr 管理 pointer-like 的资源？

系列第一篇文章里说后面会给出一个满足 RFC 4122 的可用实现，并且那会儿是打算讲一讲实现中一些需要注意的坑和有意思的点。

但是因为3月份开始就忙着准备面试，清明结束后的两周基本不是在面试，就是在准备面试；一直到五一回了趟温州老家才有比较充裕的时间把 uuidxx 的核心逻辑写完。

拉锯到现在一开始的冲动都已经被消磨得不剩下多少了（可能还是因为我比较懒），所以我不打算把具体的实现部分展开，有兴趣的可以自行查阅源代码。

Repo 地址在 https://github.com/kingsamchen/uuidxx

因为这次换工作我有很多槽点想吐，所以后面我会专门写一篇文章讲一讲。

这篇应该不会鸽，毕竟喷人挺爽的一件事。

这一篇来讲 v3 和 v5 的实现。

这两个实现要求使用方提供：

• 一个称为 namespace 的 UUID
• 一个叫 name 的数据块（不限于字符串）

然后利用一个 hash 算法算得结果，作为目标 UUID 的基础数据（还需要额外设置 variant 和 version）。

即，对于 v3/v5 的实现，本质上是

1
2
3

uuid = hash(namespace, name)
set_variant(uuid)
set_version(uuid, ver)

v3 和 v5 区别在于，前者是用 MD5，后者使用 SHA-1。

并且可以发现，对于相同的 namespace 和 name，生成的结果 UUID 是一样的。

这个就是 v3/v5 版本的特性。

借用 RFC 的描述就是：

• The UUIDs generated at different times from the same name in the same namespace MUST be equal.
• The UUIDs generated from two different names in the same namespace should be different (with very high probability).
• The UUIDs generated from the same name in two different namespaces should be different with (very high probability).
• If two UUIDs that were generated from names are equal, then they were generated from the same name in the same namespace (with very high probability).

所以 v3/v5 的版本又被叫做 name-based implementation

上篇介绍了 UUID 的格式和 v4 的实现，这篇讲 v1 & v2 的实现。

v2 版本是 v1 上衍生出来的，而 v1 因为涉及到时间戳，又称为 time-based implementation。

实现 UUID v1

v1 除了常规的 variant 和 version 部份外，还涉及三个部分：

• timestamp，需要 60-bit 通常用 64-bit 容纳；非寻常的 Unix Timestamp
• clock sequence，需要 14-bit，通常用 16-bit 存储
• node identifier，48-bit 和设备相关

下面逐一解释这三个部分。

0x0. UUID Timestamp

和常见的 Unix 时间戳不同，UUID 时间戳记录的是，自 1582-10-15 00:00:00 至今的 100-ns 数。

1582年10月15日的零点是格里高力历开始的时间，这个时间也是 UUID Epoch Time。

UUID 时间戳的分辨率（resolution）是 100 纳秒，即每 100ns 为一个 tick。

现代编程语言都可以获取 unix 时间戳，因此可以先获取 unix 时间戳，然后加上两个 epoch time 的差值；这个差值是个定值，等于 122192928000000000。

注意：获取时间戳时需要注意系统或者语言库能提供的分辨率。

0x1. Clock Sequence

因为引入了时间戳，所以存在可能由于时钟回拨、闰秒，甚至因为系统提供的时钟分辨率不够导致使用了重复的时间戳。

另外 node identifier 也有可能被改变。

所以为了尽可能保证 UUID 的唯一性，引入了 clock sequence。

注：RFC 4122 没有规定 UUID v1 必须要使用 steady clock，所以使用能够被回拨的 system clock 也是允许的。另外，即使使用了 steady clock，机器在两次启动之间也可能调整了硬件时间，一样可能会导致回拨。

Clock sequence 一开始会被初始化为一个随机值；之后如果某次获取 UUID 时间戳发现 <= 上一次的时间戳，就会自增 clock sequence。

clock sequence 通常会设置为一个无符号数，以确保溢出 wrap-around 的行为是确定的。