建议：通配符屏蔽电子邮件地址

贡献 功能
1

Would be good if there was a way to add wildcard blocked email addresses. E.g. When a spammer uses the gmail dot trick.

E.g.

example@gmail.com
example+random12345@gmail.com
ex.a.mple+random12345@gmail.com
e.xamp.le@gmail.com

Are all the same email address, spammers can use one gmail address to make unlimited accounts easily.

Blocking an address with wildcards like below I believe would be a good solution:
e*x*a*m*p*l*e*@gmail.com

I don’t necessarily think that all registrations using these gmail address variations should be blocked, just that it would be useful that if a gmail address is blocked, all variations are blocked too or that we can manually add a wildcard gmail to the email blacklist.

1 个赞
I can't easily delete spammers due to my site configuration
2

Are you seeing an actual specific problem or is this just a theory? If it is a specific problem can you share the specific spammer emails?

4 个赞
3

Yes it’s an actual problem I’m experiencing, I have spammers regularly making tens of thousands of accounts per single gmail account with the dot method and a sufficient pool of IPs.

I’m only seeing the dot trick being used, not 100% sure about if the + method works also. Last I checked it was possible to register using email addresses with + characters, so that trick should work too.

For example, this email (not a real email):
constantinehamilton1337x@gmail.com

Can make 16,777,216 unique email addresses using the dot method only and essentially unlimited using the + method. Makes it super efficient for spammers. Domain blacklist isn’t viable seeing it’s gmail.

You can see a generator here (gets laggy over 8k combinations): Gmail Dot Trick Generator

4

If this was actually implemented with a wildcard-like approach (instead of being handled automatically by Discourse), you’d probably want to be much more specific than e*x*a*m*p*l*e*@gmail.com. Doing it that way could result in blocking innocent people, especially if the spammer’s email address is relatively short. Looking specifically for . and + would probably be much safer.

2 个赞
5

What is your levenshtein_distance_spammer_emails setting at, the default 2 or the max 3 ?

2 个赞
6

Thanks for the heads up about this setting levenshtein_distance_spammer_emails. I’ve never seen or modified it before - it’s at the default of 2.

3 个赞
7

I don’t understand your math. You can add only a single dot between characters, so each N-character address is good for only 2*n addresses. You could probably have a plugin that saved or compared against the dot-removed address and disallowed +addresses.

2 个赞
8

@pfaffman - I was just going off the figures given from Gmail Dot Trick Generator which is for every additional character above 2 the amount of addresses is doubled (it freezes at about 8k though).

I think 2*n, if I understand what you mean by this (as in a 26 character address would have 52 combinations?) would be too low. As they can add multiple dots throughout the address.
E.g:
constantinehamilton1337x@gmail.com
con.stantinehamilton1337.x@gmail.com
co.nst.antineh.amilton1.3.37x@gmail.com
constantineh.a.m.ilto.n13.37x@gmail.com
c.o.nsta.ntinehamil.ton1337x@gmail.com

Anyhow, whatever the exact figure is, it’s a lot. Yeah, your suggested solution would make sense!

1 个赞
9

Yeah. I wasn’t doing the math right. I was allowing just one dot. I once almost knew that math, but didn’t this morning. :wink:

But a plugin that saved a shot and plus free version of the address as an additional address would do what you want and wouldn’t be that hard.

3 个赞
10

注意……当您屏蔽 sam.sam@gmail.com 时，我们现在会自动屏蔽 sam.sam+1@gmail.com 等地址。

10 个赞
11

这个功能运行得非常顺利 @sam :slight_smile:

我认为你之前实现的 方案 仍然可以作为一个额外的反垃圾邮件功能发挥很大作用。在它短暂可用且启用（默认关闭）的期间，效果非常出色。

否则，垃圾邮件发送者仍然可以在版主或管理员发现之前，利用一个 Gmail 地址批量创建账户。例如，创建账户但不立即发布任何内容。

管理员/版主将需要手动查找并打开每个单独账户进行封禁或删除。这可能相当繁琐，尤其是当一名垃圾邮件发送者可以在被封禁之前用一个 Gmail 地址创建数百甚至数千个账户时。此外，搜索这些邮箱也很困难，例如 j.ohan.2.1@gmail 和 jo.ha.n21@gmail。

如果这些账户没有被手动排查出来，垃圾邮件发送者就能保留大量账户池来玩“打地鼠”游戏，而只需要消耗一个 Gmail 账户即可获得这些账户。

12

@sam 在进行了更多实地测试后，我认为之前被回退的实现方案对于应对有动机的垃圾信息发送者确实更为有效。我仍然收到大量利用这些 Gmail 变体技巧的注册请求。

我非常感激当前实施的防护机制，它非常有效。然而，我认为允许使用同一邮箱创建无限数量的账户（直到被特别发现并手动封禁）是一个漏洞。这给版主带来了更大的负担（据我所知，版主默认无法查看账户邮箱，除非启用该功能），尤其是在缺乏批量账户删除工具的情况下（例如：从账户/搜索列表中使用复选框选择多个账户并批量封禁/删除）。这意味着版主必须手动逐个访问每个账户进行删除或封禁操作。当需要搜索使用变体邮箱的账户时，这种情况尤为困难。

既然之前的实现方案是可选的（默认关闭），且已经开发完成并按预期运行，随后却被移除。对于希望利用它来增强针对有动机垃圾信息发送者的反垃圾保护社区来说，它不再可用，这实在令人遗憾。

whynotboth
whynotboth596×395 42.5 KB

13

这就是为什么我说某些字符必须（可选地）完全禁止出现在电子邮件地址中。具体来说，是那些允许子地址功能的字符，例如加号、点号、连字符等。使用正则表达式，你还可以按服务进行拦截，例如“不允许使用以 @gmail.com 结尾且包含加号的电子邮件”。cc @sam

1 个赞
14

之前的实现仍然允许使用 +addressing，同时保持每个账户仅保留一个规范地址（我认为这可能更安全）。

因此，你可以注册为 sam+discourse-meta@gmail.com，这对于你设置的 Gmail 内部规则非常方便。但随后系统会禁止从 sam@gmail.com 或 sam+1@gmail.com 注册新账户。

我并不反对添加白名单，但我觉得强制使用规范地址对于 Gmail 场景非常有用，而且作为一个默认设置也并无不妥。

1 个赞
15

安全并非这里的主要目标。由于该网站面临的问题范围较大，需要更极端的解决方案。只要它是可选的（即允许用户自定义“邮箱保护正则表达式”），那么在我看来，对于需要它的网站来说，这完全安全；这些网站可以选择启用“完全锁定模式”。

1 个赞
16

我们目前拥有：

被阻止的邮箱域名

我想我们可以添加：

被阻止的邮箱模式

不过，考虑到所需的各种转义，正确编写正则表达式有些令人烦恼。我担心提供此类选项，因为用户正确且按预期编写正则表达式的几率相当低。他们需要记得转义点号和加号。

.*\\+.*@gmail\\.com

我想我们也可以采用一种非基于正则表达式的简化模式，仅扩展 * 和 ?。

*+*@gmail.com

5 个赞
17

:wave: 抱歉回复晚了！

如果将之前的实现作为选项重新添加，我相信这将彻底解决 Gmail 的问题。至少在我的情况下是这样。在我看来，这非常完美，并且为垃圾邮件发送者增加了足够的资源成本，使得应对工作变得可控。这确实是有需要全天候高强度审核与不需要之间的区别。

我已经封锁了几个允许类似操作并利用“允许邮箱域名列表”的域名。问题在于，人们可以在某个账户被禁止/封锁之前创建大量账户（这会激活对该 Gmail 地址变体的新账户封锁，但现有账户不受影响）。这使得审核工作变得相当繁重，并且事后逐个清理每个账户也很繁琐。

例如，我曾遇到一个帖子，其中有大约 200 条回复，每条回复来自一个不同的账户，但都使用同一个 Gmail 地址。类似的情况还有很多。这些是容易发现的例子，因为通过原始 Gmail 的变体来搜索它们非常困难。有些人会利用少量 Gmail 地址注册大量账户，并等到几个月后才开始发帖。

关于使用正则表达式作为解决方案：封锁加号（+）相对无害；而封锁点号（.）可能会阻止大量合法邮箱，例如 john.smith@gmail.com。封锁包含多个点号的地址可能造成的附带损害较小，但仍会允许 Gmail 地址的几种变体，不过比允许两个及以上点号的情况要少得多。

依我之见，之前的实现是理想的，并且作为可选保护措施实施起来并不过分。大多数主流社交网站都不允许使用多个 Gmail 变体进行注册，因为这些变体常被垃圾邮件发送者大量利用。

谢谢 :slight_smile:

1 个赞
18

@sam 我强烈认为，如果网站需要，应允许其实施这种可选的邮箱正则表达式锁定级别。否则，我们将违背 Discourse 的核心原则之一，即“默认安全”。

1 个赞
19

我们可以在下一个版本中完成这项工作，但我依然坚持最初的想法：规范化是对站点运营者最友好的解决方案，只需勾选一个复选框，问题便迎刃而解。而使用正则表达式，你不得不先花上五个小时学习正则表达式，最终得到的解决方案要么会让垃圾账户漏网，要么对用户不友好（不允许使用点号或加号），要么只能是一种折中方案。

不过话说回来，当然，我们可以在下一个版本中加入对正则表达式的支持。

1 个赞
20

嗯，其实很简单，就是“不允许使用包含加号或句点的电子邮件地址”，这确实相当严格，显然我们不会默认开启这个选项。但这就像“巴姆瓦”问题一样：总会有一些恶意行为者，因此你不得不准备“核按钮”，哪怕你并不想使用它。

这就像核战争。一旦核武器摆在桌面上，就不再有可能提供“用户友好”的选项了，你只能希望大多数时候永远不需要走到那一步。