# Email domain blacklist with wildcards (revisited)
**URL:** https://meta.discourse.org/t/email-domain-blacklist-with-wildcards-revisited/70088
**Category:** Feature
**Created:** [15. September 2017 um 02:37 UTC](https://meta.discourse.org/t/email-domain-blacklist-with-wildcards-revisited/70088 "2017-09-15T02:37:40Z")
**Posts on this page:** 6
**Page:** 1
### Author:  [@schungx](https://meta.discourse.org/u/schungx)
#### Post date: [15. September 2017 um 02:37 UTC](https://meta.discourse.org/t/email-domain-blacklist-with-wildcards-revisited/70088/1 "2017-09-15T02:37:40Z")
> [@Email domain blacklist with wildcards](https://meta.discourse.org/t/email-domain-blacklist-with-wildcards/28627):
>
> Hi I’m trying to block email addresses from a particular domain - from which we seem to receive multiple spam user accounts per hour sigining up. They come from .jil.kr where can be one of some 20 or so names I’ve seen so far. I tried adding jil.kr but that doesn’t match, so then tried \*.jil.kr instead but that gives an error in the log that the regex is invalid as there’s no subject for the \* character, so I then tried (.\*).jil.kr and that doesn’t match either - I think because the . charac…
The current implementation already matches black-listed domains with `EndsWith` type string matching.
I would like to propose adding `regex` type matching as well.
Reason: Recently a lot of spammers come from email addresses with a long string of numbers, for example `76987.com`, `245934.net` etc.
I would like to be able to filter them out, but with the standard `EndsWith` matching, it is impossible.
---
### Author:  [@schungx](https://meta.discourse.org/u/schungx)
#### Post date: [15. September 2017 um 02:41 UTC](https://meta.discourse.org/t/email-domain-blacklist-with-wildcards-revisited/70088/2 "2017-09-15T02:41:28Z")
EDIT:
Oops, just looked through the commit. Seems like the domain string is passed straight into the regex:
`regexp = Regexp.new("@(.+\.)?(#{domains})", true)`
Not sure if `#{domains}` gets sanitized before-hand. Unlikely because of the line:
`domains = setting.gsub('.', '\.')`
which only sanitizes the dot.
But it does appear to support putting a `regex` inside `#{domains}`, except that the `regex` cannot use the dot `.`
---
### Author:  [@schungx](https://meta.discourse.org/u/schungx)
#### Post date: [20. September 2017 um 02:44 UTC](https://meta.discourse.org/t/email-domain-blacklist-with-wildcards-revisited/70088/3 "2017-09-20T02:44:19Z")
I’ve tried it with the following blacklist domain:
`\d+\d\d\d.\w+`
which should match any domain which is made up of four or more numbers (and numbers only).
I checked the setting with [Data Explorer](https://meta.discourse.org/t/32566?silent=true) and confirms that `email_domains_blacklist` is ` mailinator.com|cc|\d+\d\d\d.\w+`, which is correct.
The code `regexp = Regexp.new("@(.+\.)?(#{domains})", true)` should now filter off emails coming from domains with long digits.
EDIT: Note: not sure what the second parameter `true` is doing in a call to `Regexp.new()`, which takes as a second parameter the matching options.
However, I just had three new SPAMmers came through:
```plaintext
ddef@445555.com
mnopp@89990001.com
gg5@996399.net
```
So obviously it is not working.
Trying the RegExp in a JavaScript console confirms that it works:
```plaintext
/@(.+\.)?(mailinator\.com|cc|\d+\d\d\d\.\w+)/.test("ddef@445555.com")
true
```
There, the domain blacklist is not working as it should.
---
### Author:  [@schungx](https://meta.discourse.org/u/schungx)
#### Post date: [20. September 2017 um 05:44 UTC](https://meta.discourse.org/t/email-domain-blacklist-with-wildcards-revisited/70088/4 "2017-09-20T05:44:02Z")
I wonder… does it require restarting the VM for the settings to “set”?
---
### Author:  [@schungx](https://meta.discourse.org/u/schungx)
#### Post date: [20. September 2017 um 06:24 UTC](https://meta.discourse.org/t/email-domain-blacklist-with-wildcards-revisited/70088/5 "2017-09-20T06:24:43Z")
Tracing through the code, there is something very suspicious.
`EmailValidator` seems to be only used when a user updates his/her email address (in `EmailUpdater`).
When a user is created, it only validates against proper email format but not whether the email domain is blacklisted.
Emphatically, it is _not_ used to verify when a _staged_ user is created via `email in`, because `email/receiver.rb`, in `process_internal`, it only checks against things:
```plaintext
Regexp.new(SiteSetting.ignore_by_title) =~ @mail.subject // Blacklisted TOPIC TITLE
raise BouncedEmailError if is_bounce? // Bounce mail
raise NoSenderDetectedError if @from_email.blank? // No From field
raise ScreenedEmailError if ScreenedEmail.should_block?(@from_email) // Screend Email address
```
After this, a new _staged_ user is created via `find_or_create_user`.
Shouldn’t `EmailValidator.validate_each` be called on `@from_email` to make sure that the incoming `email in` is not from a blacklisted domain?
Or, better, check first if the user with that email address already exists. If so, let it pass. Otherwise, call `EmailValidator.validate_each` to check if it is blacklisted. **DO NOT** create a _staged_ user if the email is blacklisted.
---
### Author:  [@schungx](https://meta.discourse.org/u/schungx)
#### Post date: [20. September 2017 um 09:21 UTC](https://meta.discourse.org/t/email-domain-blacklist-with-wildcards-revisited/70088/6 "2017-09-20T09:21:56Z")
> [@Email domain blacklist is not consulted when receiving emails (and creating staged users)](https://meta.discourse.org/t/email-domain-blacklist-is-not-consulted-when-receiving-emails-and-creating-staged-users/70424):
>
> File: email/receiver.rb Func: process\_internal When an email is received, Email.Receiver only checks the following: Regexp.new(SiteSetting.ignore\_by\_title) =~ @mail.subject // Blacklisted TOPIC TITLE raise BouncedEmailError if is\_bounce? // Bounce mail raise NoSenderDetectedError if @from\_email.blank? // No From field raise ScreenedEmailError if ScreenedEmail.should\_block?(@from\_email) // Screend Email address After this, a new staged user is created via find\_or\_create\_user. The res…
Created bug report. Hope I got it right. 😁