理想情况下，您应该让 example.com 提供一个协议来对用户进行身份验证（例如 OAuth2，如上所述）。或者只是在某些 example.com 内部网中提供的“注册密码”。

缺乏这种能力，你可能会想要某种盲签名。最好通过第三方。可能这可以使用类似于旧Mozilla Persona的系统

添加受信任的中介可以解决问题，尽管您主要是用恶意的中介替换恶意平台并与（邪恶的）平台发生冲突。

一个有趣的解决方案是（ab）使用 DKIM 签名。我们可能会假设我们所有的客户都会签署外发邮件（情况并非如此，但它无处不在，足以成为一个合理的限制）。注册时，网站会提供一个令牌并请求在 finishregistration@website.com 接收电子邮件，该电子邮件由 example.com 密钥进行 DKIM 签名，主题字段中带有此类令牌。

在验证时，它会检查消息是否确实通过 example.com 的密钥通过 DKIM，然后像往常一样使用 url 链接处理令牌。对于足够书呆子的客户，您可以允许他们上传 DKIM 签名的源电子邮件，这样他们就可以实际验证他们发送的内容。

这里的难点在于 From: 字段将包含电子邮件地址¹，因此您需要指导用户如何发送电子邮件欺骗空发件人，接受人们可以通过 from: 字段向您发送电子邮件以揭示他们的身份（也许他们不会在意？）或提供可以代表他们执行此操作的程序（为了不给您他们的电子邮件地址，他们执行您选择的不受信任的二进制文件，他们提供他们的电子邮件凭据...... ）。另外，对它们进行签名的服务器本身可能会拒绝/“修复”一个欺骗/空的 From:，或者在标头中的其他位置包含发件人身份。

¹ 可能是全名，更不用说那些不会删除他们的电子邮件签名中充满 PII 的人了。

您可以为此使用 OAuth2。

当用户想要注册时，他输入他的电子邮件，授权服务会验证他们是否有@example.com电子邮件。如果是这样，它会向带有过期时间戳的电子邮件发送一个带有随机令牌的链接。用户点击链接，接收一个随机用户名（或创建一个），并创建一个密码。没有使用个人身份，并且电子邮件根本没有与令牌链接：地址用于发送令牌，并且忘记了。该users表仅包含用户名和正确加盐和散列的密码（请不要使用 SHA1 或 MD5）。如果您想允许人们签署他们的帖子，您可以存储他们的公钥，并且用户将私钥安全地保存在他的计算机上。

每次他们想在博客上发帖时，他们都使用 OAuth2 协议登录授权服务器，获取颁发的令牌，然后使用令牌在博客上发帖。博客服务只接收一个授权令牌，没有用户名，什么都没有。

此时，即使网站变成恶意网站，也没有任何个人信息保存在任何地方，博客收到的唯一信息是一个没有任何身份的随机令牌。如果用户在帖子上签名，也没有个人信息，除非用户在另一个网站上签名，将他的签名链接到他的电子邮件。

但是用户无论如何都需要信任该服务，因为无法确定令牌不是基于用户电子邮件，他们不会将令牌和电子邮件存储在某处，或者授权服务器不会发送授权令牌加上某处编码的电子邮件。

另一个缺点（或优点）是，如果不保存电子邮件，则无法阻止任何用户使用同一电子邮件创建多个帐户，因为服务器不知道哪些电子邮件已经拥有帐户。这可能看起来是一个错误或一个功能。

我有一个部分解决方案来显示帖子的所有权，但不能证明对网站的电子邮件的所有权。

生成一个随机值 R（或仅使用 post ID/hash 或其他东西），然后使用密钥 K 对其进行签名。然后将加密密钥 K(R) 与 R 一起附加到消息中。

释放密钥 K 将使用户确定该用户是发布帖子的人，因为其他人不应该拥有将消息 K(R) 解密为 R 的密钥 K。当然，任何未来的匿名帖子或你不想同时出去需要不同的K。

这基本上是 PGP 签名使用的。

问题是任何人都可以创建键/值对，而不仅仅是您域中的人，并且站点无法控制这一点。您也无法检查您的密钥是否与其他任何人的密钥发生冲突（除非该站点允许您下载所有消息 K(R)，但允许暴力搜索任何/所有密钥），因为该站点需要知道其他键，并且会知道您的键，因为它是在查询中发送的。

您也不能向网站提供任何信息或使用网站提供给您的任何信息，因为这可能会允许网站将您的特定电子邮件与帖子/帐户相关联（甚至像“在此号码中添加数字”之类的东西。根据定义，任何可以用来证明您收到电子邮件的东西都必须是唯一的，否则它可能会被伪造/泄露并让任何人登录。另外，您无法判断它是否真的是匿名的或数据是否真实会将信息泄露到网站）。

没关系，您一开始就不想给网站您的电子邮件，因为它可以而且很可能会被记录。