My forum just receive a large number of spaming user registration.
He/She using Gmail dot tricks ( http://www.makeuseof.com/tag/1-awesome-gmail-tip-you-dont-know-about-seriously/) to create this large number of email account.
Can you prohibid this trick ?
My discourse is using Cloudflare at a CDN and DNS provider, Discourse can’t work fine caused the IP thing.
Couldn’t you ban their IP instead?
Hum, I’m using Cloudflare for CDN, and discourse only see Cloudflare, not user’s IP. (in Wordpress, Cloudflare has an plugin to pass the user IP to website)
At vB we used to get literally thousands of bot “seed” accounts like
aliasg.maila.ccount
alia.sgmai.laccount
ali.asg.mailacco.unt
alias.g.m.ailaccount
al.iasgmai.lacc.ount
… etc. ad nauseum
We eventually had a plugin written to deal with them
Yeah you’re going to need to turn that off, or figure out how to get CloudFlare to send proper headers for the passthrough IP.
Yes. I’m working on that by config Nginx.
Cloudflare actually sends user’s IP via header HTTP_CF_CONNECTING_IP
But prohibid gmail dot trick is useful too.
You really need to get IP passed through correctly otherwise you are really screwed. That’s about the only effective way to stop spammers, if they are clever.
While in this case banning the IP is the right thing to do, I think there is merit in being able to stop user.name@gmail.com and username@gmail.com from being both registered as two different users at any given discourse forum.
No sane administrator should allow this behaviour (from gmail) and maybe we could have an option to extend this prohibition to other email providers as well.
It would need a simple list like ‘@gmail.com’, ‘@anotherprovidder.com’ and then it would check for registered users by removing the dot or any other relevant character (could have a list as well) to avoid users that want to have two or more accounts.
Maybe a plugin with this functionality would be the best solution.
Definitely make it optional if you do it at all. I depend on this trick for troubleshooting!
我们正被这类注册和它们发布的垃圾信息彻底淹没。
mycoolgmailaddress4spam+unlimitedcombinationslol@gmail.com
m.ycoo.lgm.ailaddress4s.pam@gmail.com
不幸的是，我们对这类注册毫无防备。唯一的防御手段就是不被那些具备一定技巧的垃圾信息发送者盯上。
客观地说，没有任何方法可以阻止拥有足够 IP 地址的垃圾信息发送者，利用单个 Gmail 地址，通过上述技巧在任何标准的 Discourse 论坛上创建 10 万个账户。
当垃圾信息发送者能够利用单个 Gmail 地址拥有无限账户时，所有关于垃圾信息/发帖限流的设置都将徒劳无功。
奇怪的是，您的网站在此问题上存在如此严重的故障，而我在过去四年中服务的约1000多位托管客户里，从未遇到过一次类似情况？
@codinghorror 你认为这归功于针对这种常见垃圾邮件技术的充分防御，还是因为这些网站并未成为垃圾邮件发送者的目标？这些网站是否定期收到大量被防御系统拦截的垃圾邮件注册尝试？
这很大程度上取决于领域、流量规模以及是否适合他们的直接响应式垃圾邮件活动。一个能让帖子保持在帖子列表顶部的垃圾邮件发送者，实际上是以极低的价格获得了极佳的广告位。首页首屏广告位根据领域和流量规模，通常每天价值数百至数千美元不等。
如果垃圾邮件发送者通过在特定论坛进行直接响应式垃圾邮件活动每月赚取可观收入，而他们又居住在平均本地薪资极低的发展中国家，那么他们就可能受到激励而采取行动。
我运营着几个自 2015-2016 年起的 Discourse 论坛，由于未成为目标，它们在垃圾邮件注册或帖子方面几乎没有任何问题。未成为垃圾邮件发送者的目标确实是一种不错的防御手段，但一旦成为目标，情况就会不同。据我所知，Discourse 并未被大多数商业可用的论坛垃圾邮件软件（如 Xrumer）默认支持。
嗯，有一条规则我常引用。
如果你被摩萨德单独盯上，你就完蛋了。
确实，专门的垃圾邮件发送者总能找到办法绕过。我们见过他们自建邮件服务器，批量生成成千上万个邮箱地址——这确实让人头疼。
不过，禁止利用这些 Gmail 技巧进行重复注册，似乎是一个合理的预防措施？
@codinghorror - 哈哈，太棒了。不过我可不想就这样认输倒下。
我认为这并非边缘情况，许多社交网站因垃圾邮件滥用问题，不允许使用相同的 Gmail 地址注册。据我所知，大多数主流平台都禁止这样做。
@bartv - 是的，对于那些拥有自有邮件服务器的平台，我们至少可以通过封禁其域名来进行相对有效的防御（尽管在封禁前已注册的账户仍可继续使用）。他们可以获取新的域名，但这至少会消耗他们的资源——不像 Gmail 的这类技巧那样毫无成本。
针对这些 Gmail 技巧，实际上几乎没有有效的防御手段，而且额外的地址变体对垃圾邮件发送者而言成本为零。“莱文斯坦距离垃圾邮件”方法在多次封禁不同点号组合的同一 Gmail 地址后，对“点号技巧”有一定帮助。但目前仍无法防御“加号技巧”，该技巧允许生成几乎无限多的地址组合。
除非你有足够强大的朋友来帮你。而 Discourse 开发团队就在这里（如果我们考虑到插件的话，也许社区也能帮上忙）。
抱歉，但 Discourse 将所有 Gmail 地址中的点号以及加号（+）后面的内容视为同一地址，这难道不是件好事吗？技术上似乎并不复杂。只需要几行简单的代码：注册时检测到邮箱地址在@符号后是 gmail.com → 移除所有点号以及@符号前加号（+）之后的内容 → 使用该地址 → 如果已被使用 → 返回错误信息“邮箱地址已被使用”。
搞定。还是我漏掉了什么？
如果垃圾邮件发送者开始知道这在 Discourse 上有效，他们肯定会越来越多地利用这种技术攻击 Discourse 论坛。我的意思是，他们为什么不这么做呢？
我们为新用户设置了前 X 次发帖或创建主题必须经人工审核的规则，几乎一夜之间就解决了这个问题。后来我们发现，有些用户尝试事后编辑帖子来绕过限制，于是我们也将这一规则调整适用于信任等级 0 和 1 的用户。
虽然这与任何特定的域名技巧没有直接关系，但它确实干扰了问题的核心：即一个有动机的用户试图绕过你的防护措施。如果他们无法使用 Gmail 的“技巧”，总会找到其他方法。我个人更倾向于采用“信任等级 1 才能发帖，且需累计 5 分钟阅读时间”这类策略。
好吧，让我们看看。这里可以使用哪些字符？
一些邮件服务支持在本地部分（local-part）中包含标签，使得该地址成为本地部分前缀的别名。例如，地址
joeuser+tag@example.com与joeuser@example.com指向相同的投递地址。RFC 5233 将这种惯例称为子地址（sub-addressing），但它也被称为加号地址（plus addressing）、带标签地址（tagged addressing）或邮件扩展。这种形式的地址，在基础名称和标签之间使用各种分隔符，已被多种电子邮件服务支持，包括 Runbox（加号）、Gmail（加号）、Rackspace Email（加号）、Yahoo! Mail Plus（连字符）、Apple 的 iCloud（加号）、Outlook（加号）、ProtonMail（加号）、FastMail（加号和子域地址）、MMDF（等号）、Qmail 和 Courier Mail Server（连字符）。Postfix 和 Exim 允许从合法字符集中配置任意分隔符。
因此，我们有：加号、连字符、等号、句点和井号。
我能想到的唯一可行方案是设置一个非常严格的规则，禁止电子邮件地址中使用 A-Z、a-z、0-9 以外的所有字符。
这肯定会阻止一些用户注册，但如果你正被……嗯……以色列摩萨达的精英特工针对的话，这或许是一个可行的权衡：
你怎么看 @eviltrout？
这或许过于严格了；这里的重点是防止重复使用此类电子邮件地址变体，而非完全禁止。您可以改为在每个账户中添加一个“规范”电子邮件地址，其中包含用户实际电子邮件地址的清理版本。在注册新账户时，将清理后的电子邮件地址与此值进行比对。不过，说起来容易做起来难。
[quote=“codinghorror, post:18, topic:22627”]
我能想到的唯一可行的方法就是设置一个超级严格的选项，阻止电子邮件地址中出现 A-Z a-z 0-9 以外的所有字符。[/quote]
[quote=“bartv, post:19, topic:22627”]
你也可以改为给每个账户添加一个“规范”电子邮件地址，其中包含用户实际电子邮件地址的清理版本。[/quote]
是的，我更喜欢 Bart 在这里提出的建议。
[ ] 为电子邮件地址的内部存储使用规范形式（移除 + 任意内容、剥离注释等）
提供了一个我们可以借鉴的 Ruby 实现，但我们需要非常非常非常小心（示例 1 存在安全风险，详见：https://stackoverflow.com/a/52125295/17174）
EmailAddress.canonical("(test)sam.saffron(test)+100@gmail.com")
=> "test@gmail.com"
[3] pry(main)> EmailAddress.canonical("sam.saffron(test)+100@gmail.com")
=> "samsaffron(test)@gmail.com"
[4] pry(main)> EmailAddress.canonical("sam.saffron+100@gmail.com")
=> "samsaffron@gmail.com"
因此，我建议我们的“规范化”操作应执行以下步骤：
移除 + 任意内容
转换为小写（我们已强制执行此操作）
如果是 Gmail、Googlemail 或在自定义白名单中的域名，则移除点号
移除注释 (...)，这也是滥用的一个途径。
对地址进行 Unicode 规范化，这在技术上是被允许的，详见：Email address - Wikipedia
然后添加一个隐藏的站点设置，用于配置允许移除点号的域名白名单。
不过，滥用这种方式的可能性仍然很多。甚至有人可能手握 10000 个垃圾 Gmail 地址缓存，并通过某种机器人全部注册。如果你正遭受攻击，不妨暂时批准所有新注册。也许这是少数几个你确实希望在注册插件中启用 reCAPTCHA 的情况之一。