I just found this gist of common temp email address providers and it crashed chrome when I pasted it into the textarea, probably as it was tokenized. It is a bit overkill to add them all in the UI so I wondered if it would be better to have it as an option.
As in true/false - “blacklist common temporary email domains” - and link to the list.
I can’t comment about the performance of this but as this is only for sign-up it should be pretty low overhead?
I’ve attached the list of domains (pipe delimited) for your reference.
Does anyone have a documented problem with people using temporary domains? Discourse has features in place that may make such a list superfluous (i.e., level 0 users can’t do much harm).
The idea of a disposable address is that you can get the verification email to authorise your account, then the box is deleted, so in that sense it allows people to make multiple accounts with no way to trace them except for their IP. Mailinator.com is already in the box so I assume that is what email blacklists are for but, yes, no evidence per se but I am currently setting up a secure instance of Discourse so I need to make sure only real email addresses are used. In a way this is an improvement to an existing feature rather than a new one!
Perhaps you should use must approve users instead? Check the email of every new signup, research fishy domains, add them to the blacklist if they’re on this list, but not before that.
I do that already. I started this thread in the ‘feature’ category as I’m not reporting a bug but rather suggesting a possible enhancement to an already existing feature, which comes with mailinator.com already blacklisted, so I’m a little surprised the questioning is around whether temp email accounts are an issue. My own set-up isn’t really important but it may be helpful to consider this in the case of a high volume public set-up
Hey, @Einstein & @Shriyansh_Agrawal. It’s not entirely clear to me whether this is a problem that needs to be solved, but it might be, and it could be a plugin to work on to get up to speed with discourse internals.
Well, if there’s no issue actually being encountered, this is all just imagineering. If the Discourse developers make a feature that nobody wants or uses, their time has been wasted…
If you a looking for a small practice project to learn the internals of discourse a bit better, maybe. At least one person thinks they want it, and it might be a way to contribute code that someone actually uses.
If you want to contribute code that is likely to become part of core, absolutely not.
I imported that list due to a non mitigatable troll comming back constantly.
(we tried to aviod “Team-Confirmations” or read-only-Level0-Users)
But it turns out that the admin-settingspage becomes hardly usable, since the settings are so big even a Chrome running 8C/32G on a 400MBit/s connection (i do not know where the bottleneck is) runs into timeouts.
In other words: A plugin for this “disposable check” would be rather handy.
You might try filtering this list to the top 100 most commonly used temporary email services, instead. It’s unlikely you need 19k entries to accomplish your goal.
