Text after + in an email address being disregarded in uniqueness check

AI-generated summary

Users on community.drownedinsound.com are encountering an issue where email addresses with a + sign (e.g., jobloggs+discourse@gmail.com) are treated as duplicates during signup, even when the text after the + differs (e.g., jobloggs+discobot@gmail.com). This results in an “Account already exists” error, despite the emails being functionally unique under Gmail’s alias system. The issue began after a site upgrade and was traced to the normalize_emails setting, which, when enabled, strips text after the + sign — causing conflicts with existing accounts using such email formats. ma0sm confirmed the bug was introduced alongside the setting change, and Richie noted it may also cause HTTP/500 errors when users attempt to change their email to one containing a + sign. Richie suggests the setting should not be enabled if accounts with ±sign emails already exist, to avoid breaking functionality for existing users. This behavior is a regression — it did not occur before January 6th, indicating a recent change in Discourse’s handling of email normalization.

Steps to reproduce

  1. Create a new account on https://community.drownedinsound.com.
  2. Use a GMail email with a + character in the username, e.g. jobloggs+discourse@gmail.com
  3. Log out.
  4. Create another account using a GMail email with different text after the + sign, e.g. jobloggs+discobot@gmail.com

Expected Results
Your email receives a new user signup request.

Actual Results
You receive an email to jobloggs+discourse@gmail.com saying that this “Account already exists”.

Notes
After signing up, the new email isn’t used to notify that the account always exists. Discourse didn’t used to behave this way, for example, before January 6th, this never happened on this site. There has been at least one site upgrade since then, and since that happened, this bug has been introduced.

This might be related to the HTTP/500 error we get on our Discourse when using + signs in email addresses depending on the status of the normalize_emails setting:

Thanks for this, you’re right, it was the normalize_emails setting being changed during the upgrade, and there being a bug when normalize_emails is set and you already have email accounts using + signs.

I think this setting is also the cause of the 500 fatal error our users are getting when trying to change their email address to one with a + sign in it.

Perhaps it should not be enabled if such accounts already exist.