我们运行邮件。 通过单独的 Postfix 实例发送出发事务和批量邮件,通过自己的 Dovecot 邮箱发送入发邮件,通过 Rspamd 进行过滤和评分。 在允许消息声称客户的域之前,发件人的身份会与实时 DNS 进行检查。
| 措施 | 价值 | 资料来源 | 已计量 |
|---|---|---|---|
| 生产中的邮件组件 | 5 (Postfix outbound, Postfix bulk, Postfix inbound, Dovecot, Rspamd) | kubectl get deployments -n mail | |
| 发送以信誉类分隔的路径 | 2 (transactional and bulk, on distinct instances) | kubectl get deployments -n mail | |
| 在发送授权之前执行发送者域检查 | 2 (domain ownership proven by DNS record, and SPF authorisation verified live) | transactional sender-identity resolution in the email service |
它教会了我们什么建筑
当营销邮件没有到达时,营销工具会报告它已发送,这在技术上是正确的,完全没有用处。 消息被接受交付,然后被接收系统根据营销工具看不见的规则丢弃,推迟或归档为垃圾邮件,其供应商也不会解释。 这是数字营销中最常见的无法解释的失败,只有营销工具的机构没有办法调查它。
运行基础架构会改变可知内容。 我们将批量发送与事务性发送分开,这样一封新闻简报就不会损害密码重置所依赖的声誉。 我们在发送时对比实时 DNS,检查域名是否确实被证明属于声称拥有该域名的租户,以及其 SPF 记录是否实际授权了我们 — 如果查询失败,我们不记录判决,而是进行猜测,因为在这里,猜测会发送身份验证失败的邮件,并教导接收系统不信任该域名。
我们曾经因为 webhook 发布了表单编码的数据,而处理器试图将其解析为 JSON,并在丢弃内容的同时返回一个愉快的 200 值而丢失了一类传入消息。 该路径上存在三个不同的无声丢失,没有任何警报,因为所有的都报告了成功。 通过成功失败的系统是最难找到的,这也是我们在客户端工作中沉迷于仪器吸收路径的原因。
还有一个连接限制值得一提,因为这是只有在实际负载下才会出现的细节:邮件服务器允许每个用户、每个地址、每个进程同时连接的数量是有限的,超过这个数量就会停止工作,看起来就像是认证失败。 邮件容量规划是真正的工程,几乎没有人为它预算。
建于
- Postfix
- Dovecot
- Rspamd
- SPF
- DKIM
- DMARC
- IMAP
- Java
- Spring Boot