Suggestion: Wildcard Block Email Address

The thing is forcing canonical emails is effectively the same except that it is far less user hostile.

No is allowed is already registered

Anyway we can do regex next release


Yeah, but it’s useless in actual practice, which is why we’re having this discussion… once they have nukes, you need nukes too.

“User hostile” is a meaningless concept once your audience has nukes and is willing to use them.

I disagree with this, the solution worked perfectly for @markersocial, and then I reverted the change cause my hand was forced

There are no known gaps with the canonicalization approach I implemented and reverted, it solves the above gmail problem 100%


Well, I disagree, because that put the code and effort burden on our side, rather than their side. “Normalizing” emails is quite complicated, varies per email provider, and I don’t want to be in that business.

In other words, let them build and handle the nuclear devices on their own; we don’t need to ship proto-nukes to every country and in every installation of Discourse “just in case”.

(Plus being able to blocklist emails via regex is quite powerful, especially since email = identity in Discourse.)

1 Like

We could let them normalise with their own regex rules as some sort of middle ground, then we are not in the business of normalisation

That said yes regex blocking or at least wildcard blocking will happen for the next release


I can confirm that the previous implementation worked perfectly and entirely solved the gmail issue. The email domain allow list and disallow list both are quite effective nukes. But it’s just not viable to block gmail.

@codinghorror I can see the point of view against normalising for different email providers. But I think it would make sense to be able to cover at least gmail (~43% of all email addresses apparently in 2020, 53% for the US) in a non-destructive way. It might be comparable to supporting oauth from large providers out of the box.

@sam ^ This is a great idea for an alternative. :slight_smile: Maybe this, with an example for the gmail/googlemail match could be quite user friendly and powerful.


Have a user right now that has made several thousand accounts with a single gmail address (using periods) and spamming promoting their competing site to siphon off users. Will be upgrading to 2.8 and blocking all emails that contain a period or plus symbol as soon as it’s released. I do wish the previous implementation was available, but appreciate that this is being addressed and a solution will be available. It’s going to make a massive difference, thank you :slight_smile:

1 Like

So have thought about this a bit and thought of a solution that could maybe make sense.

There could be an admin option to process and store a normalised version of the email (only processing the username part i.e. username@…)

But only apply this for domains that are specified by the admin.

So a list somewhat like the email domain allow/block lists, with two checkboxes per domain:

  • Strip + string
  • Strip periods

Then use these records as a reference for disallowing additional registrations using alternative versions of that email (without affecting the primary email record, which can still have + and periods).

This way, the burden of selecting which domains to store a normalise record for and how to normalise them can be on the admin only, allowing them to respond to problematic email domains as they emerge.

Anyhow, just dropping this here so it can perhaps be considered at some point.


I merged the PR:

It adds a new site setting normalize emails which will remove dots and +… part of an email and then check for its uniqueness. For example, if there is a user and tries to sign up, they will not be allowed if the site setting is enabled.


Fantastic, I think this 100% solves @markersocial’s issue and is a great setting to enable if you end up being a target for this specific attack.

Let us know how you go @markersocial