GDPR 下邮件系统要做哪些数据最小化配置？加密算不算合规义务？

GDPR 第 5 条列出了个人数据处理的一组原则，其中三条与邮件系统配置直接相关：数据最小化——所采集的数据应与目的相称、限于必要；存储限制——保存时间不得超过必要期限；完整性与保密性——应采取适当措施保障安全。这三条不是抽象口号，可以逐条翻译成具体的系统配置项。

第一是账户与通讯录字段：只采集业务确实需要的属性，避免因「以后可能有用」而默认全量收集；第二是日志内容：投递日志记录收发地址与结果即可，把邮件主题、正文片段一并写进日志会让日志本身变成一份高敏感副本；第三是归档范围：区分需要全文归档与只需元数据留痕的场景；第四是第三方组件与外部集成，只传递其履行功能所必需的字段。

第 32 条要求控制者与处理者采取适当的技术与组织措施，以保障与风险相称的安全水平，并在列举可考虑的措施时点名了个人数据的假名化与加密。需要注意措辞——加密是「酌情考虑」的措施之一，而非对所有场景的绝对强制。该条同时要求评估风险，特别提到了传输、存储或以其他方式处理的个人数据遭意外或非法破坏、丢失、篡改、未经授权披露或访问的风险。

正确的推理顺序是：先识别邮件系统处理的数据类别与风险等级，再据此判断需要何种强度的措施，而不是反过来用「已开启加密」当作合规结论。对邮件而言，通常至少应覆盖三段：用户与服务之间的访问链路、服务器之间的传输链路、以及静态存储。风险较高的数据类别，还需要评估是否引入内容层的端到端加密。

第 32 条列举的措施不止加密，还包括：确保处理系统与服务持续的保密性、完整性、可用性与韧性；在发生事故后及时恢复可用性与访问的能力；以及定期测试、评估与评价技术与组织措施有效性的流程。落到邮件系统上，分别对应高可用与容灾设计、备份恢复演练、以及周期性的配置核查与测试——只做加密而不做这三项，覆盖是不完整的。

建议按以下顺序自查：账户与通讯录字段是否逐项有目的说明；日志中是否混入了邮件内容；归档范围是否区分了全文与元数据；访问、传输、存储三段加密是否都已覆盖；备份恢复是否做过实际演练；上述措施是否有周期性复核的记录。