You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The benefit here is that with large websites, spammers target you quite often, and so if you need to commit and push an updated config/blacklisted_email_domains.yml every time, it's going to be quite painful. By having the default be the same, but being able to override the default to be more dynamic, you can have perhaps have the best of both worlds.
The text was updated successfully, but these errors were encountered:
Great idea!
What do you think about letting the proc take the models domain as an argument and not only return a enumurable of blocked domains but also return true or false.
Then you can let the database do the heavy lifting instead of loading a huge list into the applications memory.
Hey there,
I've used this library quite a few times in the past, and even initially suggested the MX spam lookup trick (#95)
It's now a few years later, and I have a new suggestion -- allowing the
blacklist
/whitelist
option to take an array vs a boolean.E.g. right now we can do:
But it would be really cool if we could do:
This could then be used to support things like AR models, e.g.
The benefit here is that with large websites, spammers target you quite often, and so if you need to commit and push an updated
config/blacklisted_email_domains.yml
every time, it's going to be quite painful. By having the default be the same, but being able to override the default to be more dynamic, you can have perhaps have the best of both worlds.The text was updated successfully, but these errors were encountered: