Email blacklist default list of temporary domains as option?


(Simon Donaldson) #1

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.

domains.txt (6.8 KB)


(Jay Pfaffman) #2

That list was copied to this github, which does appear to be continually updated.

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).


(Simon Donaldson) #3

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!


(Kane York) #4

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.


(Simon Donaldson) #5

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 :slight_smile:


(Mittineague) #6

I’m wondering if the Screened-Emails feature isn’t working for you, if maybe tweaking the levenshtein distance spammer emails setting would help.

The default 2 seems like a good choice, but maybe 3 would work better for you?


(Jay Pfaffman) #7

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.


(Shriyansh Agrawal) #8

okay , so there’s a need of plugin , only
controllable by admin to filter emails,disposable-email-domains

Right ??


(Kane York) #9

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…


(Jeff Atwood) #10

I just don’t think one needs to have a weird list of every single possible free email service, to the point of absurdity.


(Shriyansh Agrawal) #11

So @pfaffman , do we still need to implement the feature??


(Jay Pfaffman) #12

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.