你启用域名 catch-all，希望有人误写 saels@ 而不是 sales@ 时也不漏掉询问。规则覆盖未知收件人，包括自动地址探测的目标，但不会取消垃圾邮件过滤和其他接收检查。接受收件人不等于最终接受整封邮件。向伪造发件人退信、自动回复循环及转发投递问题都是需要管理的风险，而非必然结果。
很多指南只说“启用 catch-all，全部送进收件箱”。实际运维工作却从这里开始。本文介绍隔离邮箱、Postfix 正则路由、循环预防和转发中的认证失败。如果需要基础知识，请先阅读邮件转发设置指南；本文重点讨论域名 catch-all。
什么是域名 catch-all？
Catch-all 是一种 MTA 规则，接受发往域名中未知地址的邮件，即没有对应已知邮箱、别名或群组的地址。服务器可能不返回 550 User Unknown，而是返回 250 OK，再将邮件送到备用目的地。接受收件人不等于在 DATA 后最终接受整封邮件。规则作用于 SMTP 信封收件人，本身不会破坏认证。
信封与标头：为什么需要区分
理解这两个层次有助于排查路由、认证和通知。查明原因后两分钟修复只是示例，并非承诺；其他问题可能需要数天诊断。
RFC 5321 定义 SMTP 信封，包括 SMTP 会话中交换的 RCPT TO 和 MAIL FROM 命令。RFC 5322 定义邮件标头，包括客户端显示的 To: 和 From: 字段。
MTA 可以把未知信封收件人路由到备用地址，而不修改标头。SPF 为 MAIL FROM 域名或适用 HELO 检查连接 IP；DKIM 对签名覆盖的标头及正文部分进行密码学验证；DMARC 要求 SPF 或 DKIM 至少一项成功，且其域名与可见 From 对齐。本地收件人改写不会直接破坏这些检查。外部转发可能影响 SPF，修改签名覆盖的部分可能使 DKIM 失败。
外部转发的故障模式
把 catch-all 转发到 Gmail 或 Outlook.com 会新增一跳，可能改变认证结果：
- 原始发件人：
client@bank.com（IP：1.2.3.4） - 你的服务器接受
typo@yourdomain.com，再转发到you@gmail.com - Gmail 看到来自你服务器 IP 的连接，信封可能仍使用 bank.com
- 如果该 IP 未获 bank.com 的 SPF 记录授权，SPF 就会失败
- 如果 bank.com 发布
DMARC p=reject，又没有有效且对齐的 DKIM，接收方可能拒收；SMTP 拒绝可能产生通知，但用户不一定能看到
Catch-all 不保证投递成功，转发也需要独立验证。SRS（Sender Rewriting Scheme）可能帮助重写域名通过 SPF，但不会自动保留与原始 From 的对齐，也不保证 DMARC 通过或邮件送达。所述 TrekMail 邮件别名转发在支持的配置中处理 SRS；请确认套餐和当前条件。
域名 catch-all 的三类风险
修改配置前，应检查向伪造发件人发送通知、自动回复循环和转发认证失败这三类风险。只处理一类可能使原计划五分钟的任务，例如变成一周额外维护，这不是固定耗时。
1. 退信散射：信誉风险
服务器在 DATA 后最终接受 catch-all 邮件（250 OK），随后决定不投递并生成未投递报告（NDR）时，可能产生退信散射。如果 MAIL FROM 被伪造，通知就会发给没有发送邮件的人。这类对方并未请求的回复可能损害信誉并增加进入阻止名单的风险，但并不存在必然发生的期限。
对于不在接受规则内的收件人，应在 SMTP 会话中、对应的 250 OK 之前拒绝。对于已接受的流量，可按需要使用隔离和审核，避免向可能伪造的地址发送对方并未请求的 NDR。这不意味着禁止所有合法未投递通知，也不应默认删除合法邮件。
2. 自动回复循环（Exchange 错误 5.4.14）
Catch-all 把邮件送给备用收件人，而该账户可能启用了外出自动回复（OOF）。发往 random@yourdomain.com 的伪造发件人邮件可能触发回复和退信；如果路由又把退信送回 random@yourdomain.com，服务器就会再次接受。这样的规则组合可能形成循环。Exchange 可能返回 550 5.4.14 Hop count exceeded - possible mail loop。
在支持的系统中，尤其是 Exchange，可为通配符路由的流量设置 X-Auto-Response-Suppress: All，以限制 OOF 和确认通知，包括已读回执。它不是通用防护：还应审查自动规则、Auto-Submitted 和退信路由，并测试实际行为。
3. 地址收集攻击（DHA）
如果所有地址都返回 250 OK，攻击者可以尝试 admin@、hr@、ceo@ 和 invoice@ 等数千种组合。全域 catch-all 会接受这些收件地址，但不会证明哪些地址对应真实邮箱。即便如此，垃圾流量仍可能增加，甚至持续多年；这不代表地址已获验证，也不是固定的攻击期限。
下文策略 2 的局部通配符可限制覆盖范围，但不保证阻止大多数攻击。
策略 1：独立隔离邮箱
如果需要 catch-all，可使用独立审核邮箱，限制访问并配置过滤和保留规则。除非经过单独验证与授权，否则关闭其自动转发和外出回复。邮箱并非安全沙箱，不能单独保证安全或信誉；应保留审核合法邮件的途径。
实施逻辑：
- 接受：服务器接受
*@domain.com - 标记：识别未知收件人，即没有对应获准邮箱、别名或群组
- 隔离：路由到独立邮箱，例如
catchall_sink@domain.com - 限制回复：在合适的 Exchange 环境通过 Spam Confidence Level 9 请求高置信度垃圾邮件处理，并按需要设置
X-Auto-Response-Suppress: All；验证实际分类与动作
每周审核可以作为起点，但频率应适应邮件量和紧急程度。把合法邮件移到正确邮箱，并为其余内容制定保留策略。规划容量、存储和监控，避免隔离区成为另一个遗漏客户询问的地方。
Microsoft 365 / Exchange Online 传输规则
在 M365 中，需由获授权管理员审核。Internal Relay 会关闭 Directory Based Edge Blocking（DBEB），但不会独自实现 catch-all，也不适合收件人全部在云服务中的域名。其他收件人需要经过验证的连接器指向获授权自有服务器。核查最终路由、循环以及有效邮箱、别名、群组和其他收件人的完整目录；单个群组成员条件不能代替清单。以下仅是需按真实架构适配的框架：
| 条件 | 值 | 目的 |
|---|---|---|
| 发件人位置 | 组织外部 | 仅处理外部流量 |
| 收件人不属于 | All Valid Users | 按审核后的清单排除有效收件人 |
| 重定向邮件到 | catchall_sink@domain.com | 把未知流量送到独立隔离邮箱 |
| 设置 SCL 为 | 9 | 请求高置信度垃圾邮件处理；实际分类、动作和通知还取决于其他过滤、策略及客户端 |
| 设置标头 | X-Auto-Response-Suppress: All | 在支持的系统中限制自动回复，并通过测试检查循环 |
规划并测试规则启用与任何 Internal Relay 变更的顺序。先验证连接器、收件人验证和最终路由，避免在变更期间失去对邮件接收的控制或形成循环。
策略 2：Postfix PCRE 局部通配符
局部通配符只接受指定模式，而不是开放整个域名。为预期地址定义正则表达式，并单独配置其他收件人的验证。映射表中没有匹配项，并不自动产生 SMTP 拒绝；域名类别、其他映射表和收件人限制也会影响结果。
安装 PCRE 支持后，Postfix 可以使用 PCRE（Perl Compatible Regular Expression）虚拟别名映射。请测试模式：示例注释不保证收件人验证生效或覆盖所有所述拼写错误。
# /etc/postfix/virtual_pcre
# Catch any address starting with "sales-" (sales-q1, sales-webinar, etc.)
/^sales-.*@yourdomain\.com$/ sales-team@yourdomain.com
# Catch common "support" typos (suport, supprt)
/^supp?o?rt@yourdomain\.com$/ support@yourdomain.com
# No wildcard below = hard 550 reject for everything else适配 /etc/postfix/main.cf 前，先备份配置并审查现有映射。下面的赋值会替换当前值，应合并新映射而不丢失其他路由：
virtual_alias_maps = pcre:/etc/postfix/virtual_pcre验证模式、收件人和路由后，获授权管理员可重新加载配置：postfix reload
如需扩大覆盖，可为常见地址添加谨慎设计的模式，而非使用全域 catch-all：
/^(info|contact|hello|team)@yourdomain\.com$/ info@yourdomain.com只要 MTA 验证已正确配置并测试，就可以将接受范围限制在所需地址内。
何时适合使用域名 catch-all
Catch-all 可以用于边界明确的场景。以下临时用途很常见，但不是仅有的合法用途。是否长期保留，应根据控制措施和业务需要决定。
合理用途：
- 短期活动地址：使用
promo-jan@、promo-feb@和promo-mar@，无需逐一手动创建收件人 - 客户接入：在地址正式配置完成前先接收邮件
- 旧系统迁移：切换期间接收发往尚未完整登记的活跃地址的邮件
在这些场景中，应定期评估何时停用 catch-all，并为已知地址创建明确的邮箱或别名。如果不确定需要哪种收件人，请阅读域名邮件别名与邮箱对比，选择便于长期维护的地址结构。
不理想的动机：只是为了避免为三个别名支付假定的每用户每月 $6，就启用 catch-all。别名不一定需要独立许可，应先确认服务商计费模式。解决真实成本问题，而不是增加半年后难以维护的架构。
TrekMail：选择架构，而非临时绕路
按用户计费可能影响 catch-all 的选择。所述 TrekMail 模式采用固定价格套餐和账户级共享存储，而不是统一按域名或邮箱收费；单个邮箱也可能有配额。在套餐限制内，它可能减少以 catch-all 替代明确别名的财务动机。请核实当前价格、配额和功能。
| 按用户计费 | TrekMail：按套餐固定价格 | |
|---|---|---|
| sales@、support@、info@ 邮箱 | 独立许可示例中的 3× 月费 | 可用性和限制取决于套餐，并非所有套餐普遍包含 |
| 用 catch-all 替代别名 | 如果服务商要求独立许可，可能节省成本 | 一种业务选择，不一定是财务需要 |
| 转发到 Gmail 或 Outlook | 可能按路由和 DKIM 状态影响 SPF 与 DMARC | 支持的配置中管理 SRS，不保证 DMARC 通过或投递 |
| 从旧服务商迁移 | 获授权 IMAP 同步、备份及验证 | 检查源服务和套餐支持，比较文件夹及邮件，切换 DNS 前复制最后的增量；联系人及日历另外规划 |
历史 Starter 示例（每月 $3.50）说明套餐范围内的地址配置，请确认当前条件。只有所述 Nano 模型需要自备 SMTP 发送全部外发邮件，包括回复；付费托管发送取决于权限与设置。如果需要 catch-all，将受支持的域名规则与常用明确收件人结合。初次配置时，在自有域名上设置邮件的指南介绍 DNS、SPF/DKIM/DMARC 和邮箱创建。
启用 catch-all 前的检查清单
启用前应检查以下项目，并测试整条路径。控制措施可以降低风险，但不会消除运维工作：
- SMTP 入口验证：在连接期间拒绝不属于 catch-all 接受模式的地址，避免随后向伪造发件人发送对方并未请求的通知。
- 自动回复控制：在支持的系统中设置
X-Auto-Response-Suppress: All，并检查 OOF、Auto-Submitted 和路由以预防循环。 - 隔离区就绪：准备与业务收件箱分开的邮箱，明确容量、审核和保留策略。
- 垃圾邮件分类已审核：适配隔离策略，主动审核合法邮件，而不默认删除。
- SPF 与 DMARC 已验证：如需转发，应检查 SRS、重写域名授权，以及 DMARC 所需的至少一条有效且对齐的 SPF 或 DKIM 路径。
- 按需使用 PCRE 模式：如果局部通配符足以满足需要，应优先使用，并测试 MTA 对其他地址的验证。
- NDR 控制：避免向可能伪造的发件人发送对方并未请求的退信，同时正确处理合法邮件。
结论
配合经过测试的路由、接受模式之外的 SMTP 验证、隔离区和自动回复控制，域名 catch-all 可以发挥作用。未经架构审核就启用，可能增加退信散射、循环和转发故障风险。没有一种配置能独自消除所有风险，应测试并监控实际行为。
如果目的只是避免按用户计费，应先确认邮箱和别名真正需要哪些许可。所述 TrekMail 固定价格托管允许在套餐限制内选择明确收件人，让 catch-all 成为经过考虑的业务决定。配置域名前，请了解免费试用及当前条件。
