regex
Re: regex
Only wildcards (* and ?) are supported, e.g. *@yahoo.com ... I haven't come up with a practical example for '?' but e.g. ?@yahoo.com would catch all the single-character usernames... 
(fyi, this should have been mentioned in the help, so it has now been added).
You can easily blacklist domains from the main interface. e.g. from the message list, right-click: AntiJunk -> Blacklist -> blacklist domain (or the same menu tree is available from the "antijunk" menu when viewing a message).
If that doesn't support what you want to do, you can use RegEx using rules. But if that's the case, let me know your specific scenario in case it can be incorporated.
(fyi, this should have been mentioned in the help, so it has now been added).You can easily blacklist domains from the main interface. e.g. from the message list, right-click: AntiJunk -> Blacklist -> blacklist domain (or the same menu tree is available from the "antijunk" menu when viewing a message).
If that doesn't support what you want to do, you can use RegEx using rules. But if that's the case, let me know your specific scenario in case it can be incorporated.
Re: regex
Here are some screenshots.
On first you can see the pattern @(one letter)(random numbers).us
Second image @(word)(two numbers).fr or .com
And I have a bunch of this kind of domains and I have to blacklist each day some of them.
On first you can see the pattern @(one letter)(random numbers).us
Second image @(word)(two numbers).fr or .com
Windows 10 64 bits
Re: regex
Gotcha. Yeah, you would need full-on regex to capture those patterns. So I would suggest just creating a rule. You could either:
- Create a single "rule set" containing multiple rules, one for each type of pattern
or
- Create a separate "rule set" for each pattern
The first would be better contained, but the second would make it easier to find which regex is the culprit in the event of a false positive.
I noticed that most of your highlighted email addresses didn't have any "hits" which indicates that the spammers aren't re-using them (but if they continue to re-use the "pattern", then the time to create the rule is probably worthwhile). However, what I found more interesting is that the domains in the respective groups that you highlighted share the same IP address. In fact, initially, I thought that the "bleue22" (.com) didn't fit the pattern of the others (.fr). But, in fact, they all have the same ip address (except for bol77, which doesn't resolve to anything). Presumably, those IP addresses would be in the "received" headers that the DNSBL filter processes. I'm thinking out loud here, but I don't know how practical it would be to provide the user with the capability to manually include specific IP addresses to be flagged by the DNSBL (ie. how many people are going to get the IP address, see how many times it's been used in spam, and then blacklist the IP). If the process was automated (based on whether the user marks such messages as junk or legit), then it might be more interesting...
- Create a single "rule set" containing multiple rules, one for each type of pattern
or
- Create a separate "rule set" for each pattern
The first would be better contained, but the second would make it easier to find which regex is the culprit in the event of a false positive.
I noticed that most of your highlighted email addresses didn't have any "hits" which indicates that the spammers aren't re-using them (but if they continue to re-use the "pattern", then the time to create the rule is probably worthwhile). However, what I found more interesting is that the domains in the respective groups that you highlighted share the same IP address. In fact, initially, I thought that the "bleue22" (.com) didn't fit the pattern of the others (.fr). But, in fact, they all have the same ip address (except for bol77, which doesn't resolve to anything). Presumably, those IP addresses would be in the "received" headers that the DNSBL filter processes. I'm thinking out loud here, but I don't know how practical it would be to provide the user with the capability to manually include specific IP addresses to be flagged by the DNSBL (ie. how many people are going to get the IP address, see how many times it's been used in spam, and then blacklist the IP). If the process was automated (based on whether the user marks such messages as junk or legit), then it might be more interesting...
Searching for "regex" does find the result in "Rules."
Re: regex
I think that, in the cases that you've highlighted, it's an exercise in futility to blacklist each domain because the spammer isn't re-using the same domains. You've found the pattern, so as long as you know how to express it in regex, I think it is worthwhile to add them as Rules.
The black/whitelists are basically dumbed-down versions of what Rules are capable of. Yes, they're more convenient, but what you're needing to do can't be done conveniently
Also, Rules will allow you to test your regex to make sure they're catching what you expect and not catching things it shouldn't.
The black/whitelists are basically dumbed-down versions of what Rules are capable of. Yes, they're more convenient, but what you're needing to do can't be done conveniently
Also, Rules will allow you to test your regex to make sure they're catching what you expect and not catching things it shouldn't.Re: regex
You're using the wrong escape character -- you're using forward-slash instead of backslash.
Use this instead:
- tested and matched on your sample email address.
Also, for future reference, you can copy/paste the rule set (I didn't use it above so that you could see what I changed). View the rule and from the menu, select Edit / Copy rule set; then paste it in here (preferrably in a code block). This allows us to easily access what you're using without the possibility of typos.
Use this instead:
Code: Select all
[a-z]*@[a-z][0-9]{3}\.[a-z]*\.usAlso, for future reference, you can copy/paste the rule set (I didn't use it above so that you could see what I changed). View the rule and from the menu, select Edit / Copy rule set; then paste it in here (preferrably in a code block). This allows us to easily access what you're using without the possibility of typos.