From 67869d73169e3337b79017434e603fc61e33484a Mon Sep 17 00:00:00 2001 From: Uyanide Date: Wed, 21 Jan 2026 23:50:04 +0100 Subject: [PATCH] update mail-service.md --- memo/mail-service.md | 37 ++++++++++++++++++++++++++----------- 1 file changed, 26 insertions(+), 11 deletions(-) diff --git a/memo/mail-service.md b/memo/mail-service.md index d37326c..dc346b6 100644 --- a/memo/mail-service.md +++ b/memo/mail-service.md @@ -35,7 +35,7 @@ > - 耗费数周乃至数月培养 IP 声誉的时间与物质成本 > - 为 IP 长期保活的持久战准备 > - > 如果确实觉得没问题, 那么可以忽略下文中所有有关 SMTP 中继相关的内容, 就本文包含的内容而言步骤区别并没有很大. + > 如果确实觉得没问题, 那么可以忽略下文中所有有关 SMTP 中继相关的内容. 其实就本文包含的步骤而言区别并没有很大, 下文中相关的地方会有额外说明. 4. 一个拥有公网 IP 和充足空闲资源的服务器, 并且(至少)需要开通以下 TCP 端口: @@ -54,7 +54,7 @@ 下文中将使用 `1.14.5.14` 作为服务器的公网 IP 地址. -## 放开那个 25 端口! +## 放开那个端口! 1. 检测 25 端口是否真的开放: @@ -92,7 +92,7 @@ 2. 解决占用: - 我的服务器是 Debian 13 系统, 默认使用 `exim4` 作为邮件传输代理(MTA). 它监听 127.0.0.1:25, 因此除了在防火墙里放行 25 端口外, 还需要禁用 `exim4`. + 我的服务器是 Debian 13 系统, 默认使用 `exim4` 作为邮件传输代理(MTA). 不出意外的话 25 端口已经在它手里攥了很久了. 因此除了在防火墙里放行 25 端口外, 还需要禁用 `exim4`. ```bash sudo systemctl disable --now exim4 @@ -102,7 +102,7 @@ ## 注册 SMTP 中继服务 -此类服务可以大致理解为"帮你发邮件的中介", 他们有一大堆 IP 地址, 这些地址的声誉都不错, 因此用他们发信的话, 邮件更容易送达收件箱而不是自动进入垃圾箱. 并且也可以避免 25 端口出站被封的问题. +此类服务可以大致理解为"帮你发邮件的中介", 他们通常有很多 IP 地址, 这些地址的声誉都不错, 配置也很完善, 因此用他们发信的话, 邮件更容易送达收件箱而不是自动被扔进垃圾箱. 并且这也可以避免 25 端口出站被封的问题. 我此次用的是 [Resend](https://resend.com), 其他类似服务还有 Amazon SES, Mailgun 等等. @@ -129,7 +129,9 @@ - 值: `mail.domain.tld` - 优先级: `10` - 这将会是邮件的接收和发送服务器. + 这将会是邮件的接收和发送服务器的域名. + + > 如果乐意的话可以把收信域名, 发信域名, 乃至退信域名等等都拆分开来配置, 但这超过了本文的讨论范围, 因此不做另外说明 ~~主要是懒~~ :) - A 记录: - 主机名: `mail` @@ -228,11 +230,12 @@ services: 以上配置中**必须**修改的地方有: - `domain.tld`: 替换为真实域名. +- `resend`: 替换为在 SMTP 服务商处创建的真实用户名. - `res_some_random_api_key`: 替换为在 SMTP 服务商处创建的 SMTP 凭据或 API Key. 一些 environment 的解释: -- 如果机器性能孱弱或很在意占用的资源, 可以关掉 [Raspamd](https://docker-mailserver.github.io/docker-mailserver/latest/config/security/rspamd/) 使用老东西: +- 如果机器性能孱弱或很在意占用的资源, 可以关掉 [Rspamd](https://docker-mailserver.github.io/docker-mailserver/latest/config/security/rspamd/) 使用老东西: - `ENABLE_AMAVIS=1` - `ENABLE_OPENDKIM=1` - `ENABLE_OPENDMARC=1` @@ -265,7 +268,7 @@ services: - `POSTFIX_INET_PROTOCOLS=ipv4`: - 如果服务器的 IPv6 配置不完善, 可以强制 Postfix 仅使用 IPv4. + 如果服务器的 IPv6 配置不完善, 可以强制 Postfix 仅使用 IPv4. 反之也可以只支持 IPv6. 如果要进行进一步配置, 必须先启动容器. 此时会报错, 因为还没有创建邮箱账号. 但不用管, 先让它跑着. @@ -397,7 +400,7 @@ docker compose up -d ## 配置邮件客户端 -我并非 TUI 重度爱好者, 日常用 Thunderbird 当客户端. +我并非 TUI 重度爱好者, 日常用 Thunderbird 当客户端. 这里只涉及这一种客户端的配置方法, 当然其他的也大同小异. 1. 在添加邮箱的第一个页面, 点击 `MANUAL CONFIGURATION`. @@ -426,7 +429,9 @@ docker compose up -d 5. 输入密码, 完成配置. -现在已经可以试着和其他邮箱互发邮件了! +现在已经可以试着和其他邮箱互发邮件了! + +别忘了定时检查其他邮箱平台发来的 DMARC 检查结果看 SPF 和 DKIM 配置是否正确. ## exim4: 我呢? @@ -504,6 +509,10 @@ docker compose up -d 如果一切正常, 你应该会在前面配置的邮箱客户端中收到这封测试邮件. +> [!NOTE] +> +> 此时可将 msmtp 看作 mailserver 的客户端, 因此 `/etc/msmtprc` 中配置的邮件服务器并不一定要部署在本机, 甚至可以是公共邮箱服务. + ## Catch'em All! 如果希望接收发往不存在邮箱地址的邮件, 可以启用 Catch-all 功能. 方法也很简单, 使用 alias 即可: @@ -514,6 +523,10 @@ docker exec -it mailserver setup alias add @domain.tld me@domain.tld 将其中 `me@domain.tld` 替换为希望接收这些邮件的真实邮箱地址即可. +> [!WARNING] +> +> 完全按照上述步骤配置通配符邮箱别名可能会导致后续添加其他邮箱时邮件仍然发到上面指定的 catch-all 邮箱而不是新创建的邮箱. 更好的实践是用到什么邮箱名再创建对应的别名. + ## 更进一步 **MTA-STS** (Mail Transfer Agent Strict Transport Security) 通过强制要求发送方使用加密连接发送邮件防止中间人攻击, 对个人邮箱来讲~~看起来其实没啥大用但总归~~是个加分项, 并且确实会让邮箱服务变得更酷. @@ -589,8 +602,10 @@ docker exec -it mailserver setup alias add @domain.tld me@domain.tld ## 为什么要做自建邮局? -排除利益驱动, 我能想到的最合适的接口就是"隐私". 可是如果登陆 Resend 的后台看一眼, 就会发现我写的邮件被一份份明晃晃地不加掩饰地放在那里, 所有的内容都以明文的方式被看得一清二楚. 此时和使用公共邮箱服务唯一的区别似乎也就只剩"有一个很酷的后缀"这一点了. 即便真的解决了 25 端口问题 (是的, 写完上述内容的几天后我确实做到了) 从而得以摆脱 SMTP 中继服务, 在惊讶于明明 Mail-Tester 给出了 10/10 的满分评价但还是被 Gmail 扔进垃垃圾箱的残酷现实之余, 我也意识到自建邮局这条路仅靠热情是绝对走不通的. 一是预热 IP 需要花费的时间成本乃至金钱成本远超我的想象, 二是无论如何邮件内容也会被收件方的平台以算法评估一遍的事实彻底击碎了对于"隐私"乌托邦最后的妄想. 即使有这么多复杂的安全措施, 补齐了传输过程中的每一个可能的安全漏洞, 但真正和我点对点沟通的从来都只是靠着一条条既定规则维系的平台, 而不是我在写下收件地址时心中所想的一个个鲜活的人. +排除利益驱动, 我能想到的最合适的借口就是"隐私". 可是如果登陆 Resend 的后台看一眼, 就会发现我写的邮件被一封封明晃晃地不加掩饰地放在那里, 所有的内容都以明文的方式被看得一清二楚. 此时和使用公共邮箱服务唯一的区别似乎也就只剩"有一个很酷的后缀"这一点了. 即便真的解决了 25 端口问题 (是的, 写完上述内容的几天后我确实做到了) 从而得以摆脱 SMTP 中继服务, 在惊讶于明明 Mail-Tester 给出了 10/10 的满分评价但还是被 Gmail 扔进垃圾箱的残酷现实之余, 我也意识到自建邮局这条路仅靠热情是绝对走不通的. 一是预热 IP 需要花费的时间成本乃至金钱成本远超我的想象, 二是无论如何邮件内容也会被收件方的平台以算法评估一遍的事实彻底击碎了对于"隐私"乌托邦最后的妄想. 即使有这么多复杂的安全措施, 补齐了传输过程中的每一个可能的安全漏洞, 但真正和我点对点沟通的从来都只是靠着一条条既定规则维系的平台, 而不是我在写下收件地址时心中所想的一个个鲜活的人. 那么做这一切的目的到底是什么呢? 或许也只剩"酷"了吧, 除此之外我唯一能想到的好处就是在仅需要邮箱就能注册账号的平台注册无穷无尽的小号. -Anyway, 确实是我拥有域名和服务器以来部署过最复杂, 折腾时间最久, 也可能是最无用的服务. 仅论过程还是很有意思的, 至少能让我理解现代电子邮箱系统到底是如何运作的. ~~闲的没事的话~~还是很值得试一试的 :) +Anyway, 确实是我拥有域名和服务器以来部署过的最复杂, 折腾时间最久, 也可能是最无用的服务. 仅论过程还是很有意思的, 至少能让我理解现代电子邮箱系统到底是如何运作的. ~~闲的没事的话~~还是很值得试一试的 :) + +EOF