New signup with old email including + doesnt work in rest API

It seems in a recent update, new signup with same email including a + to represent a new email isnt allowed. my system is highly dependent on it. how to enable it again?

for example if I have already signup with, I cant signup with

btw I am testing this with rest api

also, I dont have this option checked:

I believe that’s the normalize emails admin setting: :+1:

Edit: I did not see that edit before I posted. :slight_smile:

1 Like

yes it is already disabled for me

1 Like

I can’t duplicate this on

Can you sign up from the normal UI with this email?

Also, can you double check the +1 email wasn’t already used for a signup?

1 Like

yes normal UI is ok. rest api is not ok.

I did exactly the same and could not duplicate the problem on the latest code running live - it behaved as expected with the normalize emails setting disabled:

Can you show the output of these from the rails console:

[1] pry(main)> SiteSetting.normalize_emails

[2] pry(main)> User.find_by_email('').username

[3] pry(main)> User.find_by_email('').username

Also, what version of Discourse are you on?

I might also double check you’re hitting your production site and not your test one (or vice versa).


I updated right now

here it is

What do these translate to?


(and can you copy/paste them here)

I should have asked this first :man_facepalming:

“Primary email مجاز نیست.”

it is a translation for


it seems the normalized email is blocked. :thinking:

I mean if is blocked, then is blocked too. it is wierd to me when I have not normalized email option selected.

That’s why I should have asked first instead of assuming it was “already taken” :rofl:

What are your overridden settings in the email and user categories?

Have you blocked that email address, or, say, the Gmail domain?

1 Like

I didnt underestand this. where should I check?

yes I can see the normalized email is blocked.

In this case we almost definitely block subaddresses of blocked addresses regardless of the setting as an anti-griefing measure since the normalisation option is not the default.

“Only show overridden” in settings. But now I suspect we don’t need to worry about that.


Back at my desk I took a look at the actual code that does this rejection:

Right at the top we’re checking the canonical email against the blocklist:

  def self.canonical(email)
    name, domain = email.split("@", 2)
    name = name.gsub(/\+.*/, "")
    name = name.gsub(".", "") if %w[].include?(domain.downcase)

And even if that didn’t catch it, it would be caught by the Levenshtein distance check here:

[1] pry(main)> ScreenedEmail.levenshtein('', '')
=> 2

as the default for SiteSetting.levenshtein_distance_spammer_emails is 2.


This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.