邮件营销的同意与撤回同意，在技术上要怎么落地才站得住？

个人信息保护法确立的告知同意规则，对邮件营销提出了几项可直接技术化的要求：同意应当由个人在充分知情的前提下自愿、明确作出；基于个人同意处理个人信息的，个人有权撤回其同意；处理者应当提供便捷的撤回同意的方式；撤回同意不影响撤回前基于个人同意已进行的处理活动的效力。

GB/T 35273-2020 在此基础上给出了更具操作性的表述方向：授权同意应当是主动作出的，撤回的便捷程度应当与作出同意时相当。

把这些翻译成工程语言，就是三条硬性指标：

1. 同意必须留下可举证的记录——时间、来源、方式、当时展示的告知内容版本。
2. 撤回入口的操作成本不得高于订阅入口。订阅只需勾选一次，退订就不应当要求登录、填问卷或联系客服。
3. 撤回必须真正生效并可验证——不是「标记为已退订」，而是后续确实不再向该地址发送。

其中最容易失守的是第一条。很多组织能说出「我们有用户同意」，却拿不出任何一条记录来证明某个具体地址是何时、通过何种方式同意的。无法举证的同意，在合规上与没有同意接近。

同意记录应当能独立回答「这个地址为什么会在我们的发送列表里」。建议至少记录：

• 时间戳：同意作出的精确时间，含时区。
• 来源标识：具体是哪个页面、哪个表单、哪个活动、哪个渠道。「历史数据导入」不是合法来源，遇到这类记录应当单独隔离并重新征得同意。
• 同意方式：勾选、双重确认、线下签署等。
• 告知内容版本号：当时向用户展示的隐私政策或告知文本的版本。这一项几乎总是被遗漏，但它是「充分知情」的唯一证据——政策改过之后，无法回溯当初展示了什么，就无法证明知情。
• 同意范围：同意接收哪一类内容。为「产品更新通知」征得的同意，不能被用于发送第三方广告。
• 技术侧记录：提交时的来源地址、用户代理等，用于识别批量伪造提交。

强烈建议采用双重确认（先发一封确认邮件，用户点击后才真正入库）。它同时解决两个问题：一是证明该地址的持有人本人确实同意（而非被他人恶意填入），二是把无效地址在源头挡掉，直接改善送达质量。合规动作与投递质量在这一点上是完全一致的，不存在取舍。

「便捷的撤回方式」在邮件协议里有成熟的标准化实现，不需要自创。

RFC 2369 定义了一组以 URL 为元语法的邮件列表命令信头，其中 List-Unsubscribe 用于告知退订方式。它可以携带 mailto: 与 https: 两类 URL：

List-Unsubscribe: <https://example.com/unsub?id=abc>, <mailto:unsub@example.com?subject=unsubscribe>

RFC 8058 在此之上定义了一键退订功能的信令方式。它引入 List-Unsubscribe-Post 信头，其值为固定的 List-Unsubscribe=One-Click，表示邮件客户端可以直接向 List-Unsubscribe 中的 HTTPS URL 发起 POST 请求完成退订，无需用户再打开网页确认：

List-Unsubscribe: <https://example.com/unsub?id=abc>
List-Unsubscribe-Post: List-Unsubscribe=One-Click

配置时有几个必须注意的点：

1. 这两个信头必须被 DKIM 签名覆盖（RFC 6376）。未被签名的退订信头可被中途篡改，指向攻击者控制的地址，退订动作就变成了一次地址有效性确认。这一条是安全要求，不是可选项。
2. 退订 URL 中的标识必须不可枚举。使用顺序编号会让任何人都能批量退订他人。应使用足够长的随机标识，并在服务端做频率限制。
3. 一键退订的端点必须能正确处理 POST，且不得要求 Cookie、登录态或额外确认页。点了退订却跳到登录页，是最常见的不合格实现。
4. 不要用退订链接做行为追踪。在退订请求中夹带与退订无关的追踪参数，与「便捷撤回」的要求方向相反。
5. 正文里同样要有可见的退订链接。不是所有客户端都会渲染信头中的退订入口，两者应当并存。

退订请求到达之后的处理，才是真正决定合规性的部分。核心机制是抑制列表（suppression list）——一份「无论如何都不再发送」的地址清单。

它的设计要点：

• 抑制列表必须是全局的，且优先级最高。常见事故是：用户从 A 活动退订了，市场部门从 CRM 重新导入一批名单，该地址又回到了发送队列。抑制列表必须在发送前的最后一步生效，覆盖任何名单来源，不接受任何例外。
• 生效必须近乎实时。「退订后若干天内可能仍会收到」是常见的免责说法，但从合规角度看，延迟越长风险越大。技术上没有理由做不到快速生效。
• 抑制列表本身要长期保留。这里有一个看似矛盾的地方：既然用户撤回了同意，为什么还要保留他的地址？因为不保留就无法执行「不再发送」。处理这份数据的目的已经从「营销」变成了「履行不发送的义务」，这是一个不同的、必要的目的，应当在隐私政策中明确说明，并将该数据的用途严格限制在比对抑制上。
• 要区分「退订」与「投诉」。用户点击邮件客户端的「举报垃圾邮件」不会触发退订流程，但它同样是明确的拒绝信号。应通过反馈环路机制接收此类信号并同样纳入抑制。忽略投诉信号会直接损害发送域声誉，进而影响所有邮件的送达，包括业务通知邮件。
• 保留退订记录。退订的时间、方式、请求来源同样要留痕，用于在争议时举证「我们确实及时停止了」。

1. 随机抽取发送列表中的若干地址，能否为每一个都调出完整的同意记录（时间、来源、方式、告知版本）？调不出的，应当停止发送并重新征得同意。
2. 用真实邮件客户端实测一键退订：点击后是否即刻生效？是否跳出了额外页面？服务端是否收到了 POST？
3. 检查 List-Unsubscribe 与 List-Unsubscribe-Post 是否在 DKIM 的签名信头列表中。
4. 退订一个测试地址后，从另一个名单来源重新导入该地址，验证它是否仍被抑制。这是抑制列表最关键的一次测试。
5. 检查退订标识是否可枚举，尝试构造相邻标识看是否能退订其他地址。
6. 确认 DMARC（RFC 7489）配置正确且发送域通过校验。身份认证与同意管理是两回事，但缺任一项，营销邮件都会被判为不可信。
7. 核对隐私政策中关于退订与抑制列表的表述，与系统实际行为是否一致。文档写了「立即生效」而系统实际延迟数天，这种不一致本身就是风险点。