-all路由接受域中其他不匹配的收件人名称，并根据本地配置引导它们。该目的地可以是邮箱或另一个处理路径。地址验证器只能看到暴露给其测试的行为，而不一定是其背后的路由配置。使用“catch -all ”作为合格的观察，除非管理员确认实际设置。
解释检查员观察到的情况
常见测试将已知地址与随机生成的本地部分进行比较。如果两者都收到成功的 RCPT 响应，则检查器可以推断接受-all行为。该推论并不能证明名称映射到不同的邮箱，最终的消息将被传递，或者服务器始终以相同的方式对待每个连接的客户端。 SMTP收件人处理和最终邮件接受是不同的阶段。 RFC 5321第 3.3 节和4.1.1.3节.
不同的检查器可以使用不同的发送基础设施、信封发件人、时间、重试策略和阈值。因此，临时延迟、网关行为或下游目录检查可能会产生不同的分类，而无需任何工具检查邮箱目录。在选择信任的标签之前询问测试定义和原始响应。
比较两个假设的检查报告
假设检查器 A 在收到已知且不匹配的地址的 250 后报告接受-all 。检查员 B 在暂时拒绝后随后报告未知。两个报告均不包含授权目录查找。首先比较他们的观察时间、发送路线、发送者身份以及具体阶段。差异可以反映测试条件而不是更改的邮箱。
这些是发明的报告，而不是执行的探测或测量的提供商行为。当证据无法区分替代方案时，未知结果是有用的。不要为了方便或验证而将其转换为无效，因为服务器接受了不匹配的名称。在联系质量和抑制决策中将这些状态分开。
直接解决业务问题
如果您控制该域，请检查其实际的不匹配收件人路由并确定谁接收或处理这些消息。在进行更改之前确认别名、组或应用程序是否依赖于它。删除-all可以揭示长期存在的地址错误，还可以中断从未有明确帐户的合法流量。
对于外部域，授权确认过程可以确定某人当前为此目的访问了预期目的地。它不会将每个接受的本地部分变成同意的联系人。切勿使用接受-all行为作为发明收件人名称或发送未经请求的消息的许可。
记录限制并重新审视重大变更
存储验证者的观察时间、方法和准确结果。仅当存在合法需求或相关配置更改时才重新检查，而不是锤击同一服务器直到出现首选标签。通过管理员确认的路由或特定目的收件人确认（如果可用）来结束调查。否则保留不确定性并解释其实际后果：探测尚未确定可传递性和邮箱的存在。
在不失去合法流程的情况下解决-all变更
考虑一个发明的内部域案例。管理员确认不匹配的名称路由到共享接收邮箱。旧应用程序将发票发送到accounts-old@example.test ，它没有明确的别名，但到达该接收路由。报告accept -all的检查器并没有揭示这种依赖性；路由配置和授权消息跟踪执行此操作。在另一个域中，同一对成功的收件人检查可以反映边缘接受，然后是下游决策，而不是此配置的路由。在最终数据接受之前拒绝仍然是交易的一部分；接受后的通知是另一回事。
在批准-all删除之前，请确定应用程序所有者和预期目的地。如果该流程必须继续，请安排一个授权的显式地址或别名，并使用范围测试验证其路由。保留原始策略，直到批准的变更计划考虑到其他合法依赖项。更改后，确认预期地址仍然有效，并单独评估不匹配地址的处理。这些是假设的决定，而不是执行的迁移或特定产品支持这些控制的承诺。
有用的结论是具体的：管理员确认了一个路由依赖性及其所需的结果。并不是每个接受的本地部分都是邮箱或同意的联系人。不同的域需要自己的配置证据和批准。
解决业务决策
- 内部域：标识实际的不匹配接收者路由及其所有者。
- 建议删除：在批准更改之前清点别名、应用程序和合法流程。
- 外部联系：通过授权渠道寻求特定目的的确认。
- 分歧工具：比较方法、时间、路线和原始诊断，而不是多数投票。
- 证据不足：标记地址未知并单独保留同意书。