Custom Rules
Question asked by Scarab - November 20, 2014 at 12:49 PM
Answered
We get a lot of Spam that is from .link, .mobi, .in, and .pw domains and setup Custom Rules as follows:
 
Rule Source: Header
Header: Return-Path:
Rule Type: Regular Expression
Weight: 10
Rule Text: *.\.link
.*\.mobi
.*\.in
.*\.pw
 
Problem is that it isn't catching any of it...so I set up a second, almost identical, Custom Rule as follows:
 
Rule Source: Header
Header: From:
Rule Type: Regular Expression
Weight: 10
Rule Text: *.\.link
.*\.mobi
.*\.in
.*\.pw
 
And still nothing is caught.
 
What am I doing wrong with my rules? I know my REGEX is solid and suspect that I'm doing something wrong with the value in the HEADER field (or do I maybe need to account for angled brackets around the email address in the Rules Text?). Anyone have any helpful hints or pointers?

10 Replies

Reply to Thread
2
Scarab Replied
Marked As Answer
I'm beginning to understand why SmarterTools staff is always silent on the subject of Custom Rules in SmarterMail. It is very finicky. After some experimentation I got my rules to work 100% of the time with the following alterations:
 
Rule Source: Header
Header: Return-Path
Rule Type: Regular-Expression
Weight: (variable based upon your Low/Med/High weights)
Rule Text: .+\.link>$
.+\.mobi>$
.+\.in>$
.+\.pw>$
.+\.rocks>$
.+\.science>$
.+\.work>$
.+\.ninja>$
.+\.cricket>$
.+\.click>$
.+\.party>$
.+\.tk>$
(et cetera for each top-level domain you want to catch)
 
Using .+ instead of .* shouldn't make too much of a difference, but can in some unique circumstances, but the important missing piece was the ending > before the end of the string $. Not sure why it would work sometimes without with ending > and not other times, but I was able to confirm that was the problem.
 
The other thing to note is do not put a : at the end of your Header field as the Custom Rules assumes a : and putting one in that field will result in it never matching (as it will be looking for Return-Path::). 
 
The same RegEx above should work with the From or Return-Path fields if you would prefer using those.

Hope this saves someone else some head-scratching frustration in the future.
1
Bruce Barnes Replied
We are successfully trapping all of the new domains listed via our antispam settings.
 
See: SmarterMail Antispam Settings Document for the most current release of the document.
 
We have ZERO false positives.  When a new spammer comes along, we might see a couple of spam messages from them, but the several databases we run are quickly updated.
 
NOTE: These settings only work if you have all of them properly set - exactly as outlined in the document, IE:
  • point to your own DNS servers - NOT Google or other busy public servers.
  • do not allow users to override any of the antispam settings, and
  • have greylisting setup - not allowing users to disable the greylisting settings.
In every case where I have been asked to troubleshoot, there were external antispam tools setup, which modified the SmarterMail spam settings scores, the greylisting had not been enabled, or the users were allowed to modify their own antispam settings - overriding the master antispam settings.
 
Allowing users to have input in spam settings is only asking for support headaches.
Bruce Barnes
ChicagoNetTech Inc
brucecnt@comcast.net

Phonr: (773) 491-9019
Phone: (224) 444-0169

E-Mail and DNS Security Specialist
Network Security Specialist

Customer Service Portal: https://portal.chicagonettech.com
Website: https://www.ChicagoNetTech.com
Security Blog: http://networkbastion.blogspot.com/

Web and E-Mail Hosting, E-Mail Security and Consulting
0
Jay Mather Replied
Scarab. Just stumbled across your post here and really grateful for the solution you posted. Last few weeks have seen a massive rise in .top domains sending all sorts of nonsense. SPF was passing and SPAM score was a solid zero in every case! Bayesian Filtering seems helpless against this lot for some reason. Anyway, never been quite sure why SmarterMail doesn't just have a top-level domain-default option for blocked sending domains, but your solution looks like it may well work for us. Nice one.
0
David Jamell Replied
I'm running SM 15.5.6222 and cannot for the life of me figure out how to make this work.  None of the variations seem to match anything.  I've seen similar threads about custom rules and I think I tried everything.
 
Is there a bug, or am i just doing something wrong?
 
 
0
Rod Lasky Replied
Employee Post
David, I just tried this in the same version, and my custom rule did score a test@test.mobi test message with a 999.

Rule Source: Header
Header: Return-Path
Rule Type: Regular-Expression
Weight: 999
Rule Text: .+\.mobi>$
Rod Lasky
Technical Support Specialist
SmarterTools Inc.
(877) 357-6278
www.smartertools.com
0
Rod Lasky Replied
Employee Post
Hi David. Another thought. You could use SMTP blocking as well. Go to Security >> Advanced Settings >> SMTP Blocking. Add an incoming email address block and enter: "*.TLD" (without the quotes)
Rod Lasky
Technical Support Specialist
SmarterTools Inc.
(877) 357-6278
www.smartertools.com
0
David Jamell Replied
Yes, Rod, I've been using the STMP Blocking for some time. But was intrigued by the possibility of blocking by Reply-To and Return-Path in addition to From.

Or does SMTP Blocking also block Reply-To and Return-Path?

Thanks again Rod.

0
Rod Lasky Replied
Employee Post
David. No, SMTP blocking would just look at the sending domain in this example. But again, I was able to use Custom Rules against the Return-Path without issue using my example above.
Rod Lasky
Technical Support Specialist
SmarterTools Inc.
(877) 357-6278
www.smartertools.com
0
David Jamell Replied
Hi Rod - This does seem to be working. Just had to wait for the right messages to come through.

Thanks again for your replies.
0
If I wanted to catch all instances of a word (sender name) in the return path would the structure for SM be such as .+\nastyword\.+$ ? I'm looking to catch it regardless of the domain. I just am not clear on the syntax for wildcard-word-wildcard-end of string, etc. Sorry, I'm a regex nube. :). It may very well be \^nastyword\.+ for example or /^nastyword/.+ ...Not sure as the examples I have been looking at all show forward slashes. Does it matter to SM?

Reply to Thread