Blocked Canonical Gmails - Issue

I can confirm that the original fix worked perfect and solved this issue with gmails. It would be a real life saver if this optional mode was returned.

Spammers are constantly learning new techniques and are still successfully gaming big players like Facebook, Instagram and Twitter. This makes most other places ‘ez mode’. It’s a full time job for many of them, so it essentially becomes:

If exploitable and (resources required < money earned), then it will be exploited.

They can get around practically any measure, the only hope is to increase the costs of doing so to a point it is not financially rewarding to do so.

Being able to bulk spam with close to unlimited emails/accounts (prior to detection and a mod/admin retroactively blocking their canonical gmail and manually removing their posts) is quite cost efficient. More so if there is not a team of 24/7 moderators.

The cost to get around anti spam measures continues to decrease. One example is 4/5g proxies, for something like $30-$50 or so per month people can get access to virtually unlimited real mobile ips, from legitimate ISPs/ASNs that automatically/manually rotate and are shared by entire cities/states of legitimate users from major ISPs. 4/5g ips are shared by many users simultaneously.

Blocking these ISPs/ASNs or IPs is not suitable (can’t just block everyone using verizon, at&t etc.). They generally use the ip once and dump it. The blocked individual IPs from this will also block legitimate users who are sharing that IP address at random. IP blocking is slowly becoming a legacy practice (excluding ASNs of known hosting companies). You can see the tip of the iceberg on these forums:

https://mpsocial.com/c/public-marketplace/61
https://www.blackhatworld.com/forums/proxies-for-sale.112/

I believe the spammers are a mixture of fully or partially hand-rolled bots and manual spam. As Discourse takes more market share, which it clearly is growing fantastically, I’d be surprised if it doesn’t become a target of commercially available bots.

Whenever Xrumer starts supporting the latest recaptcha version, I’d say most webmasters on legacy forums notice a large uptick in spam due to the rock bottom cost of spamming (no longer need to use a captcha solving API, which are already very cheap per 1k solves):

http://botmasterlabs.net/buy1/

People can already make their own plugins/scripts to support basically any platform using Xrumer. But if they support Discourse out of the box some day:
bad time

I can’t claim to be impartial on this, seeing I’m in direct need of anti-spam measures. The original post about the gmail dot trick was created by someone else in 2014 and seems that another user solved this by requiring approval on the first x amount of posts, so maybe there is at least three user reports? :sweat_smile:

Sorry for the tangent, back on track.

Regarding the regex blocking for emails, yes you are correct. It is a partial solution, but not ideal for these reasons:

If blocking all gmails with 1 period or more before @:

  • It will unavoidably block real legitimate gmail users that have either 1 or more periods in their gmail, which is very common.
  • The spammers can still create quite a lot of variations with one period. e.g. gmail has a maximum length of 30 characters e.g. 12345678901234567890123456789.0@gmail.com will have 30 usable combinations with a single period.

Blocking all gmails with 2 periods or more before @:

  • Less legitimate gmails blocked, but still will block legit gmail users that have more than 1 period in their email.
  • The spammers can create a lot more variations with a single 30 character gmail. I think ~842 combinations or so.

I can confirm that the new accounts came through after the block was active, as the block created date is Feb 1. I was watching new accounts being created yesterday while seeing both cases of the block rule having new recent matches as well as new registrations coming in using the combinations of the same email (periods only).

I disabled registrations overnight and have re-enabled them this morning. They have created 104 new accounts so far today with permutations of that gmail address and continuing to register more. I can confirm that once the periods are removed from the emails of these accounts it is an exact match with the Screened Emails blocked record.

I tried testing the blocks in rails c as described, this is where it gets a bit weird.

So it seems that some records are returning ‘true’ as intended and some are returning ‘false’ even if the email tested is an exact match to the canonical blocked email. For the records that return ‘true’, it worked entirely as intended and returned true for all the variations that I tested. But the emails that return false, all variations I tested returned false also.

I was trying to find any correlations. I can confirm these are not correlated (or at least not consistently correlated):

Email length (before @)
Email containing characters and numbers
Matches (amount of times blocked)
Matched date

It does seem like there is a correlation with the block creation date though, older being less likely to work (returns false). Records that were created 9d ago returned a mix of true/false and all records I’ve tested so far that were created earlier than that (1h-8d) are returning true.

Could maybe be related to ‘max age unmatched emails’ perhaps? I think this option is somewhat new, I have it set at the default value of 365 days.

1 Like