现在值得在网络上混淆电子邮件地址吗？

Posted 2023-02-25

【中文标题】现在值得在网络上混淆电子邮件地址吗？

【英文标题】：Is it worth obfuscating email addresses on the web these days?

【发布时间】：2011-05-05 03:31:29

【问题描述】：

网络上有various ways 来混淆电子邮件地址，但是当您需要mailto: href 时，它们中的大多数都不起作用。

我通常使用name[AT]domain.com，因为我认为用户必须做什么才能获得真实的电子邮件地址相当明显，但我想知道这是否有任何好处（因为它很容易被垃圾邮件发送者自动化） .我知道将电子邮件地址隐藏在验证码后面的服务，但对我来说，这对用户来说工作量太大。

那么，两个问题：

有没有什么方法可以 (a) 保留 mailto: 链接的使用，(b) 阻止垃圾邮件发送者，以及 (c) 对非高级用户来说不是太复杂？

值得吗？我们是否接受垃圾邮件发送者会想办法绕过它而只使用 Gmail？

编辑：我应该提一下，在这种特定情况下，我说的是我正在制作网站的公司的联系电子邮件地址，在他们的网站上。

【问题讨论】：

设置本地联系表单似乎仍然是最简单、最安全的选择。

【参考方案1】：

在我维护的网站上，我认为保护用户的电子邮件地址是我的责任。垃圾邮件已经够糟糕了，我不需要让垃圾邮件发送者变得容易。

同时，可用性需要功能性的 mailto 链接。我最喜欢的实现方法是使用免费的SpamSpan 技术（偏执狂级别 3）。它是免费的、跨浏览器的、看起来很有效，并且在禁用 javascript 时留下易于阅读的文本。

示例 html

<span class="spamspan">
<span class="u">user</span>
[at]
<span class="d">example [dot] com</span>
</span>

结果（启用 JavaScript）

[e-mail]

结果（禁用 JavaScript）

用户 [at] 示例 [dot] com

【讨论】：

保护您的用户电子邮件地址，只允许其他登录用户查看它们，将显示电子邮件地址设置为默认禁用的用户选项。不要通过混淆来搞砸网络的语义

@Gaz - Web 语义是一项崇高的事业，但我的用户不希望他们的电子邮件地址参与其中。我们的用例要求匿名用户能够使用 mailto 链接——登录不是一种选择。我描述的技术是混淆和可用性之间的一个很好的平衡。

您不必显示电子邮件地址，除非用户想要显示它。此时，限制访问就跟用JavaScript防止右键一样蹩脚了。

我认为这种方法是控制垃圾邮件的好方法，同时，就用户而言，它提供了一个有用的功能。我不同意@Gaz Davidson 的观点，即这与禁用右键单击一样令人震惊，因为用户没有可察觉的差异。他们只是有一个 mailto 链接，这对他们来说很重要。并且允许他们隐藏他们的电子邮件地址是好的，但同时也消除了他们被联系的能力（前提是这至少是网站的一个目标）。因此，那些选择公开他们的电子邮件的人会失败。

垃圾邮件机器人通过使用 mailto: 搜索锚标记从网站收集电子邮件地址。这对机器人来说很容易。但是垃圾邮件机器人也可以在网站上搜索“spamspan”类以找到这个html标签： user [at] example [dot] com bot 读取 u 类、d 类的内容，并以这种方式从网站收集所有受垃圾邮件保护的邮件地址。 Spamspan 以这种方式使用“spamspan, u, d”, .. 类是不安全的！如何保护它？

【参考方案2】：

恕我直言，没有充分的理由混淆电子邮件。垃圾邮件过滤可以由第三方服务自动完成，因此这不是您或您的用户的问题，但检索工作电子邮件是一个障碍，无论沟通多么小。

【参考方案3】：

我怀疑它是否值得。电子邮件混淆完全基于对垃圾邮件发送者的二次猜测和对抓取工具会做什么和不会做什么的想象。

【参考方案4】：

每当我注册一个新帐户时，我都会为该帐户使用一个唯一的电子邮件地址。我知道哪些网站不擅长泄露我的地址，哪些网站对其保密，如果某个地址开始收到垃圾邮件，我会认为该公司最糟糕（即，他们转售了我的个人信息）与松懈的安全性相反，它可以被蜘蛛看到）。

您的用户不必采取此类措施。除非他们明确要求您不这样做，否则您应该尽可能保密他们的个人信息。

很难提供建议，因为显示用户信息的需求因站点而异。作为一般规则，我会在登录过程中引入验证码，然后只在正确标记的邮件地址链接中显示已登录用户的电子邮件地址。对于匿名浏览您网站的人（和蜘蛛），我会完全省略地址而不是将其显示混淆，或者禁止他们访问包含用户信息的任何页面。

【参考方案5】：

电子邮件地址是您的吗？ （您的公司？）或者是那些用户的电子邮件地址。

对于用户地址，我会使用一些混淆或登录墙。 对于个人电子邮件地址，我不会使用任何墙，但我会确保每个人都有某种垃圾邮件过滤器。

【参考方案6】：

我只是通过 JavaScript 注入电子邮件地址。

var e = ["m", "o", "c", ".", "l", "i", "a",
         "m", "g", "@", "s", "m", "a", "i",
         "l", "l", "i", "w", ".", "r", ".",
         "j", ".", "a"];

$(".email").text( e.reverse().join("") );

显然不会阻止垃圾邮件发送者在提取电子邮件地址之前手动拖网或解析抓取的页面并执行 JavaScript，但我怀疑很多人会遇到这种麻烦。

【讨论】：

“我怀疑很多人都会遇到这种麻烦。”这首先是混淆的问题。这完全是基于对垃圾邮件抓取工具会做什么和不会做什么的推测。

@Andy 是的，但如果你接受它是一种威慑而不是修复，那么它可能是值得的。

黑客可以解密您数据库中的散列+加盐密码，这是否意味着您也可以将它们存储为纯文本？鉴于选项是这样的，非混淆地址或某种验证码系统，我认为这是一个很好的折衷方案，并且需要很少的时间来实施。就算不能100%阻止刷机，也聊胜于无。

代码成本非零。代码不是免费的。这都是关于权衡的。如果代码没有成本，那可能“总比没有好”，但事实并非如此。

我们可以探索垃圾邮件发送者整天使用什么方法来获取他们的电子邮件地址，但我愿意打赌他们中的很多人只是获取原始页面 HTML 和正则表达式它用于有效地址。以几行代码的价格阻止那些规模较小的商店是本世纪的交易。

【参考方案7】：

我会说这不值得。该页面包含一个电子邮件地址，用户代理可以在获得许可的情况下读取该地址，或者不包含该地址。对其进行混淆会降低 Web 的语义价值，仅限于特定类型的用户代理，例如可以执行 JavaScript 的用户代理或具有 UI 和用户坐在该 UI 上的用户代理。

如果您要显示一个电子邮件地址，那么您应该只显示它​​ mailto: 和所有，更进一步，使其成为hCard 的一部分，链接回用户的 XFN 个人资料页面并鼓励用户代理未来使用这种丰富的语义数据。否则根本不显示电子邮件地址。

【讨论】：

“仅限于……那些拥有 UI 且用户坐在该 UI 上的人”——我认为这就是重点，并不是每个人都渴望参与完整且易于发现的活动。跨度>

@Greg，用户想要搜索某人，或者检查他们的通讯录中是否已经有人。他们可以搜索他们的浏览器历史记录，也许可以将语义链接的页面抓取到当前页面，也许它还有其他一些我们无法想象的魔法。混淆这一点会阻碍未来的创新。