List-ID 帮助接收系统识别各个邮件的邮件列表。它对于分组、过滤和事件关联很有用，但并不能证明发件人有权操作该列表。首先询问任务是列表识别、订户支持还是身份验证诊断；这些任务需要不同的证据。
解析标识符，而不仅仅是标签
RFC 2919定义了一个 List-ID 字段，其中包含用尖括号括起来的列表标识符和可选的人类可读短语。在综合示例中，项目更新 < updates.lists.example > 具有显示短语和单独的计算机标识符。保留两者，但不区分大小写地比较括号内的标识符，并忽略周围的短语以进行身份匹配，如RFC 2919第 6 节指定的那样。 RFC 2919第 2 节和第 3 节.
该标识符不一定是应联系的邮箱、工作 URL 或DNS名称。不要仅仅因为它类似于域就向其发送邮件或尝试网络发现。其目的是识别。将消息之间的更改记录为需要解释的证据，而不是列表更改所有权的自动证据。
将身份与信任分开
发送者可以插入列表ID字段。该字段本身并不验证列表操作员的身份、证明订阅者的订阅情况或确定消息的安全性。当归属很重要时，检查可信身份验证结果和原始签名字节。有效的签名可以在其签名身份下保护所覆盖字段的完整性，但该身份与列表的关系仍然需要解释。 RFC 2919第 8 节, RFC 6376.
对于过滤，请考虑信任该字段的后果。个人文件夹规则和安全绕过具有不同的风险。将列表路由到文件夹并不等同于允许它通过恶意软件或模拟控制。使用组织支持的控制措施并保持保护性检查完好无损。
关联列表的转换
比较List-ID，可见From， 信封发件人 和 DKIM 跨发件人副本和收件人副本（如果可用）签署域。列表可以添加页脚、重写主题或更改可见的发件人。这些转换可能会影响身份验证，但仅 List-ID 无法确定发生了转换或签名失败的原因。
列表标识和管理操作占据不同的领域。一个 List-Unsubscribe value 描述了RFC 2369下的管理机制，而不是 List-ID 的所有权。在点击链接或发送请求之前检查预期目的。
保持深思熟虑的操作行为
如果读者想要取消订阅，请使用经过验证的列表管理机制，而不是将List-ID视为指令地址。如果读者想要进行投递调查，请保留未修改的收到消息和相关列表操作员日志。如果读者想要过滤，请在受控样本上测试规则并确认它仅影响预期范围。
分别记录列表标识符、观察到的身份验证身份、受影响的路由和任何批准的更改。这使得另一位分析师能够将稳定列表标签与签署和传递特定消息的人的证据区分开来。
比较两个假设的列表标签
假设一条消息显示 List-ID：项目更新 < updates.lists.example >，另一条消息显示 List-ID：工程新闻 <UPDATES.LISTS.EXAMPLE>。即使描述性短语不同，在不区分大小写的规则下，括号内的标识符也比较相等。这两条消息均未通过该等式进行验证。
如果文件夹规则对它们进行分组，请验证这是否是预期的组织行为。如果请求是为了绕过恶意软件检查或确定收件人是否订阅，请停止并获取相关的安全或订阅证据。这些是发明的标头值，而不是已解析或交付的邮件列表示例。
选择列表任务的证据
- 识别：比较括号内的标识符，而不是显示短语。
- 订阅支持：使用列表运营商授权的订阅记录。
- 归属：验证签名覆盖范围以及签名者与列表的关系。
- 过滤：在不绕过安全控制的情况下测试狭窄的组织规则。
- 取消订阅：使用经过验证的管理机制，不使用List-ID作为地址。