邮件列表部署涉及多个发送身份。托管该列表的域可以发送订阅通知并重新分发由其他域中的人员编写的消息。员工还可以从组织的域发布到其他地方操作的列表。每条路径都需要自己的身份验证和策略评估。
首先命名正在审查的角色。 一个记录 保护列表管理通知不会自动解决重新分发帖子的身份验证问题。有效的列表签名不会自动与原始作者的发件人域对齐。
分离三个邮件流
在更改策略之前构建一个小型路由寄存器：
- 由列表服务发起的管理邮件，例如订阅确认。
- 从作者那里收到的帖子并重新分发给订阅者。
- 用户从您的域发送到外部列表的消息。
对于每个，记录负责的操作员、可见域、信封身份、签名域和转换。保留该路由的软件设置列表，而不是将来自同一服务器的每条消息视为同一流。
这 电子邮件身份链 解释哪些字段很重要。在下面 RFC 9989 §3.2.2、回复地址或友好列表名称不能替换作者域 DMARC 结盟.
比较直接交付和再分配交付
下表是综合比较，并非捕获的消息数据。假设writers.example和lists.example具有适用的有效DMARC策略、已完成的检查和不相关的组织域。假设来自author@writers.example的原始消息已使用d=writers.example正确签名并通过 SPF 授权的原始路由发送。
- 观察：从域可见；直接路由： writers.example ；保留 From: writers.example的列表重新分配
- 观察：连接源；直达航线：原件寄送服务；保留 From: 列表服务器的列表重新分发
- 观察：包络域；直接路由： writers.example ；列表重写后保留 From: lists.example的列表重新分配
- 观察：原始 DKIM签名;直达路由：本例有效；保留 From 的列表重新分发：取决于签名内容是否存活
- 观察：附加列表签名；直达路线：没有假定；保留 From: d=lists.example的列表重新分配可以验证
- 观察： DMARC问题；直接路线：经过的原始身份是否一致？保留 From 的列表重新分配：是否有任何幸存的传递身份仍然与writers.example一致？
在下面 RFC 9989 §4.4.2 和 RFC 7208 §2.4，如果列表将信封重写为lists.example ，则 SPF pass 验证该列表的身份。它与writers.example不一致仅仅因为重新分配是合法的。在下面 RFC 9989 §4.4.1 和 RFC 9989 §5.3.5，如果原始DKIM签名存活并对齐，它仍然可以提供所需的路径。如果列表页脚或更改的签名标头使原始签名无效，则来自不相关列表域的新签名不会替换丢失的对齐。
实际结果取决于实际的转换、签名和接收者。检查两个版本，而不是假设每个列表都保留或破坏相同的材料。
保留消息修改证据
当重新分发消息失败时 DKIM，将原始签名版本与订阅者处的版本进行比较。检查正文更改、主题编辑和其他签名字段，如中所述 RFC 6377 §3.3。稍后添加的正常消息传递标头不会全部使DKIM失效；签名的覆盖范围和 规范化 下的事项 RFC 6376 §3.4 和 RFC 6376 §3.7.
保留每个签名及其 d 和 s 值。一条消息可能有多个签名，一次失败并不意味着每个签名都失败。使用 主体哈希调查 当主体发生变化时，并将该结果与丢失密钥或其他验证错误区分开来。
切勿仅仅因为猜测它会导致失败而删除真正的业务页脚。演示更改并查阅列表运算符支持的配置。有用的修复保留了所需的列表功能，同时使最终的身份行为变得清晰。
评估可用的操作选择
列表操作员可以检查受支持的方法以避免损坏原始签名，签署自己的邮件并选择如何呈现作者身份。正如中所讨论的 RFC 7960 §4.1.3.3，如果服务将可见的发件人重写为列表控制的域，则生成的DMARC评估将涉及该新的作者域。这可能会改变向订阅者显示的身份和回复体验，因此请测试安全性和可用性。
如中所述 RFC 6377 §5.8，将重新分发的邮件签名为列表可以确定该列表域的责任。它本身无法证明原始作者或恢复与不相关的未更改的 From 域的对齐。
对于接收组织来说，本地分析可能会识别出合法的间接路线。在下面 RFC 9989 §5.4，该分析下的验收与DMARC pass 不一样。保留实际结果和任何可用的覆盖解释，并避免将广泛的允许规则视为使用列表基础结构的每条消息的永久解决方案。
选择适合域名实际使用的策略
RFC 9989 §7.4 明确警告不要发布拒绝其一般用户可能会发布到 Internet 邮件列表的域。其互操作性部分描述了用户影响和接收者责任。程序在选择策略时应应用该指导，而不是承诺所有域最终都应使用拒绝。
仅发起受控列表管理通知的域与用户参与许多外部列表的员工域具有不同的用途。在选择政策之前先审查重要的间接流量。域发布拒绝必须应用有效的DKIM签名，并且不能仅依赖SPF 。
保留可重复的列表测试
使用经过批准的测试作者和订阅者帐户。发送直接控制和代表列表帖子，然后在指定的边界内保留版本、路由、时间戳和可信接收者结果 RFC 8601 §7.1。包括实际使用的列表功能，例如页脚和主题前缀。记录影响转换的软件版本和配置。
本指南中的比较并未断言真正的列表执行。在您自己的环境中，保留实际观察结果，并在列出软件、网关、签名或策略更改时重新测试。来自单一路线或接收者的结果并不能建立通用传递。
有用的邮件列表评估显示每条消息的发起者、列表的更改内容、哪些经过身份验证的身份幸存下来以及订阅者的接收者如何处理它。将这些结果保留给列表所有者，以便以后的更改不会从策略标签重新启动调查。
记录决定及其限制
在 From 不变和假设的不相关列表域的情况下，丢失原始传递的DKIM签名既不会留下重写信封SPF ，也不会留下对齐的列表签名。如果原始签名仍然存在，则可以保留路径。 From 重写会创建不同的评估，而不是原始作者域通过的证明。仅DKIM故障无法识别哪一跳更改了内容：同时保留密钥、签名和规范化证据。