如果您正在构建任何收集欧洲用户电子邮件地址的应用，您需要了解GDPR对电子邮件地址的规定。不是令人恐惧的版本，不是官僚主义的检查清单版本——而是帮助您从一开始就正确构建事物的实用开发者版本。

好消息是：GDPR的大部分内容是用法律语言包装的常识。一旦您理解了核心原则——为什么收集数据、如何使用它、保留多长时间以及用户拥有什么权利——其余的自然会跟随。

电子邮件地址在GDPR下是个人数据

GDPR将电子邮件地址分类为个人数据，因为它们可以识别个人。即使是看似匿名的地址如[email protected]也指向一个真实的人。这意味着每次您的应用程序存储、处理或传输欧盟某人的电子邮件地址时，GDPR都适用于该处理活动。

这让一些假设GDPR只适用于"敏感"信息（如健康记录或财务数据）的开发者感到惊讶。实际上，GDPR适用于任何可以追溯到特定自然人的信息。电子邮件地址显然符合这一标准。

值得注意的是，这不仅仅是欧洲的关切。加利福尼亚的CCPA、巴西的LGPD和许多其他国家隐私框架都直接受到GDPR启发。以GDPR为出发点进行开发本质上意味着以良好的隐私实践进行开发。电子前沿基金会对这些全球框架的重要性进行了广泛撰写。

六种法律依据——为开发者简化

GDPR要求您对每个处理活动都有法律依据。共有六种，但构建消费者应用的大多数开发者只需要深入了解两种。

合同是当您需要电子邮件地址来提供用户请求的服务时的法律依据。用户注册，您发送验证邮件和交易通知。这很清晰，不需要单独的同意。

同意是服务本身以外所有事情的法律依据——营销邮件、通讯、第三方共享。GDPR对同意设定了很高的标准：必须是自由给予、具体的、知情的和明确的。预先勾选的框是明确不合规的。UK ICO指南提供了有用的实际示例。

数据最小化——最实用的原则

GDPR第5条(1)(c)规定，个人数据应"对于处理目的而言是适当的、相关的且限于必要"。这就是数据最小化原则，对开发者来说可能是整个法规中最实用的想法。

审计您的注册表单。您要求多少个字段？如果您的服务只需要一个电子邮件地址来发送验证链接，为什么还要询问电话号码、生日和邮政编码？您收集的每个超出必要范围的字段都会产生额外的责任。CNIL发布了关于保留期限的详细指南，提供了有用的参考标准。

您可以保留电子邮件地址多长时间？

GDPR的存储限制原则要求个人数据的保留时间"不超过处理目的所必需的时间"。您需要一个保留政策——并且需要在系统中技术性地执行它。

一个合理的方法：活跃用户的电子邮件地址在其账户活跃期间保留。对于不活跃用户（12-24个月无活动）：发送删除预告通知，然后在宽限期后删除。未验证的注册：30天后删除。

删除权

GDPR第17条在某些情况下赋予用户要求删除个人数据的权利。构建一个真正完整的"删除我的账户"流程：主数据库、邮件列表、子系统。软删除模式在操作上是可以的，但需要在下游有真正的清除步骤。

临时邮件与GDPR合规设计

GDPR数据最小化原则在实践中有一个有趣的例子：一个一小时后自动删除的临时电子邮件地址。没有持久的个人数据。自动删除内置于架构中。这是该原则的模型：数据只在特定目的所需的时间内存在。

从开发者的角度来看：在构建和测试处理用户电子邮件地址的系统时，使用临时邮件服务进行测试账户意味着您不会在开发环境中积累真实的个人数据——一个具有GDPR意识的开发习惯。

GDPR下的营销邮件

营销邮件根据GDPR需要明确同意。双重选择加入是最佳实践。您的同意记录应包含：同意的日期和时间、该人看到的确切措辞以及获得同意的渠道。取消订阅请求必须及时处理。FTC垃圾邮件指南提供了补充信息。

第三方电子邮件处理器

您代表自己使用的任何用于发送、存储或处理电子邮件地址的服务——SendGrid、Mailchimp、Postmark——在GDPR下都是数据处理器。您需要与每个处理器签订数据处理协议（DPA）。大多数主要提供商会自动或应要求提供这些协议。

与GDPR斗争最多的开发者和公司通常是那些在没有明确目的、没有文件化保留政策、没有清晰删除路径的情况下积累了大量数据的人。从一开始就构建这些结构比事后改造要容易得多。电子前沿基金会说得好：尊重隐私的软件是更好的软件。