The thing is forcing canonical emails is effectively the same except that it is far less user hostile.
No Sam.sam@gmail.com is allowed Sa.msam+123@gmail.com is already registered
Anyway we can do regex next release
2 Likes
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%
3 Likes
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
6 Likes
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. 
Maybe this, with an example for the gmail/googlemail match could be quite user friendly and powerful.
2 Likes
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 
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.
Cheers.
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 test+1@gmail.com user and test+2@gmail.com tries to sign up, they will not be allowed if the site setting is enabled.
7 Likes
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
4 Likes
Thank you so much for implementing this, this is a massive win - so happy this has been added. I have set it live yesterday and monitoring.
So far, seems to be working 100% as intended and solve this issue entirely. People can still register with periods in their emails (and presumably +, have not seen these registrations recently). But cannot keep making accounts with variations of the same gmail. From reading the discussion on GitHub, it was definitely the best choice to keep the original email as-is.
So having said that, I will leave suggestions here that I think would improve this feature without becoming overly complicated:
Instead of having a checkbox to toggle being enabled/disabled for normalize emails. Have two lists, similar to the email domain block list style.
- Domain list for applying period normalisation
- Domain list for applying + normalisation
For example:
Admin adds gmail.com to both domain normalisation lists.
e.mai.l+123@gmail → email@gmail.com
User adds outlook.com to the + normalisation list (only):
us.er+123@outlook.com → us.er@outlook.com
Emails us.er@email.com and user@email.com being the same address/account is specific to a few providers and not really standard. Where as + seems to be a standard (for any provider that allows it).
This would allow admins to selectively apply these rules individually to problem email domains as they emerge instead of applying normalisation (of both types) to all email domains.
Have no expectations for the above, just leaving the suggestion in case it is useful.
Anyhow, thanks again, really really appreciative this has been implemented. It is a game changer.
2 Likes
I wonder though if this is a theoretical vs real world problem. I get the desire for fidelity, but would prefer to hear about a few specific cases where this is causing an issue.
The trouble with introducing a setting like this would be re-applying normalization rules when you fiddle with the allowlist of sites, it would make it a very complex change.
We now normalize unconditionally (regardless of the site setting) so turning it on is instant and applies to all history.
Awesome 
All thanks to @nbianca
4 Likes
Awesome! I didn’t realise that it would apply retroactively. I was thinking a normalised address was being saved only for new registrations.
Yeah the main chance of an issue would be for cases of email addresses which allow + aliases but don’t consider periods in different placements to be the same.
All instances of +’s in emails can be handled the same without any issue, as it’s handled the same for all providers that allow it as far as I know. Periods are the only ones where there is some difference between providers.
If I recall correctly, I think Google work emails (using custom domains), Yandex and Outlook will consider different period placements to be different addresses, but the + aliases can still be used.
So the only cases would be like theirs@email.com existing would block the.irs@email.com from registering (when these are actually two unique accounts/addresses according to that email domain/provider). Which should probably be very rare to occur in the real world. 
2 Likes
This topic was automatically closed after 16 hours. New replies are no longer allowed.