Regex for the AntiSpam block lists

I can not find any docs on using regex's for block lists, other than it is possible, nor do any of the common styles of regex work.

In Perl regex style, I want to ban these domains: /.*\.info\.pl/
How do I describe this in this module?

It doesn't support regex. The description doesn't say it does. To block a domain you need to set the block type to Email Domain then supply the domain as info.pl.

I get infinite variations of subdomain for the domain info.pl ("aa.info.pl", "bb.info.pl", etc..) and these can currently only be caught if the entire email domains "aa.info.pl", "bb.info.pl" ad nauseum are defined. This is one example case, I have attackers who use this subdomain obfuscation trick on other domains too.

What prevents you from using a regex comparisson in MySQL instead of a direct string comparisson?

The way it works is it splits by @ and takes the second half (domain) and checks the blocks database table to see if the domain has been blocked. If it has it'll block it.

What prevents you from using a regex comparisson in MySQL instead of a direct string comparisson?

It's slow. It can't be indexed. The regexp has to be MYSQL formatted, not PHP formatted, which makes it subject to massive user error (e.g. your regex above would not work; MYSQL doesn't need delimiters and you need to double backslash). Would entirely break B/C (the current usage would not work 1:1 if it was changed to regex). There's many more reason why it's not using REGEX to do the matching.

The best way to support what you're wanting is to change the matching from being done in the query to being done PHP side, which will slow it down, but it eliminates the problems above. The problem with this is I'd need to completely rewrite most of the blocking behavior. I've added a feature ticket for this, but no idea when I'll get around to implementing it as at this time CB Activity and GJ have my focus.

forge.joomlapolis.com/issues/5263

I appreciate the complexity and unintended side effects of implementing something like this.

A compromise might be to compare on a MySQL 'like' (using wild card markers '*' on the UI and replacing with '%' at query time). Not too bad on indexing and far less prone to user error. Even that would solve the problem that I have!